Versionsprobleme mit oopo's Tool Chain

[jochen]

Hi,

Ich habe mir die Toolchain von Oopo (gp2xdev-20060525.tar.bz2) zur Portierung einiger Programme ausgesucht. Runterladen und Durchkompilieren funktionierte einwandfrei unter Ubuntu Dapper.

Mir kam es gleich schon komisch vor, dass z.B, die glibc in Version 2.3.5 benutzt wird, da im GP2X doch 2.2.5 installiert ist. Kann doch nicht gut gehen. Und es geht nicht gut.

Schon ein winziges Programm, das tolower() (aus ctype.h) aufruft und mit -O2 übersetzt wird bringt beim Ausführen den Fehler, dass GLIBC_2.3 fehlt. Ist auch klar, denn beim Optimieren wird statt eines direkten Aufrufs von _tolower() ein Macro übersetzt, das widerum __ctype_tolower_loc() aufruft. Und diese Funktion existiert erst ab Version 2.3.

Während man so ein Miniprogramm noch durch kompilieren mit -static zum Laufen bringt (allerdings wird dann aus dem 3KB Programm ein 500KB Programm) ist das keine Lösung für große Programme. Neben allen Nachteilen statischer Bibliotheken kann man Probleme mit der libprthread so gar nicht in den Griff bekommen.

Noch andere Teile der Toolchain benutzen Versionen, die so auf dem GP2X nicht installiert sind.

Nun die Frage, was man machen soll? Andere Toolchain? Warum wird dann überall diese referiert (z.B. im Wiki). Oder gibt es eine völlig neue Linux Version für den GP2X mit Kernel 2.16 und glibc 2.3.5 usw. auf die ich noch nicht gestossen bin?

Vielen Dank für jede Hilfe,

Jochen

 

[dedeibel]

Benutze auch die Toolchain und konnte noch keine Probleme feststellen, soweit ich weiß ist sie auch dazu gedacht mit -static benutzt zu werden.

Vor allem weil der neue gcc eine viel besseren floating point code ausspuckt denke ich ist ein wenig mehr Platzverbrauch zu ertragen. Ansonsten müsste man wohl zu ner anderen toolchain greifen.

 

[jochen]

Grundsätzlich ist gegen statisches Linken der Programme, die SDL benutzen nichts zu sagen - es läuft sowieso immer nur eins zu jeder Zeit. Da ist der zusätzliche Speicherverbrauch nicht relevant, nur die Startzeit des Programms kann etwas geringer sein, da die Bibliotheken jedesmal wieder relociert werden müssen.

Anders ist es natürlich bei Daemons (z.B. Samba). Diese sollten auf einem embedded System einen möglichst kleinen Memory Footprint haben. Daher wäre statisches Linken hier völlig fehl am Platz.

Außerdem bin ich schon auf ernsthafte Probleme gestossen. Ich habe versucht E-UAE zu übersetzen. Das Compilieren und Linken klappt auch soweit. Aber bei statischem Linken bricht das Programm nach dem Start sofort mit Speicherfehlermeldungen ab (angeblich schon beim Laden der shared libraries, die aber gar nicht benutzt werden sollten). Wenn nur Teile der Bibliotheken statisch gelinkt werden (z.B. glibc und pthread) dann kommt es zu Segemtation Faults. Vielleicht kann ich ja aber noch was an der Konfiguration drehen...

Ich es sehr begrüßen, wenn es für den GP2X ein vollständiges Flash auf Basis von OpenEmebedded mit allen akuellen Libs gäbe. Dann wäre man denn ganzen Ärger los. Allerdings könnte das für alle Windows Entwickler etwas aufweniger werden.

 

[Elektranox]

/me benutzt ebenfalls oopos Toolchain und keine -static Option -> geht!