Gdzie pliki wykonywalne szukają współdzielonych obiektów w czasie wykonywania?

Rozumiem, jak zdefiniować dołączone obiekty w czasie łączenia / kompilacji. Nadal jednak zastanawiam się, jak pliki wykonywalne szukają współdzielonego obiektu ( *.sobibliotek) w czasie wykonywania.

Na przykład moja aplikacja a.outwywołuje funkcje zdefiniowane w lib.sobibliotece. Po kompilacji przechodzę lib.sodo nowego katalogu w moim $HOME.

Jak mogę powiedzieć, a.outżeby tam poszukać?

Wspólna biblioteka HOWTO wyjaśnia większość mechanizmów zaangażowanych i dynamicznych instrukcja ładowarka przechodzi w bardziej szczegółowo. Każdy wariant uniksowy ma swój własny sposób, ale większość używa tego samego formatu wykonywalnego ( ELF ) i ma podobne dynamiczne linkery (pochodzące z Solaris). Poniżej podsumuję typowe zachowanie z naciskiem na Linuksa; zajrzyj do instrukcji obsługi swojego systemu, aby uzyskać pełną historię.

W skrócie, gdy szuka dynamicznej biblioteki ( .sopliku), linker próbuje:

• katalogi wymienione w LD_LIBRARY_PATHzmiennej środowiskowej ( DYLD_LIBRARY_PATHw OSX);
• katalogi wymienione w ścieżce pliku wykonywalnego ;
• katalogi na ścieżce wyszukiwania systemu, która (przynajmniej w Linuksie) składa się z pozycji w /etc/ld.so.confplus /libi /usr/lib.

RPATH jest przechowywany w pliku wykonywalnego (to jest DT_RPATHalbo DT_RUNPATHatrybut dynamiczny). Może zawierać ścieżki bezwzględne lub ścieżki zaczynające się od, $ORIGINaby wskazać ścieżkę względem położenia pliku wykonywalnego (np. Jeśli plik wykonywalny jest w, /opt/myapp/bina jego ścieżka r to, $ORIGIN/../lib:$ORIGIN/../pluginsto dynamiczny linker będzie szukał /opt/myapp/libi /opt/myapp/plugins). Ścieżka rp jest zwykle określana podczas kompilacji pliku wykonywalnego, z -rpathopcją ld, ale można ją później zmienić za pomocą chrpath.

W scenariuszu można opisać, jeśli jesteś programistą lub pakującego wniosku i zamierza na to, aby być zainstalowane w …/bin, …/libstruktury, a następnie połączyć z -rpath='$ORIGIN/../lib'. Jeśli instalujesz wstępnie skompilowany plik binarny w systemie, umieść bibliotekę w katalogu na ścieżce wyszukiwania ( /usr/local/libjeśli jesteś administratorem systemu, w przeciwnym razie katalog, do którego dodajesz $LD_LIBRARY_PATH) lub spróbuj chrpath.

W Linuksie zachowanie jest wyjaśnione na ld(1)stronie 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.

Jestem prawie pewien, że odpowiedź brzmi tutaj ldconfig.

ldconfig tworzy niezbędne łącza i pamięć podręczną do najnowszych bibliotek współdzielonych znajdujących się w katalogach określonych w linii poleceń, w pliku /etc/ld.so.conf oraz w zaufanych katalogach (/ lib i / usr / lib). Pamięć podręczna jest używana przez linker wykonawczy, ld.so lub ld-linux.so. ldconfig sprawdza nagłówek i nazwy plików napotkanych bibliotek podczas określania, które wersje powinny mieć zaktualizowane łącza.

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

Do uruchamiania aplikacji plik /proc/1234/mapszawiera wszystkie rzeczywiste dynamicznie połączone biblioteki.

Gdzie 1234jest pid działającego pliku wykonywalnego.

Linux podąża za LD_LIBRARY_PATH i innymi zmiennymi, jak wskazał w odpowiedzi Gilles.