由于静态与共享程序库两者间不兼容的格式的差异性与动词*link*过量使用于指称*编译完成后的事情*与*当编译好的程序使用时所发生的事情*这两件事上头，使得这一章节变得复杂了许多。（ and, actually, the overloading of the word `load' in a comparable but opposite sense）不过，再复杂也就是这样了，所以阁下不必过于担心。
为了稍微减轻读者的困惑，我们称执行期间所发生的事为*动态载入*，这一主题会在下一章节中谈到。你也会在别的地方看到我把动态载入描述成*动态连结*，不过不会是在这一章节中。换句话说，这一章节所谈的，全部是指发生在编译结束后的连结。
建立程序的最后一个步骤便是连结；也就是将所有分散的小程序组合起来，看看是否遗漏了些什么。显然，有一些事情是很多程序都会想做的---例如，开启文档，接著所有与开档有关的小程序就会将储存程序库的相关文档提供给你的程序使用。在一般的Linux系统上，这些小程序可以在/lib与/usr/lib/目录底下找到。
当你用的是静态的程序库时，连结器会找出程序所需的模块，然后实际将它们拷贝到执行档内。然而，对共享程序库而言，就不是这样了。共享程序库会在执行档内留下一个记号，指明*当程序执行时，首先必须载入这个程序库*。显然，共享程序库是试图使执行档变得更小，等同于使用更少的内存与磁盘空间。Linux内定的行为是连结共享程序库，只要Linux能找到这些共享程序库的话，就没什么问题；不然,Linux就会连结静态的了。如果你想要共享程序库的话，检查这些程序库（*.sa for a.out, *.so for ELF）是否住在它们该在的地方，而且是可读取的。
在Linux上，静态程序库会有类似libname.a这样的名称；而共享程序库则称为libname.so.x.y.z，此处的x.y.z是指版本序号的样式。共享程序库通常都会有连结符号指向静态程序库（很重要的）与相关联的.sa文档。标准的程序库会包含共享与静态程序库两种格式。
你可以用ldd（List Dynamic Dependencies）来查出某支程序需要哪些共享程序库。
$ ldd /usr/bin/lynx
libncurses.so.1 => /usr/lib/libncurses.so.1.9.6
libc.so.5 => /lib/libc.so.5.2.18
这是说在我的系统上，WWW浏览器*lynx*会依赖libc.so.5 (the C library)与libncurses.so.1（终端机萤幕的控制）的存在。若某支程序缺乏独立性， ldd就会说?statically linked＇或是?statically linked (ELF)＇。
sin() 在哪个程序库里？＇）
nm 程序库名称应该会列出此程序库名称所参考到的所有符号。这个指令可以应用在静态与共享程序库上。假设你想知道tcgetattr()是在哪儿定义的：你可以如此做，
$ nm libncurses.so.1 |grep tcget
U tcgetattr
*U*指出*未定义*---也就是说ncurses程序库有用到tegetattr()，但是并没有定义它。你也可以这样做，
$ nm libc.so.5 | grep tcget
00010fe8 T __tcgetattr
00010fe8 W tcgetattr
00068718 T tcgetpgrp
*W*说明了*弱态(weak)*，意指符号虽已定义，但可由不同程序库中的另一定义所替代。最简单的*正常*定义（像是tcgetpgrp）是由*T*所标识：
标题所谈的问题，最简明的答案便是libm.(so|a)了。所有定义在<math.h>的函数都保留在maths程序库内；因此，当你用到其中任何一个函数时，都需要以-lm的参数连结此程序库。
ld: Output file requires shared library `libfoo.so.1`
ld与其相类似的命令在搜寻文档的策略上，会依据版本的差异而有所不同，但是唯一一个你可以合理假设的内定目录便是/usr/lib了。如果你希望身处它处的程序库也列入搜寻的行列中，那么你就必须以-L选项告知gcc或是ld。
要是你发现一点效果也没有，就赶紧察看看那文档是不是还乖乖的躺在原地。就a.out而言，以-lfoo参数来连结，会驱使ld去寻找libfoo.sa（shared stubs）；如果没有成功，就会换成寻找libfoo.a（static）。就ELF而言， ld会先找libfoo.so，然后是libfoo.a。libfoo.so通常是一个连结符号，连结至libfoo.so.x。
与其它任何的程序一样，程序库也有修正不完的bugs的问题存在。它们也可能产生出一些新的特点，更改目前存在的模块的功效，或是将旧的移除掉。这对正在使用它们的程序而言，可能会是一个大问题。如果有一支程序是根据哪些旧的特点来执行的话，那怎么办？
所以，我们引进了程序库版本编号的观念。我们将程序库*次要*与*主要*的变更分门别类，同时规定*次要*的变更是不允许用到这程序库的旧程序发生中断的现象。你可以从程序库的档名分辨出它的版本（实际上，严格来讲，对ELF而言仅仅是一场天大的谎言；继续读将下去，便可明白为什么了）： libfoo.so.1.2的主要版本是1，次要版本是2。次要版本的编号可能真有其事，也可能什么都没有---libc在这一点上用了*修正程度*的观念，而订出了像libc.so.5.2.18这样的程序库名称。次要版本的编号内若是放一些字母、底线、或是任何可以列印的ASCII字元，也是很合理的。
ELF与a.out格式最主要的差别之一就是在设置共享程序库这件事上；我们先看ELF，因为它比较简单一些。
ELF（Executable and Linking Format）最初是由USL（UNIX System Laboratories）发展而成的二进位格式，目前正应用于Solaris与System V Release 4上。由于ELF所增涨的弹性远远超过Linux过去所用的a.out格式，因此GCC与C程序库的发展人士于1995年决定改用ELF为Linux标准的二进位格式。
这一节是来自于?/news-archives/comp.sys.sun.misc＇的文件。
ELF（“Executable Linking Format”）是于SVR4所引进的新式改良目的档格式。ELF比起COFF可是多出了不少的功能。以ELF而言，它*是*可由使用者自行延伸的。ELF视一目的档为节区（sections），如串列般的组合；而且此串列可为任意的长度（而不是一固定大小的阵列）。这些节区与COFF的不一样，并不需要固定在某个地方，也不需要以某种顺序排列。如果使用者希望补捉到新的资料，便可以加入新的节区到目的档内。ELF也有一个更强而有力的除错法式，称为DWARF（Debugging With Attribute Record Format） 目前Linux并不完全支持。DWARF DIEs（Debugging Information Entries）的连结串列会在ELF内形成 .debug的节区。DWARF DIEs的每一个 .debug节区并非一些少量且固定大小的信息记录的集合，而是一任意长度的串列，拥有复杂的属性，而且程序的资料会以有范围限制的树状资料结构写出来。DIEs所能补捉到的大量信息是COFF的 .debug节区无法望其项背的。（像是C++的继承图。）
ELF文档是从SVR4（Solaris 2.0 ？）ELF存取程序库（ELF access library）内存取的。此程序库可提供一简便快速的界面予ELF。使用ELF存取程序库最主要的恩惠之一便是，你不再需要去察看一个ELF档的qua了。就UNIX的文档而言，它是以Elf*的型式来存取；呼叫elf_open()之后，从此时开始，你只需呼叫elf_foobar()来处理文档的某一部份即可，并不需要把文档实际在磁盘上的image搞得一团乱。
ELF的优缺点与升级至ELF等级所需经历的种种痛苦，已在ELF-HOWTO内论及；我并不打算在这儿涂浆糊。ELF HOWTO应该与这份文件有同样的主题才是。
若想让libfoo.so成为共享程序库，基本的步骤会像下面这样：
$ gcc -fPIC -c *.c
$ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o
$ ln -s libfoo.so.1.0 libfoo.so.1
$ ln -s libfoo.so.1 libfoo.so
$ LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH ; export LD_LIBRARY_PATH
这会产生一个名为libfoo.so.1.0的共享程序库，以及给予ld适当的连结（libfoo.so）还有使得动态载入程序（dynamic loader）能找到它（libfoo.so.1）。为了进行测试，我们将目前的目录加到LD_LIBRARY_PATH里。
当你津津乐道于程序库制做成功之时，别忘了把它移到如/usr/local/lib的目录底下，并且重新设定正确的连结路径。libfoo.so.1与libfoo.so.1.0的连结会由ldconfig依日期不断的更新，就大部份的系统来说，ldconfig会在开机过程中执行。libfoo.so的连结必须由手动方式更新。如果你对程序库所有组成份子（如标头档等）的升级，总是抱持著一丝不?的态度，那么最简单的方法就是让libfoo.so -> libfoo.so.1；如此一来，ldconfig便会替你同时保留最新的连结。要是你没有这么做，你自行设定的东东就会在数日后造成千奇百怪的问题出现。到时候，可别说我没提醒你啊！
$ su
# cp libfoo.so.1.0 /usr/local/lib
# /sbin/ldconfig
# ( cd /usr/local/lib ; ln -s libfoo.so.1 libfoo.so )
每一个程序库都有一个soname。当连结器发现它正在搜寻的程序库中有这样的一个名称，连结器便会将soname钳入连结中的二进位档内，而不是它正在运作的实际的档名。在程序执行期间，动态载入程序会搜寻拥有soname这样的档名的文档，而不是程序库的档名。因此，一个名为libfoo.so的程序库，就可以有一个libbar.so的soname了。而且所有连结到libbar.so的程序，当程序开始执行时，会寻找的便是libbar.so了。
这听起来好像一点意义也没有，但是这一点，对于瞭解数个不同版本的同一个程序库是如何在单一系统上共存的原因，却是关键之钥。Linux程序库标准的命名方式，比如说是libfoo.so.1.2，而且给这个程序库一个libfoo.so.1的soname。如果此程序库是加到标准程序库的目录底下（e.g. /usr/lib），ldconfig会建立符号连结libfoo.so.1 -> libfoo.so.1.2，使其正确的image能于执行期间找到。你也需要连结libfoo.so -> libfoo.so.1，使ld能于连结期间找到正确的soname。
所以啰，当你修正程序库内的bugs，或是添加了新的函数进去（任何不会对现存的程序造成不利的影响的改变），你会重建此程序库，保留原本已有的soname，然后更改程序库档名。当你对程序库的变更会使得现有的程序中断，那么你只需增加soname中的编号---此例中，称新版本为libfoo.so.2.0，而soname变成libfoo.so.2。紧接著，再将libfoo.so的连结转向新的版本；至此，世界又再度恢复了和平！
其实你不须要以此种方式来替程序库命名，不过这的确是个好的传统。ELF赋予你在程序库命名上的弹性，会使得人气喘呼呼的搞不清楚状况；有这样的弹性在，也并不表示你就得去用它。
ELF总结：假设经由你睿智的观察发现有个惯例说：程序库主要的升级会破坏兼容性；而次要的升级则可能不会；那么以下面的方式来连结，所有的一切就都会相安无事了。
gcc -shared -Wl,-soname,libfoo.so.major -o libfoo.so.major.minor
建立共享程序库的便利性是升级至ELF的主要原因之一。那也是说,a.out可能还是有用处在的。上ftp站去抓 ftp://tsx-11.mit.edu/pub/linux/packages/GCC/src/tools-2.17.tar.gz；解压缩后你会发现有20页的文件可以慢慢的读哩。我很不喜欢自己党派的偏见表现得那么的淋璃尽致，可是从上下文间，应该也可以很清楚的嗅出我从来不拿石头砸自己的脚的脾气吧！:-)
QMAGIC是一种类似旧格式的a.out（亦称为ZMAGIC）的可执行档 格式，这种格式会使得第一个分页无法map。当0-4096的范围内没有mapping存在时，则可允许NULL dereference trapping更加的容易。所产生的边界效应是你的执行档会比较小（大约少1K左右）。
只有即将作废的连结器有支持ZMAGIC，一半已埋入棺材的连结器有支持这两种格式；而目前的版本仅支持QMAGIC而已。事实上，这并没有多大的影响，那是因为目前的核心两种格式都能执行。
*file*命令应该可以确认程序是不是QMAGIC的格式的。
一a.out(DLL)的共享程序库包含两个真实的文档与一个连结符号。就*foo*这个用于整份文件做为范例的程序库而言，这些文档会是libfoo.sa与libfoo.so.1.2；连结符号会是libfoo.so.1，而且会指向libfoo.so.1.2。这些是做什么用的？
在编译时，ld会寻找libfoo.sa。这是程序库的*stub*文档。而且含有所有执行期间连结所需的exported的资料与指向函数的指标。
执行期间，动态载入程序会寻找libfoo.so.1。这仅仅是一个符号连结，而不是真实的文档。故程序库可更新成较新的且已修正错误的版本，而不会损毁任何此时正在使用此程序库的应用程序。在新版---比如说libfoo.so.1.3---已完整呈现时，ldconfig会以一极微小的操作，将连结指向新的版本，使得任何原本使用旧版的程序不会感到丝毫的不悦。
DLL程序库（我知道这是无谓的反覆---所以对我提出诉讼吧！）通常会比它们的静态副本要来得大多。它们是以*洞（holes）*的形式来保留空间以便日后的扩充。这种*洞*可以不占用任何的磁盘空间。一个简单的cp呼叫，或是使用makehole程序，就可以达到这样效果。因为它们的位址是固定在同一位置上，所以在建立程序库后，你可以把它们拿掉。不过，千万不要试著拿掉ELF的程序库。
libc-lite是轻量级的libc版本。可用来存放在磁盘片上，也可以替大部份低微的UNIX任务收尾。它没有包含curses, dbm, termcap等等的程序码。如果你的/lib/libc.so.4是连结到一个lite的libc，那么建议你以完整的版本取代它。
把你连结时所遭遇的问题寄给我！我可能什么事也不会做，但是只要累积了足够的数量，我会把它们写起来*。
检查你提供给ld的连结是否正确，使ld能找到每一个对应的共享程序库，就ELF而言，这是指一个符号连结libfoo.so，连结至image；就a.out而言，就是libfoo.sa档了。很多人将ELF binutils 2.5升级至2.6之后，就产生了这个问题---早期的版本搜寻共享程序库时较有智慧，所以并没有将所有的连结建立起来。后来，为了与其它的架构兼容，这项充满智慧的行为被人给删除掉了，另外，这样的*智慧*判断错误的机率相当高，所造成的麻烦比它所解决的问题还多，所以留著也是害人精；不如归去兮！
自libc.so.4.5.x之后，libgcc已不再是共享的格式。因此，你必须在*-lgcc*出现之处以`gcc -print-libgcc-file-name`替代（完整的倒单引号（back-quotes））。另外，删除所有/usr/lib/libgcc*的文档。这点很重要哩。
__NEEDS_SHRLIB_libc_4 multiply defined messages 是同样的问题所造成的另一种结果。
这一条神秘的信息最有可能的原因是，在原始的jump.vars文档内，由于保留的空间太少，以致于造成其中一个jump table slots溢满。你可以执行工具程序 由2.17.tar.gz套件所提供的?getsize＇命令，定出所有嫌疑犯的踪迹。可能唯一的解决方法是，解除此程序库主要的版本编号，强迫它回到不兼容的年代。
ld: output file needs shared library libc.so.4 通常这是发生在当你连结的程序库不是libc（如X程序库），而且在命令列用了-g的参数，却没有一并使用-static，所发出的错误信息。
共享程序库的.sa stubs通常有一个未定义的符号_NEEDS_SHRLIB_libc_4；这一点可藉由libc.sa stub来解决，然而，以-g来编译时，会使得连结以libg.a或libc.a来结束；因此这个符号一直就没有解决，也就会导致上面的错误信息了。
总之，以-g的旗号编译时别忘了加上-static，不然就别用-g来连结。通常，以-g编译各个独立的文档时，所获得的除错信息已经足够，连结时就可以不需要它了。