Errore di Linux durante il caricamento delle librerie condivise: imansible aprire il file object condiviso: nessun file o directory di questo tipo

Il programma fa parte della suite di test Xenomai, compilata a croce dal PC Linux nella toolchain Linux + Xenomai ARM.

# 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 

Modifica: OK Non ho notato che il file .1 alla fine era parte del nome del file. Che cosa significa comunque?

Aggiornare
Mentre quello che scrivo qui sotto è vero come una risposta generale alle librerie condivise, penso che la causa più frequente di questo tipo di messaggi sia perché hai installato un pacchetto, ma non hai installato la versione “-dev” di quel pacchetto.


Beh, non sta mentendo – non c’è libpthread_rt.so.1 in quella lista. Probabilmente dovrai riconfigurarlo e ricostruirlo in modo che dipenda dalla libreria che hai, o installare qualunque cosa fornisca libpthread_rt.so.1 .

Generalmente, i numeri dopo il .so sono numeri di versione, e spesso troverai che si tratta di collegamenti simbolici tra loro, quindi se hai la versione 1.1 di libfoo.so, avrai un file reale libfoo.so.1.0, e symlinks foo.so e foo.so.1 che puntano a libfoo.so.1.0. E se si installa la versione 1.1 senza rimuovere l’altra, si avrà un libfoo.so.1.1, e libfoo.so.1 e libfoo.so ora puntano a quello nuovo, ma qualsiasi codice che richiede quella versione esatta può usa il file libfoo.so.1.0. Codice che fa semplicemente affidamento sull’API versione 1, ma non gli interessa se è 1.0 o 1.1 specificherà libfoo.so.1. Come ha sottolineato Orip nei commenti, questo è spiegato bene su http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html .

Nel tuo caso, potresti liberarti del libpthread_rt.so.1 simbolico libpthread_rt.so.1 a libpthread_rt.so . Non garantisce che non infrangerà il tuo codice e mangerà le tue cene TV, però.

La tua libreria è una libreria dynamic. Devi dire al sistema operativo dove può trovarlo in fase di esecuzione.

Per fare ciò, dovremo fare questi semplici passaggi:

(1) Trova dove si trova la biblioteca se non la conosci.

 sudo find / -name the_name_of_the_file.so 

(2) Verificare l’esistenza della variabile di ambiente del percorso della libreria dynamic ( LD_LIBRARY_PATH )

 $ echo $LD_LIBRARY_PATH 

se non c’è nulla da visualizzare, aggiungi un valore di percorso predefinito (o non se lo desideri)

 $ LD_LIBRARY_PATH=/usr/local/lib 

(3) Aggiungiamo il percorso del desiderio, lo esportiamo e proviamo l’applicazione.

Si noti che il percorso deve essere la directory in cui si trova path.so.something . Quindi se path.so.something è in /my_library/path.so.something dovrebbe essere:

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

fonte: http://www.gnu.org/software/gsl/manual/html_node/Shared-Libraries.html

Ecco alcune soluzioni che puoi provare:

ldconfig

Come ha sottolineato AbiusX: se hai appena installato la libreria, potresti semplicemente dover eseguire ldconfig .

 sudo ldconfig 

ldconfig crea i collegamenti e la cache necessari alle librerie condivise più recenti trovate nelle directory specificate nella riga di comando, nel file /etc/ld.so.conf e nelle directory attendibili (/ lib e / usr / lib).

Di solito il tuo gestore di pacchetti si prenderà cura di questo quando installi una nuova libreria, ma non sempre, e non farà male eseguire ldconfig anche se questo non è il tuo problema.

Pacchetto Dev o versione errata

Se ciò non funziona, vorrei anche controllare il suggerimento di Paolo e cercare una versione “-dev” della libreria. Molte librerie sono suddivise in pacchetti dev e non-dev. Puoi usare questo comando per cercarlo:

 apt-cache search  

Questo può anche essere d’aiuto se hai semplicemente la versione errata della libreria installata. Alcune librerie sono pubblicate simultaneamente in diverse versioni, ad esempio Python.

Posizione della biblioteca

Se sei sicuro che il pacchetto giusto sia installato e ldconfig non lo trovi, potrebbe essere solo in una directory non standard. Di default, ldconfig cerca in /lib , /usr/lib e nelle directory elencate in /etc/ld.so.conf e $LD_LIBRARY_PATH . Se la tua libreria è da qualche altra parte, puoi aggiungere la directory sulla sua stessa riga in /etc/ld.so.conf , aggiungere il percorso della libreria a $LD_LIBRARY_PATH , o spostare la libreria in /usr/lib . Quindi eseguire ldconfig .

Per scoprire dove si trova la libreria, prova questo:

 sudo find / -iname *libraryname*.so* 

(Sostituisci nome libreria con il nome della tua libreria)

Se $LD_LIBRARY_PATH rotta $LD_LIBRARY_PATH , ti consigliamo di inserirla nel tuo file ~/.bashrc modo che venga eseguita ogni volta che accedi:

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

Ho avuto l’errore simile, ho potuto risolverlo dando,

 sudo ldconfig -v 

Spero che questo ti aiuti.

È necessario assicurarsi di specificare il percorso della libreria durante il collegamento quando si compila il file .c:

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

La parte -Wl, -R dice al binario risultante di cercare anche la libreria in / usr / local / lib in runtime prima di provare a usare quello in / usr / lib /

Spero ti possa aiutare.

La pagina di riferimento di linux.org spiega la meccanica, ma non spiega le motivazioni alla base 🙁

Per questo, vedere Sun Linker and Libraries Guide

Inoltre, si noti che “il controllo delle versioni esterne” è ampiamente obsoleto su Linux, poiché il controllo delle versioni dei simboli (un’estensione GNU) consente di avere più versioni incompatibili della stessa funzione presenti in una singola libreria. Questa estensione consentiva a glibc di avere la stessa versione esterna: libc.so.6 negli ultimi 10 anni.

Prova ad aggiungere LD_LIBRARY_PATH , che indica i percorsi di ricerca, al tuo file ~/.bashrc

 LD_LIBRARY_PATH=path_to_your_library 

Funziona!

 cd /home// sudo vi .bash_profile 

aggiungi queste righe alla fine

 LD_LIBRARY_PATH=/usr/local/lib: export LD_LIBRARY_PATH 

Un’altra ansible soluzione a seconda della situazione.

Se sai che libpthread_rt.so.1 è uguale a libpthread_rt.so, puoi creare un link simbolico per:

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

Quindi ls -l /lib dovrebbe ora mostrare il link simbolico e ciò a cui punta.

Tutto quello che dovevo fare era correre:

 sudo apt-get install libfontconfig1 

Ero nella cartella situata in /usr/lib/x86_64-linux-gnu e funzionava perfettamente.

Se si esegue l’applicazione su Microsoft Windows, è necessario definire il percorso delle librerie dinamiche (con estensione dll) nella variabile di ambiente PATH.

Se si esegue l’applicazione su UNIX, è necessario definire il percorso delle librerie dinamiche (.so) nella variabile di ambiente LD_LIBRARY_PATH.

Ho avuto un errore simile e non è stato risolto con l’assegnazione di LD_LIBRARY_PATH in ~ / .bashrc. Ciò che ha risolto il mio problema è aggiungendo il file .conf e caricandolo. Vai al terminale e sii in su.

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

Aggiungi il tuo percorso di libreria in questo file e salva (es: / usr / local / lib). È necessario eseguire il seguente comando per triggersre il percorso:

 ldconfig 

Verifica il percorso della nuova libreria:

 ldconfig -v | less 

Se questo mostra i file della tua libreria, allora sei a posto.

prova a installare sudo lib32z1

sudo apt-get install lib32z1

Ho avuto questo errore durante l’esecuzione della mia applicazione con Eclipse CDT su Linux x86. Per risolvere questo problema:

  1. In Eclipse: Esegui come> Esegui configurazioni> Ambiente
  2. LD_LIBRARY_PATH = / my_lib_directory_path

L’errore si verifica in quanto il sistema non può fare riferimento al file della libreria menzionato. Segui i seguenti passi:

  1. L’esecuzione di locate libpthread_rt.so.1 elencherà il percorso di tutti i file con quel nome. Supponiamo che un percorso sia /home/user/loc .
  2. Copia il percorso ed esegui cd home/USERNAME . Sostituisci USERNAME con il nome dell’utente attivo corrente con cui vuoi eseguire il file.
  3. Esegui vi .bash_profile e alla fine del parametro LD_LIBRARY_PATH , poco prima . , aggiungi la linea /lib://home/usr/loc:. . Salva il file.
  4. Chiudi il terminale e riavvia l’applicazione. Dovrebbe funzionare.

Ho ricevuto questo errore e penso che sia la stessa ragione della tua

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

Prova questo. Correggi i permessi sui file:

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

“Sudo su” per ottenere le autorizzazioni sul tuo filesystem.

Ho ricevuto questo errore e penso che sia la stessa ragione della tua

errore durante il caricamento delle librerie condivise: libnw.so: imansible aprire il file object condiviso: nessun file o directory di questo tipo

Prova questo. Correggi i permessi sui file:

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