Diese Seite sagt über die Reihenfolge für die Bibliothekssuche in ld.so:
Unless loading object has RUNPATH:
RPATH of the loading object,
then the RPATH of its loader (unless it has a RUNPATH), ...,
until the end of the chain, which is either the executable
or an object loaded by dlopen
Unless executable has RUNPATH:
RPATH of the executable
LD_LIBRARY_PATH
RUNPATH of the loading object
ld.so.cache
default dirs
Und schlägt dann vor:
Wenn Sie Binärdateien versenden, verwenden Sie entweder RPATH und nicht RUNPATH oder stellen Sie sicher, dass LD_LIBRARY_PATH festgelegt ist, bevor sie ausgeführt werden.
Also verwenden RPATH mit RUNPATH ist schlecht weil RUNPATH Art von storniert RPATH das indirekte dynamische Laden funktioniert also nicht wie erwartet? Aber warum dann RPATH wurde zugunsten von verworfen RUNPATH?
Kann jemand die Situation erklären?
ich fand Dies Artikel von cmakes Umgang mit RPATH/RUNPATH informativ, also lassen Sie ihn hier für den nächsten Googler
– schneidig
10. Mai 2018 um 22:07 Uhr
Ausruhen
Wenn Sie eine Binärdatei versenden, ist es gut, den Benutzern Mittel zur Verfügung zu stellen, um die Binärdatei an die Besonderheiten ihres eigenen Systems anzupassen, unter anderem durch Anpassen der Suchpfade der Bibliothek.
Ein Benutzer kann im Allgemeinen optimieren LD_LIBRARY_PATH und /etc/ld.so.confdie beide eine niedrigere Priorität haben als DT_RPATHdh Sie können nicht überschreiben, was in der Binärdatei fest codiert ist, während Sie verwenden DT_RUNPATH Stattdessen kann ein Benutzer es mit überschreiben LD_LIBRARY_PATH.
(FWIW, glaube ich ld.so.conf sollte auch Vorrang haben DT_RUNPATHaber wie auch immer, zumindest haben wir LD_LIBRARY_PATH).
Außerdem widerspreche ich dem obigen Verwendungsvorschlag ausdrücklich DT_RPATH. IMO, es ist am besten, Nether zu verwenden DT_RPATH nicht DT_RUNPATH in ausgelieferten Binärdateien.
wenn nicht
Sie liefern alle Ihre abhängigen Bibliotheken mit Ihren ausführbaren Dateien und möchten sicherstellen, dass die Dinge JustWork(tm) nach der Installation verwenden, in diesem Fall DT_RPATH.
Das Problem ist, dass RUNPATH gegenüber RPATH empfohlen wird und RPATH veraltet ist, aber RUNPATH derzeit nicht von allen Systemen unterstützt wird. also was tue ich heute damit die Anwendung funktioniert? Wie der Qt-Artikel zeigt, ist es bei der Verwendung von Plugins sinnvoll, RPATH anstelle von RUNPATH zu verwenden. Die ganze Situation ist hier also sehr verwirrend
– saharpopov
7. November 2011 um 8:50 Uhr
@zaharpopov, Der beste Ansatz, den ich empfehlen und dem ich selbst folgen würde, besteht darin, Anwendungen zu erstellen, die gut in die Zielplattform integriert sind, was unter anderem Folgendes beinhalten würde: keine konkurrierenden Versionen der gemeinsam genutzten Bibliotheken der Plattform zu verteilen. Ich denke, das ist die Wurzel des Problems und Hacks und Schrägstriche herum DT_RPATH und Freunde sind eine fehlgeleitete Anstrengung, die versucht, das Problem zu umgehen, anstatt es zu lösen.
– Ausruhen
7. November 2011 um 9:15 Uhr
das ist nicht einfach. Bei Qt-Problemen wollte die App eine neuere Version von Qt-Bibliotheken als auf dem System vorhanden. Einige Systeme haben veraltete Qt-SOs, was würden Sie also tun? Ich denke, es macht Sinn, Qt-SOs mit Ihnen zu verteilen, wenn Sie eine bestimmte Version benötigen
– saharpopov
7. November 2011 um 13:01 Uhr
@zaharpopov, ja, es kann für die Anwendungsanbieter sinnvoll sein, die sich im Allgemeinen nur mit ihrer eigenen Anwendung und nicht mit dem großen Ganzen befassen. Aber aus Sicht von Systemanbietern und Integratoren macht es keinen Sinn Sie der ablehnt DT_RPATH.
– Ausruhen
7. November 2011 um 14:06 Uhr
Chills Antwort ist genau richtig; Ich wollte einfach etwas Farbe hinzufügen, aus einer kürzlichen Lektüre der glibc-Quelle ([master 8b0ccb2], in 2.17). Um es klar zu sagen, wenn eine Bibliothek nicht an dem Ort gefunden wird, der durch eine gegebene Ebene angegeben ist, wird die nächste Ebene versucht. Wenn eine Bibliothek auf einer bestimmten Ebene gefunden wird, stoppt die Suche.
Reihenfolge der dynamischen Bibliothekssuche:
DT_RPATH in der ELF-Binärdatei, sofern DT_RUNPATH nicht gesetzt ist.
LD_LIBRARY_PATH-Einträge, es sei denn, setuid/setgid
DT_RUNPATH in ELF-Binärdatei
/etc/ld.so.cache-Einträge, es sei denn, -z nodeflib wurde zum Linkzeitpunkt angegeben
/lib, /usr/lib, außer -z nodeflib
Fertig, “nicht gefunden”.
Michael Goren
Aber warum wurde dann RPATH zugunsten von RUNPATH verworfen?
Als DT_RPATH eingeführt wurde, hatte es Vorrang vor allen anderen Parametern. Dies machte es sogar für Entwicklungszwecke unmöglich, den Suchpfad der Bibliotheken zu überschreiben. Daher wurde ein weiterer Parameter, LD_RUNPATH, eingeführt, der eine niedrigere Priorität als LD_LIBRARY_PATH hat.
Diese Antwort erklärt die Notwendigkeit von DT_RUNPATHaber nicht warum DT_RPATH ist veraltet. Beide haben ihre eigene Verwendung und DT_RUNPATH geht kaputt libtool Wenn LD_LIBRARY_PATH wird genutzt: bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732
– vinc17
1. Juni 2017 um 16:27 Uhr
@vinc17 Ein Grund für die Ablehnung könnte sein, dass das Verhalten von DT_RPATH, nicht überschreibbar zu sein, im Allgemeinen unerwünscht ist. Es muss aus Kompatibilitätsgründen so funktionieren, wenn also das Verhalten nicht wie gewünscht geändert werden kann, wird es stattdessen entfernt und der erste Schritt ist, es zu verwerfen.
– Mecki
31. Oktober 2019 um 13:57 Uhr
@Mecki Wenn Sie möchten, dass der Pfad überschreibbar ist, können Sie verwenden DT_RUNPATH. Es besteht keine Notwendigkeit zu fallen DT_RPATH.
– vinc17
31. Oktober 2019 um 20:41 Uhr
@ vinc17 Es geht nicht darum, dass ich möchte, dass etwas überschreibbar ist, es geht darum, dass die Linux-Entwickler (die Leute, die Linux selbst entwickeln!) Nicht wollen, dass etwas existiert, das nicht überschreibbar ist, und RT_PATH nicht überschreibbar ist, also muss es aufhören zu existieren. Wenn du das nicht verstehst, kann ich dir nicht helfen. Ich bin mir ziemlich sicher, dass jeder andere Leser hier versteht, was ich meine.
ich fand Dies Artikel von cmakes Umgang mit RPATH/RUNPATH informativ, also lassen Sie ihn hier für den nächsten Googler
– schneidig
10. Mai 2018 um 22:07 Uhr