Když posíláte binární soubor, je dobré poskytnout uživatelům prostředky, jak přizpůsobit binární soubor specifikům jejich vlastního systému, mimo jiné úpravou cest pro vyhledávání knihoven.
Uživatel může obecně vyladit LD_LIBRARY_PATH a /etc/ld.so.conf , oba mají nižší prioritu než DT_RPATH , tj. nemůžete přepsat to, co je pevně zakódováno v binárním kódu, zatímco pokud použijete DT_RUNPATH místo toho jej může uživatel přepsat pomocí LD_LIBRARY_PATH .
(FWIW, myslím ld.so.conf by také měl mít přednost před DT_RUNPATH , ale každopádně máme alespoň LD_LIBRARY_PATH ).
Také silně nesouhlasím s výše uvedeným návrhem použít DT_RPATH . IMO je nejlepší použít nether DT_RPATH ne DT_RUNPATH v dodaných binárních souborech.
ledaže
dodáváte všechny své závislé knihovny se svými spustitelnými soubory a chcete zajistit, aby věci JustWork(tm) po instalaci, v tomto případě použijte DT_RPATH .
Ale proč byl RPATH zavržen ve prospěch RUNPATH?
Když byl zaveden DT_RPATH, měl přednost před všemi ostatními parametry. To znemožnilo přepsat cestu vyhledávání knihoven ani pro účely vývoje. Proto byl zaveden další parametr, LD_RUNPATH, který má nižší prioritu než LD_LIBRARY_PATH.
Další podrobnosti lze nalézt v práci „Jak psát sdílené knihovny“, kterou napsal Ulrich Drepper .
Chillova odpověď je naprosto správná; Chtěl jsem jednoduše přidat nějakou barvu z nedávného čtení zdroje glibc ([master 8b0ccb2], v 2.17). Aby bylo jasno, pokud knihovna není nalezena v umístění určeném danou úrovní, je zkoušena další úroveň. Pokud je knihovna nalezena na dané úrovni, hledání se zastaví.
Pořadí vyhledávání v dynamické knihovně:
- DT_RPATH v binárním souboru ELF, pokud není nastaveno DT_RUNPATH.
- Záznamy LD_LIBRARY_PATH, kromě setuid/setgid
- DT_RUNPATH v binárním kódu ELF
- /etc/ld.so.cache, pokud není v čase odkazu zadáno -z nodeflib
- /lib, /usr/lib, pokud není -z nodeflib
- Hotovo, „nenalezeno“.