Linux-Benutzer stoßen beim Ausführen von Programmen häufig auf den Fehler beim Laden von gemeinsam genutzten Bibliotheken
, und auch viele Programmierer und alle, die Software auf ihrem System kompilieren möchten, kennen diesen Fehler. Wörtlich bedeutet er, dass es ein Problem beim Laden von Shared Libraries gibt.
Der Fehler"Fehler beim Laden gemeinsamer Bibliotheken
" bedeutet, dass das Betriebssystem beim Ausführen eines Programms oder Skripts eine oder mehrere Bibliotheken nicht finden und laden konnte, die für das Funktionieren dieses Programms erforderlich sind. Dies ist ein häufiges Problem in UNIX-ähnlichen Betriebssystemen. Wenn ein Programm kompiliert wird, kann es auf verschiedene externe Bibliotheken verweisen, die zur Laufzeit verfügbar sein sollten. Wenn diese Bibliotheken fehlen oder nicht verfügbar sind, tritt ein Fehler beim Laden der gemeinsamen Bibliotheken auf.
Auch wenn Sie Ihre Programme nicht kompilieren, kann dieser Fehler: directory_name: cannot open shared object file: No such file or directory
häufig auftreten, wenn Sie neue Programme installieren, die nicht über den Paketmanager oder für eine andere Distribution bestimmt sind. Dieser Fehler tritt auf, weil das System die Bibliothek nicht finden kann. Warum kann sie nicht gefunden und geladen werden?
Dafür gibt es mehrere Gründe, in der Regel handelt es sich um eine Bibliothek, die:
Bei der Lösung des Problems werden wir uns von diesen Gründen leiten lassen und versuchen, sie zu beheben.
Betrachten wir nun konkrete Beispiele für die Lösung dieses Problems auf der Grundlage der im vorigen Absatz genannten Gründe.
Hier gibt es nichts Kompliziertes und alles ist ganz klar - die Bibliothek ist einfach nicht im System vorhanden, weshalb wir diesen Fehler erhalten. Deshalb müssen wir das Bibliothekspaket mit Hilfe eines Paketmanagers finden und es installieren. Normalerweise werden Pakete mit Bibliotheken genauso genannt wie die Bibliotheken selbst mit dem Präfix lib
.
Wenn wir die Bibliothek libfuse2.so
vermissen, können wir sie in Ubuntu mit diesem Befehl finden:
$ sudo apt search libfuse2
Dann bleibt nur noch, sie zu installieren:
$ sudo apt install libfuse2
Wenn Sie ein Programm aus dem Quellcode bauen wollen, müssen Sie auch die Header-Dateien installieren:
$ sudo apt install libfuse-dev
Und das gilt für jede Bibliothek. Aber das klappt nicht immer.
In der Praxis gibt es Fälle, in denen die Bibliothek zwar installiert ist, der Fehler aber bestehen bleibt und es dem Benutzer nicht erlaubt, normal mit dem System zu arbeiten. Was ist in einem solchen Fall zu tun? Überprüfen Sie zunächst den Linux-Bootloader, der die Bibliothek nicht finden kann. Die Suche sollte in den Verzeichnissen durchgeführt werden, die in den Konfigurationsdateien /etc/ld.conf.d/
angegeben sind. In der Regel sind dies /usr/lib, /lib, /usr/lib64, /lib64
. Wenn die Bibliothek in einem anderen Verzeichnis installiert ist, ist dies offensichtlich die Ursache des Problems.
Mit dem Befehl können Sie sehen, welche Bibliotheken dem Lader derzeit zur Verfügung stehen:
$ ldconfig -p
Finden Sie mit dem Befehl locate
heraus, wo sich Ihre Bibliothek befindet. Wir sind zum Beispiel an der Bibliothek librtfreader.so
interessiert :
$ locate librtfreader
Wenn wir den Speicherort von /opt/kingsoft/wps-office/office6/
kennen, müssen wir es dem Lader ermöglichen, die Bibliothek zu erkennen. Wir fügen den Pfad /etc/ld.so.conf.d/
in die Konfigurationsdatei oder in die Variable LD_LIBRARY_PATH
ein:
export LD_LIBRARY_PATH=/opt/kingsoft/wps-office/office6/
Sie können mit jeder Bibliothek installieren, die den Fehler hervorruft. Sie können auch den weniger komplizierten Weg gehen und einen symbolischen Link zur richtigen Bibliothek im richtigen Verzeichnis erstellen:
ln -s /opt/kingsoft/wps-office/office6/librtfreader.so /usr/lib/librtfreader.so
Dies passiert normalerweise, wenn Sie Programme für eine Distribution verwenden, die Sie nicht installiert haben. Jede Bibliothek hat eine zusätzliche Version, die hinter die .so-Erweiterung
geschrieben wird. Zum Beispiel: libav.so.1
. Die Versionsnummer ändert sich, wenn eine Bibliothek gepatcht wird.
Es kommt häufig vor, dass in einer Distribution ein Programm mit einer Bibliotheksabhängigkeit wie libc .so.1
gebaut wird und in einer anderen Distribution nur libc.so.2
vorhanden ist. In den meisten Fällen sind die Unterschiede hier gering und das Programm könnte auf der zweiten Version der Bibliothek laufen. Wir können also einfach einen symbolischen Link zu ihr erstellen.
Zum Beispiel gibt es keine libusb-1.0.so.1-Bibliothek
. Aber es gibt libusb-1.0.so.0.1
, und wir können sie verwenden:
Dazu erstellen wir einfach einen symbolischen Link auf die Bibliothek:
$ sudo ln -s /usr/lib/libusb-1.0.so.0.1 /usr/lib/libusb-1.0.so.1
Oft bemerkt das Programm die Ersetzung nicht und funktioniert. Eine clevere Lösung ist es, im Internet die richtige Version der Bibliothek für Ihre Architektur zu finden und sie in den Ordner /usr/lib/
oder /usr/lib64/
zu legen. Danach ist es jedoch wünschenswert, den Cache zu aktualisieren:
$ sudo ldconfig
Wenn das Problem nach diesen Schritten weiterhin besteht, empfiehlt es sich, die Dokumentation des Programms oder des Betriebssystems zu Rate zu ziehen, um genauere Informationen über die erforderlichen Bibliotheksversionen und deren Installation zu erhalten.