native GCC Development-Environment

Was gibts neues rund um die Pandora?
Autor
Nachricht
jilse
6 Bit
Beiträge: 78
Registriert: So Jan 24, 2010 19:27

native GCC Development-Environment

#1 Beitrag von jilse » Fr Mär 11, 2011 12:40

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.

Benutzeravatar
Atomos
6 Bit
Beiträge: 72
Registriert: Do Sep 11, 2008 08:28

Re: native GCC Development-Environment

#2 Beitrag von Atomos » Fr Mär 11, 2011 12:43

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

romsom
3 Bit
Beiträge: 15
Registriert: Sa Mär 21, 2009 14:33

Re: native GCC Development-Environment

#3 Beitrag von romsom » Fr Mär 11, 2011 17:20

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
6 Bit
Beiträge: 68
Registriert: Do Jul 10, 2008 18:58

Re: native GCC Development-Environment

#4 Beitrag von Karotte » Sa Mär 12, 2011 11:52

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

Benutzeravatar
Screeny
11 Bit
Beiträge: 3903
Registriert: Di Okt 14, 2008 18:48
Wohnort: Wiesbaden

Re: native GCC Development-Environment

#5 Beitrag von Screeny » Sa Mär 12, 2011 12:08

Karotte hat geschrieben: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!
Neues Projekt: Cosvalley.de - Deine Cosplaycommunity

b3w
7 Bit
Beiträge: 213
Registriert: Di Dez 13, 2005 22:56

Re: native GCC Development-Environment

#6 Beitrag von b3w » Sa Mär 12, 2011 13:02

Screeny hat geschrieben:
Karotte hat geschrieben: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

Benutzeravatar
ivanovic
8 Bit
Beiträge: 403
Registriert: Fr Aug 04, 2006 14:57
Kontaktdaten:

Re: native GCC Development-Environment

#7 Beitrag von ivanovic » Sa Mär 12, 2011 17:17

Karotte hat geschrieben: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.

Benutzeravatar
johnnysnet
9 Bit
Beiträge: 989
Registriert: So Dez 17, 2006 12:59
Wohnort: Leipzig
Kontaktdaten:

Re: native GCC Development-Environment

#8 Beitrag von johnnysnet » Sa Mär 12, 2011 18:21

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.
"If I arrange to have just one cross-bar in my machine, it revolves very slowly, just as if it can hardly turn itself at all, but, on the contrary, when I arrange several bars, pulleys and weights, the machine can revolve much faster"

Benutzeravatar
ivanovic
8 Bit
Beiträge: 403
Registriert: Fr Aug 04, 2006 14:57
Kontaktdaten:

Re: native GCC Development-Environment

#9 Beitrag von ivanovic » Sa Mär 12, 2011 19:44

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
6 Bit
Beiträge: 78
Registriert: So Jan 24, 2010 19:27

Re: native GCC Development-Environment

#10 Beitrag von jilse » So Mär 13, 2011 11:25

jilse hat geschrieben: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- ... 17.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:

Code: Alles auswählen

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 --
jilse hat geschrieben:
jilse hat geschrieben: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
7 Bit
Beiträge: 213
Registriert: Di Dez 13, 2005 22:56

Re: native GCC Development-Environment

#11 Beitrag von b3w » Do Mär 31, 2011 16:42

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
6 Bit
Beiträge: 78
Registriert: So Jan 24, 2010 19:27

Re: native GCC Development-Environment

#12 Beitrag von jilse » Do Mär 31, 2011 16:52

b3w hat geschrieben: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.
b3w hat geschrieben: 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:

Code: Alles auswählen

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
7 Bit
Beiträge: 213
Registriert: Di Dez 13, 2005 22:56

Re: native GCC Development-Environment

#13 Beitrag von b3w » Do Mär 31, 2011 17:01

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

Code: Alles auswählen

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
6 Bit
Beiträge: 78
Registriert: So Jan 24, 2010 19:27

Re: native GCC Development-Environment

#14 Beitrag von jilse » Mo Apr 11, 2011 15:19

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

Code: Alles auswählen

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- ... 11.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.

T4b
10 Bit
Beiträge: 1703
Registriert: Fr Okt 16, 2009 13:29
Wohnort: Confoederatio Helvetica
Kontaktdaten:

Re: native GCC Development-Environment

#15 Beitrag von T4b » Fr Apr 29, 2011 12:09

Super. :-)

Funktioniert bisher wunderbar.
... wenn ich mich nicht täusche. ;)

T4b

Allergikerhinweis: Dieser Beitrag kann Spuren* von Ironie enthalten.
* "Spuren" heisst zwischen 0% und 100%.

Antworten

Zurück zu „Pandora - News“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste