Executables funktionieren nach Crosscompiler Update nicht mehr

[Stefan S. (energizer)]

Hallo,

ich nutze ein Ubuntu-Linux mit Eclipse und den arm-linux-gnueabi-g++ in 
einer VM um für ein ARM9 System Binaries zu bauen. Das hat bisher 
wunderbar geklappt, aber seit ich die VM neu bauen musste laufen die 
Binaries nicht mehr auf dem Target:

./hellow
./hellow: /lib/arm-linux-gnueabi/libc.so.6: version `GLIBC_2.34' not found (required by ./hellow)

Tatsächlich ist GLIBC_2.34 in der Lib libc.so.6 auf dem Target nicht 
enthalten:

strings /lib/arm-linux-gnueabi/libc.so.6 | grep GLIB
GLIBC_2.4                                                                                                                                                 
GLIBC_2.5                                                                                                                                                 
GLIBC_2.6                                                                                                                                                 
GLIBC_2.7                                                                                                                                                 
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
GLIBC_2.18
GLIBC_2.22
GLIBC_2.23
GLIBC_2.24
GLIBC_PRIVATE
GNU C Library (Debian GLIBC 2.24-11+deb9u3) stable release version 2.24, by Roland McGrath et al.

Dann habe ich versucht die libc.so.6 vom Buildsystem auf das Target zu 
kopieren, in den gleichen Ordner wie das Testbinary hellow und den 
LDD_LIBRARY_PATH entsprechend gesetzt:

./hellow
./hellow: relocation error: ./libc.so.6: symbol __tunable_get_val, version GLIBC_PRIVATE not defined in file ld-linux.so.3 with link time reference

Dann noch versucht alle Libs die hellow benötigt (Liste mit ldd) 
ebenfalls zu kopieren, also ld-linux.so.3, libgcc_s.so.1, libm.so.6, 
libstdc++.so.6.

Offenbar scheint nun die libm nicht aus dem Arbeitsverzeichnis im 
Gegensatz zu den anderen geladen zu werden:

ldd hellow
./hellow: /lib/arm-linux-gnueabi/libm.so.6: version `GLIBC_2.35' not found (required by ./libstdc++.so.6)
./hellow: /lib/arm-linux-gnueabi/libm.so.6: version `GLIBC_2.29' not found (required by ./libstdc++.so.6)
        libstdc++.so.6 => ./libstdc++.so.6 (0xb6d46000)
        libgcc_s.so.1 => ./libgcc_s.so.1 (0xb6d17000)
        libc.so.6 => ./libc.so.6 (0xb6b85000)
        libm.so.6 => /lib/arm-linux-gnueabi/libm.so.6 (0xb6acb000)
        /lib/ld-linux.so.3 (0xb6f23000)

Kann mir jemand einen Tip geben wie ich aus dem Schlamassel komme?

Gruß
Stefan

[Μαtthias W. (matthias)]

Passende Toolchain für dein Zielsystem besorgen oder am Besten selber 
bauen. Einigermaßen schmerzfrei geht das mit 
https://crosstool-ng.github.io/. Das rumhantieren mit verschiedenen 
glibc Versionen würde ich mir nicht antun wollen.

[Εrnst B. (ernst)]

Schau evtl mal hier:
Beitrag "Re: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.28' not found"

Könnte grob dasselbe Problem sein, und ob der Linker jetzt für arm oder 
i386 läuft, sollte keinen Unterschied machen.

[Stefan S. (energizer)]

Vielen Dank für die wertvollen Tips! Ich habe mir mit dem crosstools-ng 
tatsächlich eine passende Toolchain bauen können 
(arm-unknown-linux-gnueabi-) und im Eclipse einfach den Prefix und den 
Pfad der Tools umgestellt, wunderbar!

Vielleicht hat jemand noch ein paar Tips zu den sich daraus ergebenden 
Problemchen:

1. Die alte (von der Distribution mitgebrachte) Toolchain hatte den 
Prefix "arm-linux-gnueabi-" (ohne "unknown"). Ich konnte im Setup von 
crosstools-ng die entsprechende Option nicht finden, bin mir aber 
ziemlich sicher dass das konfigurierbar ist. Weiß jemand wo das 
versteckt ist? Ist zwar rein kosmetischer Natur, würde es aber ersparen 
von den ganzen bestehenden Projekten den Prefix anzupassen.

2. Ich habe eine Library mit der neuen Toolchain erzeugt mit ./configure 
--host=arm-unknown-linux-gnueabi ... und installiert. Die Headerfiles 
liegen anschließend in .../arm-unknown-linux-gnueabi/bin/include, aber 
beim kompilieren werden diese Headerfiles nicht gefunden. In diesem 
Ordner liegen auch keine anderen Headerfiles, das scheint also der 
falsche Ort dafür zu sein. Wo ist der richtig Ort, und wieso werden die 
Header an einen  anderen Ort verschoben?

Gruß
Stefan

[Μαtthias W. (matthias)]

Stefan S. schrieb:
> Vielen Dank für die wertvollen Tips! Ich habe mir mit dem crosstools-ng
> tatsächlich eine passende Toolchain bauen können
> (arm-unknown-linux-gnueabi-) und im Eclipse einfach den Prefix und den
> Pfad der Tools umgestellt, wunderbar!
>
> Vielleicht hat jemand noch ein paar Tips zu den sich daraus ergebenden
> Problemchen:
>
> 1. Die alte (von der Distribution mitgebrachte) Toolchain hatte den
> Prefix "arm-linux-gnueabi-" (ohne "unknown"). Ich konnte im Setup von
> crosstools-ng die entsprechende Option nicht finden, bin mir aber
> ziemlich sicher dass das konfigurierbar ist. Weiß jemand wo das
> versteckt ist? Ist zwar rein kosmetischer Natur, würde es aber ersparen
> von den ganzen bestehenden Projekten den Prefix anzupassen.

Ich denke du suchst CT_OMIT_TARGET_VENDOR

> 2. Ich habe eine Library mit der neuen Toolchain erzeugt mit ./configure
> --host=arm-unknown-linux-gnueabi ... und installiert. Die Headerfiles
> liegen anschließend in .../arm-unknown-linux-gnueabi/bin/include, aber
> beim kompilieren werden diese Headerfiles nicht gefunden. In diesem
> Ordner liegen auch keine anderen Headerfiles, das scheint also der
> falsche Ort dafür zu sein. Wo ist der richtig Ort, und wieso werden die
> Header an einen  anderen Ort verschoben?

Da gibts jetzt ganz verschiedene Ansätze. Ich arbeite mit einem sysroot 
(CT_USE_SYSROOT). Da ich die Toolchain nicht verändern will kopiere ich 
die aus dem Compiler raus (z.B. 
$CT_PREFIX_DIR/arm-linux-gnueabihf\sysroot\) und übergebe das 
Verzeichnis dann per --sysroot an den Compiler. Dieses Verzeichnis wird 
dann auch für zu erzeugende Bibliotheken als Installationsverzeichnis 
verwendet.

Wenn man mal verstanden hat wie das alles zusammenspielt macht das fast 
schon Spaß :-)

Matthias

[Stefan S. (energizer)]

Hallo Matthias,

>Ich denke du suchst CT_OMIT_TARGET_VENDOR

Jaa, genau den meinte ich. Wobei ich das vorerst noch bei "unknown" 
gelassen habe um nicht wegen Ahnungslosigkeit mit der alten Toolchain 
durcheinander zu kommen.

Inzwischen habe ich auch eine benötigte Zusatzlib mit der neuen 
Toolchain compilieren können:

./configure --host=arm-unknown-linux-gnueabi --prefix=/home/osboxes/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot/usr

Die sysroot Angelegenheit werde ich mir mal noch näher anschauen, 
schließlich will ich da hin "dass es fast Spaß macht" :-)

Mein Hello-World (mit eingebundener Lib) funktioniert nun auf dem 
Target, prima! Ein anderes bestehendes Projekt macht noch Mucken:
./libstdc++.so.6: version `GLIBCXX_3.4.29' not found
Es benutzt offenbar ein paar Funktionen aus der libstdc++ die von meinem 
Hello World nicht verwendet werden. Alle Compiler- und 
Linkereinstellungen des Hello World Projekts und des bestehenden 
Projekts sind gleich. Kopiere ich die libstdc++ auf das Target 
funktioniert alles. Im crosstool-ng habe ich leider keine Möglichkeit 
gefunden für die GLIBCXX die Version auszuwählen wie für die libc, gibt 
es da auch eine Lösung abgesehen von libstdc++ auf das Target zu 
kopieren?

Gruß
Stefan

[Μαtthias W. (matthias)]

Stefan S. schrieb:
> Inzwischen habe ich auch eine benötigte Zusatzlib mit der neuen
> Toolchain compilieren können:
>

> ./configure --host=arm-unknown-linux-gnueabi 
> --prefix=/home/osboxes/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot/usr
>

prefix solltest du nicht auf den sysroot setzen. Spätestens wenn 
pkgconfig ins Spiel kommt wird das nicht mehr funktionieren. Besser 
DESTDIR vor dem install Target setzen und prefix unangetastet lassen.

DESTDIR=$SYSROOT (make|ninja|...) install

> Mein Hello-World (mit eingebundener Lib) funktioniert nun auf dem
> Target, prima! Ein anderes bestehendes Projekt macht noch Mucken:
> ./libstdc++.so.6: version `GLIBCXX_3.4.29' not found

Die Version der libstdc++ hängt am Compiler. Du musst also in 
crosstools-ng auch die gleiche Compilerversion auswählen wie in deiner 
Originaltoolchain.

[Stefan S. (energizer)]

>Die Version der libstdc++ hängt am Compiler. Du musst also in
>crosstools-ng auch die gleiche Compilerversion auswählen wie in deiner
>Originaltoolchain.
Ah, der alte Compiler war 11.3, die neue Toolchain auf 12, werde das 
nochmal mit der anderen Version neu bauen.

>prefix solltest du nicht auf den sysroot setzen. Spätestens wenn
>pkgconfig ins Spiel kommt wird das nicht mehr funktionieren. Besser
>DESTDIR vor dem install Target setzen und prefix unangetastet lassen.
Ok, habe mal so ausprobiert:

./configure --host=arm-unknown-linux-gnueabi
DESTDIR=/home/osboxes/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot make install

Dann landen die Headerfiles der zu installierenden Lib hier:
/home/osboxes/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueab 
i/sysroot/usr/local/include/

Aber dann findet der Compiler beim Compilieren des Projekts die 
Headerfiles der Lib wieder nicht. In der alten Toolchain lagen die 
Headerfiles der installierten Libs in
/usr/arm-linux-gnueabi/include/

Gruß
Stefan

[Μαtthias W. (matthias)]

Dann fehlt dir beim configure noch ein --prefix=/usr

Dann sollten die Header im sysroot landen.

[Stefan S. (energizer)]

Hallo Matthias,

>Dann fehlt dir beim configure noch ein --prefix=/usr
Klasse, damit landen nun die Header in
/home/osboxes/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueab 
i/sysroot/usr/include/libconfig.h++
so dass der Crosscompiler beim kompilieren der Projekte die Includes und 
Libs finden kann!

Beim make install brauch ich allerdings root-Rechte, weil die o. g. 
Pfade alle read-only angelegt sind. Das sagt mir dass man das eigentlich 
so nicht machen sollte?

Gruß
Stefan

[Stefan S. (energizer)]

>Die Version der libstdc++ hängt am Compiler. Du musst also in
>crosstools-ng auch die gleiche Compilerversion auswählen wie in deiner
>Originaltoolchain.
Nachtrag: Ich habe die Version des Crosscompilers auf 11.3.0 
heruntergesetzt (wie Originaltoolchain), aber GLIBCXX_3.4.29 wird dann 
auf dem Target nach wie vor verlangt. Muss man da noch ein anderes 
Schräubchen drehen?

Gruß
Stefan

[Μαtthias W. (matthias)]

Stefan S. schrieb:
> Beim make install brauch ich allerdings root-Rechte, weil die o. g.
> Pfade alle read-only angelegt sind. Das sagt mir dass man das eigentlich
> so nicht machen sollte?

Du willst wahrscheinlich anpassen CT_PREFIX_DIR_RO ;-)

Stefan S. schrieb:
> Nachtrag: Ich habe die Version des Crosscompilers auf 11.3.0
> heruntergesetzt (wie Originaltoolchain), aber GLIBCXX_3.4.29 wird dann
> auf dem Target nach wie vor verlangt. Muss man da noch ein anderes
> Schräubchen drehen?

Die Originaltoolchain war sicher basierend auf gcc 11.3? Und die glibc 
eine 2.24? Das passt zeitlich irgendwie nicht zusammen. Welche Version 
hat denn deine libstdc++ auf dem Target?

$ strings /lib/libstdc++.so.6  | grep '^GLIBCXX_' | sort -V -u

Kommt dann da als größter Wert GLIBCXX_3.4.24 raus war das ein gcc 8. 
Hier findest du eine Liste (letzte Zahl vergleichen)
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

Wenn ich raten müsste würde ich eher auf einen gcc 6 und damit 
libstdc++.so.6.0.22 tippen. glibc 2.24 war debian stretch und da war gcc 
in Version 6 mit dabei.

[Stefan S. (energizer)]

>Du willst wahrscheinlich anpassen CT_PREFIX_DIR_RO ;-)
Hachja :-)

>Die Originaltoolchain war sicher basierend auf gcc 11.3? Und die glibc
>eine 2.24? Das passt zeitlich irgendwie nicht zusammen. Welche Version
>hat denn deine libstdc++ auf dem Target?
Auf dem Target ist GLIBCXX_3.4.28, da hat offenbar auf dem Target schon 
mal  jemand Hand angelegt. Laut der Liste ist das dann der gcc 10, das 
werde ich nochmal ausprobieren.

---

Ok, mit dem GCC 10 läuft es nun! Prima!
Vielen Dank für die Unterstützung & Gruß
Stefan