Verstaendnisfrage Crosscompiling

[rudi_m]

Hi,
Ich hab seit vorgesten hier eine Dbox2 rumstehen und versuche mich nun daran selbst Programme dafuer zu kompilieren.

Dazu hab ich mir das cdk aus dem tuxbox-cvs installiert und bekomme auch einfache C-Programme auf der Box zum laufen indem ich den cdk/bin/powerpc-tuxbox-linux-gnu-gcc direkt aufrufe.

Nur bei groesseren Paketen (die mit dem klassischen ./configure && make compiliert werden) fehlt mir das cross compiling Verstaendnis
Wie bekomme ich einem standard "configure" beigebracht das cdk zu benutzen (ohne gcc, libs, etc. vom buildhost zu verwenden)

es gibt ja z.B die configure option
--host=HOST cross-compile to build programs to run on HOST [BUILD]

Aber dazu muss sicher das cdk irgendwie global auf dem BuildHost installiert sein!?
Hat jemand eine idee wie das geht oder wo es ne gute Einfuehrung zum lesen gibt?


(Fall es interessiert. Ich moechte Glucas fuer DBox2 kompilieren
http://www.oxixares.com/glucas/

Mlucas hab ich schon zum Laufen bekommen
ftp://hogranch.com/pub/mayer/src/C/Mluc ... .04.tar.gz
mittels
powerpc-tuxbox-linux-gnu-gcc -o Mlucas *.c -lm --static)

[Npq]

Das mit dem --host ist schon richtig, das CDK macht es dann so, daß es die Cross-Tools bzw. Config-Skripte (gcc, binutils, pkgconfig-Daten etc.) in den Pfad legt. Das kann man natürlich auch selber machen. Die Namen sind eindeutig (durch die kanonische Systemangabe "powerpc-tuxbox-linux-gnu"), so daß hier keine Verwechslungsgefahr besteht. Am sinnvollsten ist es sicherlich, einen eigenen Benutzer dafür anzulegen, dann kann man die Pfade bei diesem nach belieben anpassen.

Absolut problemlos wird es aber wohl nur in wenigen Fällen laufen. Libtool zum Beispiel ist ein hartnäckiger Gegner, bei dem man oft noch Hand anlegen muß.

Am besten ist sicher, du nimmst das Package-Build-System des CDK selber. Link dazu:

http://cvs.tuxbox-cvs.sourceforge.net/c ... iew=markup
http://cvs.tuxbox-cvs.sourceforge.net/c ... iew=markup

[Npq]

Hmm, ich habe jetzt nur mal einen kurzen Blick drauf geworfen, bei number crunchern ist noch zu sagen, daß die dbox2-CPU keine Hardware-FPU besitzt, so daß alle Gleitkommaoperationen in Software emuliert werden müssen.

Wundere dich also nicht, wenn es extrem langsam wird (kommt natürlich auf den Grad der Optimierung bzw. den Code an).

[rudi_m]

Ok das ging wirklich so einfach
export PATH=/path/to/cdk/bin:$PATH
./configure --host=powerpc-tuxbox-linux-gnu --enable-static
(nur statisch wars dann doch nicht gelinkt - da musste ich noch Hand anlegen)

Kann man nun aber wirklich sicher sein dass keine i386 libs des BUILD hosts ins binary gelinkt werden?

Das Mlucas binary laeuft erstmal an, aber irgendwann kommt dann
FATAL: iter = 63; nonzero exit carry in radix16_ditN_cy_dif1.
FATAL: iter = 10; nonzero exit carry in radix16_ditN_cy_dif1.

Da muss ich wohl mal den Autor fragen.

Hmm, ich habe jetzt nur mal einen kurzen Blick drauf geworfen, bei number crunchern ist noch zu sagen, daß die dbox2-CPU keine Hardware-FPU besitzt, so daß alle Gleitkommaoperationen in Software emuliert werden müssen.

Wundere dich also nicht, wenn es extrem langsam wird (kommt natürlich auf den Grad der Optimierung bzw. den Code an).

Hehe, so ein LL test dauert schon auf ner aktuellen CPU einige Wochen. Ich suche noch nach einer interessanten Aufgabe, die die DBox2 in anehmbarer Zeit (< 1Jahr) nebenbei loesen koennte- just for fun

Glucas braucht leider zuviel RAM - auch wenn Neutrino aus ist:(
initnumfactg: No memory to alloc trig. factors

Aber ich bin mal wieder fasziniert von Linux - trotz 100% CPU last von Mlucas lief der mp3 Player anstandlos und auch sonst war das auf dem TV nicht zu bemerken!

[Npq]

Kann man nun aber wirklich sicher sein dass keine i386 libs des BUILD hosts ins binary gelinkt werden?

Ja, in dem Fall schlägt der Linkversuch direkt fehl (der ELF-Header enthält ja die Architektur).