C++ Linux dynamic libraries linken

[Verwijderd]

Beste Tweakers,

Ik probeer de SFML1.6 libraries te linken. En heb het op diverse manieren geprobeerd, maar steeds als ik mijn succesvol gelinkte executable wil draaien krijg ik: "error while loading shared libraries: libsfml-window.so.1.6: cannot open shared object file: No such file or directory".

Ik heb geprobeerd om te linken naar de .so' s in /lib64 (SFML1.6 geïnstalleerd via de package manager) en ik heb het geprobeerd met een gedownload exemplaar van de SFML website die ik in een subdir van mijn home dir heb gezet. En met beide lukt het niet. Ik heb al $LD_LIBRARY_PATH laten verwijzen naar /lib/64 en als ik het controleer met "echo $LD_LIBRARY_PATH" dan geeft hij ook inderdaad "/lib64/". Ik heb "export LD_LIBRARY_PATH" gedaan. Ik heb de 2 laatste dingen ook geprobeerd met een zelf gedownload exemplaar in de sub dir in mijn home dir en hij blijft tijdens runtime steeds maar dezelfde error geven. Linken heb ik gedaan met:
"g++ -c ./mijnprogramma.cpp" & vervolgens "g++ -L/lib64/ -o mijnprogramma ./mijnprogramma.cpp -lsfml-window -lsfml-system" (zoals op de SFML website staat).

"ldd mijnprogramma" geeft ook aan dat de 2 .so' s niet gevonden worden.

Weet iemand meer over linking met LD/G++ onder Linux & LD_LIBRARY_PATH?

Alvast bedankt,

Superpelican

[ Voor 4% gewijzigd door Verwijderd op 18-02-2013 18:49 ]

[Ventieldopje]

Misschien een domme vraag maar gebruik je wel de 64bit variant van de compiler? Vreemd in ieder geval!

[Verwijderd]

GCC -v geeft in elk geval dat de target X86_64 Linux is, dus het lijkt me dat de compiler wel 64 bit is. Een 32 bit compiler die naar 64 bit compileert lijkt me niet mogelijk

EDIT:Na wat googlen ben ik er achter gekomen dat veel SFML gebruikers last hebben van problemen bij het gebruik van GCC 4.7 (ik heb 4.7.2). Dus misschien is dat het. Hoewel die gebruikers niks melden over dat de libraries niet kunnen worden gevonden, maar meer dingen als segfaults en crashes van het betreffende programma. Er staat geen oudere versie van GCC dan 4.7.2 in de repo' s van mijn distro... Dus 4.6 gebruiken is geen oplossing.

En ik heb het probleem ook met het zelf gedownloade exemplaren die ik ook zelf heb "gemaked". Ook komt het exemplaar in /lib64 uit de AUR (dus hij is op mijn eigen systeem gebuild, dus waarschijnlijk ook gewoon met GCC 4.7.2)

[ Voor 70% gewijzigd door Verwijderd op 18-02-2013 19:13 ]

[Klippy]

Kijk eens of je /lib64/ dir in /etc/ld.so.conf staat en doe dan eens ldconfig

[Soultaker]

Ik geloof er niets van dat het aan de versie van GCC ligt. Als de compiler probleemloos kan linken, zou je de resulterende binary ook moeten kunnen laden. Sowieso zou /lib64 op een 64-bits systeem standaard in het library search path moeten staan (eventueel via een symlink van /lib naar /lib64 of iets dergelijks) dus die zou je ook niet aan de compiler/linker mee hoeven geven met -L.

Om te controleren want er precies mis gaat tijdens het laden kun je de LD_DEBUG variabele gebruiken. Als je bash als shell gebruikt bijvoorbeeld zo:

LD_DEBUG=libs ./mijnprogramma

(LD_DEBUG=all geeft nog veel meer informatie.) Post daarvan de output eens, zou ik zeggen.

Verwijderd schreef op maandag 18 februari 2013 @ 18:45:
"g++ -c ./mijnprogramma.cpp" & vervolgens "g++ -L/lib64/ -o mijnprogramma ./mijnprogramma.cpp -lsfml-window -lsfml-system".

Dat eerste commando is volstrekt overbodig als je in het tweede geval je source file (en niet de bij de eerste stap gegenereerde object file) aan de compiler meegeeft. Je kunt om te testen net zo goed het eerste commando achterwege laten, mijnprogramma.o verwijderen, en alleen het tweede commando gebruiken.

[ Voor 29% gewijzigd door Soultaker op 18-02-2013 19:26 ]

[Verwijderd]

cat ld.so.conf geeft:

code:

#
# /etc/ld.so.conf
#

include /etc/ld.so.conf.d/*.conf

# End of file

Dus het lijkt er op dat er überhaupt geen dir in ld.so.conf staat

LD_DEBUG=libs geeft:

code:

1470:     find library=libsfml-window.so.1.6 [0]; searching
      1470:      search cache=/etc/ld.so.cache
      1470:      search path=/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib          (system search path)
      1470:       trying file=/usr/lib/tls/x86_64/libsfml-window.so.1.6
      1470:       trying file=/usr/lib/tls/libsfml-window.so.1.6
      1470:       trying file=/usr/lib/x86_64/libsfml-window.so.1.6
      1470:       trying file=/usr/lib/libsfml-window.so.1.6
      1470:
./mijnprogramma: error while loading shared libraries: libsfml-window.so.1.6: cannot open shared object file: No such file or directory

En LD_DEBUG=all geeft:

code:

1639:
      1639:     file=libsfml-window.so.1.6 [0];  needed by ./sfml_window_init [0]
      1639:     find library=libsfml-window.so.1.6 [0]; searching
      1639:      search cache=/etc/ld.so.cache
      1639:      search path=/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib          (system search path)
      1639:       trying file=/usr/lib/tls/x86_64/libsfml-window.so.1.6
      1639:       trying file=/usr/lib/tls/libsfml-window.so.1.6
      1639:       trying file=/usr/lib/x86_64/libsfml-window.so.1.6
      1639:       trying file=/usr/lib/libsfml-window.so.1.6
      1639:
./mijnprogramma: error while loading shared libraries: libsfml-window.so.1.6: cannot open shared object file: No such file or directory

Hij zoekt dus niet in /lib of /lib64 zoals hij zou moeten doen (aangezien ik export LD_LIBRARY_PATH heb gedaan en LD_LIBRARY_PATH heb geset, echo $LD_LIBRARY_PATH bevestigd dat). Waarom dat niet werkt snap ik niet.

Wat wel opmerkelijk is dat hij dus die identieke .so' s vind in /usr/lib en ze niet "gebruikt" en hij dan vervolgens gaat klagen. Terwijl hij ze al gevonden heeft.

Nu we het toch hierover hebben: ik vraag me af waarom heeft Linux (weet niet of andere *NIX'en het ook hebben) én /lib (of /lib64) én /usr/lib? Wat is het nut hiervan?

Ik heb al heel wat vragen op StackOverflow etc. gelezen en topics of diverse fora waarin gebruikers ook het ".so no such file or dir"-probleem hebben, maar daar zie je dat het altijd direct opgelost is zodra ze export LD_LIBRARY_PATH doen of met de -L flag tijdens link time de plaats van de libraries aangeven.

[ Voor 27% gewijzigd door Verwijderd op 19-02-2013 13:14 ]

[Zoijar]

Heel dom idee, en zal wel, maar heb je wel lees rechten op die files? En wat geeft: ldd ./mijnprogramma | grep "not found" ?

[ Voor 28% gewijzigd door Zoijar op 19-02-2013 13:18 ]

[Verwijderd]

cat /usr/lib/libsfml-system.so.1.6 geeft geen foutmeldingen over onvoldoende rechten, maar geeft een hoop "rare tekens" Dus hij kan het bestand wel lezen.

Wat me overigens opvalt is dat ik in /usr/lib/ alle libsfml .so' s 2x zie staan: een keer een "echte" .so en een keer iets wat lijkt op een soort link naar een bestand (met dezelfde naam als de "echte" .so). Zou dit een link zijn naar de .so in /lib64/ ?

EDIT: ldd ./mijnprogramma doorgeven aan grep "not found" geeft de 2 .so' s waar ik naar link aan als "not found"

[ Voor 17% gewijzigd door Verwijderd op 19-02-2013 14:36 ]

[Soultaker]

Zitten die files nu in /usr/lib of in /lib64? /usr/lib zit in je system search path dus daar hoef je LD_LIBRARY_PATH niet voor aan te passen. Maar je instelling van LD_LIBRARY_PATH klopt sowieso niet echt want die zou je absoluut terug moeten zien in de uitvoer van LD_DEBUG, bijvoorbeeld op mijn systeem:

LD_LIBRARY_PATH=/xyzzy LD_DEBUG=libs /bin/true

     16333:	find library=libc.so.6 [0]; searching
     16333:	 search path=/xyzzy/tls/x86_64:/xyzzy/tls:/xyzzy/x86_64:/xyzzy	(LD_LIBRARY_PATH)
     16333:	  trying file=/xyzzy/tls/x86_64/libc.so.6
     16333:	  trying file=/xyzzy/tls/libc.so.6
     16333:	  trying file=/xyzzy/x86_64/libc.so.6
     16333:	  trying file=/xyzzy/libc.so.6
     16333:	 search cache=/etc/ld.so.cache
     16333:	  trying file=/lib64/libc.so.6

Natuurlijk heb je geen LD_LIBRARY_PATH instelling nodig als die library gewoon in het systeempad staat (waar 'ie ook hoort als je 'm via de package manager hebt geïnstalleerd).

Dat libraries geïnstalleerd worden met extra symlinks is vrij gebruikelijk. Wat er precies fout gaat is me dus nog niet helemaal duidelijk. Post eens de uitvoer van:

file ./mijnprogramma

en van:

file /usr/lib/libsfml-window.so.1.6

en indien dat een symlink is, dan ook van:

file -L /usr/lib/libsfml-window.so.1.6

[Verwijderd]

file ./mijnprogramma geeft:

code:

ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x22f76a00c79293684d27c4fa10d8bd67c853d287, not stripped

Wel raar dat er staat dat hij gelinked is voor Linux 2.6.32, ik gebruik 3.4.x

file /usr/lib/libsfml1.6-window.so.1.6 geeft:

code:

ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xf7b06bd8b89bab8e6d066b0c425448e9d17bd143, stripped

Dat SysV klopt ook niet, want Manjaro Linux gebruikt al SystemD

file -L op libsfml1.6-window.so.1.6 in /usr/lib geeft precies hetzelfde als zonder de -L flag.

Of ze nou in /usr/lib/ of in /lib64/ staan: nou in allebei, ik vind het ook een beetje raar. Maar misschien komt het doordat ik SFML1.6 heb geïnstalleerd met de package manager en ook nog eens "sudo make install" heb gedraaid op het zelf gedownloade exemplaar. Waardoor het dubbel geïnstalleerd is.

[ Voor 8% gewijzigd door Verwijderd op 19-02-2013 17:38 ]

[Soultaker]

In dat geval: probeer eens te hercompileren zonder -L/lib64 mee te geven op de command line, zodat er (hopelijk) tegen de library in /usr/lib gelinkt wordt?

(Overigens slaat SYSV in de uitvoer van file op de ELF ABI, niet op het init systeem. SYSV is een prima waarde aangezien Linux geen eigen ABI nummer heeft.)

[Verwijderd]

Ik heb eindelijk gevonden wat het probleem is: -lsfml-window en -lsfml-system laat de linker zoeken naar libsfml-window.so.1.6 en libsfml-system.so, maar libsfml-system.so.1.6 en libsfml-window.so.1.6 bestaan niet. Op mijn systeem wordt duidelijk onderscheid gemaakt tussen de SFML-versies: libsfml1.6-window.so.1.6 etc. Ik had al op internet gelezen over iemand die een soort gelijk probleem had, wat ook opgelost werd door de -l flag aan te passen. Maar nu pas drong het tot me door dat dit probleem ook bij mij van toepassing is.

Toen ik "g++ -o mijnprogramma -lsfml-window -lsfml-system ./mijnprogramma.cpp" veranderde in "g++ -o mijnprogramma -lsfml1.6-window -lsfml1.6-system ./mijnprogramma.cpp" startte mijn programma eindelijk op (nou nadat ik daarna ook nog "./mijnprogramma" invoerde natuurlijk ).

Wel dat het oplossen van dit kleine probleem zo tijdrovend was

[ Voor 5% gewijzigd door Verwijderd op 19-02-2013 18:12 ]

[Soultaker]

Eerder zei je nog dat die bestanden juist wél bestonden (hoewel je in je latere post wel de goede bestandsnaam gebruikte). We kunnen je niet helpen als je ons foutieve informatie voorschotelt, hè. Voortaan dus wat zorgvuldiger werken, dat voorkomt een hoop problemen als je wil programmeren!

[ Voor 14% gewijzigd door Soultaker op 19-02-2013 18:50 ]

[Verwijderd]

Ja, klopt. De fout was ook juist dat ik die "1.6" steeds over het hoofd zag