由於静态与共享程式库两者间不相容的格式的差异性与动词*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编译各个独立的档案时，所获得的除错资讯已经足够，连结时就可以不需要它了。