事实上全部程序实行都取决于库。在包含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程序不可遭受系统变量集的太过危害。