Wo sucht Ubuntu nach gemeinsam genutzten Bibliotheken?

Wenn ich einen Prozess ausführe, der zur Laufzeit mit einer gemeinsam genutzten Bibliothek verknüpft ist (verknüpft, wenn der Prozess gestartet wird, nicht verknüpft mit dlload()), wo sucht er nach dieser gemeinsam genutzten Bibliothek ( .so) -Datei anders als LD_LIBRARY_PATH?

Hintergrund:

Ich habe C ++ - Code geschrieben, der eine bestimmte Bibliothek eines Drittanbieters verwendet. Ich habe die Bibliothek installiert und meinen Code auf zwei verschiedenen Plattformen kompiliert, sowohl Ubuntu als auch verschiedene Versionen und auch verschiedene Versionen von gcc. Die Bibliothek wurde aus dem Quellcode kompiliert und installiert und befindet sich /usr/local/libauf beiden Plattformen. Wenn ich meinen Code kompiliere, verknüpfe ich mich mit den pkg-config --libsParametern für die Drittanbieter-Bibliothek und habe überprüft, dass pkg-config --libsauf beiden Plattformen genau dasselbe zurückgegeben wird.

Mein Code wird auf beiden Plattformen erfolgreich kompiliert und LD_LIBRARY_PATHist auf beiden Plattformen nicht definiert (oder als leer definiert "":). Wenn ich es jedoch auf einer Platoform starte, funktioniert es einwandfrei, und auf der anderen bekomme ich den folgenden Fehler:

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

Witzigerweise diejenigen , die nicht tut Arbeit ist die neuere Version von Ubuntu und gcc. : /

Also versuche ich herauszufinden, wie der funktionierende Benutzer die Bibliothek finden kann, damit der kaputte Benutzer die Bibliothek auf die gleiche Weise findet. (dh ohne Einstellung LD_LIBRARY_PATH)

Aktualisieren:

Hier ist meine Ausgabe von cat /etc/ld.so.conf.d/*

... auf dem funktionierenden (älteren) System:

/usr/lib/mesa
/usr/lib32/mesa
/usr/lib/alsa-lib
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

... auf dem kaputten (neueren) System:

# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/mesa

libraries shared-library dynamic-linking

— Dave Lillethun
quelle

Ich denke, diese Orte sind in definiert /etc/ld.so.conf.d/*.conf, aber ich bin mir nicht sicher.

— Salem

Scheint so, aber siehe mein Update auf die OQ für den Inhalt dieser Dateien ... So wie es aussieht, sollte es finden, /usr/local/lib/libthrift-0.9.0.soaber es gibt immer noch den Fehler error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory... Gibt es einen Grund, warum es kein Verzeichnis abholen würde /etc/ld.so.conf.d/*.conf?

— Dave Lillethun

Versuchen Sie, sudo ldconfig -vwie unten vorgeschlagen zu starten . Wenn es immer noch nicht funktioniert, aktualisieren Sie Ihre Frage mit der Ausgabe von ldd /path/to/your/application.

— Salem

Antworten:

Dieses ganze Pfadgeschäft ist mit etwas verwandt, das Multi-Arch genannt wird. Grundsätzlich ist es so, dass Sie 32-Bit- und 64-Bit-Bibliotheken auf demselben System haben.

Haben Sie nach dem Kopieren der Datei zufällig ldconfig ausgeführt?

ldconfig  creates,  updates,  and removes the necessary links and cache
       (for use by the run-time linker,  ld.so)  to  the  most  recent  shared
       libraries  found  in  the directories specified on the command line, in
       the file /etc/ld.so.conf, and in the trusted directories (/usr/lib  and
       /lib).   ldconfig  checks the header and file names of the libraries it
       encounters when determining which  versions  should  have  their  links
       updated.  ldconfig ignores symbolic links when scanning for libraries.

— Matt H
quelle

Ich bin gelaufen sudo ldconfigund das hat das Problem behoben! (Musste meinen Code oder irgendetwas nicht neu kompilieren ...) Ich möchte nur verstehen ... Sie sagten "Nachdem Sie die Datei kopiert haben", aber ich habe keine Datei kopiert. Meinen Sie damit, nachdem ich die Bibliothek erstellt und installiert habe oder nachdem ich mein Programm kompiliert habe?

— Dave Lillethun

Nachdem Sie es dort platziert haben, wo Sie es platziert haben. Grundsätzlich wird ein Bibliothekscache aufgebaut. Ich denke, ein Neustart kann auch den Cache neu erstellen.

— Matt H

Ich kann mich irren, aber ich glaube, ich hatte seit der Installation der Bibliothek einen Neustart durchgeführt ... Hat sudo ldconfigjedoch den Trick getan. Ist dies etwas, was Bibliotheken oft automatisch für Sie als Teil ihrer Installation ausführen, und dies aus irgendeinem Grund nicht? Ich frage mich nur, warum ich das "normalerweise" nicht tun muss, sondern nur in diesem Fall ...

— Dave Lillethun

Normalerweise wird die Paketinstallation ldconfig während des Installationsprozesses ausführen, denke ich. Vielleicht macht es die Version auf Ihrer neueren Distribution aus irgendeinem Grund nicht.

— Matt H

Die in der obigen Frage UND der ersten (und einzigen) Antwort von ATT enthaltenen Informationen halfen mir, * ein ähnliches * Problem von mir unter WSL Ubuntu (unter Win10 64) zu lösen!

In meinem Fall konnte die ausführbare Datei keine Bibliothek finden. Ich bemerkte schließlich , dass die neu hergestellte Bibliothek wurde positioniert /usr/lib64, aber die Mehrbogenlinien /etc/ld.so.conf.d/x86_64-linux-gnu.conf haben nicht enthalten dieses Verzeichnis.

Also rannte ich

sudo ldconfig /usr/lib64

und das hat es endlich behoben. (Wenn Sie es alleine ohne den Verzeichnisparameter ausführen, wurde die Bibliothek nicht "magisch" gefunden.) Es ist unklar, ob ein "Neustart" meiner WSL-Bash geholfen hat ... Ich denke, das wurde nicht einmal benötigt.

— Jordan Gee
quelle

Das gleiche passierte mir mit / usr / local / lib /. Ich habe eine Datei erstellt /etc/ld.so.conf.d/usr-local.confund sie dann sudo ldconfigohne Effekt ausgeführt - Bibliotheken in diesem Verzeichnis wurden vom Loader nicht gefunden. Nach dem Laufen hat sudo ldconfig /usr/local/liballes gut funktioniert.

— Josh Milthorpe