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

上一篇(linux下so动态库一些不为人知的秘密(上))介绍了linux下so一些依赖问题,本篇将介绍linux的so路径搜索问题。

  

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

 

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

 

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

写一个最简单的so tmp.cpp

1.    int test()

2.    {

3.      return 20;

4.    }

  编译=>链接=》运行, 下面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文件内部了,路径和程序深深的耦合到一起

 

    篇幅太长,请看下回分解

时间: 2024-10-03 18:14:03

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

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

继续上一篇< linux下so动态库一些不为人知的秘密(中) >介绍so搜索路径,还有一个类似于-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    

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

 linux 下有动态库和静态库,动态库以.so为扩展名,静态库以.a为扩展名.二者都使用广泛.本文主要讲动态库方面知识.        基本上每一个linux 程序都至少会有一个动态库,查看某个程序使用了那些动态库,使用ldd命令查看  # ldd /bin/ls linux-vdso.so.1 => (0x00007fff597ff000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00000036c2e00000) librt.so.1 =

Linux下,动态库和静态库之间是否能够相互转化?

问题描述 Linux下,动态库和静态库之间是否能够相互转化? Linux下,动态库和静态库之间是否能够相互转化呢?现在我有一些动态共享库.so,但发布程序的时候总得在目标服务器上安装这些库,程序才能运行,我想把它们转化为静态库.a,能做到么?有这样的工具吗?谢谢大家. 解决方案 通过makefile编译的时候,生成一份动态,一份静态 解决方案二: 我有动态库文件so,但是没有源码.我现在希望做的是:动态库.so转化为静态库.a.大家帮帮忙啊.

Linux/Unix 下调试动态库(.so文件)

问题描述 Linux/Unix 下调试动态库(.so文件) 需要调试一个C语言编写的动态库,这个动态库也是我自己写的编译的时候加了-g参数. 但是这个动态库是给oracle数据库调用的,也就是在存储过程里面调用这个动态库.由于这个动态库是新写的,经常有问题需要用gdb跟踪代码调试.我要怎么做才能调试这个动态库呢??? 目前想到的一个办法就是再写一个C程序调用这个动态库然后gdb调试.但是这个动态库提供给数据库的接口很多全部写出来比较费时间.希望找个方便点的方法,类似于gdb直接调试运行中的程序.

交叉编译-linux下gtk的库文件有很多,不知道哪一个是我用的

问题描述 linux下gtk的库文件有很多,不知道哪一个是我用的 我做的应用运行在手持终端,基于一个精简的Linux系统.用的gcc-arm-linux交叉编译工具 现在我就想搞清楚头文件和库文件在哪里,makefile脚本很复杂而且有很多文件,完全看不懂,只能凭目录名称去找...头文件在/usr/local/arm-linux/include/gtk/下库文件用locate libgtk查找有一大堆,目测有关系的有下面这些:/usr/local/arm-linux/arm-linux/lib/

c语言-linux C 编译 动态库.so 提示 方法load failed

问题描述 linux C 编译 动态库.so 提示 方法load failed makefile里:libtest.so: 1.o 2.o 3.o 4.o gcc -shared -fPIC -o libtest.so 1.c 1.c 用到的方法都在2.o3.o4.o里, 现在编译libtest.so没问题,但是程序跑的时候,提示 1.c调用2.o里的方法load fail:小弟没怎么弄过makefile, 求大神指点! 解决方案 把所有用到的so也放到程序当前目录 解决方案二: http://

在Window和Linux下使用Zthread库

ZThread库是一个开源的跨平台高级面向对象的线性和sycnchronization 库,以运行POSIX 和Win32 系统中的C++程序. ZThread库的主页:http://zthread.sourceforge.net 最新版本Zthread远吗下载地址: http://prdownloads.sourceforge.net/zthread/ZThread-2.3.2.tar.gz ZThread文档:http://zthread.sourceforge.net/documentat

Linux下利用glibc2库和crypt()函数生成用户密码

 原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://dgd2010.blog.51cto.com/1539422/1712244 基本知识 Linux用户的密码由函数crypt()实现.crypt()是一个密码加密函数(将密码加密,明文变成密文),该函数基于数据加密标准(DES,Data Encryption Standard )算法以及基于DES的其他变种算法,该函数不依赖于计算机硬件实现数据加密.DES算法仅适合于加密字符串

[c/c++]关于linux下动态库/静态库的基础问题

问题描述 [c/c++]关于linux下动态库/静态库的基础问题 本人小白,自学没多久,有几个问题一直没搞太明白,望高手解答! 假如我写了一个动态库libmylib.so(我有函数声明mylib.h),里面用到了A同学写的动态库liba.so(我有声明a.h),现在我要在一个新的程序test.cpp里调用我写的mylib.so 问题: 1.test.cpp的头文件需要两个.h都包含还是只要mylib.h? 2.用g++链接时 -lmylib -la都需要吗? 3.假如有一天liba.so文件丢失