今年是我’有史以来’回家最晚的一年，直到阴历二十九才坐上回家的列车。今年在回家之前我还有一个特殊的’活儿’要完成，那就是给自己尚未入住的新房子贴上传统的对联和福字儿。

以前在家贴对联和福字都是父母的活儿，从小到大自己在家里都是啥活儿也不做的，都是被父母惯的^_^。这回轮到自己贴对联福字了，我还觉得有些新奇，早早的就在超市里买了漂亮的对联和福字，还特地上网查了查对联和福字该如何贴。

对联的贴法我是有耳闻的，正确的对联贴法应该是：当人面向对联时，上联在右侧，下联在左侧。对联要注意声律相对，判断上下联是按照最后一个字的平仄声来区分的，上联是仄声，下联为平声，这样贴的目的主要是为了音韵和谐，悦耳动听。但是看起来还是有些复杂。很多人还是不能识别出上下联。这里有一个技巧：现在每家每户的对联基本都没有自己去写的了，都是从市场上买回来的，买回来的对联上除了文字，往往还会有一些图案，比如鱼、胖娃娃等。而这些图案都是’对称的’，只要按照图案的’对称’去贴，基本都是没有问题的。

还有一些对联是没有图案的，人们也不习惯从右往左贴对联，那我们就从相反的角度来’改革’一下上面的对联贴法，不分什么上下联，只分左右联。改后的贴法：当人面向对门时，左边贴的对联最后一个字是平声，也就是一、二声；右边贴的对联最后一个字是仄声，也就是三、四声。这样就好记多了。

福字的贴法无疑只有两种：正着贴和倒着贴。到底该如何贴？的确让我很挠头。为了求甚解，我还是查查民俗专家是如何说的。按照民俗专家的说法：福字倒着贴是民间普通百姓的’口彩’，并被以讹传讹了。有专家考察过许多地方，不论是民宅小院，还是大宅门，或是晋商、徽商的豪宅，或是达官府第，所有镶在墙上的木雕、砖雕、石雕的’福’字都是正的。关于’福’字倒着贴的源头有诸多说法，但相同点都是’福’倒贴是不吉利的事情。

这回我可知道了：’福’字一定要正着贴。有些事情多刨根问底的去了解一下，即增长了见识，又避免了为’以讹传讹’助势，对的就是对的，错的就是错的。

清晨，部门新来的一位小兄弟打来求助电话，说是系统启动的时候出现类似："ld.so.1: testmain: 致命的: 重定位错误: 文件./libtestshared.so: 符号static_add: 参照的符号没有找到"的错误。这个系统是05年开发的一个复用度很高的自研产品，后续项目只需在其基础上做少量二次开发工作即可满足新功能的要求。为了做到一定的通用性，我们使用了类似插件的框架，这样系统在启动的时候会根据配置加载一些'共享库'(.so文件)，而这个小同事反映的问题就出在这。

上面仅仅是一个引子，在写下本篇文章之前，这个问题已经被解决，我的那个小同事在连续奋战14个小时(从昨晚21:00到今天上午11:00)后，终于也可以安心踏上返回四川老家的火车了。事后，我深入的想了一下这个问题，觉得有必要说一下。

这里用一个简单的例子来重现一下这个问题吧。我们先来准备一个静态链接库(.a)和一个动态共享库(.so)，都比较简单，能反映出问题就行。

[静态库]
//teststatic.h
int static_add(int a, int b);

//teststatic.c
#include "teststatic.h"
int static_add(int a, int b) {
        return a+b;
}

编译静态库：
gcc -c teststatic.c
ar crv libteststatic.a teststatic.o

[动态共享库]
//testshared.h
int dynamic_add(int a, int b);

//testshared.c
#include "testshared.h"
#include "teststatic.h"
int dynamic_add(int a, int b) {
        return static_add(a, b);
}

编译共享库：
gcc testshared.c -fPIC -shared -o libtestshared.so

然后，我们再写一个测试桩程序，其主要功能就是：通过dlopen和dlsym在运行时动态加载libtestshared.so，然后得到符号dynamic_add的地址，完成计算功能。
#include
#include

typedef int (*PTR)(int, int);

int main() {
        void    *handle = NULL;
        char    *errinfo = NULL;
        PTR     ptr;
        int     rv;

        handle = dlopen("./libtestshared.so", RTLD_LAZY);
        if (handle == NULL) {
                errinfo = dlerror();
                printf("dlopen失败: %s\n", errinfo);
                return;
        }

        ptr = (PTR)dlsym(handle, "dynamic_add");
        if (ptr == NULL) {
                errinfo = dlerror();
                printf("dlsym失败: %s\n", errinfo);
                return;
        }

        rv = ptr(1,2);
        printf("rv = %d\n", rv);
}
编译：gcc -o testmain testmain.c -ldl -L./ -lteststatic
运行结果：ld.so.1: testmain: 致命的: 重定位错误: 文件./libtestshared.so: 符号static_add: 参照的符号没有找到，被杀掉。

通过运行结果分析：程序在启动时，链接程序并没有找到符号:static_add，无从知道其指令代码，所以报错。这个例子反映的就是我那个小同事犯的'错误'– 程序在加载阶段链接器无法resolve共享库里调用的其他函数符号。那为什么找不到呢？我们还需简单回顾一下程序启动阶段的一些事情。

程序启动后，由加载器(即常说的loader)将之加载到内存中，过程很复杂和繁琐，我们就说程序中的符号是如何resolved的(我是从John R.Levine的"Linkers & Loaders"一书中学到的一些皮毛)。加载阶段，加载器(很多工作由链接器完成)先进行自身的初始化，之后它会根据程序文件的头(Headers)中的信息，查找程序所需要的共享库(静态库是在编译期间就已经链接到程序本身中了)的名字，对于每一个共享库的名字，它都会在搜索路径下搜索该共享库是否存在，如果存在，则处理该共享库文件，处理包括：分配text和data段空间并进行映射，其符号表将被merge到主符号表里；如果该共享库文件依然有依赖的其他共享库，且该依赖的共享库在之前并未被load，则将该依赖的共享库加入到待加载的库列表中。

有人要说，上面的testmain程序与这个加载过程不同啊，testmain是用dlopen和dlsym在运行时而不是加载时加载.so的，其实按照John R.Levine的说法: "The two routines dlopen & dlsym are actually simple wrappers that call back into the dynamic linker"，也就是说：使用dlopen和dlsym的组合时，完成的事情和加载阶段链接器完成的事情是一样的。

那我们来看，testmain编译的时候是不依赖任何显式(C运行时和unix系统库等隐式的除外)的共享库的，那么在加载libtestshare.so时，遇到static_add这个符号时，就不知所措了。这里又有人要问了：编译testmain的时候不是链接了libteststatic.a这个库了吗，这个库里不是有static_add的符号吗？你可以nm testmain > dump.log看一下，看看dump.log中是否有static_add这个符号。其实细想一下也会知道：testmain.c中根本没有使用static_add，编译器当然不会无端将static_add的放入testmain的可执行文件中了，否则在unix系统下的每个用户级程序的'体格'都会极其庞大。

上面说过，因为testmain.c中没有使用static_add，所以不能动态加载so时，不能resolve这个符号，如果testmain.c中使用了static_add，那么程序就没有问题了吧？没错！看下面：
#include "teststatic.h"
… …
int main() {
        void    *handle = NULL;
        char    *errinfo = NULL;
        PTR     ptr;
        int     rv;
    
    rv = static_add(5, 6);
    printf("rv = %d\n", rv);

        … …

        rv = ptr(1,2);
        printf("rv = %d\n", rv);
}
这样一来，static_add就会体现在testmain的符号表里，作为testmain的一部分了。当运行时加载.so后，遇到static_add这个符号时，链接器就有据可依了。

又会有人问：我们不能要求所有.so中出现的符号在主程序中都要有吧？对，这样要求显然是无理的，那么如何是好呢？我们只能在编译.so时将这些符号静态链入.so，比如：gcc testshared.c -fPIC -shared -o libtestshared.so -L./ -lteststatic

我们可以通过nm命令看到链入静态库前后的不同：

未链入静态库时nm *.so，符号static_add处于UNDEF状态
[67]    |         0|       0|NOTY |GLOB |0    |UNDEF  |static_add
链入静态库后，nm *.so的结果：
[68]    |      1412|      36|FUNC |GLOB |0    |10     |static_add
static_add的代码被copy一份放到了.so中。

这里关于dlopen函数的第二个参数mode再多写两句。上面的例子中，我们传入的参数是RTLD_LAZY，什么意思呢？RTLD_LAZY是说：.so中的符号只有在其第一次使用的时候，才会由链接器计算出其实际地址，否则在.so加载时是不计算其实际地址的。原因也很简单：一个.so文件中可能有成百上千的符号，我们的程序也许只用到其中的一两个，如果加载时所有符号都要将其实际地址映射好，显然会降低运行时动态加载的性能。还是以testmain.c为例，如果代码中去掉对ptr(1,2)的调用，那么执行testmain是不会出错的。

dlopen中还提供了些许选项，比如：RTLD_NOW，从字面含义也可以猜测出来，其含义与RTLD_LAZY正相反，即.so加载时，其内部所有符号都要计算出实际地址。还以testmain.c为例：
handle = dlopen("./libtestshared.so", RTLD_NOW);
这时即使去掉对ptr(1,2)的调用，执行时会提示：dlopen失败: ld.so.1: testmain: 致命的: 重定位错误: 文件./libtestshared.so: 符号static_add: 参照的符号没有找到。

看来，共享库中的符号链接没有想象中的那么容易，使用的时候要'小心'。也许正是这些需要你投入和认真思考的问题才让使用C语言进行底层或系统开发更具魅力。