Où Ubuntu recherche-t-il les bibliothèques partagées?

Lorsque j'exécute un processus qui lie à une bibliothèque partagée au moment de l'exécution (lié au démarrage du processus, pas lié plus tard avec dlload()), où recherche-t-il ce .sofichier de bibliothèque partagée ( ) autre que LD_LIBRARY_PATH?

Contexte:

J'ai du code C ++ que j'ai écrit 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, et différentes versions de gcc également. La bibliothèque a été compilée et installée à partir des sources et se trouve /usr/local/libsur les deux plates-formes. Lorsque je compile mon code, je fais le lien avec les pkg-config --libsparamètres de la bibliothèque tierce et j'ai vérifié que cela pkg-config --libsrenvoie exactement la même chose sur les deux plates-formes.

Mon code se compile avec succès sur les deux plates-formes et LD_LIBRARY_PATHn'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 la nouvelle version d'Ubuntu et de gcc. : /

J'essaie donc de comprendre comment celui qui fonctionne peut localiser la bibliothèque, afin que je puisse faire en sorte que celui qui est cassé trouve la bibliothèque de la même manière. (c'est-à-dire sans réglage LD_LIBRARY_PATH)

Mise à jour:

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

... sur le système (plus ancien) qui fonctionne:

/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

Toute cette entreprise de cheminement est liée à quelque chose appelé multi-arch. Fondamentalement, c'est pour vous permettre d'avoir des bibliothèques 32 bits et 64 bits sur le même système.

Après avoir copié le fichier, avez-vous 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.

Les informations contenues dans la question ci-dessus ET la première (et la seule réponse ATT) , m'ont aidé à résoudre * un problème similaire * sur 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 était positionnée dans /usr/lib64, mais les lignes multi-arch de /etc/ld.so.conf.d/x86_64-linux-gnu.conf ne comprenaient pas ce répertoire.

Alors j'ai couru

sudo ldconfig /usr/lib64

et cela l'a finalement corrigé. (l'exécuter seul sans le paramètre de répertoire ne l'a pas fait trouver "par magie" les bibliothèques BTW.) Il n'est pas clair si le "redémarrage" de mon bash WSL a aidé ... Je pense que cela n'était même pas nécessaire.