Der Blog-Artikel " LD_LIBRARY_PATH - oder: Wie bringst du dich selbst in Schwierigkeiten! "vom DTU Computing Center heißt es:
3. Inkonsistenz: Dies ist das häufigste Problem.
LD_LIBRARY_PATHerzwingt, dass eine Anwendung eine gemeinsam genutzte Bibliothek lädt, mit der sie nicht verknüpft wurde , und das ist höchstwahrscheinlich nicht mit der ursprünglichen Version kompatibel. Dies kann entweder sehr offensichtlich sein, d.h. die Anwendung stürzt ab oder es kann zu falschen Ergebnissen führen, wenn die aufgenommene Bibliothek nicht ganz das tut, was die ursprüngliche Version getan hätte. Besonders letzteres ist manchmal schwer zu debuggen.
Ist das wirklich wahr? Mit LD_LIBRARY_PATH können wir den Suchpfad für dynamische Bibliotheken ändern, aber unterdrückt wirklich die soname Suche, die Binärkompatibilität gewährleistet?
(Nach meiner Interpretation sagt das Programmbibliothek-HOWTO nicht so etwas.)
Oder ist dem Autor das Konzept der Aufrechterhaltung eines konsistenten Bibliotheksversionsschemas nicht bewusst und nimmt man daher an, dass eines für die fragliche Bibliothek nicht verwendet wird?
Ich denke, die LD_LIBRARY sollte nur zum Testen und nicht für eine endgültige Installation verwendet werden, da sie die Verwendung einer bestimmten Bibliothek erlaubt, bevor der Standard-Bibliotheksort verwendet wird. Aber das Linux-Dokumentationsprojekt sagt dies über LD_LIBRARY_PATH und macht es klarer als ich kann.
3.3.1. LD_LIBRARY_PATH
Sie können vorübergehend eine andere Bibliothek für dieses spezielle ersetzen Ausführung. In Linux ist die Umgebungsvariable LD_LIBRARY_PATH ein Doppelpunkt-getrennte Reihe von Verzeichnissen, in denen Bibliotheken gesucht werden sollten Erstens, vor dem Standardsatz von Verzeichnissen; Dies ist nützlich, wenn Debuggen einer neuen Bibliothek oder Verwenden einer Nicht-Standard-Bibliothek für spezielle Zwecke. Die Umgebungsvariable LD_PRELOAD listet gemeinsam genutzte Bibliotheken auf mit Funktionen, die den Standardsatz überschreiben, so wie /etc/ld.so.preload tut das. Diese werden vom Loader implementiert /lib/ld-linux.so. Ich sollte beachten, dass während LD_LIBRARY_PATH arbeitet viele Unix-ähnliche Systeme, es funktioniert nicht auf allen; zum Beispiel, dies Die Funktionalität ist in HP-UX aber als Umgebungsvariable verfügbar SHLIB_PATH, und auf AIX ist diese Funktionalität durch die Variable LIBPATH (mit derselben Syntax, eine durch Doppelpunkte getrennte Liste).
LD_LIBRARY_PATH ist praktisch für Entwicklung und Tests, sollte es aber nicht sein modifiziert durch einen Installationsvorgang für den normalen Gebrauch durch normale Benutzer; Siehe "Warum LD_LIBRARY_PATH ist schlecht" bei Ссылка für eine Erklärung warum. Aber Es ist immer noch nützlich für die Entwicklung oder das Testen und für die Arbeit Probleme, die sonst nicht bearbeitet werden können. Wenn du nicht willst Setzen Sie die Umgebungsvariable LD_LIBRARY_PATH, unter Linux können Sie sogar Rufen Sie den Programmlader direkt auf und übergeben Sie ihm Argumente. Beispielsweise, Im Folgenden wird der angegebene PATH anstelle des Inhalts von Umgebungsvariable LD_LIBRARY_PATH, und führen Sie die angegebene ausführbare Datei:
/lib/ld-linux.so.2 --library-path PATH EXECUTABLE
Wenn Sie ld-linux.so ohne Argumente ausführen, erhalten Sie mehr Hilfe Verwenden Sie dies, aber wieder, verwenden Sie dies nicht für den normalen Gebrauch - das sind alles zum Debuggen gedacht.
wurde am 13. August 2013 von: Ссылка
genommenDer Link im Dokument ist alt, hier finden Sie den gewünschten Artikel: Ссылка
bearbeiten
Sie können eine Bibliothek, mit der ein Programm während der Erstellung / Installation verknüpft ist, überschreiben, da ld.so eine Bibliothek sucht, die zur Laufzeit geladen werden soll. Eine Bibliothek, die an einer Position innerhalb der Umgebungsvariablen LD_LIBRARY_PATH gefunden wurde, wird anstelle einer Bibliothek geladen, die den Standardpfad ( /lib und /usr/lib )
von man 8 ld.so
Tags und Links linux dynamic-linking