¿Dónde buscan los ejecutables los objetos compartidos en tiempo de ejecución?

Entiendo cómo definir incluir objetos compartidos en el momento de vinculación / compilación. Sin embargo, todavía me pregunto cómo buscan los ejecutables el objeto compartido ( *.sobibliotecas) en el momento de la ejecución.

Por ejemplo, mi aplicación a.outllama a funciones definidas en la lib.sobiblioteca. Después de compilar, me muevo lib.soa un nuevo directorio en mi $HOME.

¿Cómo puedo decir a.outque vaya a buscarlo allí?

El CÓMO de la biblioteca compartida explica la mayoría de los mecanismos involucrados, y el manual del cargador dinámico entra en más detalles. Cada variante de Unix tiene su propio camino, pero la mayoría usa el mismo formato ejecutable ( ELF ) y tiene vinculadores dinámicos similares (derivados de Solaris). A continuación resumiré el comportamiento común con un enfoque en Linux; Consulte los manuales de su sistema para ver la historia completa.

En pocas palabras, cuando busca una biblioteca dinámica ( .soarchivo), el enlazador intenta:

• directorios listados en la LD_LIBRARY_PATHvariable de entorno ( DYLD_LIBRARY_PATHen OSX);
• directorios listados en el rpath del ejecutable ;
• directorios en la ruta de búsqueda del sistema, que (al menos en Linux) consiste en las entradas en /etc/ld.so.confmás /liby /usr/lib.

El rpath se almacena en el archivo ejecutable (es el DT_RPATHo DT_RUNPATHatributo dinámico). Puede contener rutas absolutas o rutas que comiencen $ORIGINpor indicar una ruta relativa a la ubicación del ejecutable (por ejemplo, si el ejecutable está dentro /opt/myapp/biny su rpath está $ORIGIN/../lib:$ORIGIN/../pluginsentonces, el enlazador dinámico buscará /opt/myapp/liby /opt/myapp/plugins). La ruta normalmente se determina cuando se compila el ejecutable, con la -rpathopción de ld, pero puede cambiarlo después con chrpath.

En el escenario que usted describe, si usted es el desarrollador o con el empaquetador de la aplicación y tiene la intención de que sea instalado en una …/bin, …/libestructura, y luego enlazar con -rpath='$ORIGIN/../lib'. Si está instalando un binario precompilado en su sistema, coloque la biblioteca en un directorio en la ruta de búsqueda ( /usr/local/libsi es el administrador del sistema, de lo contrario, un directorio al que agregará $LD_LIBRARY_PATH), o intente chrpath.

En Linux, el comportamiento se explicita en la ld(1)página man

       The linker uses the following search paths to locate required
       shared libraries:

       1.  Any directories specified by -rpath-link options.

       2.  Any directories specified by -rpath options.  The difference
           between -rpath and -rpath-link is that directories specified by
           -rpath options are included in the executable and used at
           runtime, whereas the -rpath-link option is only effective at
           link time. Searching -rpath in this way is only supported by
           native linkers and cross linkers which have been configured
           with the --with-sysroot option.

       3.  On an ELF system, for native linkers, if the -rpath and
           -rpath-link options were not used, search the contents of the
           environment variable "LD_RUN_PATH".

       4.  On SunOS, if the -rpath option was not used, search any
           directories specified using -L options.

       5.  For a native linker, the search the contents of the environment
           variable "LD_LIBRARY_PATH".

       6.  For a native ELF linker, the directories in "DT_RUNPATH" or
           "DT_RPATH" of a shared library are searched for shared
           libraries needed by it. The "DT_RPATH" entries are ignored if
           "DT_RUNPATH" entries exist.

       7.  The default directories, normally /lib and /usr/lib.

       8.  For a native linker on an ELF system, if the file
           /etc/ld.so.conf exists, the list of directories found in that
           file.

       If the required shared library is not found, the linker will issue
       a warning and continue with the link.

Estoy bastante seguro de que la respuesta aquí es ldconfig.

ldconfig crea los enlaces y la caché necesarios para las bibliotecas compartidas más recientes que se encuentran en los directorios especificados en la línea de comando, en el archivo /etc/ld.so.conf y en los directorios de confianza (/ lib y / usr / lib). La memoria caché es utilizada por el enlazador en tiempo de ejecución, ld.so o ld-linux.so. ldconfig comprueba el encabezado y los nombres de archivo de las bibliotecas que encuentra al determinar qué versiones deben actualizar sus enlaces.

http://linux.die.net/man/8/ldconfig

Para ejecutar aplicaciones, el archivo /proc/1234/mapscontiene todas las bibliotecas vinculadas dinámicamente.

¿Dónde 1234está el pid del ejecutable en ejecución?

Linux sigue LD_LIBRARY_PATH y otras variables, como se señala en la respuesta de Gilles.