近两天一直在考量产品安装包改进的事宜。说实话，我们的安装包做得不够"专业"，不仅没有按照各个平台的标准安装包形式(比如redhat的rpm，debian的deb或solaris上的pkg包)制作，而且安装包在生产环境中还需要再进行一次链接才能得到最终的可执行程序。这样一来，每次制作安装包都很费时费力(虽然有自动打包脚本)，安装包的"体积"也很是庞大，因为包中要包含所有.o目标文件和一部分自有库以及第三方库的.a文件。

究竟为何还需要在生产环境中重新链接一次，此问题年头已久，之前无人深究，现在也就没有了现成的答案，这次花了些时间查了一下，发现居然是有关共享库的一个问题。关于共享库，我平时接触的不多，工作中更多愿意使用静态库进行静态链接，这样一来实际上我对共享库的了解也不够深刻。

众所周知，静态链接和动态链接各有不足，也各有千秋：
采用静态链接，最终可执行文件的Size会比较大，因为你在可执行文件中包含了一份程序所依赖的库中的符号的代码copy(注意：不是整个静态库的copy)。不过也恰是由于这点，可执行程序被部署到运行环境下后就简单多了，它运行时不需要再依赖任何其他库了，是典型的自我满足型。

而动态链接则与静态链接恰恰相反，由于编译时仅仅是记录了其运行所依赖的共享库的名字而并未真正包含一份库的copy，所以这样的可执行文件的Size都较小，但在运行环境中我们需要先进行一番配置以让链接器能找到可执行程序所依赖的共享库。

但实际工作中，完全的采用静态链接有时是会遇到麻烦的。因为很多OS在默认安装时是不带开发包的，也就是说像libc、libpthread等系统库只提供了共享库版本(如/lib下提供了libc的共享库libc.so.6)，其静态库版本是需要自行下载、编译和安装的(如libc的静态库libc.a在安装后是放在/usr/lib下面的)。所以多数情况下，我们是将两种链接方式混合在一起使用的，至少像libc这样的系统库多是采用动态链接的。

共享库的制作方法很简单，用下面两行代码我们就可以得到一个名为libfoo.so的共享库：
gcc -fPIC -c libfoo.c -o libfoo.o
gcc -shared -o libfoo.so libfoo.o

不过不知道大家是否留意过：在/lib和/usr/lib等集中放置共享库的目录下，你总是会看到诸如下面的情况：
2010-12-10 12:28 libfoo.so -> libfoo.so.0.0.0*
2010-12-10 12:28 libfoo.so.0 -> libfoo.so.0.0.0*
2010-12-10 12:28 libfoo.so.0.0.0*

关于libfoo.so居然有三个文件入口，其中libfoo.so.0.0.0是真正的共享库文件，而其他两个文件入口则是指向libfoo.so.0.0.0的符号链接。为何会出现这个情况呢？这与共享库的命名惯例和版本管理不无关系。

共享库的惯例中每个共享库都有多个名字属性，包括real name、soname和linker name：
real name – 指的是实际包含共享库代码的那个文件的名字(如上面例子中的libfoo.so.0.0.0)，也是在共享库编译命令行中-o后面的那个参数;

soname – 是shared object name的缩写，也是这三个名字中最重要的一个，无论是在编译阶段还是在运行阶段，系统链接器都是通过共享库的soname(如上面例子中的libfoo.so.0)来唯一识别共享库的。即使real name相同但soname不同，也会被链接器认为是两个不同的库。共享库的soname可在编译期间通过传给链接器的参数来指定，如上例中我们可以通过"gcc -shared -Wl,-soname -Wl,libfoo.so.0 -o libfoo.so.0.0.0 libfoo.o"来指定libfoo.so.0.0.0的soname为libfoo.so.0(在solaris上的命令为"gcc -shared -Wl,-h -Wl,libfoo.so.0 -o libfoo.so.0.0.0 libfoo.o")。ldconfig -n directory_with_shared_libraries命令会根据共享库的soname自动生成一个名为soname的符号链接指向real name文件，当然你也可以通过ln命令自己来创建这个符号链接。另外在linux下我们可通过readelf -d查看共享库的soname(在solaris下可使用dump -Lvp查看)，ldd输出的ELF文件依赖的共享库列表中显示的也是共享库的soname及所在路径。

linker name – 是编译阶段提供给编译器的名字(如上面例子中的libfoo.so)。如果你构建的共享库的real name是类似于上例中libfoo.so.0.0.0那样的带有版本号，那么你在编译器命令中直接使用-L path -lfoo是无法让链接器找到对应的共享库文件的，除非你为libfoo.so.0.0.0提供了一个linker name(如libfoo.so，一个指向libfoo.so.0.0.0的符号链接)。linker name一般在共享库安装时手工创建。

了解了共享库的名称惯例后，我们考虑如何使用这些共享库。使用共享库分为两个阶段，第一个阶段是可执行文件构建阶段。构建阶段我们需要为编译器(实为链接器)提供可执行程序依赖的共享库的位置信息：

如果依赖的共享库放置在链接器搜索的默认目录下(linux下一般依次为/lib和/usr/lib; solaris下依次为/usr/ccs/lib，/lib和/usr/lib)，你可以直接使用-l指定共享库的linker name即可；

如果依赖的共享库在非默认路径下，可使用-L来告知位置，比如gcc -o fooapp fooapp.c -L private_shared_lib_dir -lfoo，与默认目录相比，-L指定的目录优先级更高，另外注意：这里-L的位置信息并不记录在fooapp文件中，也不会对fooapp的执行产生影响；

在Solaris上，通过配置LD_LIBRARY_PATH也可以为编译器指定共享库路径，且其优先级比-L指定的路径更高，不过在Linux上LD_LIBRARY_PATH在编译阶段似乎不起作用。

运行时阶段，链接器同样要确定可执行文件依赖的共享库的位置和版本，不过与编译构造阶段不同，运行时的链接器按如下顺序搜索共享库：

-rpath
链接器优先在可执行文件中记录的rpath路径下搜索。rpath是在编译时传给链接器的路径参数：
linux平台下可使用：gcc -o fooapp fooapp.c -Wl,-rpath -Wl,fooapp_rpath -L foo_so_path -lfoo
solaris下可用：gcc -o fooapp fooapp.c -R fooapp_rpath -L foo_so_path -lfoo
多个路径可用冒号分割。编译成功后，这些信息会被记录在最终文件的RPATH节中，在运行时链接器读取RPATH节并搜索其值对应的目录。ldd 显示的是运行时应用依赖的库及其在运行环境下的确定路径，例如ldd fooapp的结果为：libfoo.so.0 => fooapp_rpath/libfoo.so.0 (0×00458000)

LD_LIBRARY_PATH
如果fooapp_rpath实际并不存在，则链接器会尝试在LD_LIBRARY_PATH配置的路径中查找依赖的共享库。

ldconfig配置的缓存中的路径
如果在rpath和LD_LIBRARY_PATH中依旧没有搜索到libfoo.so，那么链接器将尝试在ldconfig配置缓存中查找。linux平台上使用ldconfig配置搜索路径的方法如下：在/etc/ld.so.conf.d下增加一个自定义的链接器搜索路径配置文件，执行ldconfig更新缓存后生效。

系统默认路径
链接器最后将在默认路径下查找相关共享库，linux和solaris下均为/lib和/usr/lib。

如果在以上路径下依然没有找到libfoo.so，那么fooapp运行将出错。

好了，到目前为止，前面提到安装包的问题的原因也可以解释清楚了，问题就在于使用了-rpath但却没有在生产环境下进行共享库的配置。一旦安装包制作环境下记录到-rpath中的路径在生产环境下无法找到，且生产环境下没有将相关库的路径配置到链接器搜索的路径下，那么安装后的可执行文件执行时就会出错。解决方法有多种，这里就不赘述了。

上午对一段代码进行单元测试，由于需要用到mock，所以选择使用cmockery
作为Unit Testing框架(lcut还未提供mock功能)。测试代码里需要mock malloc以模拟分配内存失败的异常情况。

编写一个用例后，Build，提示出错：multiple definition of `malloc'。经检查发现Makefile中定义mock malloc的那个目标文件(.o文件)居然被link了两次，类似于下面的这种错误情形：
$ gcc testmain.c malloc.o malloc.o
malloc.o: In function `malloc':
malloc.c:(.text+0×0): multiple definition of `malloc'
malloc.o:malloc.c:(.text+0×0): first defined here
collect2: ld returned 1 exit status

去掉一个显式链接的malloc.o文件后Build顺利通过，运行该单元测试，程序dump core，对此很是疑惑！使用gdb查看core文件，很快发现了问题所在：因为cmockery本身也使用了malloc，但在链接过程中，cmockery库中的malloc符号被绑定到了malloc.c中的那个malloc实现上了，而我们mock的那个malloc在测试用例中又被设置返回NULL，这样非法地址访问就不足为奇了。

对以上两个问题的理解或多或少都需要一些链接方面的知识，这里你可能会问到以下两个问题：
1、C运行库(libc.a)是要被作为默认库隐式提供给ld程序做链接的，那么用自己实现的malloc替代C标准库中的malloc，链接器在链接时为什么没有检查出重定义？
2、cmockery库中的malloc是如何绑定到我们自己实现的那个malloc上的呢？为什么不绑定到C运行库中的那个malloc？

从问题内容我们也似乎可隐约推论出一点：那就是链接器对目标文件(.o)和归档文件(.a)的对待似乎是不同的。没错，的确是这样的。

可执行程序是由一系列.o文件“合并”而成。以静态链接为例，.o文件集合中除了包含我们显式(.c->.o)提供的.o文件外，还有从归档文件(.a)中提取出来的.o文件。这类.o文件是“按需”从.a中提取出来的，这也符合.a文件最初设计的初衷(减少可执行文件的size + 减少可执行文件load到内存后的内存占用)。

我们用一个的例子来解释.o文件“按需”从.a中提取的过程，也顺便回答上面的两个问题。
我们有三个源文件testmain.c、print.c和libprint.c，三个文件都很简单：
/* testmain.c */
extern void print();

int main() {
    print();
    return 0;
}

/* print.c */
#include
void print() {
    printf("print in object files\n");
}

/* libprint.c */
#include
void print() {
    printf("print in archive files\n");
}
我们将libprint.c构建为一个.a文件(gcc -c libprint.c; ar rcs libprint.a libprint.o)，用于模拟库中的符号。print.c中的print则是我们自定义函数，试图用来替换库中同名函数。

执行gcc testmain.c print.c -L ./ -lprint，编译顺利通过。执行a.out，输出“print in object files”。显然testmain.c中的print调用被绑定到print.o中的print函数了。分析这个编译链接过程，我们就能回答上面的两个问题了。

我们知道gcc只是一组gnu compile tools的外部名称，gcc像个指挥官，协调一系列tools去完成任务。其中链接是最后一环，ld的输入是.o文件和.a文件。以这个例子来说，最后一步执行的是ld testmain.o print.o -L ./ -lprint …..，其中…..代表的是默认传入的C运行库。链接器从左向右扫描命令行参数中的.o和.a，目的是确定最终.o集合以及为每个.o中的外部符号(引用了但是未在本.o文件中定义)确定具体定义的位置。

链接器依从左到右顺序首先扫描testmain.o，将testmain.o加入到"最终.o文件集合"(初始该集合为空)，并发现testmain.o中引用了符号print，但却未定义，将该符号放到"undefined集合"中（初始"undefined集合"为空），另外testmain中还有一个符号main，与print不同，该符号为已定义的符号，同样链接器将之放到"defined集合"中(初始"defined集合"为空)。

继续从左向右扫描，轮到print.o这个目标文件了。该文件中有一个已定义的符号print和一个引用但未定义的外部符号printf，链接器的处理过程是：发现print是当前"undefined集合"中的元素，将print从"undefined集合"中取出，放入"defined集合"中; printf因无法确定定义，放入"undefined集合"，print.o放入"最终.o文件集合"。

继续向右扫描，遇到libprint.a。上面说过链接器对待.a与.o不同，.a中的符号是按需提取，这里的“按需”指的就是"undefined集合"中的符号。当前"undefined集合"中只有一个元素：printf，链接器尝试在libprint.a中查找printf的定义，未果。则链接器略过libprint.a，继续向右扫描。

最后剩下的就是libc.a了，也就是默认传递的C运行库。libc.a中包含了成百上千个.o文件。但目前只剩下printf一个符号没有得到定义了，我们只需要libc.a中包含printf符号定义的那个.o文件，也就是print.o，链接器找到print.o后将print.o放入"最终.o文件集合"，将printf符号从"undefined集合"挪到"defined集合"中，此致"undefined集合"变为空集合了。也就说明这次链接是成功的。

相信上面的两个问题通过这段过程描述已经可以被解释了。

如果我们将构建语句写为:gcc testmain.c -L./ -lprint print.c会发生什么呢？我们看看执行结果：
/tmp/ccSNKvLP.o: In function `print':
print.c:(.text+0×0): multiple definition of `print'
.//libprint.a(libprint.o):libprint.c:(.text+0×0): first defined here
collect2: ld returned 1 exit status

出现重定义错误！不过有了之前的基础，这里的重定义也很好理解了。gcc testmain.c -L./ -lprint print.c执行到最后一步是ld testmain.o -L./ -lprint print.o ….; 链接器扫描完libprint.a后，print的符号已经从libprint.a中的libprint.o目标文件中被"按需"提取出来放入"defined集合"中了。接下来链接器扫描print.o居然又发现了一个名为print的全局定义的符号，与"defined集合"中冲突，ld自然就会报错。

我们再来做点修改，构造一个稍微复杂些的例子：
/* testmain.c */
extern void do_print();

int main() {
    do_print();
    return 0;
}

/* print.c */
#include
void print() {
    printf("print in object files\n");
}

/* libprint.c */
#include
void print();
void do_print() {
    print();
}

void print() {
    printf("print in archive files\n");
}
在testmain.c中我们换作调用do_print了，do_print在libprint.a中有定义。执行gcc testmain.c print.c -L ./ -lprint，结果出错：
.//libprint.a(libprint.o): In function `print':
libprint.c:(.text+0xd): multiple definition of `print'
/tmp/ccoWjHZS.o:print.c:(.text+0×0): first defined here
collect2: ld returned 1 exit status

这回怎么又变成“重定义”了呢？我们来分析一下：
*扫描testmain.o，"undefined集合"中有了符号do_print;
*扫描print.o，"undefined集合"未变，"defined集合"中增加了print
*碰到libprint.a，按照"按需"提取的原则，我们找到了do_print定义，"undefined集合"中的do_print被移到"defined集合"，libprint.a中的libprint.o被放置到"最终.o文件集合"中;与前面例子不同的是libprint.o中有两个符号do_print和print，作为"最终.o文件集合"中的一分子，libprint.o的地位与testmain.o和print.o是一致的，链接器需要扫描其全部内容，而不仅仅只是提取do_print，这样链接器又发现一个print的定义，与"defined集合"中的print符号重复，链接器报错！

如果要进一步了解链接器相关内容的话，推荐阅读一下下面几本书籍：
1、《链接器与加载器》
2、《深入理解计算机系统》
3、国人总结性质的大作《程序员的自我修养–链接、装载与库》