¿Dónde busca Ubuntu las bibliotecas compartidas?

Cuando ejecuto un proceso que se vincula a una biblioteca compartida en tiempo de ejecución (vinculado cuando se inicia el proceso, no vinculado posteriormente dlload()), ¿dónde busca ese .soarchivo de biblioteca compartida ( ) diferente LD_LIBRARY_PATH?

Fondo:

Tengo un código C ++ que escribí que usa una biblioteca de terceros en particular. He instalado la biblioteca y he compilado mi código en dos plataformas diferentes, ambas Ubuntu pero diferentes versiones, y también diferentes versiones de gcc. La biblioteca se compiló e instaló desde el origen, y se encuentra en /usr/local/libambas plataformas. Cuando compilo mi código, enlazo con los pkg-config --libsparámetros de la biblioteca de terceros y he verificado que pkg-config --libsdevuelve exactamente lo mismo en ambas plataformas.

Mi código se compila correctamente en ambas plataformas y LD_LIBRARY_PATHno está definido (o definido como vacío:) ""en ambas plataformas. Sin embargo, cuando lo ejecuto en una plataforma funciona bien, y en la otra me sale este error:

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

Curiosamente, la que no funciona es la versión más nueva de Ubuntu y gcc. : /

Así que estoy tratando de descubrir cómo el que trabaja puede localizar la biblioteca, de modo que pueda hacer que el roto localice la biblioteca de la misma manera. (es decir, sin configuración LD_LIBRARY_PATH)

Actualizar:

Aquí está mi salida de cat /etc/ld.so.conf.d/*

... en el sistema de trabajo (más antiguo):

/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

... en el sistema roto (más nuevo):

# 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

libraries shared-library dynamic-linking

— Dave Lillethun
fuente

Creo que esos lugares están definidos /etc/ld.so.conf.d/*.conf, pero no estoy seguro de eso.

— Salem

Parece que sí, pero vea mi actualización de OQ para ver el contenido de esos archivos ... Parece que debería encontrar /usr/local/lib/libthrift-0.9.0.sopero aún así da el error error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory... ¿Hay alguna razón por la que no recogería un directorio /etc/ld.so.conf.d/*.conf?

— Dave Lillethun

Intenta correr sudo ldconfig -vcomo se sugiere a continuación. Si todavía no funciona, actualice su pregunta con la salida de ldd /path/to/your/application.

— Salem el

Respuestas:

Todo este camino está relacionado con algo llamado multi-arco. Básicamente es para permitirle tener bibliotecas de 32 bits y 64 bits en el mismo sistema.

Después de copiar el archivo, ¿ejecutó 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.

— Matt H
fuente

Corrí sudo ldconfigy eso solucionó el problema! (No necesitaba volver a compilar mi código ni nada ...) Solo quiero entender, sin embargo ... Usted dijo "Después de copiar el archivo", pero no copié un archivo. ¿Quiere decir después de que construí e instalé la biblioteca, o después de compilar mi programa?

— Dave Lillethun

Después de colocarlo donde lo colocó. Básicamente se construye un caché de biblioteca. Creo que reiniciar también puede reconstruir el caché.

— Matt H

Puedo estar equivocado, pero creo que me reinicié desde que instalé la biblioteca ... Sin embargo, sudo ldconfigfuncionó. ¿Es esto algo que las bibliotecas a menudo se ejecutan automáticamente para usted como parte de su instalación, y esta por alguna razón no lo hizo? Solo me preguntaba por qué no "normalmente" tengo que hacer esto, pero solo lo hice en este caso ...

— Dave Lillethun

Por lo general, creo que la instalación del paquete ejecutará ldconfig durante el proceso de instalación. Tal vez la versión en su distribución más nueva no lo esté haciendo por alguna razón.

— Matt H

¡La información contenida en la pregunta anterior Y la primera (y solo ATT) respuesta , me ayudó a resolver * un * problema mío similar en WSL Ubuntu (en Win10 64)!

En mi caso, el ejecutable no pudo encontrar una biblioteca. Me di cuenta de que en última instancia, la biblioteca recién hecho quedó posicionada en /usr/lib64, pero las líneas de múltiples arquitecturas de /etc/ld.so.conf.d/x86_64-linux-gnu.conf lo que no incluyo ese directorio.

Entonces corrí

sudo ldconfig /usr/lib64

y eso finalmente lo arregló. (ejecutarlo solo sin el parámetro de directorio no lo hizo 'mágicamente' para encontrar las bibliotecas, por cierto). No está claro si 'reiniciar' mi WSL bash ayudó ... Creo que ni siquiera era necesario.

— Jordan Gee
fuente

Lo mismo me sucedió con / usr / local / lib /. Creé un archivo /etc/ld.so.conf.d/usr-local.confy luego lo ejecuté sudo ldconfigsin efecto: el cargador no encontró las bibliotecas en ese directorio. Después de correr, sudo ldconfig /usr/local/libtodo funcionó bien.

— Josh Milthorpe