Speicherzugriffsfehler mit selbst kompiliertem GNU G++ Compiler

Piet

Hallo C++ Community,

ich habe zu Lernzwecken die Gnu Compiler Collection
(git clone git://gcc.gnu.org/git/gcc.git) kompiliert mit dem Prefix /home/user/apps.
Wenn ich damit ein kleines C++ Konsolen-Programm kompiliere, erhalte ich bei dem ersten cout >>
(auf die Konsole) einen Speicherzugriffsfehler.
Die Kompilation läuft ohne Fehler durch.
Wenn ich den Standard-Compiler meiner Linux Distro verwende, habe ich diesen Fehler nicht.

Woran kann das liegen, bitte?
Vielen Dank!

Piet

SeppJ

Genauere Vorgangs- und Fehlerbeschreibung bitte.

Tendenziell besteht der Verdacht, dass da irgendwelche globalen Pfadeinstellungen bei dir gesetzt sind, die dafür sorgen, dass dein Programm den Bibliothekscode des vorinstallierten Compilers benutzt, für den das Programm aber nicht ausgelegt ist. Daher bitte auch Ausgabe von ldd auf die beiden compilierten Programme angeben.

Piet

Hallo,

auf die fehlerhafte bin:

ldd ./test.bin 
	linux-vdso.so.1 (0x00007ffcea1f7000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe32e400000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe32e321000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe32e6b6000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe32e140000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fe32e6f5000)

Auf die fehlerfreie bin:

ldd ./ok.bin
	linux-vdso.so.1 (0x00007ffee05e0000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f618d200000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f618d51c000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f618d4fc000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f618d01f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f618d61a000)

Ich nutze IDE Code::Blocks mit den geänderten Einstellungen für c++ Compiler.
Beim Debuggen mit CB bricht das Programm bei dem ersten cout ab.

Gruß

Piet

Th69

Bei beiden Programmen sind, wie du ja selbst siehst, dieselben Libs verlinkt.
Kompiliere mal mit -nodefaultlibs und gebe mit -L explizit die Pfade zu den von dir kompilierten Libs an.

firefly

@Th69 sagte in Speicherzugriffsfehler mit selbst kompiliertem GNU G++ Compiler:

Bei beiden Programmen sind, wie du ja selbst siehst, dieselben Libs verlinkt.

Nicht ganz. Beim linken selbst wurden wohl die richtigen libs verwendet (welche zur Compiler version passen).
Nur im binary wurde nur angegeben, dass die library z.b. libstdc++.so.6 benötigt wird aber kein absoluter pfad zu dieser library. (Absolute pfade werden verwendet wenn die rpath option genutzt wird)

Daher sucht der library loader nur in den standard(konfigurierten) sourchpfaden nach der library

Diese liste der suchpfade kann man z.b. via folgenden befehl herausfinden

ldconfig -v 2>/dev/null | grep -v ^$'\t'

man kann mit einer ENV variable zusätzliche suchpfade angeben
LD_LIBRARY_PATH

Im Beispiel von Piet könnte man es mit der ENV variable wie folgt lösen:

LD_LIBRARY_PATH="/home/user/apps/lib/x86_64-linux-gnu" ./test.bin
@Piet: Da ich nicht genau aus dem kopf weis wie die verzeichnisstruktur unterhalb des prefix "/home/user/apps" aussieht musst du den teil nach "/home/user/apps" eventuell korrigieren wo die gcc libraries wirklich liegen (das Verzeichnis in dem die libstdc++.so.6 liegt)

Piet

Hallo und Danke für Eure Tipps,

wer lesen kann ist klar im Vorteil.

Die Kompilation wird beendet mit dem Hinweis:

Libraries have been installed in:
   /home/user/apps/gcc/lib/../lib64

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.

Das müsste ja das sein, was firefly gepostet hat.

Mir geht es ja um's Klügerwerden :).
Also ein Programm, das ich kompiliere, 'läuft' nicht in jeder Umgebung?
Sondern es sucht sich zu Laufzeit seine libs*.so.*, die dazu passen müssen?
Oder eben mit Pfadangabe dahin?
Aber warum laufen dann so viele "alte" Programme unter den OS?
Werden die Pakete der Distris immer dementsprechend angepasst bzw. gelinkt?

Gruß

Piet