Linux 下有动态库和静态库,动态库以.so为扩展名,静态库以.a为扩展名。二者都使用广泛。本文主要讲动态库方面知识。
链接了冗余的库会怎样?
基本上每一个linux 程序都至少会有一个动态库,查看某个程序使用了那些动态库,使用ldd命令查看
这么多so,是的。使用ldd显示的so,并不是所有so都是需要使用的,下面举个例子:
main.cpp
使用缺省参数编译结果
如果我链接一些so,但是程序并不用到这些so,又是什么情况呢?下面我加入链接压缩库,数学库,线程库
看看,虽然没有用到,但是一样有链接进来,那看看程序启动时候有没有去加载它们呢?
看,有加载!!!
所以必定会影响进程启动速度,所以我们最后不要把无用的so编译进来,这里会有什么影响呢?
大家知不知道linux从程序(program或对象)变成进程(process或进程),要经过哪些步骤呢,这里如果详细的说,估计要另开一篇文章。简单的说分三步:
1、fork进程,在内核创建进程相关内核项,加载进程可执行文件;
2、查找依赖的so,一一加载映射虚拟地址
3、初始化程序变量。
可以看到,第二步中dll依赖越多,进程启动越慢,并且发布程序的时候,这些链接但没有使用的so,同样要一起跟着发布,否则进程启动时候,会失败,找不到对应的so。所以我们不能像上面那样,把一些毫无意义的so链接进来,浪费资源。但是开发人员写makefile 一般有没有那么细心,图省事方便,那么有什么好的办法呢。继续看下去,下面会给你解决方法。
先使用 ldd -u demo 查看不需要链接的so,看下面,一面了然,无用的so全部暴露出来了吧
使用-Wl,--as-needed 编译选项
呵呵,办法很简单省事吧,本文主要讲so依赖的一些问题,下面将介绍so的路径方面一些不为人知的小秘密。
库路径不为人知的小秘密
我们知道Linux链接so有两种途径:显示和隐式。所谓显示就是程序主动调用dlopen打开相关so;这里需要补充的是,如果使用显示链接,上篇文章讨论的那些问题都不存在。首先,dlopen的so使用ldd是查看不到的。其次,使用dlopen打开的so并不是在进程启动时候加载映射的,而是当进程运行到调用dlopen代码地方才加载该so,也就是说,如果每个进程显示链接a.so;但是如果发布该程序时候忘记附带发布该a.so,程序仍然能够正常启动,甚至如果运行逻辑没有触发运行到调用dlopen函数代码地方。该程序还能正常运行,即使没有a.so.
既然显示加载这么多优点,那么为什么实际生产中很少码农使用它呢,主要原因还是起使用不是很方便,需要开发人员多写不少代码。所以不被大多数码农使用,还有一个重要原因应该是能提前发现错误,在部署的时候就能发现缺少哪些so,而不是等到实际上限运行的时候才发现缺东少西。
下面举个工作中最常碰到的问题,来引申出本篇内容吧。
写一个最简单的so,tmp.cpp
编译=>链接=》运行,下面指令中的main.cpp请参见前文。
[stevenrao]$ g++ -fPIC -c tmp.cpp
[stevenrao]$ g++ -shared -o libtmp.so tmp.o
[stevenrao]$ mv libtmp.so /tmp/
[stevenrao]$ g++ -o demo -L/tmp -ltmp main.cpp
[stevenrao]$ ./demo
./demo: error while loading shared libraries: libtmp.so: cannot open shared object file: No such file or directory
[stevenrao]$ ldd demo
linux-vdso.so.1 => (0x00007fff7fdc1000)
libtmp.so => not found
这个错误是最常见的错误了。运行程序的时候找不到依赖的so。一般人使用方法是修改LD_LIBRARY_PATH这个环境变量
export LD_LIBRARY_PATH=/tmp
[stevenrao]$ ./demo
test
这样就OK了,不过这样export只对当前shell有效,当另开一个shell时候,又要重新设置。可以把export LD_LIBRARY_PATH=/tmp语句写到~/.bashrc中,这样就对当前用户有效了,写到/etc/bashrc中就对所有用户有效了。
前面链接时候使用-L/tmp/ -ltmp是一种设置相对路径方法,还有一种绝对路径链接方法。
[stevenrao]$g++ -o demo/tmp/libtmp.so main.cpp
[stevenrao]$./demo
test
[stevenrao]$ldd demo
linux-vdso.so.1 =>(0x00007fff083ff000)
/tmp/libtmp.so (0x00007f53ed30f000)
绝对路径虽然申请设置环境变量步骤,但是缺陷也是致命的,这个so必须放在绝对路径下,不能放到其他地方,这样给部署带来很大麻烦。所以应该禁止使用绝对路径链接so。
搜索路径分两种,一种是链接时候的搜索路径,一种是运行时期的搜索路径。像前面提到的-L/tmp/是属于链接时期的搜索路径,即给ld程序提供的编译链接时候寻找动态库路径;而LD_LIBRARY_PATH则既属于链接期搜索路径,又属于运行时期的搜索路径。
这里需要介绍链-rpath链接选项,它是指定运行时候都使用的搜索路径。聪明的同学马上就想到,运行时搜索路径,那它记录在哪儿呢。也像LD_LIBRARY_PATH那样,每部署一台机器就需要配一下吗。呵呵,不需要..,因为它已经被硬编码到可执行文件内部了。看看下面演示
1. [stevenrao] $ g++ -o demo -L /tmp/ -ltmp main.cpp
2. [stevenrao] $ ./demo
3. ./demo: error while loading shared libraries: libtmp.so: cannot open shared object file: No such file or directory
4. [stevenrao] $ g++ -o demo -Wl,-rpath /tmp/ -L/tmp/ -ltmp main.cpp
5. [stevenrao] $ ./demo
6. test
7. [stevenrao] $ readelf -d demo
8.
9. Dynamic section at offset 0xc58 contains 26 entries:
10. Tag Type Name/Value
11. 0x0000000000000001 (NEEDED) Shared library: [libtmp.so]
12. 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
13. 0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
14. 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
15. 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
16. 0x000000000000000f (RPATH) Library rpath: [/tmp/]
17. 0x000000000000001d (RUNPATH) Library runpath: [/tmp/]
看是吧,编译到elf文件内部了,路径和程序深深的耦合到一起。
-
Linux
+关注
关注
87文章
11285浏览量
209266 -
程序
+关注
关注
117文章
3782浏览量
80990 -
静态库
+关注
关注
0文章
21浏览量
7426 -
动态库
+关注
关注
0文章
17浏览量
6222
原文标题:Linux下so动态库一些不为人知的秘密
文章出处:【微信号:LinuxDev,微信公众号:Linux阅码场】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论