Traçage des bibliothèques liées

Question

Je reçois des erreurs qui me font penser que mon programme Linux ne crée pas de liens vers les bibliothèques auxquelles il est censé appartenir. Comment puis-je obtenir le chemin complet de toutes les bibliothèques liées? Je sais que ldd va me donner les noms, mais comment puis-je l'utiliser pour obtenir le chemin complet?

Merci.

Answer 1

En fait ldd vous donne le chemin absolu avec le nom de fichier de tout ce que les dépendances de bibliothèques partagées de votre application peuvent trouver.

$ ldd v8test 
    linux-gate.so.1 => (0xb78b2000) 
    libz.so.1 => /usr/lib/libz.so.1 (0xb787e000) 
    librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7875000) 
    libcppunit-1.12.so.1 => /usr/lib/libcppunit-1.12.so.1 (0xb782c000) 
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7604000) 
    libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb75dd000) 
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb75bf000) 
    libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7478000) 
    libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb745f000) 
    libboost_system-mt.so.1.38.0 => /usr/lib/libboost_system-mt.so.1.38.0 (0xb745b000) 
    /lib/ld-linux.so.2 (0xb78b3000) 
    libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7456000) 
    libboost_thread-mt.so.1.38.0 => /usr/lib/libboost_thread-mt.so.1.38.0 (0xb7383000) 
    libboost_filesystem-mt.so.1.38.0 => /usr/lib/libboost_filesystem-mt.so.1.38.0 (0xb7370000) 
    libtinyxml.so.1 => /home/dmitry/tinyxml/libtinyxml.so.1 (0xb7359000) 
    libboost_regex-mt.so.1.38.0 => /usr/lib/libboost_regex-mt.so.1.38.0 (0xb728c000) 
    libmysqlclient_r.so.15 => /usr/lib/libmysqlclient_r.so.15 (0xb70a1000) 
    libicuuc.so.42 => /usr/lib/libicuuc.so.42 (0xb6f61000) 
    libicudata.so.42 => /usr/lib/libicudata.so.42 (0xb601a000) 
    libicui18n.so.42 => /usr/lib/libicui18n.so.42 (0xb5e6b000) 
    libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb5e39000) 
    libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb5e22000) 

Les bibliothèques sont recherchées par sa soname (par exemple libboost_filesystem-mt.so.1.38.0) dans les chemins mentionnés dans /etc/ld.so.conf, LD_LIBRARY_PATHrpath ou serties dans le binaire lui-même.

Si ldd est incapable de trouver quelque chose qu'il va ressembler à

libicuuc.so.42 => not found 

Dans ce cas, envisagez d'utiliser l'un des moyens mentionnés pour donner le chemin de recherche correcte.

ldd vous avertira s'il est impossible de charger la bibliothèque pour une raison quelconque.

$ ldd v8test 
./v8test: error while loading shared libraries: /home/dmitry/a/liba.so.2: invalid ELF header 

Bien sûr, il ne peut pas vous protéger des erreurs dans la bibliothèque elle-même. En fait, il est possible que votre application dépende des bibliothèques A et B, toutes deux dépendant de versions incompatibles sur une bibliothèque C. Dans cette situation votre programme a une bonne chance de planter (sauf si la bibliothèque C n'a pas symbol versioning) - ldd ne va pas pour vous avertir, mais vous devriez être capable de le voir dans la sortie.

Program-Library-HOWTO vous sera utile. Vérifiez également certaines options de ldd ou dynamic linker.