查看linux下程序或者动态库到底依赖哪些so动态库以及对应的版本
基本上每一个linux 程序都至少会有一个动态库，查看某个程序使用了那些动态库，使用ldd命令查看#ldd/bin/lslinux-vdso.so.1=>(0x00007fff597ff000)libselinux.so.1=>/lib64/libselinux.so.1(0x00000036c2e00000)librt.so.1=>/lib64/librt.so.1(0x000
一. ldd命令
基本上每一个linux 程序都至少会有一个动态库，查看某个程序使用了那些动态库，使用ldd命令查看
# ldd /bin/ls
linux-vdso.so.1 => (0x00007fff597ff000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00000036c2e00000)
librt.so.1 => /lib64/librt.so.1 (0x00000036c2200000)
libcap.so.2 => /lib64/libcap.so.2 (0x00000036c4a00000)
libacl.so.1 => /lib64/libacl.so.1 (0x00000036d0600000)
libc.so.6 => /lib64/libc.so.6 (0x00000036c1200000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000036c1600000)
/lib64/ld-linux-x86-64.so.2 (0x00000036c0e00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000036c1a00000)
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;
}使用缺省参数编译结果
# g++ -o demo main.cpp
# ldd demo
linux-vdso.so.1 => (0x00007fffcd1ff000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f4d02f69000)
libm.so.6 => /lib64/libm.so.6 (0x00000036c1e00000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000036c7e00000)
libc.so.6 => /lib64/libc.so.6 (0x00000036c1200000)
/lib64/ld-linux-x86-64.so.2 (0x00000036c0e00000)如果我链接一些so，但是程序并不用到这些so，又是什么情况呢，下面我加入链接压缩库，数学库，线程库
# g++ -o demo -lz -lm -lrt main.cpp
# ldd demo
linux-vdso.so.1 => (0x00007fff0f7fc000)
libz.so.1 => /lib64/libz.so.1 (0x00000036c2600000)
librt.so.1 => /lib64/librt.so.1 (0x00000036c2200000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007ff6ab70d000)
libm.so.6 => /lib64/libm.so.6 (0x00000036c1e00000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000036c7e00000)
libc.so.6 => /lib64/libc.so.6 (0x00000036c1200000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000036c1a00000)
/lib64/ld-linux-x86-64.so.2 (0x00000036c0e00000)看看，虽然没有用到，但是一样有链接进来，那看看程序启动时候有没有去加载它们呢！
二. strace命令
# strace ./demo
execve("./demo", ["./demo"], [/* 30 vars */]) = 0
... = 0
open("/lib64/libz.so.1", O_RDONLY) = 3
...
close(3) = 0
open("/lib64/librt.so.1", O_RDONLY) = 3
...
close(3) = 0
open("/usr/lib64/libstdc++.so.6", O_RDONLY) = 3
...
close(3) = 0
open("/lib64/libm.so.6", O_RDONLY) = 3
...
close(3) = 0
open("/lib64/libgcc_s.so.1", O_RDONLY) = 3
...
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY) = 3
...
close(3) = 0
open("/lib64/libpthread.so.0", O_RDONLY) = 3
...
close(3) = 0
...看，有加载，所以必定会影响进程启动速度，所以我们最后不要把无用的so编译进来，这里会有什么影响呢？
大家知不知道linux从程序（program或对象）变成进程（process或进程），要经过哪些步骤呢，这里如果详细的说，估计要另开一篇文章。简单的说分三步：
- fork进程，在内核创建进程相关内核项，加载进程可执行文件；
- 查找依赖的so，一一加载映射虚拟地址
- 初始化程序变量。
可以看到，第二步中dll依赖越多，进程启动越慢，并且发布程序的时候，这些链接但没有使用的so，同样要一起跟着发布，否则进程启动时候，会失败，找不到对应的so。所以我们不能像上面那样，把一些毫无意义的so链接进来，浪费资源。但是开发人员写makefile 一般有没有那么细心，图省事方便，那么有什么好的办法呢。继续看下去，下面会给你解决方法。
先使用 ldd -u demo 查看不需要链接的so，看下面，一面了然，无用的so全部暴露出来了吧
# ldd -u demo
Unused direct dependencies:
/lib64/libz.so.1
/lib64/librt.so.1
/lib64/libm.so.6
/lib64/libgcc_s.so.1使用 -Wl,--as-needed 编译选项
# g++ -Wl,--as-needed -o demo -lz -lm -lrt main.cpp
# ldd demo
linux-vdso.so.1 => (0x00007fffebfff000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007ff665c05000)
libc.so.6 => /lib64/libc.so.6 (0x00000036c1200000)
libm.so.6 => /lib64/libm.so.6 (0x00000036c1e00000)
/lib64/ld-linux-x86-64.so.2 (0x00000036c0e00000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000036c7e00000)
# ldd -u demo
Unused direct dependencies:
三. so文件的链接（编译时）方式
我们知道linux链接so有两种途径：显示和隐式。
显示就是程序主动调用dlopen打开相关so。如果使用显示链接，上面讨论的那些问题都不存在。首先,dlopen的so使用ldd是查看不到的。其次，使用dlopen打开的so并不是在进程启动时候加载映射的，而是当进程运行到调用dlopen代码地方才加载该so，也就是说，如果每个进程显示链接a.so;但是如果发布该程序时候忘记附带发布该a.so,程序仍然能够正常启动，甚至如果运行逻辑没有触发运行到调用dlopen函数代码地方。该程序还能正常运行，即使没有a.so.
既然显示加载这么多优点，那么为什么实际生产中很少码农使用它呢, 主要原因还是起使用不是很方便，需要开发人员多写不少代码。所以不被大多数码农使用，还有一个重要原因应该是能提前发现错误，在部署的时候就能发现缺少哪些so，而不是等到实际上限运行的时候才发现缺东少西。
下面举个工作中最常碰到的问题，来引申出本篇内容吧。
写一个最简单的so， tmp.cpp1.
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库查找路径和运行时的so库查找路径
这个错误是最常见的错误了。运行程序的时候找不到依赖的so。一般人使用方法是修改LD_LIBRARY_PATH这个环境变量。
export LD_LIBRARY_PATH=/tmp
[stevenrao]$ ./demo
test- 不过这样export 只对当前shell有效，当另开一个shell时候，又要重新设置；
- 可以把export LD_LIBRARY_PATH=/tmp 语句写到 ~/.bashrc中，这样就对当前用户有效了；
- 写到/etc/bashrc中就对所有用户有效了。
修改LD_LIBRARY_PATH的方法：
方法一： export LD_LIBRARY_PATH=LD_LIBRARY_PATH:/tmp，但是登出后就失效
方法二： 修改~/.bashrc或~/.bash_profile或系统级别的/etc/profile
1. 在其中添加例如export LD_LIBRARY_PATH=/tmp:$LD_LIBRARY_PATH
2. source .bashrc (Source命令也称为“点命令”，也就是一个点符号（.）。source命令通常用于重新执行刚修改的初始化文件，使之立即生效，而不必注销并重新登录)
方法三：这个没有修改LD_LIBRARY_PATH但是效果是一样的实现动态库的查找，
1. /etc/ld.so.conf下面加一行/tmp
2. 保存过后ldconfig一下（ldconfig 命令的用途,主要是在默认搜寻目录(/lib和/usr/lib)以及动态库配置文件/etc/ld.so.conf内所列的目录下,搜索出可共享的动态链接库(格式如前介绍,lib*.so*),进而创建出动态装入程序(ld.so)所需的连接和缓存文件.缓存文件默认为/etc/ld.so.cache,此文件保存已排好序的动态链接库名字列表.）
前面链接时候使用 -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文件内部了，路径和程序深深的耦合到一起。-Wl后面跟着逗号分隔的链接器参数-rpath和/tmp，意思是告诉链接器参数-rpath的值是/tmp。
除了上述的-rpath外，还有一个类似于-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影响动态库加载的东西：
- ELF 中的变量 RPATH 和 RUNPATH
- 环境变量 LD_PRELOAD 和 LD_LIBRARY_PATH
LD_PRELOAD 属于强制加载，有点Injection的感觉，这里暂时不讨论，LD_PRELOAD 似乎总是最强势的。
我们从一个应用程序 a 链接一个 lib_b.so 开始。下面是 a 和 b 的代码以及编译链接过程
a.c:
#include <stdio.h>
void test_a()
{
test_b();
}
int main()
{
test_a();
return 0;
}b.c:
#include <stdio.h>
void test_b()
{
}编译：
[root@vm153 01]# gcc b.c -shared -fPIC -o lib/lib_b.so
[root@vm153 01]# gcc -o a a.c -Llib -l_b
因为lib_b.so 在 lib 目录下 所以需要 -Llib
运行结果如下：
[root@vm153 01]# ./a
./a: error while loading shared libraries: lib_b.so: cannot open shared object file: No such file or directory失败，解决方案如下：
- 把 lib_b.so 挪到 /lib 或 /usr/lib 下面，但是这个不太靠谱，毕竟是系统的目录
- 使用LD_LIBRARY_PATH 把当前 lib 目录加进来，执行OK
[root@vm153 01]# LD_LIBRARY_PATH=lib ./a
- 重新编译a 加入RPATH，执行 OK，注意用readelf 可以查看RPATH (原来-Wl,-rpath= 的作用就是在目标文件里加入了RPATH)
[root@vm153 01]# gcc -o a a.c -Llib -l_b -Wl,-rpath=lib [root@vm153 01]# ./a [root@vm153 01]# readelf -d a | grep PATH 0x0000000f (RPATH) Library rpath: [lib] [root@vm153 01]#
那么LD_LIBRARY_PATH 和 RPATH 同时提供的情况下，结果会如何呢？
我们要做一个简单的实验，我们尝试提供两个lib_b.so 并且在test_b代码中给出打印。
b1.c 和 b2.c 代码一致 如下：
#include <stdio.h>
void test_b()
{
printf("test_b in: %s\n", __FILE__);
}
编译过程如下：
[root@localhost 02]# gcc b1.c -shared -fPIC -o lib1/lib_b.so [root@localhost 02]# gcc b2.c -shared -fPIC -o lib2/lib_b.so [root@localhost 02]# gcc -o a a.c -Llib1 -l_b -Wl,-rpath=lib1
显然 a 的 RPATH 已经被设置成了 lib1 , 然后我们使用 LD_LIBRARY_PATH 设置为lib2 来看看 a究竟加载那个 lib_b
[root@localhost 02]# LD_LIBRARY_PATH=lib2 ./a test_b in: b1.c [root@localhost 02]#
很明显是RPATH 起了作用。其实没有必要加入打印，用ldd 一样可以验证具体加载了哪个 so
[root@localhost 02]# LD_LIBRARY_PATH=lib2 ldd a
linux-vdso.so.1 => (0x00007fffc51c8000)
lib_b.so => lib1/lib_b.so (0x00007f5b6d268000)
libc.so.6 => /lib64/libc.so.6 (0x00007f5b6cebe000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5b6d46a000)
[root@localhost 02]#
加上RUNPATH 吧！
再复杂一点的情况， RUNPATH 我们用的不太多，但是有的系统上 -Wl,-rpath 会一起加上RUNPATH，重新编译a 使用--enable-new-dtags 加入RUNPATH
[root@localhost 02]# gcc -o a a.c -Llib1 -l_b -Wl,-rpath=lib1,--enable-new-dtags
[root@localhost 02]# readelf -d a | grep PATH
0x000000000000000f (RPATH) Library rpath: [lib1]
0x000000000000001d (RUNPATH) Library runpath: [lib1]
[root@localhost 02]# LD_LIBRARY_PATH=lib2 ldd a
linux-vdso.so.1 => (0x00007fffa4591000)
lib_b.so => lib2/lib_b.so (0x00007f8779855000)
libc.so.6 => /lib64/libc.so.6 (0x00007f87794ab000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8779a57000)
[root@localhost 02]#
恩～～ 这个有点困惑了。 其实逻辑是这样的：加载器首先看有没有 RUNPATH， 如果有那么就尝试从LD_LIBRARY_PATH 加载，如果还是失败再从RUNPATH加载。当然最后如果还是不行，会尝试 /lib 和 /usr/lib。
这个RUNPATH 真的有点二，设置了一个值，但是不会马上启用，而且还干掉了 RPATH 成全了LD_LIBRARY_PATH……
总结下来，它们的先后顺序如下：
如何创建只有RUNPATH 的 ELF 文件？
按照上面的推论，当RPATH 和 RUNPATH 同时存在的话，那么RPATH 实际就没有用了（这点逻辑应该能理解吧），可是ld 链接出来的要么没有 RPATH 和 RUNPATH，要么只有RPATH， 要么两个都有（我想可能是为了兼容一下老版本的loader 吧）。
简单的方案，利用第三方工具 patchelf (GitHub - NixOS/patchelf: A small utility to modify the dynamic linker and RPATH of ELF executables)。先编译出一个没有RPATH RUNPATH的 ELF 文件，然后 用 patchelf --set-rpath 来添加，这样就只会添加 RNPATH。当然这个工具还有好些个其他选项……
LD_DEBUG
查看一个程序搜索其各个动态库的路径的另一个简单的办法是使用 LD_DEBUG这个环境变量，LD_DEBUG这个变量可以提供非常详细的加载动态链接库的信息。
[stevenrao] $ export LD_DEBUG=libs
[stevenrao] $ ./demo
可以把LD_DEBUG设成以下值：
- export LD_DEBUG=files # 显示库的依赖性和加载的顺序
- export LD_DEBUG=bindings # 符号绑定
- export LD_DEBUG=libs # 显示加载器查找库时使用的路径的顺序
- export LD_DEBUG=versions # 版本依赖性
- export LD_DEBUG=help # LD_DEBUG的帮助信息
试一下把LD_DEBUG设成以上值之一，再随便运行一个程序试试。一个试验：
root@vicarious:/home/kamus/projs/horoscope/bins# export LD_DEBUG=libs
root@vicarious:/home/kamus/projs/horoscope/bins# vim my.conf
24360: find library=libm.so.6 [0]; searching
24360: search cache=/etc/ld.so.cache
24360: trying file=/lib/x86_64-linux-gnu/libm.so.6
24360:
24360: find library=libtinfo.so.5 [0]; searching
24360: search cache=/etc/ld.so.cache
24360: trying file=/lib/x86_64-linux-gnu/libtinfo.so.5
24360:
24360: find library=libselinux.so.1 [0]; searching
24360: search cache=/etc/ld.so.cache
24360: trying file=/lib/x86_64-linux-gnu/libselinux.so.1
24360:
24360: find library=libacl.so.1 [0]; searching
24360: search cache=/etc/ld.so.cache
24360: trying file=/lib/x86_64-linux-gnu/libacl.so.1
24360:
24360: find library=libgpm.so.2 [0]; searching
24360: search cache=/etc/ld.so.cache
24360: trying file=/usr/lib/x86_64-linux-gnu/libgpm.so.2
24360:
24360: find library=libc.so.6 [0]; searching
24360: search cache=/etc/ld.so.cache
24360: trying file=/lib/x86_64-linux-gnu/libc.so.6
24360:
24360: find library=libdl.so.2 [0]; searching
24360: search cache=/etc/ld.so.cache
24360: trying file=/lib/x86_64-linux-gnu/libdl.so.2
24360:
24360: find library=libattr.so.1 [0]; searching
24360: search cache=/etc/ld.so.cache
24360: trying file=/lib/x86_64-linux-gnu/libattr.so.1四. 让可执行文件链接指定版本的动态库
系统中存在soname为libpcre.so.1和libpcre.so.3两个动态库，怎样让编译出来的可执行文件链接libpcre.so.1的soname动态库？
解答：首先使用-L指定动态库的位置，然后使用-l:libpcre.so.1的全名即可。-L${PWD}/usr/lib -l:libpcre.so.1。
gcc编译怎样指定特定的链接器？
-Wl,--dynamic-linker=/path/lib/ld-linux-x86-64.so.2
五. 现实场景
文中的例子很易于理解，但毕竟有些不切实际，没人会手动编译源文件，也不会手动设置rpath。对于Linux上的开发者而言，CMake可以说是最常用的构建工具。当我们写好CMakeLists.txt后，CMake会帮我们设置好链接库的名称，以及rpath等搜索路径。此外，CMake提供了一些命令用来手动设置rpath，但我们一般都不需要用，这里就不提了。值得一提的是，CMake会根据构建类型来决定是否设置rpath，在build时，会添加库路径到rpath，而在install时，则会把rpath设置为空。这是因为，install之后，认为可执行文件是可移植的，不必依赖于编译时链接的特定的库，库的搜索路径完全由所在系统的默认库路径和环境变量决定。
参考链接：
linux下so动态库一些不为人知的秘密（中） - DoubleLi - 博客园
linux下so动态库一些不为人知的秘密（上）-raochaoxun-ChinaUnix博客
https://blog.csdn.net/xie__peng/article/details/88978629
华为开发者空间，是为全球开发者打造的专属开发空间，汇聚了华为优质开发资源及工具，致力于让每一位开发者拥有一台云主机，基于华为根生态开发、创新。
更多推荐
9
0- 0
已为社区贡献6条内容
所有评论(0)