實際上所有程序執(zhí)行都依賴于庫。在包括Linux的大多數(shù)現(xiàn)代類Unix系統(tǒng)中，程序缺省使用動態(tài)連接庫（DLL）進行編譯。這樣就可以更新某個庫，所有使用該庫的程序如果可能的話，都將使用新的（希望有所改進的）版本。

動態(tài)連接庫通常被放在若干特殊目錄下。通常這些目錄包括/lib、/usr/lib、有關(guān)PAM模塊的/lib/security、有關(guān)X-windows的/usr/X11R6/lib和/usr/local/lib。

對于庫的命名和進行庫的符號連接有些特殊約定，這樣就可以更新庫，同時繼續(xù)支持需要使用不具有反向兼容的老版本庫的程序。在執(zhí)行特定程序時可以覆蓋某個指定庫，甚至只覆蓋某個庫里的指定函數(shù)。這是類Unix系統(tǒng)相對于類Windows系統(tǒng)的一個實際優(yōu)點；我相信類Unix系統(tǒng)有一個更好的系統(tǒng)來處理庫的更新，這也是Unix和Linux系統(tǒng)被認為比基于Windows的系統(tǒng)更穩(wěn)定的原因。

在包括所有Linux系統(tǒng)的基于GNU glibc的系統(tǒng)中，程序啟動時自動尋找的目錄列表存儲在文件/etc/ld.so.conf中。很多源于Red Hat的發(fā)行版一般在文件/etc/ld.so.conf中不包含/usr/local/lib。我認為這是個Bug，要在源于Red Hat的系統(tǒng)里運行很多程序都需要進行一個通用的“修復(fù)”，把/usr/local/lib加入/etc/ld.so.conf。

如果只是想覆蓋某個庫里的若干函數(shù)，而想保留該庫的其它部分，可以在/etc/ld.so.preload中輸入要覆蓋的庫名（.o文件）；這些“預(yù)載入”的庫會優(yōu)先于標(biāo)準(zhǔn)庫使用。通常這種預(yù)載入文件是用于緊急補丁的；發(fā)行版在發(fā)行時一般不會包含這樣的文件。

在程序啟動時尋找所有這些目錄太花時間，所以實際上使用了一個cache管理方法。程序ldconfig(8)缺省讀入文件/etc/ld.so.conf，在動態(tài)連接目錄里建立相應(yīng)的符號連接（這樣就遵循了標(biāo)準(zhǔn)約定），然后把cache寫入/etc/ld.so.cache，這樣就可以被其它程序使用了。所以一旦增加一個DLL，或刪除一個DLL，或者DLL目錄集發(fā)生改變，ldconfig就要運行一次；在安裝庫時，運行l(wèi)dconfig通常是軟件包管理程序需要執(zhí)行的一個步驟。在啟動時，程序使用動態(tài)加載程序來讀入文件/etc/ld.so.cache，然后載入其所需的庫。

各種環(huán)境變量可以控制這一過程，而且事實上也有允許覆蓋此過程的環(huán)境變量（所以可以在某次特別的執(zhí)行過程中臨時替換某個不同的庫）。在Linux下，環(huán)境變量LD_LIBRARY_PATH是一組用逗號隔開的目錄，在查找標(biāo)準(zhǔn)目錄集之前先查找這些庫；這在調(diào)試新庫或為特殊目的使用非標(biāo)準(zhǔn)庫時很有用。變量LD_PRELOAD列出了覆蓋標(biāo)準(zhǔn)集的函數(shù)所在的目標(biāo)文件，就像/etc/ld.so.preload一樣。

如果不采取特別的措施，允許用戶控制動態(tài)連接庫會對setuid/setgid程序造成災(zāi)難性的后果。因此在實現(xiàn)GNU glibc時，如果是setuid或setgid程序，將忽略這些變量（和其它類似的變量），或者嚴(yán)格限制這些變量所起的作用。GNU的glibc庫通過檢查程序的證明來確定其是否為setuid或setgid程序；如果uid和euid不同，或者gid和egid不同，則庫就假設(shè)該程序為setuid/setgid程序（或者為其子程序），然后嚴(yán)格限制它控制連接的能力。如果載入GNU的glibc庫，就可以看到這種情況；

請?zhí)貏e閱讀一下文件elf/rtld.c和sysdeps/generic/dl-sysdep.c。這就意味著如果使uid和gid等于euid和egid，再調(diào)用程序，這些變量就具有完全的效力。其它類Unix系統(tǒng)處理這些情況有所不同，但原因相同：一個setuid/setgid程序不應(yīng)受到環(huán)境變量集的過分影響。