native GCC Development-Environment

[jilse]

Hallo,

ich bin gerade dabei, mir ein solches basierend auf gcc4.5.2 (neueste stable GCC-Version),
neuestens binutils, aktuellste libelf, libgmp, libmpfr, libmpc und ansonsten Libraries ueber-
nommen aus dem Cross-Development-Environment zu basteln. Allerdings zieht sich das
compilieren etwas hin (und einige kleinere Problemchen hatte ich zwischendurch dabei
auch) ... Besonders das uebersetzen des gcj-Environments benoetigt erheblich Resourcen.
Weil das ganze ueber SD-Karten doch alles sehr langsam geht, habe ich sowohl die Sourcen
als auch das Filesystem fuer das Ergebnis und das fuer das compilieren sowie Swapspace
ueber Netz gemountet (nicht WLAN sondern Kabelgebundenes ethernet mit einem USB-
to-Ethernet-Adapter). Gegenueber der Nutzung der SD-Karten ist das so teilweise um
bis zu Faktor 10 schneller ...

Wenn ich den Kram fertig habe, werde ich ein tar-Ball davon (der nach /usr/local entpackt
werden muesste) zum Download bereitstellen (auf /usr/local muesste man vorher ein hin-
reichend grosses Filesystem mounten, ich vermute, im Endeffekt koennten so um die 2GB
benoetigt werden ...). Unterstuetzte Sprachen in dem Paket (sofern alles glatt geht):
c, c++, objc, obj-c++, fortran, java und Support fuer "lto" ("link time Optimization").

Ausserdem bin ich z.Zt. daran, ein PND fuer "Blockout2" zu bauen (ich kenne das
Spiel Blockout noch aus der "MSDOS" Zeit und habe es schon damals gern gespielt).
Ausserdem habe ich noch vor, ein in eienr aelteren Version der Sprache "OCAML"
geschriebenes Spiel als PND zu bauen (dafuer muss ich dann aber erst einmal OCAML
auf der Pandora bauen, und der Versuch, das mit dem Cross-Development hinzubekommen
ging im ersten Versuch schief, was mich dazu gebracht hat, ein native Development
Environment bauen zu wollen ...).

Ich denke, im Laufe der naechsten Woche werde ich die ersten Downloads dieser
Projekte berit stellen koennen.

 

[Atomos]

Das hört sich sehr gut an, ich bin schon gespannt! :juhu:

 

[romsom]

Ausserdem bin ich z.Zt. daran, ein PND fuer "Blockout2" zu bauen (ich kenne das
Spiel Blockout noch aus der "MSDOS" Zeit und habe es schon damals gern gespielt).

Sehr schön, Blockout hat ungemeinen Suchtfaktor
Übrigens: Schon 'mal das Orginal mir Dosbox ausprobiert? Läuft hervorragend und sieht auch spitze aus - Stichwort native Auflösung. Die Tasten sollte man allerdings sinnvoll belegen.

 

[Karotte]

Das wäre echt super. Meine Image wird (dank Hotfix 5?) immer unbrauchbar, sobald ich mit opkg etwas installiere.

 

[Screeny]

Das wäre echt super. Meine Image wird (dank Hotfix 5?) immer unbrauchbar, sobald ich mit opkg etwas installiere.

Du musst darauf achten, was du mit opkg installierst. Abhängigkeiten beachten!

 

[b3w]

Das wäre echt super. Meine Image wird (dank Hotfix 5?) immer unbrauchbar, sobald ich mit opkg etwas installiere.

Du musst darauf achten, was du mit opkg installierst. Abhängigkeiten beachten!

Das Problem ist etwas spezieller. Alte Anleitungen von DJWillis sind mitlerweile nutzlos und das Wiki verweist momentan auch nur noch auf die Crosscompiler

 

[ivanovic]

Das wäre echt super. Meine Image wird (dank Hotfix 5?) immer unbrauchbar, sobald ich mit opkg etwas installiere.

Mit opkg Sachen installieren kannst du vergessen, da angstrom und die Pandora version vom OS einfach zu unterschiedlich sind in sachen Abhängigkeiten und verlinkten libs.

 

[johnnysnet]

Das ist ja wirklich gut, dies mal zu erfahren, denn auch ich bin schon Opfer dieser opkg Misere geworden und durfte mir das OS neu flashen. Dann war es im Prinzip ein Fehler, diesen Paketmanager im System zugänglich zu belassen. Aber vielleicht ist das schon wieder zu viel Spekulation.

 

[ivanovic]

Nein, es ist einfach ein Fehler einen Paketmanager ohne extra nachdenken zu verwenden. So könnte es evtl funktionieren, wenn man erst ein "upgrade" laufen lässt, bevor man neues installiert, aber selbst das kann alles zerstören. Generell ist der Paketmanager erstmal für jene, die wirklich wissen, was sie machen...

 

[jilse]

Hallo,

ich bin gerade dabei, mir ein solches basierend auf gcc4.5.2 (neueste stable GCC-Version),
neuestens binutils, aktuellste libelf, libgmp, libmpfr, libmpc und ansonsten Libraries ueber-
nommen aus dem Cross-Development-Environment zu basteln. Allerdings zieht sich das
compilieren etwas hin (und einige kleinere Problemchen hatte ich zwischendurch dabei
auch) ... Besonders das uebersetzen des gcj-Environments benoetigt erheblich Resourcen.

Update:

So, der Kram ist jetzt fertig. Ich habe das als bzip2-gepacktes tar-archiv (ist aber immer noch ueber 500MB gross) hier bereit gestellt:

http://kimu.usenet-verwaltung.de/devel-pandora-native-20110317.tar.bz2

Um das Zeug zu benutzen, sollte man das Archiv in / auspacken (der Kram landet dann in /usr/local, wo man genuegend freien Platz, sprich mindestens 2,5 GB, haben sollte). Und nicht vergessen, das Verzeichnis /usr/local/lib in den LD_LIBRARY_PATH aufzunehmen, also:

<i>
</i>LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib
export LD_LIBRARY_PATH

in der shell ausfuehren, von der aus man den Compiler aufrufen moechte ...

Neben dem gcc-4.5.2 (mit Support fuer so ziemlich alle unterstuetzten Sprachen ausser Ada) ist auch noch eine aktuelle libgmp, libmpfr, libmpc, ppl, autoconf, aktuelle binutils, flex, bison, ... mit in dem Archiv. ausgepackt sind es ca. 2,5GB. Wer es ausprobieren moechte: viel Spass. Fuer Kommentare, Anregungen, etc. bin ich natuerlich ebenfalls offen, also schreibt ruhig eure Meinung dazu.

Ach ja: beim uebersetzen der Java-Libraries hat der Compiler ziemlich Resourcen gebraucht, da waren auch mal ueber 300 MB Swap in Gebrauch (und /var/tmp habe ich dazu dann auch von der Ramdisk auf ein Device mit mehr Platz verlegen muessen, damit das durchlief). Also rechnet damit, dass manches evt. doch relativ viel Resourcen brauchen koennte und man ggfs. /var/tmp auf ein grosses Massenspeicherdevice verlegen und dort auch evt. ein paar hundert MB Swap bereitstellen sollte ...

-- Sa Mär 19, 2011 15:39 --

Hallo,

ich bin gerade dabei, mir ein solches basierend auf gcc4.5.2 (neueste stable GCC-Version),
neuestens binutils, aktuellste libelf, libgmp, libmpfr, libmpc und ansonsten Libraries ueber-
nommen aus dem Cross-Development-Environment zu basteln. Allerdings zieht sich das
compilieren etwas hin (und einige kleinere Problemchen hatte ich zwischendurch dabei
auch) ... Besonders das uebersetzen des gcj-Environments benoetigt erheblich Resourcen.

Update:

Irgendwo ist mir beim zusammenpacken von dem Kram ein Fehler unterlaufen (waehrend des einen oder anderen crashes waehrend des ganzen Build-Vorgangs sind wohl auch ein paar shared libraries beschaedigt worden ...). Ausserdem sind wohl einige C++-Header verloren gegangen ...

Da ich aber gelesen habe,das (auch gerade fur ARM) die momentane Development-Version von gcc-4.6.0 einige Vorteile biete, baue ich den Kram eben nochmal, aber mit neuerer GCC-Version.

Ich habe dann auch noch ein paar andere Goodies, die ich mit dazu packen werde (u.a. der neue Support fuer die Sprache "go", libppl, libcloog und evt auch schon guile und ocaml).

Ich werde daher den bisherigen tarball vom Server entfernen und in ein paar Tagen durch den aktualisierten ersetzen ...

 

[b3w]

Lange Zeit habe ich die Aktualisierung dieses Threads übersehen.

Handelt es sich in der Verlinkung nun um die gefixte Version? Oberflächlich habe ich die Umgebung kurz getestet. Zuerst fehlte cc, habe dieses mit gcc verlinkt und bekam dann eine Fehlermeldung zu libmpc.

Eigentlich wollte ich Vorbereitungen treffen, eine fehlerbereingte Version von jumanchi, nach dem Vorbild der aktuellen Midori PNDs herauszubringen, da jumanchi das gleiche, fehlerhafte Rendering wie die Midori Version aus der Firmware hat. Auf der anderen Seite stellt sich die Frage nicht, da in einer Debian, vielleicht auch Arch Umgebung, diese Probleme nicht auftreten und das Kompilieren fehlerfrei verläuft. Aber irgendwer hat jumachi im Wiki eingetragen und bei einem Filehoster hochgeladen. Die fehlerhafte Version tut dem eigentlichen Programm unrecht und das wurmt mich schon.

 

[jilse]

Lange Zeit habe ich die Aktualisierung dieses Threads übersehen.
Handelt es sich in der Verlinkung nun um die gefixte Version?

Nein, noch nicht. Ich hatte ein bischen viel zu tun und bin daher noch nicht dazu gekommen.
sie ist in Arbeit und ich werde mich auf jeden Fall melden, wenn ich eine gefixte Version (dann
auch mit gcc-4.5.2 sowie gcc-4.6.0) dort liegen habe.

Oberflächlich habe ich die Umgebung kurz getestet. Zuerst fehlte cc, habe dieses mit gcc
verlinkt und bekam dann eine Fehlermeldung zu libmpc.

Ich schrieb in der Ankuendigung, dass man darauf achten solle, /usr/local/lib in den
LD_LIBRARY_PATH aufzunehmen. Also:

<i>
</i>LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib
export LD_LIBRARY_PATH

oder irgend etwas dergleichen in der shell eingeben, von der aus man das benutzen moechte,
und zwar *vor* dem Aufurf des compilers (dann werden auch die shared libraries fuer gmp,
mpfr und mpc gefunden, die alle notwendig sind aber auch in /usr/local/lib vorliegen).

 

[b3w]

Ich schrieb in der Ankuendigung, dass man darauf achten solle, /usr/local/lib in den
LD_LIBRARY_PATH aufzunehmen. Also:

<i>
</i>LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib
export LD_LIBRARY_PATH

oder irgend etwas dergleichen in der shell eingeben, von der aus man das benutzen moechte,
und zwar *vor* dem Aufurf des compilers (dann werden auch die shared libraries fuer gmp,
mpfr und mpc gefunden, die alle notwendig sind aber auch in /usr/local/lib vorliegen).

Hatte ich eingetragen, bzw auch von Hand vorher eingegeben. Muss ich nochmal schauen, ob dort ein Fehler vorliegt. Danke

 

[jilse]

Ich schrieb in der Ankuendigung, dass man darauf achten solle, /usr/local/lib in den
LD_LIBRARY_PATH aufzunehmen. Also:

<i>
</i>LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib
export LD_LIBRARY_PATH

oder irgend etwas dergleichen in der shell eingeben, von der aus man das benutzen moechte,
und zwar *vor* dem Aufurf des compilers (dann werden auch die shared libraries fuer gmp,
mpfr und mpc gefunden, die alle notwendig sind aber auch in /usr/local/lib vorliegen).

Hatte ich eingetragen, bzw auch von Hand vorher eingegeben. Muss ich nochmal schauen, ob dort ein Fehler vorliegt. Danke

Ich hatte jetzt endlich Zeit gefunden, die Ankuendigung einer neuen Version in dieRealitaet umzusetzen...
Unter http://kimu.usenet-verwaltung.de/devel-pandora-native-20110411.tar.bz2 ist nun die aktuelle (neu zusammengestellte) Version zu finden. Sie enthaelt neben einer Reihe von Dateien, die vom "Cross-Development-Environment" uebernommen wurden die folgenden von mir selbst compilierten Pakete:

• autoconf-2.68
  autogen-5.9.8
  automake-1.11
  binutils-2.21
  bdwgc-7_2alpha5-20110107
  bison-2.4.3
  cloog-parma-0.16.1
  cloog-ppl-0.15.10
  ddd-3.3.12
  dstat-0.6.5
  flex-2.5.35
  gcc-4.5.2
  gcc-4.6.0
  gdb-7.2
  gmp-5.0.1
  guile-1.8.8
  libelf-0.8.13
  libiconv-1.13.1
  libtool-2.2.8
  libunistring-0.9.3
  m4-1.4.16
  make-3.82
  mpc-0.9
  mpfr-3.0.0
  openmotif-2.3.1
  pkg-config-0.25
  ppl-0.11.2
  tcl-9.4.19
  tk-8.4.19
  valgrind-3.6.1

Vieles davon habe ich nur oeberflaechlich getestet, ueber Rueckmeldungen bei Problemen waere ich also durchaus dankbar. Bei dieser Version habe ich waehrend des bauens der Software auch sowohl LD_LIBRARY_PATH als auch LD_RUN_PATH auf "/usr/local/lib" gesetzt, dadurch sollte bei dieser Version nicht mehr notwendig sein, fuer die Benutzung die Environment-Variable LD_LIBRARY_PATH zu setzen. Wie bei der alten Version auch ist das Archiv in / auszupacken (es enthaelt nur Dateien unterhalb von /usr/local). Auf /usr/local sollte ein Filesystem mit ausreichend Platz (mindestens 2,7 GB) gemountet sein, und zwar kein FAT/VFAT (weil das keine Zugriffsrechte unterstuetzt). Per Default wird gcc-4.6.0 verwendet, fuer gcc-4.5.2 muss gcc entweder mit der Option "-V 4.5.2" oder aber als armv7l-pandora-linux-gnueabi-gcc-4.5.2 aufgerufen werden. Bei den anderen unterstuetzten Sprachen funktioniert nur der Aufruf mit der Option "-V 4.5.2" wenn die alte Compilerversion gemeint ist.

Update:

Ich bin aktuell gerade dabei (nachdem es mir endlich gelungen ist, einen passenden ADA-Crosscompiler zu bauen) ein Update zusammenzustellen, dass neben den bisher unterstuetzten Sprachen auch ADA-Support (sowohl fuer gcc-4.5.2 als auch fuer gcc-4.6.0) als auch Support fuer die Sprache "D" (nur fuer gcc-4.5.2, da die entsprechenden Patches noch nicht fuer gcc-4.6.0 verfuegbar sind, ich habe den D-Compiler als "Version 2" konfiguriert, ggfs. muesste man das noch einmal aendern, wenn fuer D Version 1 mehr Bedarf bestuende ...) . Auch wollte ich noch einmal einen Versuch unternehmen, bei gcc-4.6.0 Support fuer googles Programmiersprache "go" mit einzubauen (beim letzten Versuch stiess ich dabei auf eine Fehlermeldung, aber ich habe noch eine Idee, woran es liegen koennte ...). Als naechstes werde ich dann wohl nach und nach die Libraries aus dem Cross-Development-Environment durch auf der Pandora compilierte (fuer armv7 optimierte) Versionen ersetzen (das Cross-Development-Environment ist anscheinend fuer armv5 gebaut, was wohl die Pandora nicht optimal ausnutzt auch wenn die armv5 binaries natuerlich auch auf der Pandora laufen).

Viel Spass mit dieser Version. Und fuer Kommentare (sowohl positive als auch Kritik) bin ich natuerlich dankbar.

 

[Granitehead]

Super.

Funktioniert bisher wunderbar.

 

[jilse]

Super.

Funktioniert bisher wunderbar.

Wie gesagt bin ich momentan am basteln, um auch noch Support fuer die Sprachen
D (nur fuer gcc-4.5.2) und go (nur fuer gcc-4.6.0) hinzuzufuegen, aber bisher be-
komme ich da teilweise recht seltsame Fehlermeldungen, und teils muss ich dann
den (recht langwierigen) Compilerlauf noch einmal komplett neu anstossen ...
Ich hoffe, dass das compilieren von "go" funktioniert, wenn ich zu den CFLAGS
"-D__USE_GNU=1" hinzufuege, und bei der Erstellung von "libjava" gibt es aktuell
noch einen Linker-Fehler, wenn ich das mit dem "per Crosscompiler erstellten gcc"
compiliere, also baue ich jetzt erst einmal einen gcc-4.5.2 mit Support nur fuer
C und ada, um damit dann den gcc-4.5.2 neu zu bauen (dann hoffentlich mit
Support fuer alle Sprachen und ohne Fehler), und anschliessend versuche ich
dann das neu bauen des gcc-4.6.0 mit Support fuer alle Sprachen einschliesslich
go (aber ohne D, weil das noch nicht fuer gcc-4.6.0 angepasst wurde).

 

[abc]

Da ich nicht wirklich Ahnung von GCC habe, traue ich mir mal eine (vermutlich) dumme Frage zu stellen.

Besteht die Möglichkeit nicht "einfach" auf einem PC ein ARM Binary zu erzeugen und das auf die Pandora zu deployen und eine GDB Sitzung anzustoßen?

 

[espiritu_protector]

Besteht die Möglichkeit nicht "einfach" auf einem PC ein ARM Binary zu erzeugen

Ja, die Möglichkeit besteht. Nennt sich Cross- Compiling. im englischen wiki sind einige Toolchains dafür verknüpft.

und das auf die Pandora zu deployen und eine GDB Sitzung anzustoßen?

Was ist eine GDB- Session?
Generell kann man die Programme natürlich am PC übersetzen und dann erst auf die Pandora bringen. Vorteil beim Erzeugen der Binaries auf der Pandora wäre natürlich, daß man sie besser testen kann - man hat sie ja direkt auf dem Zielsystem.

 

[abc]

GDB ist GNU Debugger, der über Sockets steuerbar ist. Aus meiner Sicht wäre es doch notwendig die eigene Software auf der Zielplattform debuggen zu können, oder? Oder denke ich da zu kompliziert?

Gruß
Matthias

 

[espiritu_protector]

Ah okay.
Ich bin kein Entwickler, deswegen kenne ich mich Debugging nicht wirklich aus.

Als fortgeschrittener Linuxer hab ich aber schon häufiger mal was gebaut.

Wenn Du selbst entwickelst und das debuggen willst kannst Du die ARM- Binaries natürlich nur auf ner ARM- Maschine laufen lassen, egal wo Du sie compiliert hast. Dein weg wäre also definitiv nicht verkehrt.
Alternativ sollte es aber auch möglich sein, das Programm erstmal auf PC für PC zu übersetzen, die gröbsten Fehler auszumerzen und erst dann ein Binary für die Pandora zu bauen.