我之前写过一篇名为"也谈共享库"的博文，对共享库的查找和符号解析机制做了还算比较详细的说明，不过百密一疏，总有一些意想不到的情况发生。这不今天我又遇到了一个有关共享库的新问题，这里将这个问题及其解决过程记录下来，也算是对上一篇文章中未涉及内容的一个补充吧。

N年前我曾参与过部门的一个可复用系统的设计开发，当时我们设计了一种插件式的系统结构，其中所谓的"插件"是以共享库的形式提供。主程序通过读取配置，获取插件的位置，并在运行期利用dlopen动态加载插件(.so文件)，用dlsym查找、绑定并执行.so中的特定业务函数。

我们可以用下面样例代码简单地模拟出这种设计：

/*
 * 主程序 main.c */
 * 需include dlfcn.h、link.h等标准头文件，这里省略
 */
typedef int (*PLUGIN_MAIN_FUNC)(void);

int main() {
        void *handle = NULL;
        char *dso = "plugin.so";
        char *func_name = "plugin_main";
        PLUGIN_MAIN_FUNC func = NULL;

        handle = dlopen(dso, RTLD_LAZY);
        if (handle == NULL) {
                printf("dlopen (%s)失败!\n", dso);
                return -1;
        }

        func = dlsym(handle, func_name);
        if (func == NULL) {
                printf("dlsym (%s)失败!\n", func_name);
                return -1;
        }

        printf("%d\n", my_add(4, 8));
        printf("%d\n", func());

        dlclose(handle);
        return 0;
}

以下my_add接口可以理解为主程序所使用的底层库，亦可为plugin程序使用。

/* add.h */
int my_add(int a, int b);

/* add.c */
int my_add(int a, int b) {
       return a + b;
}

/* 以下是plugin.so的源代码 */
/* plugin.c */
#include "add.h"

int plugin_main() {
        return my_add(5, 6);
}

在Solaris 10 for x86, Gcc 3.4.6下编译plugin和主程序：
$ gcc -fPIC -shared -o plugin.so plugin.c
$ gcc -o main main.c add.c -ldl

执行main，我们得到了期望的结果：
12
11

将该样例拿到Solaris 10 for sparc平台上编译运行一样没有问题。最后，我把源代码拿到了我的Ubuntu 10.04下，Gcc的版本是4.4.3，编译过程很顺利，但是执行的结果却与预期不符，执行main后得到的结果是：
12
main: symbol lookup error: ./plugin.so: undefined symbol: my_add

居然提示无法找到符号my_add！在Solaris上明明可以正确执行的程序，搬到Linux下却出错。这种问题十分对我的胃口，开始“破案”^_^。

我们先来收集证据，先看看plugin.so的符号表：

$ nm -f sysv plugin.so

Name                  Value   Class        Type         Size     Line  Section
… …
my_add              |        |   U  |            NOTYPE|        |     |*UND*
plugin_main         |0000046c|   T  |              FUNC|0000002c|     |.text

my_add符号的确是Undefined（未定义）的，也就是说在主程序获得my_add符号并准备执行时(注意我们在dlopen的参数中使用了RTLD_LAZY)，加载器需要在此时为my_add这个符号寻找其定义。main这个可执行文件中是定义了这个符号的，我们可以通过nm命令看到这一情况：

$ nm -f sysv main

Name                  Value   Class        Type         Size     Line  Section
… …
main                |080484f4|   T  |              FUNC|000000ee|     |.text
my_add              |080485e4|   T  |              FUNC|0000000e|     |.text

按照我原先的理解，加载器在为my_add符号寻找定义时，是应该可以将main中的my_add定义与之相绑定的，但是事实却是加载器无法找到my_add这个符号的定义，导致执行出错。

你也许会立刻想出一种解决方法，将add.c与plugin.c一起编译：
$ gcc -fPIC -shared -o plugin.so plugin.c
这样编译后的plugin.so中的确有了my_add的定义：

$ nm -f sysv plugin.so
Name                  Value   Class        Type         Size     Line  Section
… …
my_add              |00000498|   T  |              FUNC|0000000e|     |.text
plugin_main         |0000046c|   T  |              FUNC|0000002c|     |.text

main也可以正确执行了。但这显然不是我么想要的结果。作为一个plugin，其编译时很可能无法得到add.c或者add.c对应的静态库，也许只能得到add.h，所以这种方法很局限。另外这个方案也在plugin源码与主程序源码之间无端建立一个耦合，导致后续的一些不方便。

接下来，我使用readelf工具对main的ELF格式做了一次全面检查：
$ readelf -a main

在readelf输出的内容中，我发现了两个“符号表(Symbol table)”：

Symbol table '.dynsym' contains 9 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
   … …
     3: 00000000     0 FUNC    GLOBAL DEFAULT  UND dlclose@GLIBC_2.0 (2)
     4: 00000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.0 (3)
     5: 00000000     0 FUNC    GLOBAL DEFAULT  UND dlsym@GLIBC_2.0 (2)
     6: 00000000     0 FUNC    GLOBAL DEFAULT  UND dlopen@GLIBC_2.1 (4)
     7: 00000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.0 (3)
   … …

Symbol table '.symtab' contains 70 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
   … …
    52: 080485e4    14 FUNC    GLOBAL DEFAULT   14 my_add
    54: 00000000     0 FUNC    GLOBAL DEFAULT  UND dlclose@@GLIBC_2.0
    55: 00000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@@GLIBC_
    58: 00000000     0 FUNC    GLOBAL DEFAULT  UND dlsym@@GLIBC_2.0
    60: 00000000     0 FUNC    GLOBAL DEFAULT  UND dlopen@@GLIBC_2.1
    63: 00000000     0 FUNC    GLOBAL DEFAULT  UND printf@@GLIBC_2.0
    68: 080484f4   238 FUNC    GLOBAL DEFAULT   14 main
   … …

仔细观察一下这两个表，你会发现有些函数是重复的，如dlopen在两个表里面都有，但my_add却只在.symtab中出现。也许问题就在这里。迅速翻阅了一些资料（比如"Linkers and Loaders"），发现这两个符号表的功用确有不同。

.symtab中的符号也称为normal symbol，表中包含了所有ELF文件中涉及的所有符号，用于普通的链接器；.dynsym中的符号则是由未定义的动态链接符号以及该ELF文件本身导出(export)的用于动态链接的符号组成。说到这里，头绪渐渐明晰。在本例中，.symtab这个普通符号表中虽然包含了my_add符号，但是这并不能说明my_add是main导出的用于动态链接的符号(dynamic symbol)，只有my_add出现在.dynsym中时，加载器才能在符号查找时看到my_add，而本例中my_add恰恰没有出现在.dynsym表中。

使用nm -D命令，我们也可以查看.dynsym符号表：
$ nm -D -f sysv main

Symbols from main:

Name                  Value   Class        Type         Size     Line  Section
… …
dlclose             |        |   U  |              FUNC|        |     |*UND*
dlopen              |        |   U  |              FUNC|        |     |*UND*
dlsym               |        |   U  |              FUNC|        |     |*UND*
… …

让我奇怪的是为何在Solaris上main的执行是没有问题的呢，换到Solaris下，我们同样使用nm -D查看上面的main文件：

$ nm -D main
main:

[Index]   Value      Size    Type  Bind  Other Shndx   Name
…
[10]    | 134547364|     305|FUNC |GLOB |0    |10     |main
[19]    | 134547353|      11|FUNC |GLOB |0    |10     |my_add
…

从结果可以看出，Solaris上main文件的.dynsym符号表中是包含了my_add符号的，这也就是main在Solaris上可以正常执行的原因。

难道与Gcc版本有关系？Solaris上的Gcc是3.4.6，而我的Ubuntu上的Gcc是4.4.3。"Binary Hacks"一书中曾提到使用-rdynamic选项可为可执行文件留下可用于动态连接的符号。向gcc传入-rdynamic，则链接器会得到-export-dynamic选项。我在Ubuntu下试一下这个选项：

$ gcc -o main main.c add.c -ldl -rdynamic
$ main
12
11

问题果然解决了。我们再用nm -D查看一下这个新版main文件：
$ nm -D -f sysv main
Symbols from main:

Name                  Value   Class        Type         Size     Line  Section
… …
dlsym               |        |   U  |              FUNC|        |     |*UND*
main                |080486e4|   T  |              FUNC|000000ee|     |.text
my_add              |080487d4|   T  |              FUNC|0000000e|     |.text
…

果然，.dynsym表扩大了好多，my_add也出现在了该表中，这样在main执行时加载器就可以为plugin.so中的my_add符号绑定到其定义了。

我在Solaris下的gcc命令行上也增加-rdynamic选项，但编译后得到的结果却是：
gcc: unrecognized option `-rdynamic'

查看了Gcc官方的Manual后发现，在Gcc 4.1.2版本之前的Manual中都无法找到-rdynamic这一选项，也就是说这个选项是后加入Gcc中的。之前我们看到Solaris上main文件的dynsym表默认就包含了my_add，而4.1.2版本后的Gcc则默认不将自定义的全局函数导出。这是为什么呢？也许是为了提升可执行程序动态链接的性能，这个性能估计与dynsym表的大小不无关系。表越小，需要动态链接的符号越少，符号解析和绑定的速度也就越快；同时由于该表的内容需要在执行时加载到内存，这样表越小，加载的时间以及内存的占用也都很少，所以GCC更改了策略，默认选择不导出自定义的全局符号，并提供-rdynamic让程序员选择是否导出已定义的符号用于动态链接。

近两天一直在考量产品安装包改进的事宜。说实话，我们的安装包做得不够"专业"，不仅没有按照各个平台的标准安装包形式(比如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中的路径在生产环境下无法找到，且生产环境下没有将相关库的路径配置到链接器搜索的路径下，那么安装后的可执行文件执行时就会出错。解决方法有多种，这里就不赘述了。