linux动态库加载时搜索路径
摘自http://gotowqj.iteye.com/blog/1926613
对动态库的实际应用还不太熟悉的读者可能曾经遇到过类似“error while loading shared libraries”这样的错误,这是典型的因为需要的动态库不在动态链接器ld.so的搜索路径设置当中导致的。
具体说来,动态链接器ld.so按照下面的顺序来搜索需要的动态共享库:
1.ELF可执行文件中动态段中DT_RPATH所指定的路径。这实际上是通过一种不算很常用,却比较实用的方法所设置的:编译目标代码时,可以对gcc加入链接参数“-Wl,-rpath”指定动态库搜索路径;
2.环境变量LD_LIBRARY_PATH指定的动态库搜索路径;
3./etc/ld.so.cache中所缓存的动态库路径(如果支持ld.so.cache的话)。这可以通过修改配置文件/etc/ld.so.conf中指定的动态库搜索路径来改变;
4.默认的动态库搜索路径/lib;
5.默认的动态库搜索路径/usr/lib。
在嵌入式Linux系统的实际应用中,1和2被经常使用,也有一些相对简单的的嵌入式系统会采用4或5的路径来规范动态库。3在嵌入式系统中使用的比较少,因为有很多系统根本就不支持ld.so.cache。
4和5的方式非常简单,只要将所需要的库放到/lib或/usr/lib就可以解决找不到库的问题,不过对于大一些的系统来说,不太方便管理。1和2的方式要稍微复杂一些,下面我们用一个非常简单的例子来说明如何应用。
首先编写一个最简单的动态共享库,源代码pirnt.c如下:
1 #include <stdio.h> 2 3 void print_foo() 4 { 5 printf("fooooooooo\n"); 6 } |
注意将它编译成共享库:
# gcc print.c -shared -o libprint.so # file libprint.so libprint.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped |
调用该共享库main.c代码如下:
1 #include <stdio.h> 2 3 extern void print_foo(); 4 5 int main() 6 { 7 print_foo(); 8 9 return 0; 10 } |
编译之后的运行结果如下:
# gcc main.c -L./ -lprint -o pfoo # ./pfoo ./pfoo: error while loading shared libraries: libprint.so: cannot open shared object file: No such file or directory |
这便是典型的找不到动态库的错误。通常我们可以通过设置环境变量LD_LIBRARY_PATH来指定动态库的搜索路径(即上面的方法2),比如这样就可以正确运行了:
# export LD_LIBRARY_PATH=./ # ./pfoo fooooooooo |
但这种方法有一个明显的缺点:一旦LD_LIBRARY_PATH被设定,则在这个环境变量生效的范围之内,所有其他的ELF可执行程序也会按照这个顺序去搜索动态库,这样势必会造成搜索时的一些浪费。
我们也可以使用另外一种方案来解决这种问题,即利用参数“-Wl,-rpath”在编译时指定运行时的搜索路径(即上面的方法1),如下所示:
# unset LD_LIBRARY_PATH # echo $LD_LIBRARY_PATH # gcc main.c -L./ -lprint -o pfoo_r -Wl,-rpath=./ # ./pfoo ./pfoo: error while loading shared libraries: libprint.so: cannot open shared object file: No such file or directory # ./pfoo_r fooooooooo |
我们首先unset了LD_LIBRARY_PATH,可以看到它已经不再有效了(当然这不是使用参数“-Wl,-rpath”的必要步骤,在这里只是为了说明它已经不再起作用了),而且”pfoo”程序运行时也会发生找不到库的错误,而我们加入编译参数“-Wl,-rpath,./”之后得到的pfoo_r程序则能正常运行。
事实上我们可以通过readelf工具来查看两个文件的差异:
# readelf -d pfoo
Dynamic segment at offset 0x514 contains 21 |
“readelf -d”可以用来查看ELF文件的动态节(Dynamic
Section)。对比pfoo 和pfoo_r的结果我们可以发现,pfoo_r中多出来了RPATH项,指定”Library rpath:
[./]”。通过这种方式,我们可以用非常小的代价(仅增加几乎可以忽略的空间开销),对每个ELF文件都指定最优化的搜索路径,达到提升性能的目的。这是我们比较推荐的一种方法。当然了,具体如果操作依赖于具体的软件系统的情况,简单的系统中直接将所有的库都放到/lib下也未尝不是一种简单易行的优化方案。
最新文章
- angularJS支持的事件
- 在IIS上创建FTP服务
- MVC Router学习
- Saltstack系列4:Saltstack之Grains组件
- Shell编程笔记
- C#获取文件和文件夹大小
- 用户向导页面实现左右滑动的ImageSwitcher
- asp.net 使用HttpModule记录全局错误
- Iterator 的hasNext方法和next方法
- 二维字符数组利用gets输入
- 【转】linux shell 逻辑运算符、逻辑表达式
- ThinkPHP缓存技术(S(),F(),查询缓存,静态缓存)
- A1008. Elevator
- PAT甲级1127. ZigZagging on a Tree
- Mysql与InnoDB优化
- 通过Intel XDK编写跨平台app(一)
- github提交表情包
- windows快捷命令修炼
- Some Principles
- Python Tornado之四(Http层)
热门文章
- 基于 Bootstrap 的扁平化 UI 开发包
- 探索PHP+Nginx(一) 安装Linux操作系统
- ubuntu centos debina
- nsinteger 与 int 区别
- Spring(二)——IoC
- JavaScript 轮播图
- 【Heritrix基础教程之3】Heritrix的基本架构
- weblogic8.1在myeclipse中启动正常,在单独的weblogic中无法正常启动的解决方案.
- c语言的lua库编写
- Zero Downtime Upgrade of Oracle 10g to Oracle 11g Using GoldenGate — 2