0 前言
gcc编译程序时,可通“-L”、“-rpath”或“-rpath-link”参数指定依赖库路径,关于这3个参数的说明,有不少资料,但是看完了还是觉得模糊,分不清它们的区别。本文将用实验的方法去探讨这3个参数的区别。
1 源文件
用于本文实验的3个源文件如下所示:
(1)world.c
#include<stdio.h>
void world(void)
{
printf("world.\n");
}
(2)hello.c
#include <stdio.h>
void world(void);
void hello(void)
{
printf("hello\n");
world();
}
(3)test.c
void main(void)
{
hello();
}
2 生成动态库
参照《Linux静态库与动态库制作》,将hello.c和world.c分别生成动态库
gcc -c hello.c world.c
gcc -shared -o libhello.so hello.o
gcc -shared -o libworld.so world.o
这时,生成的文件及其依赖如下图:
由上图可见,libhello.so和libworld都依赖linux-gate.so.1、libc.so.6以及/lib/ld-linux.so.2,并且这3个库的路径都已经硬编码进libhello.so和libworld.so中了(=>右边的部分)。
然而,虽然libhello.so中调用了libworld.so的函数,但是在上图中并没有显示出此关系。为了达到使libhello.so依赖libworld.so的目的,在生成libhello.so时要链接到libworld.so:
gcc -shared -o libhello.so hello.o -lworld -L
此时,再使用ldd查看libhello.so的依赖:
由上图可见,此时libhello.so已经依赖libworld.so。
3 编译test.c
3.1 -L
由于test.c直接依赖libhello.so,因此使用-lhello -L
gcc test.c -lhello -L .
结果如下图:
由上图可见已经在-L指定的路径找到了libhello.so,只是libhello.so还需要libworld.so。虽然它都在同一目录下,但是还是没有办法自动找到libworld.so。
那么,能不能使用-lworld将libworld.so也一并链接到test.c中呢?下面做一个尝试:
gcc test.c -lhello -lworld -L .
没有报错,成功生成a.out。
执行a.out并且使用ldd查看a.out的依赖:
由上图可见,虽然使用-lworld参数将libworld.so链接到了a.out中,但是上面只显示a.out依赖libhello.so。由于找不到libhello.so(=> not found)的路径,因此需要设置环境变量LD_LIBRARY_PATH:
export LD_LIBRARY_PATH=/home/liyihai/documents
再次执行a.out,并用ldd命令查看a.out的依赖库:
由上图可见,libhello.so已经通过LD_LIBRARY_PATH环境变量找到,并且libworld.so也出现在a.out的依赖中!
结论:-L指定的是链接时的库路径,生成的可执行文件在运行时库的路径由LD_LIBRARY_PATH环境变量指定。
3.2 -rpath
根据图3.1的提示,由于libhello.so依赖libworld.so,可以只用-rpath或者-rpath-link来指定。这里先使用-rpath。
先清空LD_LIBRARY_PATH环境变量,然后重新编译test.c并且带上-rpath参数:
export LD_LIBRARY_PATH=
gcc test.c -lhello -L . -Wl,-rpath .
执行a.out,并且使用ldd命令查看a.out的依赖:
由上图可见,虽然没有明确指出链接libworld.so,但是libworld.so还是出现在a.out的依赖中。
另外,虽然LD_LIBRARY_PATH已经清空,但是a.out还是可以执行,这说明库的路径已经被硬编码进a.out中了。需要注意的是,libhello.so和libworld.so的路径都是通过-rpath指定的路径找到的。
3.2.1 实验1
这时候,如果libhello.so和libworld.so的路径改变了,将会发生什么情况呢?下面做一个实验。
创建一个lib_tmp目录,然后将libhello.so和libworld.so移动进这个目录。
mdir lib_tmp
mv libhello.so lib_tmp/
mv libworld.so lib_tmp/
这时再执行a.out时,提示找不动态库,使用ldd命令查看a.out的库路径:
由上图红色圈部分可见,libhello.so的路径是not found的,并且libworld.so没有出现在其中。这和3.1的情况是相同的。
究其原因,就是要先找到libhello.so再去找libworl.so,因为是libhello.so依赖libworld.so,而不是a.out依赖于libworld.so。
由此可见,使用了-rpath参数指定库的路径后,生成的可执行文件的依赖库路径并非就固定不变了。而是执行时先从-rpath指定的路径去找依赖库,如果找不到,还是会报not found。
那么,这时候,LD_LIBRARY_PATH对a.out是否还有影响呢?下面将LD_LIBRARY_PATH设为当前libhello.so和libworld.so所在的路径
export LD_LIBRARY_PATH=./lib_tmp
再次执行a.out,并且使用ldd查看此时a.out的依赖库路径:
由上图可见LD_LIBRARY_PATH还是起作用的!由上图可见,和使用-rpath指定路径的效果是一样的。
3.2.2 实验2
将LD_LIBRARY_PATH清空,然后将libhello.so移动到lib_tmp中,而libworld.so则留在documents目录中。
执行a.out,并且使用ldd查看此时a.out的依赖库:
由上图可见,找不到libhello.so。这时,再指定LD_LIBRARY_PATH的路径为libhello.so所在的路径:
export LD_LIBRARY_PATH=./lib_tmp/
再次执行a.out,并且使用ldd查看其依赖库:
由上图可见,一切又恢复了正常。此时,libhello.so是通过LD_LIBRARY_PATH找到的,而libworld.so则是通过-rpath指定的路径找到的。
3.2.3 回顾
其实,经过测试,在3.1小节中,如果先指定LD_LIBRARY_PATH的值为libhello.so和libworld.so所在的路径,然后再编译test.c(执行3.1节的第1条编译命令),是可以成功编译的,并不会报图3.1的那种错误。也就是说,LD_LIBRARY_PATH不仅指定可执行文件的库路径,还指定了库所依赖其它库的路径。
3.2.4 结论
并非指定-rpath参数后,就抛弃LD_LIBRARY_PATH环境变量,只是多了个可选的依赖库路径而已。
3.3 -rpath-link
先将LD_LIBRARY_PATH的值清空,然后将libworld.so移动到lib_tmp目录中,而libhello.so则留在documents目录中,使用以下命令对test.c进行编译:
gcc test.c -lhello -L . -Wl,-rpath-link ./lib_tmp
执行a.out并且使用ldd查看a.out的依赖库:
找不到 libhello.so,这在预料之中。下面指定LD_LIBRARY_PATH的值为libhello.so的路径,然后在执行a.out,并且查看a.out的依赖:
由上图可见,libhello.so已经通过LD_LIBRARY_PATH找到,但是libworld.so由于没有在LD_LIBRARY_PATH指定的路径中,而且编译时a.out又没有包含库的路径,因此找不到。这
对比3.2.2可以得出结论:-rpath和-rpath-link都可以在链接时指定库的路径;但是运行时rpath-link指定的路径就不再有效(链接器没有将库的路径包含进可执行文件中),而-rpath指定的路径还有效(因为链接器已经将库的路径包含在可执行文件中了)。
最后,不管使用了-rpath还是-rpath-link,LD_LIBRARY_PATH还是有效的。
4 总结
三个变量/参数的生效时机总结如下:
编译(链接)时 | 运行时 | 备注 | |
-L | Y | N | |
-rpath-link | Y | N | 其作用类似于-L |
-rpath | Y | Y | 优先级高于LD_LIBRARY_PATH |
LD_RUN_PATH | Y | Y | 待验证[6] |
LD_LIBRARY_PATH | N | Y |
参考资料
[1]动态库的链接和链接选项-L,-rpath-link,-rpath