GCC 中 -L、-rpath和-rpath-link的区别

来源 http://blog.csdn.net/q1302182594/article/details/42102961

关于这3个参数的说明，有不少资料，但是看完了还是觉得模糊，分不清它们的区别。本文将用实验的方法去探讨这3个参数的区别。

1、三个.c文件

1.1 world.c

1. #include<stdio.h>
2. void world(void) {
3. printf("world.\n");
4. }

1.2 hello.c

1. #include <stdio.h>
2. void world(void);
3. void hello(void) {
4. printf("hello\n");
5. world();
6. }

1.3 test.c

1. void main(void) {
2. hello();
3. }

2、生成动态库

参照《Linux静态库与动态库制作》，将hello.c和world.c分别生成动态库

1. ubuntu $ gcc -c hello.c world.c
2. ubuntu $ gcc -shared -o libhello.so hello.o
3. ubuntu $ 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：

1. ubuntu $ gcc -shared -o libworld.so world.o -lhello -L .

此时，再使用ldd查看libhello.so的依赖：

    由上图可见，此时libhello.so已经依赖于libworld.so。

3、编译test.c

3.1 -L

由于test.c直接依赖于libhello.so，因此使用-lhello -L

1. ubuntu $ gcc test.c -lhello -L .

结果如下图:

由上图可见已经在-L指定的路径找打了libhello.so，只是libhello.so还需要libworld.so。虽然它都在同一目录下，但是还是没有办法自动找到libworld.so。

那么，能不能使用-lworld将libworld.so也一并链接到test.c中呢？下面做一个尝试：

1. ubuntu $ 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

1. ubuntu 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第1张图的提示，由于libhello.so依赖于libworld.so，可以只用-rpath或者-rpath-link来指定。这里先使用-rpath。

先清空LD_LIBRARY_PATH环境变量，然后重新编译test.c并且带上-rpath参数：

1. ubuntu $ export LD_LIBRARY_PATH=
2. ubuntu $ 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移动进这个目录。

1. ubuntu $ mdir lib_tmp
2. ubuntu $ mv libhello.so lib_tmp/
3. ubuntu $ 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 fund。

那么，这时候，LD_LIBRARY_PATH对a.out是否还有影响呢？下面将LD_LIBRARY_PATH设为当前libhello.so和libworld.so所在的路径

1. ubuntu $ 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所在的路径：

1. ubuntu $ 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小节第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进行编译:

1. ubuntu $ 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、ld命令的man手册

4.1  -rpath=dir

1. Add a directory to the runtime library search path.  This is used when linking an ELF executable with shared objects.
2. All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at
3. runtime.  The -rpath option is also used when locating shared objects which are needed by shared objects explicitly
4. included in the link; see the description of the -rpath-link option.  If -rpath is not used when linking an ELF
5. executable, the contents of the environment variable "LD_RUN_PATH" will be used if it is defined.
6. The -rpath option may also be used on SunOS.  By default, on SunOS, the linker will form a runtime search path out of
7. all the -L options it is given.  If a -rpath option is used, the runtime search path will be formed exclusively using
8. the -rpath options, ignoring the -L options.  This can be useful when using gcc, which adds many -L options which may
9. be on NFS mounted file systems.
10. For compatibility with other ELF linkers, if the -R option is followed by a directory name, rather than a file name, it
11. is treated as the -rpath option.

4.2  -rpath-link=dir

1. When using ELF or SunOS, one shared library may require another.  This happens when an "ld -shared" link includes a
2. shared library as one of the input files.
3. When the linker encounters such a dependency when doing a non-shared, non-relocatable link, it will automatically try
4. to locate the required shared library and include it in the link, if it is not included explicitly.  In such a case,
5. the -rpath-link option specifies the first set of directories to search.  The -rpath-link option may specify a sequence
6. of directory names either by specifying a list of names separated by colons, or by appearing multiple times.
7. This option should be used with caution as it overrides the search path that may have been hard compiled into a shared
8. library. In such a case it is possible to use unintentionally a different search path than the runtime linker would do.

4.3  search paths

1. The linker uses the following search paths to locate required shared libraries:
2. 1.  Any directories specified by -rpath-link options.
3. 2.  Any directories specified by -rpath options.  The difference between -rpath and -rpath-link is that directories
4. specified by -rpath options are included in the executable and used at runtime, whereas the -rpath-link option is
5. only effective at link time. Searching -rpath in this way is only supported by native linkers and cross linkers
6. which have been configured with the --with-sysroot option.
7. 3.  On an ELF system, for native linkers, if the -rpath and -rpath-link options were not used, search the contents of
8. the environment variable "LD_RUN_PATH".
9. 4.  On SunOS, if the -rpath option was not used, search any directories specified using -L options.
10. 5.  For a native linker, search the contents of the environment variable "LD_LIBRARY_PATH".
11. 6.  For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of a shared library are searched for shared
12. libraries needed by it. The "DT_RPATH" entries are ignored if "DT_RUNPATH" entries exist.
13. 7.  The default directories, normally /lib and /usr/lib.
14. 8.  For a native linker on an ELF system, if the file /etc/ld.so.conf exists, the list of directories found in that
15. file.

参考资料

[1]动态库的链接和链接选项-L，-rpath-link，-rpath

[2]ld的-rpath与-rpath-link选项

原文地址：https://www.cnblogs.com/lsgxeva/p/8257784.html