项目需要我编写了一个动态库libs2cShareLib.so供同组同事Carson使用，他也也编了一个动态库libnative.so,并在这个库内部使用我提供的接口。
昨天下午CAE的Evan编写的一个动态库libcapi_pcie.so中用到了libnative.so。这样Evan的一个工程下就有了3个动态库libcapi_pcie.so, libnative.so和libs2cShareLib.so,
他的编译命令行是这样的：
"gcc -rdynamic -DKERNEL_64BIT -m64 -DLINUX -Wall -o main main.c -ldl"，
并没有指定链接相关动态库，而是在程序中采用手动方式加载动态库：
“void *CAPI_LIB_handle = dlopen(”./capi_pcie.so“, RTLD_LAZY);
......
dlclose(CAPI_LIB_handle);"
编译完，运行"./main",前面都运行正常，到最后程序退出时出现segment fault。
我们尝试了几种改动都可以避免出现segment fault：
1. 注释掉代码最后”(CAPI_LIB_handle);“;
2.注释掉libnative.so中调用libs2cShareLib.so的部分代码并重新编译libnative.so;
问题貌似已经定位到是libs2cShareLib.so的问题了，但这个库是我写的，经过反复测试的，我把自己的测试程序拿到Evan那里跑也是OK的。难道是动态库中调用动态库会有什么限制？我又写了个自测试程序测试libnative.so。编译参数：
”gcc -o test -lnative -lstdc++ main.cpp“
结果一切正常。
只能查找我测试程序和Evan程序的不同了，不同点有两个：
1.我的测试程序中的调用关系是：test->libnative.so->libs2cShareLib.so,两层动态库调用；而Evan的程序中是main->libcapi_pcie.so->libnative.so->libs2cShareLib.so,三层动态库调用。
2.我的测试程序中我是用链接器链接要用到的动态库；而Evan的程序中是采用手动load的方式。
一个一个来排查，针对第一点，让Evan修改他的程序，直接load libnative.so,结果还是出错，说明不是动态库调用层数的关系了。
针对第二点，修改Evan的编译选项，指定链接要用到的相关动态库，而不是程序中手动load。运行，结果正确！！！
说明不是动态库本身的问题了，难道说多层动态库调用不能手动load？带着这个疑问找老大，老大看了一下Evan代码，指着”void *CAPI_LIB_handle = dlopen(”./capi_pcie.so“, RTLD_LAZY); “这一行，会不会是这个load参数的问题。百度了一下：
果断把RTLD_LAZY改成RTLD_NOW,重新编译运行，正常，也没有segment fault了。
终于找到原因了，RTLD_LAZY在调用dlopen时为了节省时间，并没有解析所用到的未定义符号，而是在用到的时候再来解析；而RTLD_NOW就是解析所有用到的符号，类似于链接器链接指定动态库的效果。
但还是有个问题搞不明白，问什么在libnative.so中注释掉调用libs2cShareLib.so的代码, RTLD_LAZY方式就是可以的呢？
main->libcapi_pcie.so->libnative.so->libs2cShareLib.so 程序结束出现segment fault错误；
main->libcapi_pcie.so->libnative.so 程序结束，正常退出。
希望有大神帮忙解惑，小弟感激不尽！