dlopen加载一个动态库=>file not found的错的查错过程

转载于：http://hi.baidu.com/li_dayao/blog/item/ad6cddcb9d25641bbf09e66b.html　

　在arm-linux环境下运行可执行程序mocp，在加载动态库libdecoder.so时，却总是报错：File not found。在代码中添加很多printf，找到是在dlopen时报错。最初以为，是函数dlopen找不到lib_decoder.so文件。那么就认为有以下几种可能：

１，动态库给的搜索路径不对；

２，编译生成动态库的编译工具和程序的运行环境不同；

３，交叉编译环境不能识别dlopen（当然这个可能性是瞎猜的）。

　　于是写了个测试程序并交叉编译，自己创建一个动态库libabc.so，并用dlopen加载它。

１，更改动态库的存放路径，结果是在任何路径下都可以找到；

２，用这个正确的测试程序加载libdecoder.so，结果是不管什么路径，就是找不到；

３，在mocp运行时加载libabd.so，能找到；

结论：只要给了dlopen函数一个路径，它就能到这个路径下去寻找指定的库；都是用arm-linux-uclibc-编译的，编译环境相同。那么就是libdecoder.so这个库本身的问题。

　　于是将命令从Makefile中抽出来，在shell中单独运行命令生成这个库，结果还是找不到。然后把命令简化，去掉各种选项，比如链接选项，仅仅用

arm-linux-uclibc-gcc -fpic -shared snow.c rain.c -o libdecoder.so

生成库后，测试发现能找到了。添加一个链接选项-ldl，又找不到了。

　　这才想到，libdecoder.so还要加载一个动态库libdl.so，file not found是不是指的是这个库找不到啊？查找运行环境下的/lib发现，果然没有libdl.so文件。把这个库拷进来，mocp在dlopen的时候就通过了。Done！

　　其实，如果我在运行程序之前就检查好这个程序究竟需要那些动态库，也就不至于花了这么大力气查找这个问题。

　　用objdump命令()就可以查看目标文件包含的信息，其中就有程序需要链接的动态库。

ldd    *.so

readelf    -d    *.so

nm *.so | grep NEEDED

objdump -x libxxxxx.so | grep NEEDED