转载自： http://blog.csdn.net/q1302182594/article/details/42102961
1. 三个C文件
1. world.c
#include<stdio.h> void world(void) { printf("world. "); }
2. hello.c
#include <stdio.h> void world(void); void hello(void) { printf("hello "); world(); }
3. main.c
void main(void) { hello(); }
2. 编译动态库
gcc -c -fPIC hello.c world.c gcc -shared -o libhello.so hello.o gcc -shared -o libworld.so world.o
-fPIC编译选项是因为我是AMD64位系统，X86的系统似乎不需要
这时，生成的文件及其依赖如下图：
由上图可见，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. 编译main.c
3.1: -L
gcc test.c -lhello -L .
由上图可见已经在-L指定的路径找打了libhello.so，只是libhello.so还需要libworld.so。虽然它都在同一目录下，但是还是没有办法自动找到libworld.so。
能不能使用-lworld将libworld.so也一并链接到test.c中呢？下面做一个尝试：
gcc main.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第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 .
由上图可见，虽然没有明确指出链接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 fund。那么，这时候，LD_LIBRARY_PATH对a.out是否还有影响呢？下面将LD_LIBRARY_PATH设为当前libhello.so和libworld.so所在的路径
export LD_LIBRARY_PATH=./lib
由上图可见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
由上图可见，一切又恢复了正常。此时，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目录中，而libhello.so则留在linker目录中，使用以下命令对main.c进行编译:
gcc test.c -lhello -L . -Wl,-rpath-link ./lib
找不到 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还是有效的。
可以参考另一博文http://www.cnblogs.com/flyinggod/p/8026567.html 查看ld的搜索路径