Fehler beim Laden von Shared Libraries: der gefürchtete Fehler, auf den jeder Linux-Benutzer früher oder später stoßen wird. Bei den gemeinsamen Objektabhängigkeiten (den Bibliotheken), die von der ausführbaren Datei verwendet werden, ist ein Fehler aufgetreten. Erfahren Sie, wie Sie solche Probleme und mehr beheben können!
Was ist ein Shared Object Dependency?
Ein Shared Object (auch Bibliothek genannt) ist eine Binärdatei (normalerweise nicht direkt ausführbar), die von mehreren Programmen/Anwendungen auf einer Linux-Instanz verwendet wird. Solche Bibliotheken werden oft auf Betriebssystemebene installiert und gemeinsam genutzt (daher der Name gemeinsames Objekt oder Bibliotheken) zur Verwendung durch eine oder mehrere (und sogar viele) direkt ausführbare Anwendungen.
Ein Programm, das das Komprimieren von Dateien ermöglicht, benötigt beispielsweise dazu die bz2-Bibliothek (bzip2) libbz2.so.1.0. Der Begriff Bibliothek wird in Linux-Kreisen häufiger verwendet und ist die bevorzugte Sprache unter Fachleuten, obwohl gemeinsames Objekt (und gemeinsame Bibliothek) beide technisch korrekt sind. Interessant ist auch, dass die in vielen Bibliotheken verwendete Dateinamenerweiterung .so für Shared Object steht!
Eine ausführbare Datei kann über keine, eine oder viele Bibliotheken verfügen, auf die sie angewiesen ist. Je weniger Bibliotheken, desto besser (z. B. beim Upgrade Ihres Betriebssystems) ist die Kompatibilität. Je mehr Bibliotheken, desto größer ist die Wahrscheinlichkeit, dass früher oder später einige Bibliotheksabhängigkeiten aufgehoben werden. Aus diesem Grund entscheiden sich Anwendungsanbieter manchmal auch dafür, statisch kompilierte Binärdateien anstelle von dynamisch kompilierten Binärdateien zu veröffentlichen.
Der Unterschied zwischen statisch und dynamisch kompilierten Binärdateien ist einfach, hat aber weitreichende Konsequenzen. Bei einer statisch kompilierten Binärdatei werden die Bibliotheken (die zum Zeitpunkt der Kompilierung auf dem Entwicklersystem verfügbar sind) in die resultierende Binärdatei/ausführbare Datei kompiliert. Eine dynamisch kompilierte Binärdatei verwendet die auf dem System des Benutzers installierten, verfügbaren und freigegebenen Bibliotheken.
Wie Sie sofort sehen können, erfordert dies, dass der Benutzer alle erforderlichen Abhängigkeiten installiert, es sei denn, dies wird im Paketverwaltungssystem und in den Details des Betriebssystems oder des Anwendungsanbieters berücksichtigt. Aus diesem Grund führt die Ausführung eines einfachen Befehls wie sudo apt install …some_app… oft zu einer Reihe anderer verwandter Dinge (zB erforderliche Bibliotheken), die gleichzeitig mitinstalliert werden müssen.
Beide Statisches und dynamisches Kompilieren haben Vor- und Nachteile. Wenn Sie beispielsweise statisches Kompilieren verwenden und eine Bibliothek, die Sie in Ihr Softwarepaket aufgenommen haben (aus der Sicht eines Softwareanbieters), jetzt einen Sicherheitsfehler oder ein kritisches Update aufweist, müssen Sie wahrscheinlich re -veröffentlichen Sie Ihr Softwarepaket, auch wenn sich an Ihrem Code nichts geändert hat.
Werbung
Andererseits ist es auch nicht ideal, sich auf die Installation von Bibliotheken durch den Benutzer zu verlassen, insbesondere bei komplexen Programmen oder wenn eine Selbstkompilierung von Software erforderlich ist, mit der Erkenntnis, dass Endbenutzer oft mit solchen Dingen zu kämpfen haben. Es ist ein komplexes Gebiet und das Thema wurde oft diskutiert.
In diesem Artikel betrachten wir Shared Libraries im Zusammenhang mit einem dynamisch kompilierten Programm, wie es häufig bei Betriebssystemprogrammen/ausführbaren Programmen/Tools der Fall ist. Bei statisch kompilierten Programmen (die weniger verbreitet sind) wird ein Fehler wie ‘Fehler beim Laden gemeinsam genutzter Bibliotheken’ Es ist sehr unwahrscheinlich, dass sie angezeigt werden, da die Bibliotheken in der ausführbaren Datei enthalten sind, es sei denn, das Programm ist teildynamisch und enthält nur einen begrenzten Satz eingebauter statischer Bibliotheken.
Fehler beim Laden von freigegebenen Bibliotheken!
Wechseln wir zu root-Modus für eine Weile (mit sudo su) und erkunden Sie, wie gemeinsam genutzte Bibliotheken funktionieren, wenn es um ein Tool wie /usr/bin/zip geht, das in großen Linux-Distributionen enthalten oder installierbar ist.
Hier haben wir die Verzeichnisse nach /usr/bin geändert und überprüft, ob das Zip-Programm/binary/executable ist anwesend. Nachdem wir festgestellt hatten, dass sie vorhanden war, überprüften wir als nächstes die Version, indem wir sie mit –version aufrufen und nur die obersten beiden Zeilen der Ausgabe verwenden, indem wir die Ausgabe mit Pipe umleiten (mit |), um die sonst gegebene lange Ausgabe zu vermeiden.
Schließlich haben wir das Tool ldd (ein Programm, das Abhängigkeiten von gemeinsamen Objekten ausgibt) verwendet, um zu sehen, welche Bibliotheken die ausführbare Datei benötigt. Wie wir sehen, benötigt das Programm vier Shared Libraries. Die Liste der benötigten Bibliotheken hat normalerweise das Format der benötigten Bibliothek, gefolgt von einem Pfad, in dem die genannte Bibliothek bereits gefunden wurde.
Werbung
Für einige Top-Level- oder spezielle OS-Level-Bibliotheken (wie linux-vdso.so.1) wird kein solcher Pfad angezeigt. Solange jedoch kein Fehler für einen Eintrag angezeigt wird, wissen Sie, dass er in Ordnung und verfügbar (oder bevorzugt) ist. Tatsächlich ist linux-vdso.so.1 ein spezielles virtuelles gemeinsam genutztes Objekt/eine spezielle virtuelle Bibliothek, die vom Linux-Kernel in jeden Prozess eingefügt wird und für das keine physische Datei auf der Festplatte vorhanden ist. Es ist dazu da, Systemaufrufe effizienter zu machen.
Also, lass uns die Dinge ein wenig unterbrechen und eine der erforderlichen Bibliotheken umbenennen, damit sie nicht mehr automatisch von den binär:
Wie Sie sehen, haben wir hier die Datei von /lib/x86_64-linux-gnu/libbz2.so.1.0 in /lib/x86_64-linux-gnu/libbz2.so.1.0.NOT_PRESENT umbenannt/verschoben. Dies hat unsere Zip-Anwendung beschädigt, und wenn wir versuchen, sie auszuführen, erhalten wir den gefürchteten Fehler beim Laden von Shared Libraries. Bei näherer Betrachtung ist die Fehlermeldung jedoch eigentlich recht anschaulich:
zip: Fehler beim Laden von Shared Libraries: libbz2.so.1.0: Shared Object File kann nicht geöffnet werden: No such file or directory
Ein erfahrener IT-Ingenieur wird alle Protokolle und Programmausgaben/Informationen, die ihm oder ihr vorgelegt werden, immer sorgfältig überprüfen, bevor er einen Anruf zu einem Problem tätigt. Es würde sich auch hier lohnen, da die erforderliche Datei, libbz2.so.1.0, deutlich angezeigt wird und auch das Problem deutlich angezeigt wird. Es gibt keine solche Datei oder kein solches Verzeichnis. Mit anderen Worten, libbz2.so.1.0 fehlt!
Dasselbe können wir auch mit ldd überprüfen, wie im obigen Bild zu sehen ist. Eine klare libbz2.so.1.0 => not found hilft uns zu wissen, was passiert. Sobald wir klar verstehen, wie dynamisch kompilierte Binärdateien (die meisten Binärdateien im Betriebssystem werden auf diese Weise kompiliert) Bibliotheken laden und benötigen, und wie man sieht, ob eine fehlt (oder über die Fehlermeldung darüber informiert wird), gehen die Dinge nicht mehr #8217;sieht nicht mehr so kompliziert aus.
Werbung
Darüber hinaus zeigt eine Schnellsuche in Ihrer bevorzugten Suchmaschine, sobald wir den erforderlichen Bibliotheksnamen kennen, das zusätzliche Paket an, das installiert (oder neu installiert) werden muss, um den erforderlichen Bibliotheksnamen zu erhalten. Nicht selten kann der Paketname sogar direkt aus dem Bibliotheksnamen abgeleitet werden. Allerdings ist in diesem Fall der Name für die Laufzeitbibliothek etwas versetzt.
Es gibt zwei Arten von Bibliotheken: Laufzeitbibliotheken und Entwicklungsbibliotheken. In diesem Fall ist der Paketname, der die Bibliothek libbz2.so.1.0 enthält, wahrscheinlich bzip2, und der Versuch einer Deinstallation würde wahrscheinlich verschiedene andere Elemente zerstören, wie aus einer langen Liste von Programmen hervorgeht, die entfernt werden, wenn man versucht, eine Deinstallation durchzuführen oder bereinigen Sie das bzip2-Paket.
Der zweite Bibliothekstyp ist eine Entwicklungsbibliothek. Diese werden häufig beim Versuch, Programme zu kompilieren, benötigt und sind oft noch enger mit ihren eigentlichen Bibliotheksdateinamen verbunden. Nehmen Sie beispielsweise in Ubuntu einfach den Bibliotheksnamen und fügen Sie -dev hinzu. Wenn wir beispielsweise das Entwicklungspaket für das Paket libbz2.so.1.0 installieren möchten, können wir uns die Installation von libbz2-dev ansehen:
Obwohl diese Entwicklungsbibliothek nicht direkt mit unserer Laufzeitbibliothek libbz2.so.1.0 zusammenhängt, ist es hilfreich, die Benennungssyntax der meisten Entwicklungspaketnamen in Ubuntu zu kennen (Präfix von lib und Suffix von -dev mit dem Namen der Bibliothek dazwischen) wenn eine bestimmte Entwicklungsbibliothek benötigt wird (was am häufigsten beim Kompilieren von Software erforderlich ist).
Nehmen Sie außerdem an, dass irgendeine Bibliothek irgendwie kaputt gegangen ist. In diesem Fall besteht eine der einfachsten schnellen Lösungen darin, den Bibliotheksbefehl sudo apt purge your_library_name zu löschen (der die übergebene Bibliothek/das übergebene Programm vollständig löschen würde), gefolgt von einer Neuinstallation mit dem Befehl sudo apt install your_library_name.
Und wenn Sie in eine ähnliche Situation wie oben geraten, in der die Deinstallation der Laufzeitbibliothek das Deinstallieren/Bereinigen des Hauptprogramms erfordert und eine solche Bereinigung/Entfernung einen zu großen Teil des Betriebssystems ausmacht oder zu viele andere Dinge beeinträchtigen würde, werden Sie kann stattdessen eine Neuinstallationsoption verwenden:
sudo apt reinstall bzip2
Es ist jedoch nicht immer so einfach, obwohl die Kenntnis der oben genannten (und insbesondere der Namenskonvention in Bezug auf das Hinzufügen von -dev) enorm bei der Fehlerbehebung hilft und das Problem oft direkt beheben wird.
Es hilft auch sehr zu wissen, wie Bibliotheken mit ldd überprüft werden können, und schließlich zu verstehen, dass eine Bibliothek nur eine ausführbare (wenn auch nicht direkt) .so-Datei ist, die sich in einem Unterverzeichnis von /lib oder in /usr/lib oder anderen befindet ähnliche Verzeichnisse.
Manchmal kollidieren Bibliotheken und/oder Pakete miteinander, oder bestimmte Pakete erfordern bestimmte Bibliotheksversionen oder bestimmte Bibliotheken erfordern andere Bibliotheken in bestimmten Versionen selbst. Ja, es wird etwas komplex. Wenn es so komplex wird, ist es auch ziemlich einfach, ein System leicht durcheinander zu bringen. Manchmal ist es sogar durchaus möglich, eine Betriebssysteminstallation vollständig zu unterbrechen, indem eine zu wichtige Bibliothek usw. verschoben wird.
Werbung
Oftmals ist es etwas sicherer, einen Symlink (einen virtuellen Link mit einem gegebenen Dateinamen, der auf eine andere vorhandene Datei verweist/verlinkt oder einen anderen Symlink selbst, der wiederum auf eine echte Datei verweist) für eine fehlende Bibliothek an einer älteren zu erstellen create version, und verweist diesen symbolischen Link auf die neueste installierte Version. Es funktioniert nicht immer, aber für den Fall, dass es fehlschlägt, kann der Symlink entfernt werden, hoffentlich sicherer (vorausgesetzt, dass vorher kein solcher Symlink oder eine Datei mit demselben Namen existierte).
Der beste Weg Um diese komplexeren Probleme zu beheben, sollten Sie immer zuerst eine apt-basierte Lösung (oder ein ähnliches Paketverwaltungstool auf Ihrem Betriebssystem) ausprobieren. An dieser Stelle sollten Sie auch lesen, wie Sie mit dkpg apt reparieren können, da es Ihnen eine detailliertere Möglichkeit zur Verwaltung von Paketen zeigt (obwohl Sie vorsichtig sein müssen, da mehr Kontrolle mit mehr Verantwortung verbunden ist!).
Wenn alles andere fehlschlägt, versuchen Sie, einen Symlink zu erstellen, oder fügen Sie die Bibliotheksdatei sogar manuell hinzu. (Stellen Sie bitte dreifach sicher, dass jede heruntergeladene Datei virenfrei ist, indem Sie sie beispielsweise mit VirusTotal überprüfen. Es ist immer am besten, die von Linux-Anbietern bereitgestellten Repositorys zum Herunterladen von Binärdateien zu verwenden.)
Im Extremfall finden Sie möglicherweise auch eine Bibliothek in einem benachbarten Linux-Betriebssystem. Zum Beispiel läuft eine ausführbare Ubuntu-Datei auf Mint und umgekehrt. Das Kopieren einer Bibliothek von einem anderen PC, den Sie haben, ist manchmal auch ein praktikabler Ansatz.
Zusammenfassung
Genaues Bibliotheksmanagement ist eine Fähigkeit, die man ein Leben lang lernen muss. Es ist fast eine Kunst. Dieser Artikel enthält die grundlegenden Informationen/das Know-how und die zu verwendenden Tools und enthält einige erweiterte Vorschläge zur Fehlerbehebung, wenn die Dinge undurchsichtig werden, und früher oder später werden sie es tun, wenn Sie ein häufiger Benutzer von Linux sind, der regelmäßig installiert Pakete.
Wenn Sie das nächste Mal den ‘Fehler beim Laden gemeinsam genutzter Bibliotheken’ Fehler auf Ihrem Linux-Rechner haben, können Sie besser verstehen, woher das Problem kommen könnte, wenn Sie ein Tool wie ldd verwenden, wie in diesem Artikel beschrieben. Wir haben uns auch statische und dynamisch kompilierte Binärdateien angesehen und wie gemeinsame oder integrierte Bibliotheken in beide passen und mit ihnen arbeiten.
Werbung
Wenn Ihnen dieser Artikel gefallen hat, möchten Sie vielleicht auch den Artikel lesen auf dpkg, das oben verlinkt ist, sowie wie man das Universum, das Multiversum und eingeschränkte Repositorys in Ubuntu hinzufügt.