Błąd systemu Linux podczas ładowania bibliotek współdzielonych: nie można otworzyć pliku obiektu współdzielonego: brak takiego pliku lub katalogu

Program jest częścią pakietu testowego Xenomai, skompilowanego krzyżowo z Linux PC na Linux + Xenomai ARM toolchain.

# echo $LD_LIBRARY_PATH                                                                                                                                          
/lib                                                                                                                                                             
# ls /lib                                                                                                                                                        
ld-2.3.3.so         libdl-2.3.3.so      libpthread-0.10.so                                                                                                       
ld-linux.so.2       libdl.so.2          libpthread.so.0                                                                                                          
libc-2.3.3.so       libgcc_s.so         libpthread_rt.so                                                                                                         
libc.so.6           libgcc_s.so.1       libstdc++.so.6                                                                                                           
libcrypt-2.3.3.so   libm-2.3.3.so       libstdc++.so.6.0.9                                                                                                       
libcrypt.so.1       libm.so.6                                                                                                                                    
# ./clocktest                                                                                                                                                    
./clocktest: error while loading shared libraries: libpthread_rt.so.1: cannot open shared object file: No such file or directory                                 

Edycja: OK Nie zauważyłem, że .1 na końcu było częścią nazwy pliku. Co to w ogóle znaczy?

Aktualizacja
Chociaż to, co piszę poniżej, jest prawdą jako ogólna odpowiedź na temat bibliotek współdzielonych, myślę, że najczęstszą przyczyną tego rodzaju wiadomości jest to, że zainstalowałeś pakiet, ale nie zainstalowałeś wersji „-dev” tego pakietu.

Cóż, to nie kłamstwo - nie ma go libpthread_rt.so.1na tej liście. Prawdopodobnie konieczna będzie ponowna konfiguracja i ponowna kompilacja, tak aby zależało to od posiadanej biblioteki lub zainstalowania tego, co udostępnia libpthread_rt.so.1.

Zasadniczo liczby po .so są numerami wersji i często okaże się, że są to dowiązania symboliczne, więc jeśli masz wersję 1.1 libfoo.so, będziesz mieć prawdziwy plik libfoo.so.1.0, i dowiązania symboliczne foo.so i foo.so.1 wskazujące na libfoo.so.1.0. A jeśli zainstalujesz wersję 1.1 bez usuwania drugiej, będziesz mieć libfoo.so.1.1, a libfoo.so.1 i libfoo.so będą teraz wskazywać na nowy, ale każdy kod, który wymaga tej dokładnej wersji, może użyj pliku libfoo.so.1.0. Kod, który opiera się tylko na interfejsie API wersji 1, ale nie obchodzi go, czy to 1.0, czy 1.1, określa libfoo.so.1. Jak zauważył orip w komentarzach, wyjaśniono to dobrze na stronie http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html .

W twoim przypadku, to może uciec z symlinking libpthread_rt.so.1do libpthread_rt.so. Nie ma jednak gwarancji, że nie złamie twojego kodu i nie zje obiadów telewizyjnych.

Twoja biblioteka jest biblioteką dynamiczną. Musisz powiedzieć systemowi operacyjnemu, gdzie może go zlokalizować w czasie wykonywania.

Aby to zrobić, musimy wykonać te proste kroki:

(1) Znajdź, gdzie znajduje się biblioteka, jeśli jej nie znasz.

sudo find / -name the_name_of_the_file.so

(2) Sprawdź, czy istnieje zmienna środowiskowa dynamicznej ścieżki biblioteki ( LD_LIBRARY_PATH)

$ echo $LD_LIBRARY_PATH

jeśli nie ma nic do wyświetlenia, dodaj domyślną wartość ścieżki (lub nie, jeśli chcesz)

$ LD_LIBRARY_PATH=/usr/local/lib

(3) Dodajemy ścieżkę pożądania, eksportujemy ją i wypróbowujemy aplikację.

Zauważ, że ścieżka powinna być katalogiem, w którym się path.so.somethingznajduje. Więc jeśli path.so.somethingjest w /my_library/path.so.somethingnim, powinno być:

$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_library/
$ export LD_LIBRARY_PATH
$ ./my_app

źródło: http://www.gnu.org/software/gsl/manual/html_node/Shared-Libraries.html

Oto kilka rozwiązań, które możesz wypróbować:

ldconfig

Jak wskazał AbiusX: Jeśli właśnie zainstalowałeś bibliotekę, być może będziesz musiał po prostu uruchomić ldconfig .

sudo ldconfig

ldconfig tworzy niezbędne łącza i pamięć podręczną do najnowszych bibliotek współdzielonych znalezionych w katalogach określonych w wierszu poleceń, w pliku /etc/ld.so.conf oraz w zaufanych katalogach (/ lib i / usr / lib).

Zwykle menedżer pakietów zajmie się tym podczas instalowania nowej biblioteki, ale nie zawsze, i nie zaszkodzi uruchomić ldconfig, nawet jeśli nie jest to twój problem.

Pakiet deweloperski lub zła wersja

Jeśli to nie zadziała, sprawdziłbym również sugestię Paula i poszukał „-dev” wersji biblioteki. Wiele bibliotek jest podzielonych na pakiety programistyczne i inne. Możesz użyć tego polecenia, aby go wyszukać:

apt-cache search <libraryname>

Może to również pomóc, jeśli po prostu masz zainstalowaną niewłaściwą wersję biblioteki. Niektóre biblioteki są publikowane jednocześnie w różnych wersjach, na przykład Python.

Lokalizacja biblioteki

Jeśli masz pewność, że odpowiedni pakiet został zainstalowany, a ldconfig go nie znalazł, może on znajdować się w niestandardowym katalogu. Domyślnie ldconfig wygląda w /lib, /usr/libi katalogi wymienione w /etc/ld.so.confi $LD_LIBRARY_PATH. Jeśli twoja biblioteka jest gdzieś indziej, możesz dodać katalog do własnego wiersza /etc/ld.so.conf, dołączyć ścieżkę do $LD_LIBRARY_PATHbiblioteki lub przenieść bibliotekę /usr/lib. Potem biegnij ldconfig.

Aby dowiedzieć się, gdzie jest biblioteka, spróbuj tego:

sudo find / -iname *libraryname*.so*

(Zamień librarynamena nazwę swojej biblioteki)

Jeśli wybierzesz $LD_LIBRARY_PATHtrasę, zechcesz umieścić ją w swoim ~/.bashrcpliku, aby był uruchamiany przy każdym logowaniu:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/library

Miałem podobny błąd, mogłem go rozwiązać, podając,

sudo ldconfig -v

Mam nadzieję że to pomoże.

Musisz upewnić się, że określasz ścieżkę biblioteki podczas łączenia podczas kompilacji pliku .c:

gcc -I / usr / local / include xxx.c -o xxx -L / usr / local / lib -Wl, -R / usr / local / lib

Część -Wl, -R mówi wynikowemu plikowi binarnemu, aby szukał również biblioteki w / usr / local / lib w czasie wykonywania, zanim spróbuje użyć tej w / usr / lib /

Mam nadzieję, że ci to pomoże.

Spróbuj dodać plik LD_LIBRARY_PATH, który wskazuje ścieżki wyszukiwania~/.bashrc

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path_to_your_library

To działa!

Strona referencyjna linux.org wyjaśnia mechanikę, ale nie wyjaśnia motywacji :-(

Aby to zrobić , zobacz Sun Linker i przewodnik po bibliotekach

Ponadto zauważ, że „zewnętrzna wersja” jest w dużej mierze przestarzała w Linuksie, ponieważ wersjonowanie symboli (rozszerzenie GNU) pozwala na posiadanie wielu niekompatybilnych wersji tej samej funkcji, które mogą być obecne w jednej bibliotece. To rozszerzenie pozwoliło glibc mieć tę samą wersję zewnętrzną: libc.so.6przez ostatnie 10 lat.

cd /home/<user_name>/
sudo vi .bash_profile

dodaj te linie na końcu

LD_LIBRARY_PATH=/usr/local/lib:<any other paths you want>
export LD_LIBRARY_PATH

Miałem podobny błąd i nie naprawiłem się, podając LD_LIBRARY_PATH w ~ / .bashrc. Rozwiązałem mój problem, dodając plik .conf i ładując go. Idź do terminalu i bądź w su.

gedit /etc/ld.so.conf.d/myapp.conf

Dodaj ścieżkę do biblioteki w tym pliku i zapisz. (Np .: / usr / local / lib). Musisz uruchomić następujące polecenie, aby aktywować ścieżkę:

ldconfig

Sprawdź swoją nową ścieżkę do biblioteki:

ldconfig -v | less

Jeśli pokazuje to twoje pliki bibliotek, możesz zacząć.

Inne możliwe rozwiązanie w zależności od twojej sytuacji.

Jeśli wiesz, że libpthread_rt.so.1 jest taki sam jak libpthread_rt.so, możesz utworzyć dowiązanie symboliczne poprzez:

ln -s /lib/libpthread_rt.so /lib/libpthread_rt.so.1

Następnie ls -l /libpowinien teraz pokazać dowiązanie symboliczne i to, na co wskazuje.

Wystąpił ten błąd podczas uruchamiania aplikacji za pomocą Eclipse CDT w systemie Linux x86.
Aby to naprawić:

1. W środowisku Eclipse:

   Uruchom jako -> Uruchom konfiguracje -> Środowisko

2. Ustaw ścieżkę

   LD_LIBRARY_PATH=/my_lib_directory_path
   

Wszystko, co musiałem zrobić, to uruchomić:

sudo apt-get install libfontconfig1

Byłem w folderze znajdującym się pod /usr/lib/x86_64-linux-gnui działało idealnie.

Jeśli aplikacja jest uruchomiona w systemie Microsoft Windows, ścieżkę do bibliotek dynamicznych (.dll) należy zdefiniować w zmiennej środowiskowej PATH.

Jeśli aplikacja jest uruchomiona w systemie UNIX, ścieżkę do bibliotek dynamicznych (.so) należy zdefiniować w zmiennej środowiskowej LD_LIBRARY_PATH.

spróbuj zainstalować sudo lib32z1

sudo apt-get install lib32z1

Błąd występuje, ponieważ system nie może odwoływać się do wspomnianego pliku biblioteki. Wykonaj następujące kroki:

1. Uruchomiony locate libpthread_rt.so.1wyświetli ścieżkę do wszystkich plików o tej nazwie. Załóżmy, że ścieżka jest /home/user/loc.
2. Skopiuj ścieżkę i uruchom cd home/USERNAME. Zamień USERNAME na nazwę bieżącego aktywnego użytkownika, z którym chcesz uruchomić plik.
3. Uruchom vi .bash_profilei na końcu LD_LIBRARY_PATHparametru, tuż przed ., dodaj linię /lib://home/usr/loc:.. Zapisz plik.
4. Zamknij terminal i uruchom ponownie aplikację. Powinien biec.

Wystąpił ten błąd i myślę, że to ten sam powód

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

Spróbuj tego. Napraw uprawnienia do plików:

cd /opt/Popcorn (or wherever it is) 
chmod -R 555 * (755 if not ok) 
chown -R root:root *

„Sudo su”, aby uzyskać uprawnienia do systemu plików.

Wystąpił ten błąd i myślę, że to ten sam powód

błąd podczas ładowania bibliotek współdzielonych: libnw.so: nie można otworzyć pliku obiektu współdzielonego: brak takiego pliku lub katalogu

Spróbuj tego. Napraw uprawnienia do plików:

cd /opt/Popcorn (or wherever it is) 
chmod -R 555 * (755 if not ok) 

podobny problem znaleziono tutaj: https://bugzilla.redhat.com/show_bug.cgi?id=1456202 Wypróbowałem wspomniane rozwiązanie i faktycznie działa.

Rozwiązania z poprzednich pytań mogą działać. Ale myślę, że to łatwy sposób, aby to naprawić. Spróbuj ponownie zainstalować pakiet libwbclient w Fedorze:

dnf reinstall libwbclient

Używam Ubuntu 18.04

Instalacja odpowiedniego pakietu „-dev” działała dla mnie,

sudo apt install libgconf2-dev

Otrzymałem następujący błąd, dopóki nie zainstalowałem powyższego pakietu,

turtl: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory