linux编写程序时，会经常的接触动态库，而在程序运行时可能会遇到类似于:libxxx.so cannot open shared object file no such file or directory的问题，这个代表什么含义，该怎么解决呢？
含义
这个问题代表的含义是，可执行程序在加载libxxx.so库时，找不到该库。至于找不到的情况分为两种:系统里根本不存在libxxx.so库；libxxx.so库在系统中存在，但是ld找不到，即libxxx.so库的位置没有告知ld。
解决办法
对于第一种情况，需要将libxxx.so放到系统ld的搜索路径中；对于第二种情况，通过locate工具定位libxxx.so的位置，然后将其放到ld的搜索路径中。
动态库的搜索路径配置
linux下ld对于动态库的搜索路径的配置方式包括以下几种方式:
- 通过配置gcc编译器的参数-wl,-rpath指定；
- 通过ld_library_path环境变量指定；
- 通过/etc/ld.so.conf指定，切记修改完ld.so.conf之后必须执行/sbin/ldconfig -v同步动态库;
- 默认搜素路径/lib、/usr/lib/指定；
同时，上述几种方式存在一定的搜索顺序，按照搜索的先后依次为:1 > 2 > 3 > 4。对于动态库的搜索路径的配置可以参考21aspnet的这篇博文。
依赖动态库的查看
我们可以通过ldd(x86环境)或者cross_compile-readelf -d(arm环境，cross_compile为具体交叉编译前缀，-d 为读取动态库信息的参数)来分析相应平台下可执行程序所依赖的动态库的情况，我们可以举一例：
test.c：
#include
void test()
{
printf("test()\n");
}
$ $(cc) -fpic -c test.c //生成test.o，-fpic(position-independent code)为了生成位置无关的代码，一般用于动态库编译选项。
$ $(cc) -static -fpic -o libtest.so test.o
extern void test();
main.c:
int main()
{
test();
return 0;
}
$ $(cc) -c main.c
$ $(cc) main.o -o main -l. -ltest
其中，cc代表不同平台的编译器；
通过，修改cc为gcc或者arm-linux-gnueabi-gcc分别生成x86、arm平台下的main可执行程序，下面分别通过ldd和arm-linux-gnueabi-readelf查看main所依赖的动态库:
-
x86:
ldd main linux-vdso.so.1 => (0x00007ffc98f6a000) libtest.so => /home/qihua/develop/linux/static_dynamic_libs/code/libtest.so (0x00007fe850df4000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe850a10000) /lib64/ld-linux-x86-64.so.2 (0x000055950a132000) -
arm:
arm-linux-gnueabi-readelf -d main dynamic section at offset 0xf10 contains 25 entries: 标记 类型 名称/值 0x00000001 (needed) 共享库：[libtest.so] 0x00000001 (needed) 共享库：[libc.so.6] 0x0000000c (init) 0x10430 0x0000000d (fini) 0x10590 0x00000019 (init_array) 0x20f08 0x0000001b (init_arraysz) 4 (bytes) 0x0000001a (fini_array) 0x20f0c 0x0000001c (fini_arraysz) 4 (bytes) 0x00000004 (hash) 0x101ac 0x00000005 (strtab) 0x10300 0x00000006 (symtab) 0x10200 0x0000000a (strsz) 200 (bytes) 0x0000000b (syment) 16 (bytes) 0x00000015 (debug) 0x0 0x00000003 (pltgot) 0x21000 0x00000002 (pltrelsz) 32 (bytes) 0x00000014 (pltrel) rel 0x00000017 (jmprel) 0x10410 0x00000011 (rel) 0x10408 0x00000012 (relsz) 8 (bytes) 0x00000013 (relent) 8 (bytes) 0x6ffffffe (verneed) 0x103e8 0x6fffffff (verneednum) 1 0x6ffffff0 (versym) 0x103c8 0x00000000 (null) 0x0
note
-
如果一个可执行程序(常见于第三方库提供的bin)依赖了某些动态库，但可执行程序的cpu架构与本地的cpu架构不同(例如，可执行程序为32位，但本地系统为64位，本地系统安装的动态库也为64位的)，那么程序运行时，通过会提示:libxxx.so cannot open shared object file no such file or directory。这是，我们通过locate是可以定位到libxxx.so库，并且libxxx.so处于合适的ld搜索路径之下，这是我们通过修改libxxx.so路径是没有用的。解决问题的方式有这么几种:
1）下载与本地系统cpu架构相匹配的程序；
2）在本地系统重新编译该程序；
3）编译、更新与可执行程序cpu架构相匹配的动态库；