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

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

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

在包括所有Linux系統的基于GNU glibc的系統中，程序啟動時自動尋找的目錄列表存儲在文件/etc/ld.so.conf中。很多源于Red Hat的發行版一般在文件/etc/ld.so.conf中不包含/usr/local/lib。我認為這是個Bug，要在源于Red Hat的系統里運行很多程序都需要進行一個通用的“修復”，把/usr/local/lib加入/etc/ld.so.conf。如果只是想覆蓋某個庫里的若干函數，而想保留該庫的其它部分，可以在/etc/ld.so.preload中輸入要覆蓋的庫名（.o文件）；這些“預載入”的庫會優先于標準庫使用。通常這種預載入文件是用于緊急補丁的；發行版在發行時一般不會包含這樣的文件。在程序啟動時尋找所有這些目錄太花時間，所以實際上使用了一個cache管理方法。程序ldconfig(8)缺省讀入文件/etc/ld.so.conf，在動態連接目錄里建立相應的符號連接（這樣就遵循了標準約定），然后把cache寫入/etc/ld.so.cache，這樣就可以被其它程序使用了。所以一旦增加一個DLL，或刪除一個DLL，或者DLL目錄集發生改變，ldconfig就要運行一次；在安裝庫時，運行ldconfig通常是軟件包管理程序需要執行的一個步驟。在啟動時，程序使用動態加載程序來讀入文件/etc/ld.so.cache，然后載入其所需的庫。

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

如果不采取特別的措施，允許用戶控制動態連接庫會對setuid/setgid程序造成災難性的后果。因此在實現GNU glibc時，如果是setuid或setgid程序，將忽略這些變量（和其它類似的變量），或者嚴格限制這些變量所起的作用。GNU的glibc庫通過檢查程序的證明來確定其是否為setuid或setgid程序；如果uid和euid不同，或者gid和egid不同，則庫就假設該程序為setuid/setgid程序（或者為其子程序），然后嚴格限制它控制連接的能力。如果載入GNU的glibc庫，就可以看到這種情況；請特別閱讀一下文件elf/rtld.c和sysdeps/generic/dl-sysdep.c。這就意味著如果使uid和gid等于euid和egid，再調用程序，這些變量就具有完全的效力。其它類Unix系統處理這些情況有所不同，但原因相同：一個setuid/setgid程序不應受到環境變量集的過分影響。