清晨，部门新来的一位小兄弟打来求助电话，说是系统启动的时候出现类似："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语言进行底层或系统开发更具魅力。

几十年不遇的暴雪冻雨席卷了南方十几个省份，现在你打开电视机、收音机、翻开报纸、浏览互联网，可能看到的最多的就是关于南方灾情的报道。罪也受了、钱也损失了、人也死了，在灾难面前，我们普通人显得那么弱小和无力。我们能做什么呢？自救。

今天听说美国若干个州也受灾了，气象专家说：中国和美国受灾都是'拉尼娜'现象引起的全球大气环流异常导致的。至于产生'拉尼娜'的原因，我猜多半是人类'自食恶果'。老天在惩罚人类的时候，并不急于一次性摧毁，而是慢慢的'折磨'，真是'残忍'啊^_^。

人类社会在天灾面前的脆弱在这次雪灾面前体现的淋漓尽致，没有煤了，没有电了，人们仿佛又回到了"原始社会"，但是与原始社会的人不同的是：我们身处钢筋水泥的世界，没有食物，没有河流，如何生存？

也许上述的描写有些夸张，的确在党中央和政府的努力下，每个人都不会受冻受饿。但是我想的更加长远，按照目前的情况，我觉得天灾只会'愈演愈烈'，而且频度加剧，也许某一天其剧烈程度可能让政府都无法自保的情况了，比如美国大片"后天"中的情形，那时候我们不能等、靠、要了，我们需要自救！

自救不是说当灾难发生了再行动，那时候自救的成功率显然就会很低了，自救是需要计划和准备的。假设现在发生天灾，停电停水，没有人来救援，考量一下你能坚持几天，或者说你利用你周围的资源可以支撑几天呢？

以前看过新闻，说美国或者日本某些人花巨资打造地下避难所，据说避难所可以抵御核武器攻击，并且储存了大量的食物和淡水。当时很是不解，在这么和平幸福的时代，我们为什么要这么做呢？随着近两年灾害次数的增加，特别是在自己也亲身体验了一回'雪灾'后，我也觉得应该做一些'灾害预防'工作了。

对于普通老百姓，我们没有能力建立避难所，那我们能做些什么预防工作呢？- 底线原则：储存能维持基本生命活动的资源。早上醒来后，躺在床上我就在想这个问题，哪些属于能让人维持活着的资源呢？

1、水
没有什么，也不能没有水啊。不吃东西可以坚持7天甚至1个月也可以，但是没有水，两三天就完蛋了。储存一箱纯净水我想是个底线吧。

2、粮食
粮食有多种：
主食你可以储存大米白面，这些食物需要简单烹制；
感觉存储一些罐头是很必要的。至于存储多少，根据个人食量而定；
另外中国人独创的腊肉可以保存多年不腐，可以多存些，毕竟肉类所释放的能量还是蛮大的。

3、光源
多准备蜡烛，有条件可以弄一盏煤油灯。毕竟人在光明中，是会产生力量和希望的。

4、火种
手里起码要有一个质量好的打火机(实在没有，多准备几盒火柴)，否则即使有食物也无法食用、有蜡烛也无法使用。

5、药品
灾难面前不可避免会有伤员，即使不是自己，药品也可以用来救助别人的。阿莫西林、芬必得、创可贴、速效救心丸、药用纱布、绷带、胶布等所有你能想到的特效药都存储点吧。

6、工具
结实且足够长的绳子、结实且够大的背包和一把万能瑞士军刀等，如果你的家里还没有这些，那有机会就买吧，会有用的。

7、钱
这里指的是现金，而不是银行卡或存折中那虚无缥缈的数字(灾难时，试想哪个银行不是门前爆满，能取出钱那是幸运)，在灾难面前，钱是最不堪一击的。但是往往在灾难初期，手上足够的现金还是可以帮上忙的。比如上述1-6的资源储存不够，那你完全可以抓紧时间用现金购买。所以平时手里还是放上万把千的，关键时候也许真管用啊。

8、其他…

以上是躺在床上和坐在班车到公司路上的胡思乱想，如果你觉得有道理，可以参考。