usa RPATH ma non RUNPATH?

Question

Questa pagina - http://labs.qt.nokia.com/2011/10/28/rpath-and-runpath/ - dice di ordine per la ricerca in biblioteca 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 

E poi suggeriscono:

Quando si invia i binari, utilizzare RPATH e non RunPath o garantire LD_LIBRARY_PATH è impostato prima che vengano eseguiti.

Quindi, utilizzando RPATH con RUNPATH è un male perché RUNPATH kind-of annulla RPATH in modo indiretto il caricamento dinamico non funziona come previsto? Ma perché allora lo RPATH è stato deprecato a favore di RUNPATH?

Qualcuno può spiegare la situazione?

Answer 1

Quando spedite un file binario, è utile fornire agli utenti mezzi per adattare il file binario alle specifiche del proprio sistema, tra le altre cose, regolando i percorsi di ricerca della libreria.

Un utente può generalmente modificare LD_LIBRARY_PATH e /etc/ld.co.conf, entrambi i quali sono con precedenza inferiore DT_RPATH, quindi non è possibile sostituire quello che viene codificato in binario, mentre se si utilizza DT_RUNPATH invece, un utente può ignorare con LD_LIBRARY_PATH .

(FWIW, penso che dovrebbe anche avere la precedenza su DT_RUNPATH, ma, almeno, abbiamo LD_LIBRARY_PATH).

Inoltre, sono fortemente in disaccordo con il suggerimento sopra riportato per utilizzare DT_RPATH. IMO, è meglio usare il nether DT_RPATH non DT_RUNPATH nei binari spediti.

meno

di spedire tutte le librerie dipendenti con i vostri eseguibili e desidera garantire che le cose JustWork (tm) dopo l'installazione, in questo caso l'uso DT_RPATH.

Answer 2

La risposta di Chill è esatta; Volevo semplicemente aggiungere un po 'di colore, da una lettura recente della fonte glibc ([master 8b0ccb2], in 2.17). Per essere chiari, se una libreria non viene trovata nella posizione specificata da un determinato livello, viene provato il livello successivo. Se una libreria viene trovata a un determinato livello, la ricerca si interrompe.

dinamico Biblioteca Ordine di ricerca:

1. DT_RPATH nel binario ELF, a meno che non DT_RUNPATH set.
2. voci LD_LIBRARY_PATH, a meno che non setuid/setgid
3. DT_RUNPATH nelle voci
4. /etc/ld.so.cache binari ELF, a meno che non nodeflib -z dato in fase di collegamento
5. /lib,/usr/lib a meno che - z nodeflib
6. Fine, "non trovato".

Answer 3

Ma perché poi RPATH ottenuto sconsigliato a favore RUNPATH?

Quando DT_RPATH è stato introdotto, aveva la precedenza su tutti gli altri parametri. Ciò ha reso impossibile sovrascrivere il percorso di ricerca delle librerie anche a fini di sviluppo. Quindi è stato introdotto un altro parametro, LD_RUNPATH, con precedenza inferiore rispetto a LD_LIBRARY_PATH.

Maggiori dettagli possono essere trovati nel lavoro "How to write shared libraries" scritto da Ulrich Drepper.