C++ Linux-Linker-Problem mit einigen dynamischen Libs

[badday]

Hallo zusammen,

ich habe folgendes Szenario: Ich habe ein Programm und linke dieses mit verschiedenen Libs, die teilweise selbst wiederum Abhängigkeiten haben. Alle libs, gegen die gelinkt wird, liefere ich im bin-Verzeichnis mit, in der auch das executable liegt. Ich verwende die GCC.

Um den Linker anzuweisen, hier zu schauen, habe ich die executable mit der Option

-Wl,-rpath,$ORIGIN

gelinkt. Gemäß der Ausgabe von

readelf -d | grep RPATH

war das soweit auch erfolgreich. Gebe ich nun aber

ldd -v <binary>

ein, so werden 2 Libs nicht aufgelöst. Andere, die völlig analog mit dem selben Mechanismus und den selben Linker-Optionen gelinkt werden, werden völlig korrekt aufgelöst und gegen die Exemplare, die im bin-Ordner sind, gelinkt.
Der Ausgabe ist auch zu entnehmen, dass er offenbar direkt aus dem executable versucht, diese libs zu laden, es sind also nicht Abhängigkeiten anderer dyn. gelinkter libs. Andere, die ebenfalls direkt vom executable geladen werden, werden aber gelinkt wie gedacht.

Meine Frage daher: Woran könnte das liegen? Hat es vll. damit was zu tun, dass irgwelche statisch gelinkten libs in anderen rpaths nach Abhängigkeiten suchen?

Wenn weitere Infos benötigt werden, werde ich diese so schnell wie möglich bereitstellen.


Vielen Dank!


Gruß,

badday

 

[7H3 N4C3R]

Hmm... mach doch mal ein LD_DEBUG=all, bevor du das Executable startest.

man ld.so gibt weitere Infos.

Gibt es denn Fehler beim Start oder geht es dir nur im die ldd-Ausgabe? Mit LD_DEBUG kannst du auf jeden Fall rausfinden, woher die Symbols kommen, wenn sie gezogen werden.

Um welche Libs geht es denn? System-Libraries oder etwas selbstgebautes? Schonmal libtool probiert?

 

[IceMatrix]

ldd -v <binary> sucht nur in den default library pfaden nach deinen libraries. wenn die nicht dort liegen werden sie auch nicht gefunden. wenn du alternative pfade angeben willst musst du die umgebungsvariable LD_LIBRARY_PATH setzen, also z.B. LD_LIBRARY_PATH=$ORIGIN ldd -v <binary>

 

[7H3 N4C3R]

@IceMatrix: Spielt das noch eine Rolle bei RPATH?

 

[IceMatrix]

Sollte es normalerweise nicht tun, sofern die Binaries auf den Zielsystemen auch dort liegen. Ich würd davon dennoch Abstand nehmen es statisch in die Binary hinein zu kodieren, da unflexibel und nach meiner Kenntnis nicht weit verbreitet. badday solls einfach mal direkt per LD_LIBRARY_PATH testen ob die Binary damit zu laden ist.

 

[badday]

mach doch mal ein LD_DEBUG=all, bevor du das Executable startest.

Er versucht demnach in der Tat die library im bin-Ordner, sprich

trying file=/bin/lib.so.8

Danach sieht er sich offenbar veranlast, weitere Standard-Pfade zu durchsuchen, um dann am Ende die Fehlermeldung zu bringen, er hätte es nicht öffnen können, da nicht vorhanden.

Wichtig vll. noch: der Dateiname beinhaltet ein Sonderzeichen "+", was ich natürlich ändern kann, aber ich nehme mal an, dass ist kein Problem.

Um welche Libs geht es denn? System-Libraries oder etwas selbstgebautes?

System-Libraries. libcrypto++.so.8 (libcrypto++.so.8.0.0 liefere ich mit)

Schonmal libtool probiert?

Soweit ich das sehe, ist es eher dann interessant wenn man die Quelldateien samt makefile mitausliefert, damit es sich der Benutzer dann selber baut? Das möchte ich aber nicht.

wenn du alternative pfade angeben willst musst du die umgebungsvariable LD_LIBRARY_PATH setzen, also z.B. LD_LIBRARY_PATH=$ORIGIN ldd -v <binary>

Änder leider nichts.



Danke & Gruß,

badday

 

[IceMatrix]

Heißt die Datei denn lib.so.8? Du hast was von + Zeichen gesagt?

 

[badday]

Die Datei heißt crypto++.so.8.0.0, das habe ich nur zur Verkürzung benutzt

 

[7H3 N4C3R]

Mmh - zeig doch mal die Linker-Zeile komplett bzw. den relevanten Teil.

Du linkst schon einfach mit -lcrypt++? (+rpath)

Achso, ld.so ist einfach nur der stinknormale dynamische Loader - der lädt jedes dynamische Executable.

 

[IceMatrix]

Wenn es sich dabei und das Crypto++ von cryptopp.com handelt würde ich vorschlagen es direkt aufm System als Paket zu fordern und direkt über -lcrypto++ zu linken (ohne rpath). Alternativ sehe ich crypto++ auch oft als statisch gelinkte Bibliothek. Wenn du dennoch eine eigene shared Library haben willst solltest du auf jeden Fal über -lcrypto++ linken mit entsprechenden Suchpfaden, oder du gibst die shared Library direkt beim Linker über lib/libcrypto++.so an, das sollte auch gehen.

 

[badday]

Mmh - zeig doch mal die Linker-Zeile komplett bzw. den relevanten Teil.

g++  -o ../bin/executable ./obj/source.o 
-s -Wl,-rpath,\\$ORIGIN
-lcrypto++

Wenn es sich dabei und das Crypto++ von cryptopp.com handelt würde ich vorschlagen es direkt aufm System als Paket zu fordern und direkt über -lcrypto++ zu linken (ohne rpath)

Ja, es handelt sich darum. Allerdings denke ich, dass die verschiedenen Distributionen hier sehr verschiedene Versionsstände haben, daher würde ich es gerne mitliefern.

Alternativ sehe ich crypto++ auch oft als statisch gelinkte Bibliothek.

Ich bin mir da nicht sicher, ob das lizenzmäßig i. O. wäre, daher dachte ich an die dynamische Variante.

 

[IceMatrix]

Schau dir die Lizenz mal einfach durch. Ich weiß definitiv dass es von kommerzieller Software statisch gelinkt wird (z.B. von Steam). Crypto++ steht nicht unter GPL, sondern hat ne eigene Lizenz. Hab aufn ersten Blick auch nichts gefunden was das verbieten würde.

http://www.cryptopp.com/wiki/Related_Links

 

[badday]

Konnte das Problem nun beheben. Habe die lib von lib.so.8.0.0 in lib.so.8 umbenannt.