Linux-Fehler beim Laden von gemeinsam genutzten Bibliotheken: Datei für gemeinsam genutzte Objekte kann nicht geöffnet werden: Keine solche Datei oder kein solches Verzeichnis

Das Programm ist Teil der Xenomai-Testsuite, die vom Linux-PC in die Linux + Xenomai ARM-Toolchain kompiliert wurde.

# 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                                 

Bearbeiten: OK Ich habe nicht bemerkt, dass die .1 am Ende Teil des Dateinamens war. Was bedeutet das überhaupt?

Update
Während das, was ich unten schreibe, als allgemeine Antwort auf gemeinsam genutzte Bibliotheken gilt, ist meiner Meinung nach die häufigste Ursache für diese Art von Nachrichten, dass Sie ein Paket installiert haben, aber nicht die "-dev" -Version dieses Pakets installiert haben.

Nun, es lügt nicht - es gibt keine libpthread_rt.so.1in dieser Auflistung. Sie müssen es wahrscheinlich neu konfigurieren und neu erstellen, damit es von Ihrer Bibliothek abhängt, oder installieren, was auch immer bereitgestellt wird libpthread_rt.so.1.

Im Allgemeinen sind die Zahlen nach der .so Versionsnummern, und Sie werden häufig feststellen, dass sie Symlinks zueinander sind. Wenn Sie also Version 1.1 von libfoo.so haben, haben Sie eine echte Datei libfoo.so.1.0, und Symlinks foo.so und foo.so.1, die auf libfoo.so.1.0 verweisen. Und wenn Sie Version 1.1 installieren, ohne die andere zu entfernen, haben Sie eine libfoo.so.1.1, und libfoo.so.1 und libfoo.so verweisen jetzt auf die neue, aber jeder Code, der genau diese Version erfordert, kann Verwenden Sie die Datei libfoo.so.1.0. Code, der nur auf der API der Version 1 basiert, sich aber nicht darum kümmert, ob es sich um 1.0 oder 1.1 handelt, gibt libfoo.so.1 an. Wie orip in den Kommentaren hervorhob , wird dies unter http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html gut erklärt .

In Ihrem Fall könnten Sie mit Symlinking libpthread_rt.so.1zu davonkommen libpthread_rt.so. Es gibt jedoch keine Garantie dafür, dass Ihr Code nicht beschädigt wird und Sie nicht im Fernsehen essen.

Ihre Bibliothek ist eine dynamische Bibliothek. Sie müssen dem Betriebssystem mitteilen, wo es es zur Laufzeit finden kann.

Dazu müssen wir die folgenden einfachen Schritte ausführen:

(1) Finden Sie heraus, wo sich die Bibliothek befindet, wenn Sie es nicht wissen.

sudo find / -name the_name_of_the_file.so

(2) Überprüfen Sie, ob die Umgebungsvariable für den dynamischen Bibliothekspfad vorhanden ist ( LD_LIBRARY_PATH)

$ echo $LD_LIBRARY_PATH

Wenn nichts angezeigt werden soll, fügen Sie einen Standardpfadwert hinzu (oder nicht, wenn Sie möchten).

$ LD_LIBRARY_PATH=/usr/local/lib

(3) Wir fügen den gewünschten Pfad hinzu, exportieren ihn und testen die Anwendung.

Beachten Sie, dass der Pfad das Verzeichnis sein sollte, in dem sich das path.so.somethingbefindet. Also , wenn path.so.somethingin /my_library/path.so.somethinges sein sollte:

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

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

Hier sind einige Lösungen, die Sie ausprobieren können:

ldconfig

Wie AbiusX betonte: Wenn Sie die Bibliothek gerade installiert haben, müssen Sie möglicherweise nur ldconfig ausführen .

sudo ldconfig

ldconfig erstellt die erforderlichen Links und den Cache zu den neuesten gemeinsam genutzten Bibliotheken in den in der Befehlszeile angegebenen Verzeichnissen, in der Datei /etc/ld.so.conf und in den vertrauenswürdigen Verzeichnissen (/ lib und / usr / lib).

Normalerweise kümmert sich Ihr Paketmanager darum, wenn Sie eine neue Bibliothek installieren, aber nicht immer, und es schadet nicht, ldconfig auszuführen, auch wenn dies nicht Ihr Problem ist.

Entwicklungspaket oder falsche Version

Wenn das nicht funktioniert, würde ich auch Pauls Vorschlag prüfen und nach einer "-dev" -Version der Bibliothek suchen. Viele Bibliotheken sind in dev- und non-dev-Pakete unterteilt. Mit diesem Befehl können Sie danach suchen:

apt-cache search <libraryname>

Dies kann auch hilfreich sein, wenn Sie einfach die falsche Version der Bibliothek installiert haben. Einige Bibliotheken werden gleichzeitig in verschiedenen Versionen veröffentlicht, z. B. Python.

Bibliotheksstandort

Wenn Sie sicher sind, dass das richtige Paket installiert ist und ldconfig es nicht gefunden hat, befindet es sich möglicherweise nur in einem nicht standardmäßigen Verzeichnis. Standardmäßig sucht ldconfig in /lib, /usr/libund Verzeichnisse in /etc/ld.so.confund $LD_LIBRARY_PATH. Wenn sich Ihre Bibliothek an einem anderen Ort befindet, können Sie das Verzeichnis entweder in einer eigenen Zeile hinzufügen, den /etc/ld.so.confPfad der Bibliothek anhängen $LD_LIBRARY_PATHoder die Bibliothek verschieben /usr/lib. Dann renne ldconfig.

Versuchen Sie Folgendes, um herauszufinden, wo sich die Bibliothek befindet:

sudo find / -iname *libraryname*.so*

(Ersetzen Sie librarynamedurch den Namen Ihrer Bibliothek)

Wenn Sie den $LD_LIBRARY_PATHWeg gehen , möchten Sie dies in Ihre ~/.bashrcDatei einfügen, damit es jedes Mal ausgeführt wird, wenn Sie sich anmelden:

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

Ich hatte den ähnlichen Fehler, ich konnte ihn beheben, indem ich gab,

sudo ldconfig -v

Hoffe das hilft.

Sie müssen sicherstellen, dass Sie den Bibliothekspfad beim Verknüpfen angeben, wenn Sie Ihre .c-Datei kompilieren:

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

Der Teil -Wl, -R weist die resultierende Binärdatei an, zur Laufzeit auch in / usr / local / lib nach einer Bibliothek zu suchen, bevor versucht wird, die in / usr / lib / zu verwenden.

Hoffe es wird dir helfen.

Versuchen Sie LD_LIBRARY_PATH, Ihrer ~/.bashrcDatei , die Suchpfade angibt, etwas hinzuzufügen

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path_to_your_library

Es klappt!

Die Referenzseite von linux.org erklärt die Mechanik, erklärt aber nicht die Motivation dahinter :-(

Informationen hierzu finden Sie im Sun Linker- und Bibliothekshandbuch

Beachten Sie außerdem, dass die "externe Versionierung" unter Linux weitgehend veraltet ist, da durch die Symbolversionierung (eine GNU-Erweiterung) mehrere inkompatible Versionen derselben Funktion in einer einzigen Bibliothek vorhanden sein können. Diese Erweiterung ermöglichte es glibc, dieselbe externe Version zu haben: libc.so.6in den letzten 10 Jahren.

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

Fügen Sie diese Zeilen am Ende hinzu

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

Ich hatte einen ähnlichen Fehler und er wurde nicht behoben, indem LD_LIBRARY_PATH in ~ / .bashrc angegeben wurde. Was mein Problem gelöst hat, ist das Hinzufügen einer .conf-Datei und das Laden. Gehe zum Terminal und sei in su.

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

Fügen Sie Ihren Bibliothekspfad in diese Datei ein und speichern Sie ihn (z. B. / usr / local / lib). Sie müssen den folgenden Befehl ausführen, um den Pfad zu aktivieren:

ldconfig

Überprüfen Sie Ihren neuen Bibliothekspfad:

ldconfig -v | less

Wenn dies Ihre Bibliotheksdateien anzeigt, können Sie loslegen.

Eine weitere mögliche Lösung je nach Ihrer Situation.

Wenn Sie wissen, dass libpthread_rt.so.1 mit libpthread_rt.so identisch ist, können Sie einen Symlink erstellen, indem Sie:

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

Dann ls -l /libsollte nun der Symlink angezeigt werden und worauf er zeigt.

Ich hatte diesen Fehler beim Ausführen meiner Anwendung mit Eclipse CDT unter Linux x86.
Um dies zu beheben:

1. In Eclipse:

   Ausführen als -> Konfigurationen ausführen -> Umgebung

2. Stellen Sie den Pfad ein

   LD_LIBRARY_PATH=/my_lib_directory_path
   

Ich musste nur rennen:

sudo apt-get install libfontconfig1

Ich war in dem Ordner bei /usr/lib/x86_64-linux-gnuund es hat perfekt funktioniert.

Wenn Sie Ihre Anwendung unter Microsoft Windows ausführen, muss der Pfad zu dynamischen Bibliotheken (DLL) in der Umgebungsvariablen PATH definiert werden.

Wenn Sie Ihre Anwendung unter UNIX ausführen, muss der Pfad zu Ihren dynamischen Bibliotheken (.so) in der Umgebungsvariablen LD_LIBRARY_PATH definiert werden.

Versuchen Sie, sudo lib32z1 zu installieren

sudo apt-get install lib32z1

Der Fehler tritt auf, da das System nicht auf die erwähnte Bibliotheksdatei verweisen kann. Führen Sie die folgenden Schritte aus:

1. Beim Ausführen locate libpthread_rt.so.1wird der Pfad aller Dateien mit diesem Namen aufgelistet. Nehmen wir an, ein Pfad ist /home/user/loc.
2. Kopieren Sie den Pfad und führen Sie ihn aus cd home/USERNAME. Ersetzen Sie USERNAME durch den Namen des aktuell aktiven Benutzers, mit dem Sie die Datei ausführen möchten.
3. Führen Sie aus vi .bash_profileund fügen Sie am Ende des LD_LIBRARY_PATHParameters kurz zuvor .die Zeile hinzu /lib://home/usr/loc:.. Speicher die Datei.
4. Schließen Sie das Terminal und starten Sie die Anwendung neu. Es sollte laufen.

Ich habe diesen Fehler erhalten und ich denke, es ist der gleiche Grund von Ihnen

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

Versuche dies. Fix Berechtigungen für Dateien:

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

"Sudo su", um Berechtigungen für Ihr Dateisystem zu erhalten.

Ich habe diesen Fehler erhalten und ich denke, es ist der gleiche Grund von Ihnen

Fehler beim Laden von gemeinsam genutzten Bibliotheken: libnw.so: Datei für gemeinsam genutzte Objekte kann nicht geöffnet werden: Keine solche Datei oder kein solches Verzeichnis

Versuche dies. Fix Berechtigungen für Dateien:

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

Ähnliches Problem finden Sie hier: https://bugzilla.redhat.com/show_bug.cgi?id=1456202 Ich habe die erwähnte Lösung ausprobiert und sie funktioniert tatsächlich.

Die Lösungen in den vorherigen Fragen können funktionieren. Aber ich denke, das ist ein einfacher Weg, um das Problem zu beheben. Versuchen Sie, das Paket libwbclient in Fedora neu zu installieren :

dnf reinstall libwbclient

Ich benutze Ubuntu 18.04

Die Installation des entsprechenden "-dev" -Pakets hat bei mir funktioniert,

sudo apt install libgconf2-dev

Ich habe den folgenden Fehler erhalten, bis ich das obige Paket installiert habe.

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