web-dev-qa-db-fra.com

Où Ubuntu cherche-t-il des bibliothèques partagées?

Lorsque j'exécute un processus lié à une bibliothèque partagée au moment de l'exécution (lié au démarrage du processus, et non lié ultérieurement à dlload()), où cherche-t-il ce fichier de bibliothèque partagée (.so) autre que LD_LIBRARY_PATH?

Background:

J'ai écrit du code C++ qui utilise une bibliothèque tierce particulière. J'ai installé la bibliothèque et compilé mon code sur deux plates-formes différentes, Ubuntu mais des versions différentes, ainsi que des versions différentes de gcc. La bibliothèque a été compilée et installée à partir des sources et se trouve dans /usr/local/lib sur les deux plates-formes. Lorsque je compile mon code, je fais un lien avec les paramètres pkg-config --libs pour la bibliothèque tierce et j'ai vérifié que pkg-config --libs renvoie exactement la même chose sur les deux plates-formes.

Mon code est compilé correctement sur les deux plates-formes et LD_LIBRARY_PATH n'est pas défini (ou défini comme vide: "") sur les deux plates-formes. Cependant, lorsque je l'exécute sur une plate-forme, cela fonctionne bien et sur l'autre, j'obtiens cette erreur:

error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory

Curieusement, ceux qui ne fonctionnent pas sont les versions les plus récentes d'Ubuntu et gcc. : /

J'essaie donc de comprendre comment le fonctionnaire est capable de localiser la bibliothèque, afin que celui qui est brisé puisse localiser la bibliothèque de la même manière. (c'est-à-dire sans définir LD_LIBRARY_PATH)

Mise à jour:

Voici ma sortie de cat /etc/ld.so.conf.d/*

... sur le système de travail (ancien):

/usr/lib/mesa
/usr/lib32/mesa
/usr/lib/alsa-lib
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

... sur le système cassé (plus récent):

# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/mesa
librariesshared-librarydynamic-linking
23
Dave Lillethun

Toute cette affaire de chemin est liée à quelque chose appelé multi-Arch. En gros, cela vous permet d'avoir des bibliothèques 32 bits et 64 bits sur le même système.

Après avoir copié le fichier, avez-vous déjà exécuté ldconfig?

ldconfig  creates,  updates,  and removes the necessary links and cache
       (for use by the run-time linker,  ld.so)  to  the  most  recent  shared
       libraries  found  in  the directories specified on the command line, in
       the file /etc/ld.so.conf, and in the trusted directories (/usr/lib  and
       /lib).   ldconfig  checks the header and file names of the libraries it
       encounters when determining which  versions  should  have  their  links
       updated.  ldconfig ignores symbolic links when scanning for libraries.
27
Matt H

Les informations contenues dans la question ci-dessus ET en premier (et uniquement ATT) réponse , m'ont aidé à résoudre * un problème similaire * sur le WSL Ubuntu (sur Win10 64)!

Dans mon cas l'exécutable n'a pas pu trouver de bibliothèque. J'ai finalement remarqué que la bibliothèque nouvellement créée s'était positionnée dans /usr/lib64, mais les lignes multi-arches de /etc/ld.so.conf.d/x86_64-linux-gnu.conf l'ont pas inclure ce répertoire.

Alors j'ai couru

Sudo ldconfig /usr/lib64

et cela a finalement résolu. (L'exécuter seul sans le paramètre directory ne permettait pas de trouver les bibliothèques BTW comme par magie.) Il est difficile de savoir si le "redémarrage" de mon bash WSL a aidé ... Je pense que n'était même pas nécessaire.

0
Jordan Gee