動態連接庫通常被放在若干特殊目錄下。通常這些目錄包括/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程序不應受到環境變量集的過分影響。
