usa RPATH pero no RUNPATH?

Question

Esta página - http://labs.qt.nokia.com/2011/10/28/rpath-and-runpath/ - dice acerca del orden de búsqueda de la biblioteca 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 entonces sugieren:

Cuando se envía binarios, o bien utilizar rPath y no RUNPATH o garantizar LD_LIBRARY_PATH se establece antes de que se ejecuten.

Por lo tanto, el uso de RPATH con RUNPATH es malo porque RUNPATH tipo de cancela RPATH carga dinámica de modo indirecto no funciona como se esperaba? Pero ¿por qué entonces RPATH obsoleto a favor de RUNPATH?

¿Alguien puede explicar la situación?

Answer 1

Cuando envía un archivo binario, es bueno proporcionar los medios para que los usuarios puedan acomodar 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 ajustar LD_LIBRARY_PATH y /etc/ld.co.conf, ambos de los cuales está con menor precedencia que DT_RPATH, es decir, no se puede anular lo que está codificado en el binario, mientras que si se utiliza DT_RUNPATH lugar, un usuario puede anular con LD_LIBRARY_PATH .

(FWIW, creo que ld.so.conf también debe 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 de utilizar DT_RPATH. IMO, es mejor utilizar nether DT_RPATH no DT_RUNPATH en binarios enviados.

menos

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

Answer 2

La respuesta de Chill es exactamente correcta; Simplemente quería agregar un poco de color, a partir de una lectura reciente de la fuente glibc ([master 8b0ccb2], en 2.17). Para ser claros, si no se encuentra una biblioteca en la ubicación especificada por un nivel determinado, se intenta el siguiente nivel. Si se encuentra una biblioteca en un nivel determinado, la búsqueda se detiene.

dinámico Biblioteca Orden de búsqueda:

1. DT_RPATH en el binario ELF, a menos que DT_RUNPATH conjunto.
2. entradas LD_LIBRARY_PATH, a menos que setuid/setgid
3. DT_RUNPATH en las entradas de
4. /etc/ld.so.cache binarios ELF, a menos que nodeflib -z dado en tiempo de enlace
5. /lib,/usr/lib menos - z nodeflib
6. Hecho, "no encontrado".

Answer 3

Pero por qué entonces rPath quedó desfasada y en RUNPATH?

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

Más detalles se pueden encontrar en el trabajo "How to write shared libraries" escrito por Ulrich Drepper.