Dove Ubuntu cerca le librerie condivise?

Quando eseguo un processo che si collega a una libreria condivisa in fase di runtime (collegato all'avvio del processo, non collegato in seguito con dlload()), dove cerca quel .sofile della libreria condivisa ( ) diverso da LD_LIBRARY_PATH?

Sfondo:

Ho del codice C ++ che ho scritto che utilizza una particolare libreria di terze parti. Ho installato la libreria e compilato il mio codice su due piattaforme diverse, entrambe Ubuntu ma versioni diverse e anche versioni diverse di gcc. La libreria è stata compilata e installata dal sorgente e si trova /usr/local/libsu entrambe le piattaforme. Quando compilo il mio codice, mi collego ai pkg-config --libsparametri per la libreria di terze parti e ho verificato che pkg-config --libsrestituisce esattamente la stessa cosa su entrambe le piattaforme.

Il mio codice viene compilato correttamente su entrambe le piattaforme e LD_LIBRARY_PATHnon è definito (o definito come vuoto:) ""su entrambe le piattaforme. Tuttavia, quando lo eseguo su un platoform funziona bene, e dall'altro ottengo questo errore:

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

Stranamente, quelli che non funzionano è la versione più recente di Ubuntu e gcc. : /

Quindi sto cercando di capire come quello che lavora è in grado di localizzare la libreria, in modo che io possa far sì che quello rotto localizzi la libreria allo stesso modo. (ovvero, senza impostazione LD_LIBRARY_PATH)

Aggiornare:

Ecco il mio output da cat /etc/ld.so.conf.d/*

... sul sistema di lavoro (precedente):

/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

... sul sistema rotto (più recente):

# 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

L'intero percorso aziendale è legato a qualcosa chiamato multi-arco. Fondamentalmente è per permetterti di avere librerie a 32 e 64 bit sullo stesso sistema.

Dopo aver copiato il file, ti è capitato di eseguire 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.

Le informazioni contenute nella domanda sopra E la prima (e unica risposta ATT) , mi hanno aiutato a risolvere * un mio simile * problema su WSL Ubuntu (su Win10 64)!

Nel mio caso l'eseguibile non è riuscito a trovare una libreria. Alla fine ho notato che la libreria appena fatto ottenuto posizionato /usr/lib64, ma le linee multi-Arco di /etc/ld.so.conf.d/x86_64-linux-gnu.conf fatto non includere tale directory.

Quindi ho corso

sudo ldconfig /usr/lib64

e questo finalmente risolto. (eseguirlo da solo senza il parametro directory non ha fatto in modo che "magicamente" trovasse le librerie BTW.) Non è chiaro se "riavviare" il mio bash WSL abbia aiutato ... Penso che non fosse nemmeno necessario.