Dove gli eseguibili cercano oggetti condivisi in fase di esecuzione?


102

Capisco come definire includere oggetti condivisi in fase di collegamento / compilazione. Tuttavia, mi chiedo ancora come gli eseguibili cercano l'oggetto condiviso ( *.solibrerie) al momento dell'esecuzione.

Ad esempio, la mia app a.outchiama le funzioni definite nella lib.solibreria. Dopo la compilazione, mi sposto lib.soin una nuova directory nella mia $HOME.

Come posso dire a.outdi andare a cercarlo lì?

Risposte:


102

La libreria condivisa HOWTO spiega la maggior parte dei meccanismi coinvolti e il manuale del caricatore dinamico viene approfondito. Ogni variante di unix ha il suo modo, ma la maggior parte utilizza lo stesso formato eseguibile ( ELF ) e ha linker dinamici simili (derivati ​​da Solaris). Di seguito riassumerò il comportamento comune con un focus su Linux; controlla i manuali del tuo sistema per la storia completa.

In poche parole, quando cerca una libreria ( .sofile) dinamica il linker prova:

  • directory elencate nella LD_LIBRARY_PATHvariabile d'ambiente ( DYLD_LIBRARY_PATHsu OSX);
  • directory elencate nella dell'eseguibile rPath ;
  • directory sul percorso di ricerca del sistema, che (almeno su Linux) è costituito dalle voci in /etc/ld.so.confpiù /libe /usr/lib.

Il percorso è memorizzato nell'eseguibile (è l' attributo DT_RPATHo DT_RUNPATHdinamico). Può contenere percorsi assoluti o percorsi che iniziano con $ORIGINper indicare un percorso relativo alla posizione dell'eseguibile (ad es. Se l'eseguibile è dentro /opt/myapp/bine il suo percorso è $ORIGIN/../lib:$ORIGIN/../pluginsallora il linker dinamico cercherà dentro /opt/myapp/libe /opt/myapp/plugins). Il rpath viene normalmente determinato quando viene compilato l'eseguibile, con l' -rpathopzione to ld, ma è possibile modificarlo in seguito con chrpath.

Nello scenario che descrivi, se sei lo sviluppatore o del confezionatore della richiesta e l'intenzione per essere installato in una …/bin, …/libla struttura, quindi collegare con -rpath='$ORIGIN/../lib'. Se stai installando un binario predefinito sul tuo sistema, inserisci la libreria in una directory sul percorso di ricerca ( /usr/local/libse sei l'amministratore di sistema, altrimenti una directory a cui aggiungi $LD_LIBRARY_PATH), oppure prova chrpath.


3
In alcuni sistemi, /lib64e /usr/lib64sono utilizzati per 64 bit binari ed /libe /usr/libsono utilizzati per 32 binari bit.
— Mark Lakata,

Perché questa risposta corretta non parla di ldconfig ??
— Loves Probability,

1
@LovesProbability Perché la domanda era su dove gli eseguibili cercano le librerie, il che non comporta ldconfig. ldconfigviene coinvolto quando si installa una libreria.
— Gilles,

1
Si noti che il "percorso di ricerca del sistema" per le *.solibrerie non è lo stesso di $PATH. Il percorso di ricerca è indicato da @enzotib nella loro risposta. Per stampare i percorsi che verranno cercati, eseguire ldconfig -v 2>/dev/null | grep -v ^$'\t'.
— Andrew Bate,

per me, per eseguire ldconfig, avevo bisogno /sbin/ldconfige quell'altra magia di Andrew Bate per farlo funzionare senza root
— Robert Lugg,

16

In Linux il comportamento è esplicitato nella ld(1)pagina 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.

1
"Le directory predefinite, normalmente / lib e / usr / lib." -> come posso sapere se il mio sistema è normale?
— Thorsten Staerk,

2
La domanda riguarda il tempo di esecuzione e non il tempo di collegamento
— Talespin_Kit

2

Sono abbastanza sicuro che la risposta qui sia ldconfig.

ldconfig crea i collegamenti e la cache necessari alle più recenti librerie condivise trovate nelle directory specificate sulla riga comandi, nel file /etc/ld.so.conf e nelle directory attendibili (/ lib e / usr / lib). La cache viene utilizzata dal linker di runtime, ld.so o ld-linux.so. ldconfig controlla l'intestazione e i nomi dei file delle librerie che incontra quando determina quali versioni debbano aggiornare i loro collegamenti.

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


0

Per le applicazioni in esecuzione, il file /proc/1234/mapscontiene tutte le librerie collegate dinamicamente.

Dov'è 1234il pid dell'eseguibile in esecuzione.

Linux segue LD_LIBRARY_PATH e altre variabili, come sottolineato nella risposta di Gilles.


4
È bello che tu confermi nella tua seconda frase che la risposta di Gilles aiuta. La prima parte tuttavia non contribuisce affatto a spiegare come dire a.out dove sono i file, solo da dove sono stati ottenuti se sono già stati trovati. Tutto sommato, questo dovrebbe essere solo un commento, non una risposta.
— Anthon,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.