c shared library example

usar RPATH pero no RUNPATH?

Question

Esta página - http://labs.qt.nokia.com/2011/10/28/rpath-and-runpath/ - dice acerca del orden para la búsqueda de bibliotecas en ld.so:

Unless loading object has RUNPATH:
    RPATH of the loading object,
        then the RPATH of its loader (unless it has a RUNPATH), ...,
        until the end of the chain, which is either the executable
        or an object loaded by dlopen
    Unless executable has RUNPATH:
        RPATH of the executable
LD_LIBRARY_PATH
RUNPATH of the loading object
ld.so.cache
default dirs

Y luego sugerir:

Cuando envía binarios, use RPATH y no RUNPATH o asegúrese de que LD_LIBRARY_PATH esté establecido antes de que se ejecuten.

Entonces, el uso de RPATH con RUNPATH es malo porque el tipo de RPATH cancela el RPATH por lo que la carga dinámica indirecta no funciona como se esperaba? Pero, ¿por qué entonces RPATH quedó en desuso a favor de RUNPATH ?

¿Alguien puede explicar la situación?

Answer 1

Pero, ¿por qué entonces RPATH quedó en desuso a favor de RUNPATH?

Cuando se introdujo DT_RPATH, tenía prioridad sobre todos los demás parámetros. Esto hizo imposible anular la ruta de búsqueda de las bibliotecas, incluso con fines de desarrollo. Por lo tanto, se introdujo otro parámetro, LD_RUNPATH, que tiene una prioridad menor que LD_LIBRARY_PATH.

Se pueden encontrar más detalles en el trabajo "Cómo escribir bibliotecas compartidas" escrito por Ulrich Drepper .

Answer 2

Cuando envía un binario, es bueno proporcionar medios para que los usuarios adapten el binario a las características específicas de su propio sistema, entre otras cosas, ajustando las rutas de búsqueda de la biblioteca.

Un usuario generalmente puede modificar LD_LIBRARY_PATH y /etc/ld.co.conf , ambos con menor prioridad que DT_RPATH , es decir, no puede anular lo que está codificado en el binario, mientras que si utiliza DT_RUNPATH, un usuario puede anular con LD_LIBRARY_PATH.

(FWIW, creo que ld.so.conf también debería tener prioridad sobre DT_RUNPATH , pero, de todos modos, al menos tenemos LD_LIBRARY_PATH ).

Además, estoy totalmente en desacuerdo con la sugerencia anterior para usar DT_RPATH . En mi opinión, es mejor usar DT_RPATH no DT_RUNPATH en los archivos binarios enviados.

a no ser que

envía todas sus bibliotecas dependientes con sus ejecutables y desea asegurarse de que las cosas que JustWork (tm) después de la instalación, utilizan DT_RPATH .

Answer 3

La respuesta de Chill es exactamente correcta; Quería simplemente agregar algo de color, de una lectura reciente de la fuente de glibc ([master 8b0ccb2], en 2.17). Para que quede claro, si no se encuentra una biblioteca en la ubicación especificada por un nivel dado, se intenta el siguiente nivel. Si se encuentra una biblioteca en un nivel determinado, la búsqueda se detiene.

Orden de búsqueda de biblioteca dinámica:

1. DT_RPATH en el binario ELF, a menos que se establezca DT_RUNPATH.
2. Entradas LD_LIBRARY_PATH, a menos que setuid / setgid
3. DT_RUNPATH en binario ELF
4. Entradas /etc/ld.so.cache, a menos que se especifique -z nodeflib en el momento del enlace
5. / lib, / usr / lib a menos que -z nodeflib
6. Hecho, "no encontrado".