NI-Buildsystem

[annie]

Um den Log mit dem Fehler zu zeigen, musste ja das Betriebssystem auf Original gebracht werden

[vanhofen]

Kann es sein, dass ihr die Toolchain nur kopiert und auf dem neuen Host nicht neu erstellt habt?

[annie]

eigentlich wenn ich alle neu mache wird auch die Toolchain neu gebaut.

Aber ich lösche die mal und lasse die bauen und probiere...

[tannen]

Kann es sein, dass ihr die Toolchain nur kopiert und auf dem neuen Host nicht neu erstellt habt?

Nein ich habe kompl. neu aufgesetzt

[annie]

im Buildordner den Symlink setzen

Code: Alles auswählen

ln -sf ../../lib/libgcc_s.so.1 ./root/usr/lib/libgcc_s.so.1

muß man nach jedem "make clean" machen

Der Admin wird das noch richten und wahrscheinlich /lib in den rpath mit einschließen ?

Das Buildsystem-ddt hat den gleichen Fehler, nur da ist es in /home/user/buildsystem-ddt/tufsbox/cdkroot/usr/lib !!

[BPanther]

Das Buildsystem-ddt hat den gleichen Fehler, nur da ist es in /home/user/buildsystem-ddt/tufsbox/cdkroot/usr/bin !!

Hmm, kann ich nicht bestätigen. Wenn ich die vielen Images vom DDT hier am Stück durchbaue, muß ich keinen extra Sym manuell setzen.
Zudem liegt die ganz normal in /home/user/buildsystem-ddt/tufsbox/cdkroot/lib/, da wo sie auch sein sollte - nicht wo Du sie angegeben hast.

Code: Alles auswählen

bpanther@neutrino:~$ ls -l /home/bpanther/DDT/buildsystem-ddt/tufsbox/cdkroot/lib/libgcc*
-rw-r--r-- 1 bpanther bpanther     132 Aug 23  2020 /home/bpanther/DDT/buildsystem-ddt/tufsbox/cdkroot/lib/libgcc_s.so
-rw-r--r-- 1 bpanther bpanther 8971064 Aug 23  2020 /home/bpanther/DDT/buildsystem-ddt/tufsbox/cdkroot/lib/libgcc_s.so.1

bpanther@neutrino:~/DDT/buildsystem-ddt/tufsbox/cdkroot$ find ./ -name *libgcc*
./lib/libgcc_s.so.1
./lib/libgcc_s.so

[annie]

dann nutze mal ein neueres Betriebssystem, ich nutze hier LinuxMint 20.x
Mit LinuxMint 19 hab ich auch keine Probleme.

[tannen]

im Buildordner den Symlink setzen

Code: Alles auswählen

ln -sf ../../lib/libgcc_s.so.1 ./root/usr/lib/libgcc_s.so.1

muß man nach jedem "make clean" machen

Danke so baut es wieder durch

[vanhofen]

Hmm, kann ich nicht bestätigen.

Ich kann den Fehler hier auch nicht nachstellen. Dennoch ist er da.

Ich kann erstmal nur im Trüben fischen und vermute den Fehler bei rpath. Da sieht es nämlich bei euch genauso aus wie bei mir.

https://github.com/Duckbox-Developers/b ... nv.mk#L154

Code: Alles auswählen

-Wl,-rpath -Wl,/usr/lib -Wl,-rpath-link -Wl,$(TARGET_LIB_DIR)

Wenn libgcc_s.so.1 in <root>/lib liegt, findet die rpath-Angabe sie logischerweise nicht.

[BPanther]

Ich will nicht bestreiten, daß vielleicht bestimmte Systeme da ein Problem haben. Ich kann es hier nur leider weder mit Ubuntu 18 noch Ubuntu 20 nachstellen (beide Updatestand von heute). Wäre auch spätestens bei UFS910/22 aufgefallen, weil das Image viel zu groß geworden wäre - das muß da ja in rund 10 MB (+Kernel und Var) passen.

Was mich nur wundert ist, daß die Datei bei den bestimmten Systemen offensichtlich komplett falsch kopiert wird, denn was soll die in usr/bin?!

[vanhofen]

/usr/bin ist natürlich falsch. Als Workaround ist der Symlink von <root>/lib nach <root>/usr/lib sicher erstmal die sinnvollste Lösung. Schön ist aber anders.

[BPanther]

Aso, das meinst Du. Im Image landet die am Ende auch in /lib und nicht in /usr/lib, wobei beides eh im normalen Suchpfad steht und daher nicht wirklich einen Unterschied machen sollte.

[vanhofen]

... wobei beides eh im normalen Suchpfad steht ...

Nicht so bei der Angabe von rpath. Dort ist nur <root>/usr/lib angegeben. Drum müssen sich die Jungs ja eben mit dem Symlink helfen.

[annie]

/usr/bin ist natürlich falsch. Als Workaround ist der Symlink von <root>/lib nach <root>/usr/lib sicher erstmal die sinnvollste Lösung. Schön ist aber anders.

Yepp /usr/lib natürlich

[BPanther]

Hmm, nur soweit ich das verstanden habe mit rpath erstellt der doch nur zusätzliche, zum vorhandenen wie z.B. /lib, noch Suchpfade. Dann wären die vorhandenen doch schon unvollständig - oder?
Ich hatte auch nochmal gebaut unter Ubuntu 18 und 20 mit GCC 10, lief aber hier auch durch. Hatte da schon GCC 10 in Verdacht, da ich selbst nur mit der 8.4.0 baue, aber war es auch nicht.

[ice32]

hallo,

ich baue mit LinuxMint 19 und habe keine Probleme.
Werde nachher nochmal ein Image bauen, letztes hatte ich gestern generiert,
ohne Probleme.

LG ice32

[BPanther]

Kann es sein, daß nur 32 Bit Systeme betroffen sind?

Im Falle von DDT bitte das hier: https://github.com/Duckbox-Developers/b ... nv.mk#L154 ändern in:

Code: Alles auswählen

TARGET_LDFLAGS = $(CORTEX_STRINGS) -Wl,-rpath -Wl,$(TARGET_DIR)/usr/lib -Wl,-rpath-link -Wl,$(TARGET_LIB_DIR) -L$(TARGET_LIB_DIR) -L$(TARGET_DIR)/lib $(TARGET_EXTRA_LDFLAGS)

Vielleicht reicht das ja schon?

[vanhofen]

Nee, das zweite -L-Flag reicht nicht. Ich hab das bei mir schon drin.

[BPanther]

Ich habe kein 2. -L eingefügt.

aus: TARGET_LDFLAGS = $(CORTEX_STRINGS) -Wl,-rpath -Wl,/usr/lib -Wl,-rpath-link -Wl,$(TARGET_LIB_DIR) -L$(TARGET_LIB_DIR) -L$(TARGET_DIR)/lib $(TARGET_EXTRA_LDFLAGS)

wird: TARGET_LDFLAGS = $(CORTEX_STRINGS) -Wl,-rpath -Wl,$(TARGET_DIR)/usr/lib -Wl,-rpath-link -Wl,$(TARGET_LIB_DIR) -L$(TARGET_LIB_DIR) -L$(TARGET_DIR)/lib $(TARGET_EXTRA_LDFLAGS)


EDIT: Nein, das ist nicht das Problem...

[TangoCash]

rpath gibt den pfad zur runtime ab, rpath-link zur link time

Aber in Log lese ich ein "-L /usr/lib" , mal sehen wo das her kommt, das hat da nix zu suchen