GNU/Linux >> LINUX-Kenntnisse >  >> Linux

Linux-Fehler beim Laden gemeinsam genutzter Bibliotheken:Gemeinsam genutzte Objektdatei kann nicht geöffnet werden:Keine solche Datei oder dieses Verzeichnis

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

Dazu müssen wir diese einfachen Schritte ausführen:

(1 ) Finde heraus, wo sich die Bibliothek befindet, falls du sie nicht kennst.

sudo find / -name the_name_of_the_file.so

(2) Prü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 auch nicht, wenn Sie möchten)

$ LD_LIBRARY_PATH=/usr/local/lib

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

Beachten Sie, dass der Pfad das Verzeichnis sein sollte, in dem sich path.so.something befindet ist.Also wenn path.so.something ist in /my_library/path.so.something es sollte sein:

$ 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 erst installiert haben, müssen Sie möglicherweise einfach ldconfig.

ausführen
sudo ldconfig

ldconfig erstellt die notwendigen Links und den Cache zu den neuesten gemeinsam genutzten Bibliotheken, die in den Verzeichnissen gefunden werden, die auf der Befehlszeile, in der Datei /etc/ld.so.conf und in den vertrauenswürdigen Verzeichnissen (/lib und /usr/lib) angegeben sind.

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 das 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 Entwickler- und Nicht-Entwicklerpakete aufgeteilt. Sie können diesen Befehl verwenden, um danach zu 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, beispielsweise Python.

Standort der Bibliothek

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/lib , und Verzeichnisse, die in /etc/ld.so.conf aufgeführt sind und $LD_LIBRARY_PATH . Wenn sich Ihre Bibliothek woanders befindet, können Sie das Verzeichnis entweder in einer eigenen Zeile in /etc/ld.so.conf hinzufügen , hängen Sie den Pfad der Bibliothek an $LD_LIBRARY_PATH an , oder verschieben Sie die Bibliothek nach /usr/lib . Führen Sie dann ldconfig aus .

Um herauszufinden, wo sich die Bibliothek befindet, versuchen Sie Folgendes:

sudo find / -iname *libraryname*.so*

(Ersetzen Sie libraryname mit dem Namen Ihrer Bibliothek)

Wenn Sie die $LD_LIBRARY_PATH gehen route, sollten Sie diese in Ihren ~/.bashrc einfügen Datei, damit sie bei jeder Anmeldung ausgeführt wird:

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

Aktualisieren
Während das, was ich unten schreibe, als allgemeine Antwort zu gemeinsam genutzten Bibliotheken gilt, denke ich, dass die häufigste Ursache für diese Art von Meldung darin besteht, dass Sie ein Paket installiert haben, aber nicht die "-dev" -Version dieses Pakets.

Nun, es lügt nicht - es gibt kein libpthread_rt.so.1 in dieser Auflistung. Sie müssen es wahrscheinlich neu konfigurieren und neu erstellen, damit es von der Bibliothek abhängt, die Sie haben, oder installieren, was immer libpthread_rt.so.1 bereitstellt .

Im Allgemeinen sind die Nummern nach dem .so Versionsnummern, und Sie werden oft feststellen, dass sie symbolische Links zueinander sind. Wenn Sie also Version 1.1 von libfoo.so haben, haben Sie eine echte Datei libfoo.so.1.0, und symbolische Links foo.so und foo.so.1, die auf die libfoo.so.1.0 zeigen. 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 zeigen jetzt auf die neue, aber jeder Code, der genau diese Version erfordert, kann dies tun Verwenden Sie die Datei libfoo.so.1.0. Code, der nur auf Version 1 der API angewiesen ist, sich aber nicht darum kümmert, ob es sich um Version 1.0 oder 1.1 handelt, gibt libfoo.so.1 an. Wie orip in den Kommentaren betonte, ist dies unter http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html.

gut erklärt

In Ihrem Fall vielleicht kommen Sie mit dem symbolischen Linken von libpthread_rt.so.1 davon bis libpthread_rt.so . Keine Garantie, dass es nicht Ihren Code knackt und Ihr Fernsehessen frisst.


Linux
  1. So beheben Sie den Fehler „Datei mit gemeinsam genutzten Objekten kann nicht geöffnet werden“ in Ubuntu-basierten Linux-Distributionen

  2. So beheben Sie „Fehler beim Laden gemeinsam genutzter Bibliotheken:libgtk-x11-2.0.so.0“

  3. rpm:Fehler beim Laden gemeinsam genutzter Bibliotheken:ungültiger ELF-Header

  4. libstdc++.so.5:Shared-Object-Datei kann nicht geöffnet werden - aber Bibliothek ist installiert und aktuell

  5. libaio.so.1:Shared-Object-Datei kann nicht geöffnet werden

So beheben Sie den Fehler „pacman:Fehler beim Laden gemeinsam genutzter Bibliotheken“ in Arch Linux

Fehler beim Laden gemeinsam genutzter Bibliotheken:libncurses.so.5:

libpulse.so.0:Shared-Object-Datei kann nicht geöffnet werden:Keine solche Datei oder Verzeichnis

ImportError:libtk8.6.so:Shared-Object-Datei kann nicht geöffnet werden:Keine solche Datei oder Verzeichnis

ImportError:libcblas.so.3:Shared-Object-Datei kann nicht geöffnet werden:Keine solche Datei oder Verzeichnis

conda.exe:Fehler beim Laden gemeinsam genutzter Bibliotheken:libz.so.1