Gdzie Ubuntu szuka bibliotek współdzielonych?

Kiedy uruchamiam proces, który łączy się z biblioteką współużytkowaną w czasie wykonywania (połączony podczas uruchamiania procesu, nie połączony później z dlload()), gdzie szuka .soinnego pliku biblioteki współdzielonej ( ) niż LD_LIBRARY_PATH?

Tło:

Mam napisany przez siebie kod C ++, który korzysta z konkretnej biblioteki innej firmy. Zainstalowałem bibliotekę i skompilowałem mój kod na dwóch różnych platformach, zarówno Ubuntu, ale różnych wersjach, a także różnych wersjach gcc. Biblioteka została skompilowana i zainstalowana ze źródła i znajduje się /usr/local/libna obu platformach. Kiedy kompiluję kod, łączę się z pkg-config --libsparametrami biblioteki innej firmy i sprawdziłem, czy pkg-config --libszwraca to samo na obu platformach.

Mój kod kompiluje się pomyślnie na obu platformach i LD_LIBRARY_PATHnie jest zdefiniowany (lub zdefiniowany jako pusty:) ""na obu platformach. Jednak gdy uruchomię go na jednej platformie, działa dobrze, a na drugiej pojawia się ten błąd:

error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory

Co ciekawe, te, które nie działają, to nowsza wersja Ubuntu i gcc. : /

Próbuję więc dowiedzieć się, w jaki sposób działający jest w stanie zlokalizować bibliotekę, dzięki czemu uszkodzony mogę zlokalizować bibliotekę w ten sam sposób. (tj. bez ustawienia LD_LIBRARY_PATH)

Aktualizacja:

Oto mój wynik z cat /etc/ld.so.conf.d/*

... w działającym (starszym) systemie:

/usr/lib/mesa
/usr/lib32/mesa
/usr/lib/alsa-lib
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

... w zepsutym (nowszym) systemie:

# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/mesa

libraries shared-library dynamic-linking

— Dave Lillethun
źródło

Myślę, że te miejsca są zdefiniowane /etc/ld.so.conf.d/*.conf, ale nie jestem tego pewien.

— Salem,

Wydaje się, że tak, ale zobacz moją aktualizację OQ dla zawartości tych plików ... Wygląda na to, że powinien znaleźć, /usr/local/lib/libthrift-0.9.0.soale nadal powoduje błąd error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory... Czy jest jakiś powód, dla którego nie chciałby pobrać katalogu /etc/ld.so.conf.d/*.conf?

— Dave Lillethun,

Spróbuj uruchomić sudo ldconfig -vzgodnie z sugestią poniżej. Jeśli nadal nie działa, zaktualizuj swoje pytanie z wynikiem ldd /path/to/your/application.

— Salem,

Odpowiedzi:

Cały ten biznes związany jest ze ścieżką zwaną multi-arch. Zasadniczo pozwala to na posiadanie bibliotek 32-bitowych i 64-bitowych w tym samym systemie.

Czy po skopiowaniu pliku uruchomiłeś ldconfig?

ldconfig  creates,  updates,  and removes the necessary links and cache
       (for use by the run-time linker,  ld.so)  to  the  most  recent  shared
       libraries  found  in  the directories specified on the command line, in
       the file /etc/ld.so.conf, and in the trusted directories (/usr/lib  and
       /lib).   ldconfig  checks the header and file names of the libraries it
       encounters when determining which  versions  should  have  their  links
       updated.  ldconfig ignores symbolic links when scanning for libraries.

— Matt H.
źródło

Pobiegłem sudo ldconfigi to rozwiązało problem! (Nie musiałem ponownie kompilować mojego kodu ani nic ...) Chcę tylko zrozumieć ... Powiedziałeś „Po skopiowaniu pliku”, ale nie skopiowałem pliku. Masz na myśli po tym, jak skompilowałem i zainstalowałem bibliotekę lub po skompilowaniu mojego programu?

— Dave Lillethun,

Po umieszczeniu go tam, gdzie go umieściłeś. Zasadniczo jest budowana pamięć podręczna biblioteki. Myślę, że ponowne uruchomienie może również odbudować pamięć podręczną.

— Matt H

Mogę się mylić, ale wydaje mi się, że zrestartowałem się od czasu zainstalowania biblioteki ... Jednak sudo ldconfigudało się. Czy jest to coś, co biblioteki często uruchamiają automatycznie w ramach instalacji, a ta z jakiegoś powodu nie? Po prostu zastanawiasz się, dlaczego nie „normalnie” trzeba to zrobić, ale nie tylko w tym przypadku ...

— Dave Lillethun

Zwykle myślę, że instalacja pakietu uruchomi ldconfig podczas procesu instalacji. Może wersja z nowej dystrybucji nie robi tego z jakiegoś powodu.

— Matt H

Informacje zawarte w powyższym pytaniu ORAZ pierwsza (i tylko ATT) odpowiedź pomogły mi rozwiązać * podobny * mój problem na WSL Ubuntu (na Win10 64)!

W moim przypadku plik wykonywalny nie mógł znaleźć biblioteki. I w końcu zauważył, że nowo wykonany został umieszczony w bibliotece /usr/lib64, ale na multi-arch linie /etc/ld.so.conf.d/x86_64-linux-gnu.conf czy nie zawierają tego katalogu.

Więc pobiegłem

sudo ldconfig /usr/lib64

i to w końcu to naprawiło. (samo uruchomienie bez parametru katalogu nie spowodowało, że „magicznie” znalazło biblioteki BTW.) Nie jest jasne, czy „ponowne uruchomienie” mojej bash WSL pomogło ... Myślę, że to nawet nie było potrzebne.

— Jordan Gee
źródło

To samo przytrafiło mi się z / usr / local / lib /. Utworzyłem plik, /etc/ld.so.conf.d/usr-local.confa następnie uruchomiłem sudo ldconfigbez efektu - biblioteki w tym katalogu nie zostały znalezione przez moduł ładujący. Po uruchomieniu sudo ldconfig /usr/local/libwszystko działało dobrze.

— Josh Milthorpe