linux下so动态库一些不为人知的秘密

linux 下有动态库和静态库，动态库以.so为扩展名，静态库以.a为扩展名。二者都使用广泛。本文主要讲动态库方面知识。

   基本上每一个linux 程序都至少会有一个动态库，查看某个程序使用了那些动态库，使用ldd命令查看

  1. # ldd /bin/ls
  2. linux-vdso.so.1 => (0x00007fff597ff000)
  3. libselinux.so.1 => /lib64/libselinux.so.1 (0x00000036c2e00000)
  4. librt.so.1 => /lib64/librt.so.1 (0x00000036c2200000)
  5. libcap.so.2 => /lib64/libcap.so.2 (0x00000036c4a00000)
  6. libacl.so.1 => /lib64/libacl.so.1 (0x00000036d0600000)
  7. libc.so.6 => /lib64/libc.so.6 (0x00000036c1200000)
  8. libdl.so.2 => /lib64/libdl.so.2 (0x00000036c1600000)
  9. /lib64/ld-linux-x86-64.so.2 (0x00000036c0e00000)
  10. libpthread.so.0 => /lib64/libpthread.so.0 (0x00000036c1a00000)
  11. libattr.so.1 => /lib64/libattr.so.1 (0x00000036cf600000)

   这么多so，是的。使用ldd显示的so，并不是所有so都是需要使用的，下面举个例子

main.cpp

#include <stdio.h>
#include <iostream>
#include <string>

using namespace std;

int main ()
{
   cout << "test" << endl;
   return 0;
}

   使用缺省参数编译结果

  1. # g++ -o demo main.cpp
  2. # ldd demo
  3.     linux-vdso.so.1 => (0x00007fffcd1ff000)
  4.         libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f4d02f69000)
  5.         libm.so.6 => /lib64/libm.so.6 (0x00000036c1e00000)
  6.         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000036c7e00000)
  7.         libc.so.6 => /lib64/libc.so.6 (0x00000036c1200000)
  8. /lib64/ld-linux-x86-64.so.2 (0x00000036c0e00000)

   如果我链接一些so，但是程序并不用到这些so，又是什么情况呢，下面我加入链接压缩库，数学库，线程库

  1. # g++ -o demo -lz -lm -lrt main.cpp
  2. # ldd demo
  3.         linux-vdso.so.1 => (0x00007fff0f7fc000)
  4. libz.so.1 => /lib64/libz.so.1 (0x00000036c2600000)
  5. librt.so.1 => /lib64/librt.so.1 (0x00000036c2200000)
  6.         libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007ff6ab70d000)
  7. libm.so.6 => /lib64/libm.so.6 (0x00000036c1e00000)
  8.         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000036c7e00000)
  9.         libc.so.6 => /lib64/libc.so.6 (0x00000036c1200000)
  10.         libpthread.so.0 => /lib64/libpthread.so.0 (0x00000036c1a00000)
  11. /lib64/ld-linux-x86-64.so.2 (0x00000036c0e00000)

  看看，虽然没有用到，但是一样有链接进来，那看看程序启动时候有没有去加载它们呢

  1. # strace ./demo
  2.     execve("./demo", ["./demo"], [/* 30 vars */]) = 0
  3. ... = 0
  4. open("/lib64/libz.so.1", O_RDONLY) = 3
  5. ...
  6. close(3) = 0
  7. open("/lib64/librt.so.1", O_RDONLY) = 3
  8. ...
  9. close(3) = 0
  10. open("/usr/lib64/libstdc++.so.6", O_RDONLY) = 3
  11. ...
  12. close(3) = 0
  13. open("/lib64/libm.so.6", O_RDONLY) = 3
  14. ...
  15. close(3) = 0
  16. open("/lib64/libgcc_s.so.1", O_RDONLY) = 3
  17. ...
  18. close(3) = 0
  19. open("/lib64/libc.so.6", O_RDONLY) = 3
  20. ...
  21. close(3) = 0
  22. open("/lib64/libpthread.so.0", O_RDONLY) = 3
  23. ...
  24. close(3) = 0
  25. ...

  看，有加载，所以必定会影响进程启动速度，所以我们最后不要把无用的so编译进来，这里会有什么影响呢？

   大家知不知道linux从程序（program或对象）变成进程（process或进程），要经过哪些步骤呢，这里如果详细的说，估计要另开一篇文章。简单的说分三步：

    1、fork进程，在内核创建进程相关内核项，加载进程可执行文件；

    2、查找依赖的so，一一加载映射虚拟地址

    3、初始化程序变量。

  可以看到，第二步中dll依赖越多，进程启动越慢，并且发布程序的时候，这些链接但没有使用的so，同样要一起跟着发布，否则进程启动时候，会失败，找不到对应的so。所以我们不能像上面那样，把一些毫无意义的so链接进来，浪费资源。但是开发人员写makefile 一般有没有那么细心，图省事方便，那么有什么好的办法呢。继续看下去，下面会给你解决方法。

  先使用 ldd -u demo 查看不需要链接的so，看下面，一面了然，无用的so全部暴露出来了吧

  1. # ldd -u demo
  2. Unused direct dependencies:
  3. /lib64/libz.so.1
  4. /lib64/librt.so.1
  5. /lib64/libm.so.6
  6. /lib64/libgcc_s.so.1

  使用 -Wl,--as-needed 编译选项

  1. # g++ -Wl,--as-needed -o demo -lz -lm -lrt main.cpp
  2. # ldd demo
  3.         linux-vdso.so.1 => (0x00007fffebfff000)
  4.         libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007ff665c05000)
  5.         libc.so.6 => /lib64/libc.so.6 (0x00000036c1200000)
  6.         libm.so.6 => /lib64/libm.so.6 (0x00000036c1e00000)
  7. /lib64/ld-linux-x86-64.so.2 (0x00000036c0e00000)
  8.         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000036c7e00000)
  9. # ldd -u demo
  10. Unused direct dependencies:

  呵呵，办法很简单省事吧，本文主要讲so依赖的一些问题，下一篇将介绍so的路径方面一些不为人知的小秘密

我们知道linux链接so 有两种途径：显示和隐式。所谓显示就是程序主动调用dlopen打开相关so;这里需要补充的是，如果使用显示链接，上篇文章讨论的那些问题都不存在。首先,dlopen的so使用ldd是查看不到的。其次，使用dlopen打开的so并不是在进程启动时候加载映射的，而是当进程运行到调用dlopen代码地方才加载该so，也就是说，如果每个进程显示链接a.so;但是如果发布该程序时候忘记附带发布该a.so,程序仍然能够正常启动，甚至如果运行逻辑没有触发运行到调用dlopen函数代码地方。该程序还能正常运行，即使没有a.so.

既然显示加载这么多优点，那么为什么实际生产中很少码农使用它呢, 主要原因还是起使用不是很方便，需要开发人员多写不少代码。所以不被大多数码农使用，还有一个重要原因应该是能提前发现错误，在部署的时候就能发现缺少哪些so，而不是等到实际上限运行的时候才发现缺东少西。

下面举个工作中最常碰到的问题，来引申出本篇内容吧。

写一个最简单的so， tmp.cpp

int test()
{
     return 20;
}

  编译=>链接=》运行, 下面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那样，每部署一台机器就需要配一下吗。呵呵，不需要..,因为它已经被硬编码到可执行文件内部了。看看下面演示

[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] $ g++ -o demo -Wl,-rpath /tmp/ -L/tmp/ -ltmp main.cpp

[stevenrao] $ ./demo

test

[stevenrao] $ readelf -d demo

Dynamic section at offset 0xc58 contains 26 entries:

  Tag        Type                         Name/Value

0x0000000000000001 (NEEDED)             Shared library: [libtmp.so]

0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]

0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]

0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]

0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

0x000000000000000f (RPATH)              Library rpath: [/tmp/]

0x000000000000001d (RUNPATH)            Library runpath: [/tmp/]

   看看是吧，编译到elf文件内部了，路径和程序深深的耦合到一起

   还有一个类似于-path，叫LD_RUN_PATH环境变量, 它也是把路径编译进可执行文件内，不同的是它只设置RPATH。

[stevenrao] $ g++ -o demo -L /tmp/  -ltmp main.cpp

[stevenrao] $ readelf -d demo

Dynamic section at offset 0xb98 contains 25 entries:

  Tag        Type                         Name/Value

0x0000000000000001 (NEEDED)             Shared library: [libtmp.so]

....

0x000000000000000f (RPATH)              Library rpath: [/tmp/]

  另外还可以通过配置/etc/ld.so.conf，在其中加入一行

  /tmp/

  这个配置项也是只对运行期有效，并且是全局用户都生效，需要root权限修改，修改完后需要使用命令ldconfig 将 /etc/ld.so.conf 加载到ld.so.cache中，避免重启系统就可以立即生效。

  除了前面介绍的那些搜索路径外，还有缺省搜索路径/usr/lib/ /lib/ 目录，可以通过-z nodefaultlib编译选项禁止搜索缺省路径。

  [stevenrao] $ g++ -o demo -z nodefaultlib  -L/tmp -ltmp main.cpp

  [stevenrao] $  ./demo

   ./demo: error while loading shared libraries: libstdc++.so.6: cannot open shared object file

  这么多搜索路径，他们有个先后顺序如下

  1、RUMPATH 优先级最高

  2、RPATH   其次

  3、LD_LIBRARY_PATH

  4、/etc/ld.so.cache

  5、/usr/lib/ /lib/

  查看一个程序搜索其各个动态库另一个简单的办法是使用 LD_DEBUG这个环境变量；

  [stevenrao] $ export LD_DEBUG=libs

  [stevenrao] $ ./demo

注：本文转载自http://blog.csdn.net/suwei19870312/article/details/20045281

时间： 2024-10-18 22:28:52

linux下so动态库一些不为人知的秘密的相关文章

linux下so动态库一些不为人知的秘密(转)

linux 下有动态库和静态库,动态库以.so为扩展名,静态库以.a为扩展名.二者都使用广泛.本文主要讲动态库方面知识.基本上每一个linux 程序都至少会有一个动态库,查看某个程序使用了那些动态库,使用ldd命令查看 # ldd /bin/ls 使用 ldd -u /bin/ls 查看不需要链接的so 大家知不知道linux从程序(program或对象)变成进程(process或进程),要经过哪些步骤呢,这里如果详细的说,估计要另开一篇文章.简单的说分三步:    1.fork进程,在内核创建

Linux下的动态库与静态库

2019-09-25 关键字:生成库.静态库引用.动态库引用 在 C 开发中,“库”是一个经常听到的名词. 所谓的库其实就是一个二进制文件.这个二进制文件的内容是可被其它C程序调用执行的函数.换句话说,库就是一组C代码的打包形式而已,打包是指将源代码以库的形式编译而生成的文件. 不过即使它只是源代码的打包,它也仍然是有系统专有性的,即不同系统下编译出来的库并不能互相兼容使用. C库可分为动态库与静态库两种.引用了外部库的应用程序在编译时会在”链接期“处理库与程序源码之间的关系. 1.静态库 静态

linux 下的动态库制作 以及在python 中如何调用 c 函数库

动态库: 动态库又称动态链接库英文为DLL,是Dynamic Link Library 的缩写形式,DLL是一个包含可由多个程序同时使用的代码和数据的库,DLL不是可执行文件.动态链接提供了一种方法,使进程可以调用不属于其可执行代码的函数.函数的可执行代码位于一个 DLL 中,该 DLL 包含一个或多个已被编译.链接并与使用它们的进程分开存储的函数.DLL 还有助于共享数据和资源.多个应用程序可同时访问内存中单个DLL 副本的内容.DLL 是一个包含可由多个程序同时使用的代码和数据的库.Wind

在Linux下编译生成动态库*.so后发现用dlopen打开时出错解决办法

在Linux下有时候编译的源文件可能有语法错误,但是很多时候还是能生成动态库,这个时候,用dlopen打开时就没有办法返回句柄,导致能生成动态库,却无法打开,这个时候最好的办法是不用dlopen动态调用的方法,而是使用静态调用的方法. 1.在测试文件中加上静态调用需要的头文件,同时将此头文件放在与测试文件同一个目录下,以便测试文件能够找到该头文件 2.将生成的库定位输出到/usr/lib(如果是64位系统,则是在/usr/lib64)文件夹中 3.编译时参考我的代码, gcc main.c -L

linux下的动态库

也就是windows下的.dll 1.命名 2.制作 (1)生成与位置无关的.o文件 gcc -fPIC -c *.c -I ../include (2)将.o打包成动态库(或者叫共享库) gcc -shared -o libmytest.so *.o -I ../include 3.发布和使用 (1)gcc main.c lib/libmytest.so -o app -I include (2)gcc main.c -L ./lib -l mytest -o app 4.如何解决动态库无法加

用Vs2013+VELT进行Linux开发：动态库

快乐虾 http://blog.csdn.net/lights_joy/ 欢迎转载,但请保留作者信息 本文适用于vs2013 + Visual EmbedLinux Tools 0.1.1 1.1    什么是VELT VELT的全称是Visual EmbedLinuxTools,它是一个与visual gdb类似的visual studio插件,用以辅助完成Linux开发.利用这个插件,将可以在visual studio的IDE中进行Linux应用程序的开发(包括编译和调试),也可以进行ubo

用VS2013+VELT-0.1.3进行Linux开发：动态库

快乐虾 http://blog.csdn.net/lights_joy/(QQ群:Visual EmbedLinux Tools 375515651) 欢迎转载,但请保留作者信息 本文仅适用于vs2013 + velt-0.1.3 1.1    什么是VELT VELT的全称是Visual EmbedLinuxTools,它是一个与visual gdb类似的visual studio插件,用以辅助完成Linux开发.利用这个插件,将可以在visual studio的IDE中进行Linux应用程序

linux下的静态库创建与查看，及如何查看某个可执行依赖于哪些动态库

linux下的静态库创建与查看,及如何查看某个可执行依赖于哪些动态库 创建静态库:ar -rcs test.a *.o查看静态库:ar -tv test.a解压静态库:ar -x test.a 查看程序依赖的动态库:readelf -a xxx|grep library如:可以看到,下面的交叉程序hello执行依赖于如下两个动态库.[email protected]:~/test$ arm-none-linux-gnueabi-readelf -a hello|grep "library&quo

Linux下的动态连接库及其实现机制

Linux与Windows的动态连接库概念相似,但是实现机制不同.它引入了GOT表和PLT表的概念,综合使用了多种重定位项,实现了"浮动代码",达到了更好的共享性能.本文对这些技术逐一进行了详细讨论. 本文着重讨论x86体系结构,这是因为 (1)运行Linux的各种体系结构中,以x86最为普及: (2)该体系结构上的Windows操作系统广为人知,由此可以较容易的理解Linux的类似概念: 下表列出了Windows与Linux的近义词,文中将不加以区分: Windows Linux 动