1、UNIX 系统开发静态库和动态库的建立UNIX 系统及各种软件包为开发人员提供了大量的库文件。但一般情况下这些库文件还不能足以满足用户的所有需求。开发人员大多会根据他们自己的开发、研究要求编写出许多函数。对于这些函数，如果都用在命令行中指定源文件的方法同调用它们的的程序链接起来，虽然也是可以的，但也有一些缺点：对每一个调用了这些函数的程序，在编译时都需要将这些函数的代码分别重新编译，这实际是对计算时间的大量浪费。 一个文件中通常都不止包含有一个函数的定义。使用上述编译方法将使得大量无关函数的代码被拷贝到最终的可执行文件中，无端加大对存储资源的占用量，使运行时装载变慢。 维护上的诸多不便。由于一
2、个源文件供多个程序使用，当由于某个程序的需要面对此源文件进行了某种修改时将引起诸多意想不到的麻烦。等等。 所有这些原因，使得我们想到能否将自己编写的函数也作成库文件供多个程序调用，就如同那些标准的库函数那样。事实上在 UNIX 系统中提供了这方面的工具。借助于这些工具我们不光是能将函数放到静态库，而且能够将其作成动态库。下面来看看如何生成静态库。我们知道静态库也称档案库，在此档案文件中实际上是收集了一系列的目标文件。这些目标文件就是由 CC 对函数的源代码编译生成的。因此，静态库的生成方法实际上可分成两步： 1.将各函数代码所在地源文件编译成目标文件。例如，对于前面的 myfunc.c，可以用
3、如下命令将其编译成目标文件： $ cc -c myfunc.c 当然在有多个源文件时，只需在 cc 命令行中将其分别列上就可以了。 经此一步我们将能够得到各源文件的目标文件。对上例将得到 myfunc.o。 2.将各目标文件收集起来放到一个静态库文件中。这主要借助于 ar 命令完成，如： $ ar r $HOME/lib/libtest.a myfunc.o ar:creating /home/yxz/libtest.a$这里-o $HOME/lib/libtest.a 是生成的静态库的全路径名。其中我们假定$HOME/lib 目录已经存在。注意对静态库的命名要遵循 libx.a 的原则，便于
4、以后能够在 cc 命令行中用-l 选项指定之。后面的 myfunc.o 则是待收集到档案库中的目标文件名。有多个目标文件时只需分别列上即可。这生成了 libtest.a 档案库之后，再编译 myprog.c 时，便可使用下面的办法：$ cc -L $HOME/lib -o myprog myprog.c -ltest这里-L 选项指示链接程序在$HOME/lib 目录下去搜索有关的库文件（当然它还会自动搜索标准位置） 。下一节我们对此将进行更详细的说明。最后的-ltest 选项指示链接程序在libtest.so 或 libtest.a 中取搜索 myprog.c 中对 TestInput()的
5、引用。当然由于我们并没有生成libtest.so 文件，故链接程序将只能搜索 libtest.a。另外，由于我们在命令行中并未指定-dn选项，故对于缺省的-lc 选项，链接程序将搜索 libc.so 而不是 libc.a。静态链接库的生成虽然比较简单，但此种链接方式也正因为其简单而在某些情况下达不到比较高的效率。同动态链接方式相比，这种链接方式具有如下一些明显的不足：由于在生成的可执行文件中包含有函数代码的单独拷贝，这些重复的代码会消耗掉大量的磁盘空间。 运行时各进程单独在自己的地址空间中装入它所调用的每一个函数的代码，这样在有多个进程都调用了同一个函数时，内存中将会有此函数代码的多个拷贝，无
6、端地占用比较多的内存。 由于对符号引用的确定是在编译链接时完成的。故以后对函数的定义进行更新的时候，必须重新链接调用这些函数的程序。 在虚拟存储管理方案的基础上，实现的动态链接方式克服了静态链接上述不足，而使整个系统能够获得比较高的效率。因此缺省情况下，链接程序只要有可能就要试图进行动态链接（找库函数的动态版本） 。进行动态链接的核心问题是要生成动态链接库（共享对象） 。下面我们介绍如何生成动态链接库，然后讨论建立动态链接库的一些原则。建立动态链接库并不需要用到其他的工具，借助于 cc 命令即可完成。此时需在命令行中加上-K PIC 和-G 这两个选项，如下我们可以建立 libtest 的动态
7、版本：$ cc -K PIC -G -o $ HOME/lib/libtest.so myfunc.c这里-o $ HOME/lib/libtest.so 指定待生成的动态链接库的全路径名。同静态库一样，动态库的命令应遵循 libx.so 约定。 -G 选项指示 cc 按动态链接库的格式将其各文件的目标代码组织起来。-K PIC 选项是生成动态链接库所必须的。我们已经知道，动态链接时建立在页式虚拟管理方式的基础上的。在这种需存管理方式下，进程之间内存的共享是以页为单位的。只要运行时内存页不改变，它们就能够被共享。但是这些共享的页在不同的进程中。可能会具有不同的虚地址。因此这些代码的物理地址只是
8、在运行时才能得到。 （这个过程称为地址的重定位。 ）如果在重定位某个共享对象的引用时，某个进程写了一个共享页，此时操作系统将为该进程生成改页的一个专用拷贝。这种情况下，页面共享的好处就没有了。因此程序必须尽可能减少对页面的修改的次数，减少此修改次数的方法就是使用地址浮动的代码。地址可浮动的代码将能够被装入到进程地址空间的任何地方。由于此种代码不依赖于绝对地址，故这些代码将在使用它的每一个进程中在不同的虚地址正确的运行，而且在运行过程中是没有页面修改的。-K PIC 选项的作用，就是指示编译系统生成地址可浮动的目标文件。此时在目标文件中，可重定位的引用将从所在地正文段被移动到数据段的表中。在生成
9、了动态库之后，就可以在 cc 命令行中使用它了。如：$ cc -L $ HOME/lib -o myprog myprog.c -l test这时虽然在$HOME/lib 目录下也具有 test 库的静态版本 libtest.a，但链接程序将优先搜索libtest.so。在搞清楚如何生成动态库之后，下面我们来看一看建立动态库的一些原则。所有这些原则都是为了性能的改善而提出来的。性能的改善主要涉及两方面的问题。其一是尽量减少动态链接库的数据段。我们知道，所谓共享，共享的只是代码。而对于动态库的数据段却是无法供多个进程共享的。系统将为每个共享该库文件的进程都分配该库整个数据段的一份内存拷贝。因此，
10、要想真正实现动态链接库少占用内存的目的，必须尽可能地减小共享对象的数据段大小。归纳起来，大致有以下四种方法：（1）尽量使用自动（堆栈）变量。如果自动变量行的通，就不要使用全局变量或者静态变量。（2）尽量使用函数接口而少使用全局变量进行参数的传递。这样还能够提高程序的可维护性。（3）将那些大量使用全局变量的函数排除在动态链接库之外。对于此类函数，将其放到静态链接库中比较合适。（4）动态链接库应是自包含的。也就是说在生成某个动态链接库时，对其他库的函数调用不要使用动态链接而应使用静态链接。因为在此种情况下使用动态链接时，调用该动态库中函数的进程将除了得到该动态库的数据段的拷贝以外，还将得到该数据库
11、说链接的其他动态库的数据段拷贝。这实际上是得不偿失的了。动态链接性能的改善所涉及到的第二个问题，尽量减少内存页面的交换动作。虽然使用共享库的进程并不会写共享页面，但它们仍然可能引起页面失效而导致动态链接的性能降低。对这个问题可以使用以下两种方法加以解决：（1）改进对符号引用的定位性 这包括两方面的含义。其一在共享库中排除哪些很少用到的、库本身不依赖于它们的那些函数定义。如果共享库中装有许多不相关的函数，而且只是一些不相关的进程偶尔调用这些函数，那么定位性将降低，页面的交换将会变得频繁。其二是要尽可能把相关的函数组合在一起，放到同一个页面中以改进引用的定位性。例如：假定 func1()调用了 f
12、unc2()和 func3()，并且这三个函数的代码被放到同一页中。那么在执行 func1()的代码时，func2() 和 func3()地代码也将被同时装入内存。而假如 func2()的代码与 func1()的代码不在同一页上。那么在执行 func1()的过程中可能还需要去调页，从而系统的效率将受到影响。(2)调整页面安排 这主要是指要对共享库的目标文件进行整理，使那些频繁使用的函数的代码不要越过页边界被分到不同的页上去了。完成这个工作首先要搞清楚系统内存页面的大小。然后用 nm 命令显示出目标文件中各符号的偏移值。然后据此可对各函数的位置进行调整，使那些必须跨越页边界的是那些使用不太频繁的函数，以尽可能提高页面的命中率。上述对动态链接性能改善的分析实际上也是动态链接的一些不足。因此并不是说在什么情况下都应使用动态链接而排除静态链接。理想情况下，对同一个库应提供其静态和动态两个不同的版本。这主要是由于一些用户可能找不到适合自己应用程序的动态库，另一方面有些 UNIX 系统并不支持共享对象。从上面我们对静态库和动态库建立方法的介绍，知道完成这一点并不是什么特别费力的事。
