GCC als Crosscompiler compilieren

De Kus · Beitrag von **De Kus** » 10.12.2005 01:46:16

System:
OS: Debian 3.1 AMD64 Sarge
CPU: Sempron 64
Kernel: 2.6.14.2 (keine patchs)

Compiler: gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
Binutils: v2.14

Umgebung:
CROSSDIRECTORY=/opt/crosscomp
configure und make werden entsprechend mit 'PATH=$PATH:$CROSSDIRECTORY/bin ' als prefix gestartet und mit --prefix=$CROSSDIRECTORY
Symlinks (sonst findet er gar nix):
/opt/crosscomp/i686-pc-linux-gnu/lib -> /emul/ia32-linux/usr/lib
/opt/crosscomp/lib -> /emul/ia32-linux/lib

Geschichte:
Da mir nun schon einige Anwendungen unter die Nase gekommen sind, die einfach 32bit compiliert werden müssen (zB. Cedega), wollte ich mein Compiler mal auf Crosscompiling aufmotzen. Ein komplettes chroot erscheint mir doch "leicht" übertrieben, da eine 32bit Anwendung mit entsprechenden Bibliotheken in /emul/ia32-linux auch so laufen sollte.
Also erstmal schlau gemacht was ich brauche und binutils und gcc sourcen gezogen. Nach einigem hin und her mit GCC habe ich es dann tatsächlich geschafft immerhin das compilieren und linken von GCC selbst hinter mir zu bringen, aber ganz fertig wird er leider doch nicht.

Configure Zeile:
PATH=$PATH:$CROSSDIRECTORY/bin /usr/src/gcc-4.0.2/configure --prefix=$CROSSDIRECTORY --target=i686-pc-linux-gnu --enable-languages=c --disable-threads --disable-dynamic

Kommentar zu Configure:
das mit den disable-dynamic hatte ich probiert in der Hoffnung, dass er sich was anderes wie libc.so suchen würde

. Aber glaube er hatte eh schon dynamic als nicht unterstützt erwähnt beim Hauptconfigure. Wenn ich threads nicht deaktiviere scheitert er beim Linken von gcc, weil ihm 2 header files (pthread.h und unistd.h) fehlten. C++ compilieren hatte auch Probleme gemacht, darum hab ich das erstmal ausgeschaltet, kann man ja später immer noch compileren

.

Fehlermeldungungen:

Code: Alles auswählen

make[1]: Verlasse Verzeichnis »/tmp/gcc-build/gcc«
Checking multilib configuration...
multilib.out is unchanged
Configuring in i686-pc-linux-gnu/libmudflap
configure: loading cache ./config.cache
checking build system type... x86_64-unknown-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for i686-pc-linux-gnu-strip... i686-pc-linux-gnu-strip
checking for --enable-version-specific-runtime-libs... no
checking whether to enable maintainer-specific portions of Makefiles... no
checking for i686-pc-linux-gnu-gcc...  /tmp/gcc-build/gcc/xgcc -B/tmp/gcc-build/gcc/ -B/opt/crosscomp/i686-pc-linux-gnu/bin/ -B/opt/crosscomp/i686-pc-linux-gnu/lib/ -isystem /opt/crosscomp/i686-pc-linux-gnu/include -isystem /opt/crosscomp/i686-pc-linux-gnu/sys-include
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** [configure-target-libmudflap] Fehler 1

Code: Alles auswählen

configure:2293:  /tmp/gcc-build/gcc/xgcc -B/tmp/gcc-build/gcc/ -B/opt/crosscomp/i686-pc-linux-gnu/bin/ -B/opt/crosscomp/i686-pc-linux-gnu/lib/ -isystem /opt/crosscomp/i686-pc-linux-gnu/include -isystem /opt/crosscomp/i686-pc-linux-gnu/sys-include -O2 -g -O2   conftest.c  >&5
/opt/crosscomp/i686-pc-linux-gnu/bin/ld: warning: ld-linux.so.2, needed by /emul/ia32-linux/lib/libc.so.6, not found (try using -rpath or -rpath-link)
/emul/ia32-linux/lib/libc.so.6: undefined reference to `_dl_lookup_versioned_symbol_skip@GLIBC_PRIVATE'
...
collect2: ld returned 1 exit status
configure:2296: $? = 1
configure: failed program was:
| /* confdefs.h.  */
...
configure:2335: error: C compiler cannot create executables
See `config.log' for more details.

locate ld-linux.so.2 hat geschrieben:/emul/ia32-linux/lib/ld-linux.so.2
/emul/ia32-linux/lib/tls/ld-linux.so.2
/lib/ld-linux.so.2

Frage:
wie ich bekommen Compiler der könne machen 32Bit Code?

(und sagt nu bitte nicht mit chroot, das versuche ich gerade zu vermeiden...)

gms · Beitrag von **gms** » 10.12.2005 14:43:16

Muß das umbedingt ein 3.3.5er sein. Den 3.4er kannst du per apt/aptituder installieren. Mit dem kannst du dann sowohl 32 bit als auch 64 bit compilieren. Dss ist auch kein "echter" Crosscompiler, sondern ein "normaler" Compiler der Biarch (2 ABI's) unterstützt.

Gruß
gms

P.S. Die zeiten wo man dafür ein Chroot braucht sind damit auch vorbei. Verstanden habe ich allerdings nie warum bei AMD64 nicht von anfang an Biarch unterstützt wurde. War ja damals schon eine bewährte Methode (Sparc, Powerpc,)

[edit]
Ich habe dir noch einen Thread rausgesucht, damit du siehst, daß es mit dem 3.4er funktioniert:
http://www.debianforum.de/forum/viewtop ... highlight=
[/edit]

De Kus · Beitrag von **De Kus** » 11.12.2005 01:04:20

De-Kus:/home/dekus# apt-get install gcc-3.4-base gcc-3.4
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut... Fertig
gcc-3.4-base ist schon die neueste Version.
gcc-3.4 ist schon die neueste Version.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
De-Kus:/home/dekus# gcc --version
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)

De-Kus:/home/dekus# apt-get remove gcc-3.3 gcc-3.3-base gcc-3.3-doc
...
0 aktualisiert, 0 neu installiert, 245 zu entfernen und 0 nicht aktualisiert.
Es müssen 0B Archive geholt werden.
Nach dem Auspacken werden 795MB Plattenplatz freigegeben sein.
Sie sind im Begriff, etwas potenziell Schädliches zu tun.
Zum Fortfahren geben Sie bitte »Ja, tu was ich sage!« ein.
?]

Ich frage mich nur, wie ich den installieren soll?! Soll ich einfach den 3.4er versuchen drüberzuinstallieren?

PS: ach der is schon installiert, daher die Beiträge über Symlink umsetzung... @_o

meandtheshell · Beitrag von **meandtheshell** » 11.12.2005 10:45:38

mach einmal

Code: Alles auswählen

dpkg -l | grep gcc

und
in /usr/bin/

Code: Alles auswählen

ls -l | grep gcc

markus

De Kus · Beitrag von **De Kus** » 11.12.2005 13:52:40

Danke, hatte ihn bei einem 'ls -l /usr/bin/gcc*' gefunden

. Für das 32bit Module vom NVidia Treiber reichts, leider hatte er mir für Winex compilieren auch nich geholfen, vielleicht doch nochma versuchen GCC als reine 32er version zu compilieren

.

meandtheshell · Beitrag von **meandtheshell** » 11.12.2005 13:59:56

@de kus
und der symbolische link von gcc - auf welches binary zeigt der? posten bitte

Code: Alles auswählen

ls -l /usr/bin/ | grep gcc

das du den 3.4er gefunden hast bedeutet nicht unbeding das beim aufruf von gcc der 3.4er genommen wird.

markus

De Kus · Beitrag von **De Kus** » 11.12.2005 14:04:15

ich hab gcc auf gcc-3.4 umgeschrieben, sagt mir auch gcc --version und hat auch der NVidia Treiber gemerkt, dass nu 3.4 läuft und er kein Bock drauf hatte, weil der Kernel mit 3.3 compiliert war

. Also heute Nacht nochma fleisig Kernel kompiliert ^-^. Und nach Compilieren vom WLAN und den NForce Treiber lüft nu alles vom 3.4er kompiliert soweit, wie gesagt beim compilieren der Kompatiblitätbibliotheken für 32bit gabs diesmal keine Probleme beim ForceWare Treiber. Daraus schließe ich mal, dass es der 3.4er ist, der auch 32bit unterstützt

. Bei Winex ist das Problem eigentlich auch der Assembler. Vielleicht nochmal die Binutils mit dem neuen 3.4er für i686 compilieren ^-^.

Edit: Ich werd vielleicht mal neuen Thread für das mit Winex aufmachen, passt hier nicht rein. Werd dann auch nochmal zu nem Thread auf Linuxforen.de verlinken (Foren für holarse.de).

meandtheshell · Beitrag von **meandtheshell** » 11.12.2005 14:09:40

es gibt eine möglichkeit die versionsprüfung zwischen modul und kernel zu deaktivieren ... glaube aber nicht das ich da jetzt ad hoc genau sagen kann wie - da müsste ich nachsehen

naja - kernel kompilieren ist ja nicht wirklich der Aufwand - altes konfig file verwenden!

markus

gms · Beitrag von **gms** » 11.12.2005 14:58:47

De Kus hat geschrieben:Bei Winex ist das Problem eigentlich auch der Assembler. Vielleicht nochmal die Binutils mit dem neuen 3.4er für i686 compilieren ^-^.

Vielleicht liegt's auch nur am Makefile bzw an der Konfiguration. Was für einen Fehler bekommst du denn ?

Gruß
gms

De Kus · Beitrag von **De Kus** » 12.12.2005 03:43:10

Da Winex ja immer noch net geht, habe ich nun die Binutils nochmal mit GCC 3.4 und sich selbst neu compiliert/gelinkt. GCC wieder dazu angetan als i686-pc-linux-gnu zu compilieren und siehe da... selber Fehler

. Naja, ich werds erstmal ruhen lassen und versuchen meine Probleme anderwertig zu beheben.

gms · Beitrag von **gms** » 12.12.2005 08:29:52

Warum du vermutest, daß dein Problem am Assembler liegt, habe ich auch nie so ganz verstanden. Der gleiche Assembler funktioniert ja beim erstellen der WLAN und NForce Treiber und eine Fehlerberschreibung wolltest du anscheinend nicht herausrücken.

Gruß
gms

De Kus · Beitrag von **De Kus** » 12.12.2005 16:51:39

Ich gehe davon aus, weil die Fehlermeldung von Assembler kommt, aber das wäre hier off-topic. Aber wenns dich beruhigt:

gcc -MMD -c -I. -I. -I../include -I../include -g -O2 -Wall -fno-keep-static-consts -D__const=const -fno-strict-aliasing -D__i386__ -D__int8=char -D__int16=short -D__int32=int "-D__int64=long long" -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o port.o port.c
tmp/ccAGXpVP.s: Assembler messages:
/tmp/ccAGXpVP.s:261: Error: suffix or operands invalid for `push'
/tmp/ccAGXpVP.s:264: Error: suffix or operands invalid for `pop'
make[1]: *** [port.o] Fehler 1

Glaube die wollen mich verarschen, die benutzen den x86_64-linux assembler statt dem i686-pc-linux-gnu, glaub ich: (hier von glibc)

../sysdeps/unix/i386/sysdep.S: Assembler messages:
../sysdeps/unix/i386/sysdep.S:59: Error: suffix or operands invalid for `push'
../sysdeps/unix/i386/sysdep.S:63: Error: suffix or operands invalid for `pop'
../sysdeps/unix/i386/sysdep.S:64: Error: `(%eax)' is not a valid 64 bit base/index expression

De Kus · Beitrag von **De Kus** » 27.12.2005 11:18:09

Ich hab heute mal wieder weiter mit Winex rumgespielt und dabei viel mir auf, dass er folgendes gar nicht mag:
--host=i686-pc-linux-gnu CFLAGS="-m32 -march=athlon-xp"
das macht er ohne anstand: (aber bringt ja immer den assembler Fehler)
--host=i686-pc-linux-gnu CFLAGS=-m32
nun wirds interessant, denn bei:
--host=i686-pc-linux-gnu CFLAGS="-m32 -march=i686"
bringt er den selben Fehler wie beim GCC compilieren, nämlich, dass ihm die ld-linux.so.2 fehle, obwohl sie doch im selben Verzeichnis wie die libc ist

. Und glibc compilieren scheitert wieder am Assembler *sich gleich die Haare rauft*

../sysdeps/unix/i386/sysdep.S:64: Error: `(%eax)' is not a valid 64 bit base/index expression

Glaub der will mich verarschen, hab ihm doch gesagt, dass er host=i686 machen soll...
Bleibt einem trotz theoretischer crosscompiler Funktionalität nichts anderes übrig wie den Schembels unter nem chroot zu compiliere?!

gms · Beitrag von **gms** » 27.12.2005 15:52:36

De Kus hat geschrieben:Aber wenns dich beruhigt:

Nun, ich war vorher auch nicht beunruhigt

De Kus hat geschrieben: bringt er den selben Fehler wie beim GCC compilieren, nämlich, dass ihm die ld-linux.so.2 fehle!

Also doch kein Assemblerproblem!!!
Hast du die Pakete "ia32-libs" und "ia32-libs-dev" installiert ?

De Kus · Beitrag von **De Kus** » 29.12.2005 02:22:26

gms hat geschrieben:Hast du die Pakete "ia32-libs" und "ia32-libs-dev" installiert ?

natürlich... wie gesagt, die Datei ist vorhanden (und nicht aus /lib kopiert/verlinkt

).

Code: Alles auswählen

De-Kus:/home/dekus# locate ld-linux.so.2
/emul/ia32-linux/lib/ld-linux.so.2
/emul/ia32-linux/lib/tls/ld-linux.so.2
/lib/ld-linux.so.2

gms · Beitrag von **gms** » 29.12.2005 10:58:53

De Kus hat geschrieben:natürlich... wie gesagt, die Datei ist vorhanden (und nicht aus /lib kopiert/verlinkt ).
Code: Alles auswählen
De-Kus:/home/dekus# locate ld-linux.so.2
/emul/ia32-linux/lib/ld-linux.so.2
/emul/ia32-linux/lib/tls/ld-linux.so.2
/lib/ld-linux.so.2

/lib/ld-linux.so.2 sollte aber schon ein Link sein und letztendlich auf eine gültige Datei zeigen. Kannst du leicht überprüfen:

Code: Alles auswählen

root@gms1:~/tmp# /lib/ld-linux.so.2
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
...

überprüfe auch einmal mit ldconfig welche ld-config.so.2 dort auftauchen:

Code: Alles auswählen

ldconfig -N -X -p

Falls das auch keinen Hinweis liefert, fangen wir am besten mit einem kleinen Testprogramm an und probieren diese statisch und dynamisch zu linken:

Code: Alles auswählen

root@gms1:~/tmp# cat main.c
#include <stdio.h>

int main() {
  printf("blabla\n");
  return 0;
}

root@gms1:~/tmp# gcc -m32 -static -o tests main.c 
root@gms1:~/tmp# gcc -m32 -o testd main.c 
root@gms1:~/tmp# ldd tests
        not a dynamic executable
root@gms1:~/tmp# ldd testd
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7dae000)
        /lib/ld-linux.so.2 (0xb7ef4000)

Gruß
gms

De Kus · Beitrag von **De Kus** » 29.12.2005 16:08:22

Hmm, das scheint langsam etwas licht zu bringen. Die ld-linux is keine i386/i686 sondern ne ELF Datei anscheints (ne ld-config gibts keine ^^):

De-Kus:/home/dekus# ldconfig -N -X -p | grep ld-linux
ld-linux.so.2 (ELF, hwcap: 0x8000000000000000) => /emul/ia32-linux/lib/tls/ld-linux.so.2
ld-linux.so.2 (ELF) => /emul/ia32-linux/lib/ld-linux.so.2
ld-linux.so.2 (ELF) => /lib/ld-linux.so.2
ld-linux-x86-64.so.2 (libc6,x86-64) => /lib/ld-linux-x86-64.so.2

De-Kus:/tmp# ldd testd
linux-gate.so.1 => (0x00000000)
libc.so.6 => /emul/ia32-linux/lib/tls/libc.so.6 (0x5557c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x55555000)

alles klar, er linkt zur falschen File... komischerweise lassen sich aber tests un testd trotzdem ausführen

.

dekus@De-Kus:/emul/ia32-linux/lib/tls$ ls -l
insgesamt 2004
-rwxr-xr-x 1 root root 88904 2004-12-27 03:41 ld-2.3.2.so
lrwxrwxrwx 1 root root 11 2005-11-22 13:54 ld-linux.so.2 -> ld-2.3.2.so
...

PS: bei deinem kleinen Testproggii nimmt er auch -march=athlon-xp an *achsel zuck*

gms · Beitrag von **gms** » 29.12.2005 17:33:46

Nö, schaut alles ok aus, der linkt schon richtig.
Ein 32 bit Programm kann nicht mit 64 bit Libraries gelinkt werden und daß du mit "-m32" ein 32 bit Programm erstellst, kannst du mit folgendem Code selber leicht beweisen:

Code: Alles auswählen

#include <stdio.h>

int main() {
  int* p;
  printf("%d\n",sizeof(p));
  return 0;
}

Wenn dies als 32 bit Programm kompiliert wirt sollte die Ausgabe 4 sein, bei einem 64 bit Programm 8.

Code: Alles auswählen

PS: bei deinem kleinen Testproggii nimmt er auch -march=athlon-xp an *achsel zuck*

Grundstätzlich scheint auch wirklich alles korrekt zu funktionieren, daher würde ich doch die Suche bei dem Winex-Buildprozess vortsetzen.

Gruß
gms

De Kus · Beitrag von **De Kus** » 30.12.2005 02:09:31

dekus@De-Kus:/tmp$ gcc -m32 -march=athlon-xp -static -o tests main2.c
dekus@De-Kus:/tmp$ ./tests
4
dekus@De-Kus:/tmp$ gcc -O2 -static -o tests2 main2.c
dekus@De-Kus:/tmp$ ./tests2
8

passt also wirklich schon.

Nun ja, aber wie gesagt, ich bekomme den selben Fehler wie bei GCC seltsamerweise. Und das direkt beim ./configure.
zB.diese Zeile: PATH=/opt/crosscomp/i686-pc-linux-gnu/bin:$PATH ./configure --build=i686-pc-linux-gnu --enable-pthreads --with-x --disable-debug --disable-trace CFLAGS="-m32 -march=athlon-xp"
Das ist die Config Log Zeile: configure:2008: gcc -m32 -march=athlon-xp conftest.c >&5

Das Testprogramm enthällt ein paar DEFINE und eine return 0 int main...

Bei folgendem dann: PATH=$PATH:/opt/crosscomp/bin ./configure --build=i686-pc-linux-gnu --enable-pthreads --with-x --disable-debug --disable-trace CFLAGS="-m32 -march=athlon-xp"
also im Prinzip das selbe, nur ohne das Aufzwingen von i686 binutils geht configure durch und dann bricht er hier ab:

gcc -m32 -march=athlon-xp -Wall -mpreferred-stack-boundary=2 -fno-keep-static-consts -D__const=const -fno-strict-aliasing -D__i386__ -D__int8=char -D__int16=short -D__int32=int "-D__int64=long long" -o winebuild import.o main.o parser.o relay.o res16.o res32.o spec16.o spec32.o utils.o -L../../unicode -lwine_unicode
/usr/bin/ld: skipping incompatible ../../unicode/libwine_unicode.so when searching for -lwine_unicode
/usr/bin/ld: cannot find -lwine_unicode

Das sieht verdächtig nach Winex Makefile aus, okay. Aber fraglich wäre, ob diese Änderung nun tatsächlich den Fehler beheben würden, oder ob er nicht am Ende doch wieder beim Assembeln rummurksen würde

.

Aber was ist mit GCC? Sowohl mit --target= als auch --host= bringt er den Fehler aus dem ersten Post. Aufzwingen der i686 binutil via "PATH=/opt/crosscomp/i686-pc-linux-gnu/bin:$PATH" bringt auch keine Veränderung.

De-Kus:/usr/src/winex# PATH=$PATH:/opt/crosscomp/bin make | grep libwine_unicode.so
gcc -shared -Wl,-soname,libwine_unicode.so casemap.o compose.o cptable.o mbtowc.o string.o utf8.o wctomb.o wctype.o c_037.o c_042.o c_424.o c_437.o c_500.o c_737.o c_775.o c_850.o c_852.o c_855.o c_856.o c_857.o c_860.o c_861.o c_862.o c_863.o c_864.o c_865.o c_866.o c_869.o c_874.o c_875.o c_878.o c_932.o c_936.o c_949.o c_950.o c_1006.o c_1026.o c_1250.o c_1251.o c_1252.o c_1253.o c_1254.o c_1255.o c_1256.o c_1257.o c_1258.o c_10000.o c_10006.o c_10007.o c_10029.o c_10079.o c_10081.o c_20866.o c_28591.o c_28592.o c_28593.o c_28594.o c_28595.o c_28596.o c_28597.o c_28598.o c_28599.o c_28600.o c_28603.o c_28604.o c_28605.o -o libwine_unicode.so.1.0
/usr/bin/ld: warning: i386 architecture of input file `casemap.o' is incompatible with i386:x86-64 output
..

Das ganze wiederholt sich mit jeder .o file. Kann sein, dass das -m32 wieder fehlt? Hab nen Blick in die Makefile von winex/unicode/ geworfen, die CFLAGS sind dort richtig eingetragen. Da ich ziemlich wenig Peil hab, kann ich das wohl nicht selbst fixen

.

PS: ich hab jetzt mit einer kleinen bash script das Problem beseitigt (es fehlten ja nur die -m32 Parameter), allerdings geht das immer weiter und weiter... kann ich nicht Configue oder zumindest die Makefile.in irgendwie dahingehend abändern, dass er auch beim Linken mit gcc die $CFLAGS mitnimmt?

gms · Beitrag von **gms** » 30.12.2005 16:10:50

LFLAGS=-m32 sollte da helfen.
Alternativ kannst du auch "CC=gcc-3.4 -m32" versuchen. (Eventuell auch "LD=ld -m32" und "AS=as -m32")

Gruß
gms