Executables funktionieren nach Crosscompiler Update nicht mehr

Stefan S. OP #7356734
Lesenswert?
• ▲
▼

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:

1
 
./hellow

2
 
./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:

1
 
strings /lib/arm-linux-gnueabi/libc.so.6 | grep GLIB

2
 
GLIBC_2.4                                                                                                                                                 

3
 
GLIBC_2.5                                                                                                                                                 

4
 
GLIBC_2.6                                                                                                                                                 

5
 
GLIBC_2.7                                                                                                                                                 

6
 
GLIBC_2.8

7
 
GLIBC_2.9

8
 
GLIBC_2.10

9
 
GLIBC_2.11

10
 
GLIBC_2.12

11
 
GLIBC_2.13

12
 
GLIBC_2.14

13
 
GLIBC_2.15

14
 
GLIBC_2.16

15
 
GLIBC_2.17

16
 
GLIBC_2.18

17
 
GLIBC_2.22

18
 
GLIBC_2.23

19
 
GLIBC_2.24

20
 
GLIBC_PRIVATE

21
 
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:

1
 
./hellow

2
 
./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:

1
 
ldd hellow

2
 
./hellow: /lib/arm-linux-gnueabi/libm.so.6: version `GLIBC_2.35' not found (required by ./libstdc++.so.6)

3
 
./hellow: /lib/arm-linux-gnueabi/libm.so.6: version `GLIBC_2.29' not found (required by ./libstdc++.so.6)

4
 
        libstdc++.so.6 => ./libstdc++.so.6 (0xb6d46000)

5
 
        libgcc_s.so.1 => ./libgcc_s.so.1 (0xb6d17000)

6
 
        libc.so.6 => ./libc.so.6 (0xb6b85000)

7
 
        libm.so.6 => /lib/arm-linux-gnueabi/libm.so.6 (0xb6acb000)

8
 
        /lib/ld-linux.so.3 (0xb6f23000)

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

Gruß Stefan

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Stefan S. OP #7365085
Lesenswert?
• ▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Μαtthias W. Persönliche Seite #7365704
Lesenswert?
• ▲
▼

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

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan S. OP #7366587
Lesenswert?
• ▲
▼

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:

1
 
./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

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Μαtthias W. Persönliche Seite #7366637
Lesenswert?
• ▲
▼

Stefan S. schrieb:

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

1
 
> ./configure --host=arm-unknown-linux-gnueabi 

2
 
> --prefix=/home/osboxes/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot/usr

3
 
>

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.

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan S. OP #7366748
Lesenswert?
• ▲
▼

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:

1
 
./configure --host=arm-unknown-linux-gnueabi

2
 
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-gnueabi/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

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan S. OP #7368007
Lesenswert?
• ▲
▼

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-gnueabi/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

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan S. OP #7368014
Lesenswert?
• ▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Μαtthias W. Persönliche Seite #7368027
Lesenswert?
• ▲
▼

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?

1
 
$ 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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan S. OP #7373214
Lesenswert?
• ▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren