程序运行时，是怎么找到动态库的？

我们随便开发一个C/C++程序，都很大程度不可避免的需要用到动态库：

我们提供的服务有：成都网站制作、成都做网站、微信公众号开发、网站优化、网站认证、高港ssl等。为1000多家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的高港网站制作公司

 
 
 
    
  
  
  
  1. // 来源：公众号【编程珠玑】
    2. 
  
  
  
  2. #include 
    3. 
  
  
  
  3. int main()
    4. 
  
  
  
  4. {
    5. 
  
  
  
  5.     printf("hello，编程珠玑\n");
    6. 
  
  
  
  6.     return 0;
    7. 
  
  
  
  7. }
    8.

编译并查看使用到的动态库：

 
 
 
    
  
  
  
  1. $ gcc -o main main.c
    2. 
  
  
  
  2. $ ldd main
    3. 
  
  
  
  3.     linux-vdso.so.1 (0x00007ffdf8fdf000)
    4. 
  
  
  
  4.     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1f8535e000)
    5. 
  
  
  
  5.     /lib64/ld-linux-x86-64.so.2 (0x00007f1f85951000)
    6.

从ldd命令的结果我们可以看到main程序依赖了哪些动态库，并且在哪个路径。那么你有没有想过，动态库的路径是怎么找到的，查找顺序又是怎样的呢?

准备动态库

在此之前如果你还没有对动态库有一个基本的了解的话，建议你阅读《浅谈静态库和动态库》或其他相关资料。为了说明后面的问题，这里我们先创建一个简单的动态库，你也可以参考《手把手教你制作动态库》：

 
 
 
    
  
  
  
  1. // test.c
    2. 
  
  
  
  2. //来源：公众号【编程珠玑】
    3. 
  
  
  
  3. #include 
    4. 
  
  
  
  4. #include "test.h"
    5. 
  
  
  
  5. #include "test1.h"
    6. 
  
  
  
  6. void test()
    7. 
  
  
  
  7. {
    8. 
  
  
  
  8.     printf("I am test；hello，编程珠玑\n");
    9. 
  
  
  
  9.     test1();
    10. 
  
  
  
  10. }
    11. 
  
  
  
  11. 
  
  
  
  12. // test.h
    13. 
  
  
  
  13. void test();
    14. 
  
  
  
  14. 
  
  
  
  15. 
  
  
  
  16. //test1.c
    17. 
  
  
  
  17. #include 
    18. 
  
  
  
  18. #include "test1.h"
    19. 
  
  
  
  19. void test1()
    20. 
  
  
  
  20. {
    21. 
  
  
  
  21.     printf("test1,needed by test\n");
    22. 
  
  
  
  22. }
    23. 
  
  
  
  23. // test1.h
    24. 
  
  
  
  24. void test1();
    25.

分别制作动态库libtest.so和libtest1.so，这在后面的示例中会用到：

 
 
 
    
  
  
  
  1. $ gcc test1.c -fPIC -shared -o libtest1.so
    2. 
  
  
  
  2. $ gcc test.c -fPIC -shared -o libtest.so -L. -ltest1
    3.

这样你在当前目录下就会看到有一个libtest.so和libtest1.so文件生成了，其中litest.so依赖libtest.so

注意，由于libtest.so依赖libtest1.so，这里用-L指定了要链接的test1的路径，因此我们看到：

 
 
 
    
  
  
  
  1. $ ldd libtest.so
    2. 
  
  
  
  2.     linux-vdso.so.1 (0x00007ffd1bbca000)
    3. 
  
  
  
  3.     libtest1.so => not found
    4. 
  
  
  
  4.     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9f1d0ae000)
    5. 
  
  
  
  5.     /lib64/ld-linux-x86-64.so.2 (0x00007f9f1d6a1000)
    6.

从这里可以看出libtest是依赖libtest1库的，但是特别注意到，libtest1.so指向的是not found，这会有什么影响吗?我们后面就会看到。

链接时查找路径

我们都知道，在编译成可执行文件前，链接器链接动态库也是需要查找动态库路径的，否则怎么链接上指定的动态库呢?那么这个顺序又是怎样的呢?

首先会查找的会是编译时链接的路径。修改前面的main.c，让它调用libtest.so中的test函数：

 
 
 
    
  
  
  
  1. // 来源：公众号【编程珠玑】
    2. 
  
  
  
  2. #include 
    3. 
  
  
  
  3. #include "test.h"
    4. 
  
  
  
  4. int main()
    5. 
  
  
  
  5. {
    6. 
  
  
  
  6.     test(); // 调用libtest.so中的test函数
    7. 
  
  
  
  7.     return 0;
    8. 
  
  
  
  8. }
    9.

编译链接：

 
 
 
    
  
  
  
  1. $ gcc -o main main.c -I ./ -L./ -ltest -ltest1
    2.

完美编译过。除此之外，如果我们把libtest.so和libtest1.so都移到/usr/lib下面，我们发现，即便不用-L也能编译过了:

 
 
 
    
  
  
  
  1. $ gcc -o main main.c -I ./  -ltest -ltest1
    2.

这里需要说明的是，我们通过-L./来指定搜索库的路径，由于libtest.so依赖libtest1.so，因此在编译链接时，也需要链接上test1。

小结

从上面的内容可以看到，在链接时，我们通过-L参数搜索要链接的库路径，但是这个路径信息不会写到ELF文件中，因此你会通过ldd命令看到not found，而通过-rpath可以指定链接时的搜索路径，这个信息会写入到ELF文件中，最终看到的结果是，由于libtest.so依赖libtest1.so，所以其他程序依赖libtest.so时，会自动从写入ELF的rpath中搜索它依赖的其他库，因此只需要链接libtest即可，例如：

在制作库libtest1.so时，加上-rpath-link选项：

 
 
 
    
  
  
  
  1. $ gcc test.c -fPIC -shared -o libtest.so -L. -ltest1 -Wl,-rpath-link $(pwd)
    2.

在编译main的时候，就不需要特意指定链接libtest1.so

 
 
 
    
  
  
  
  1. $ gcc -o main main.c -L ./ -ltest
    2.

只需要链接libtest.so，其依赖的libtest1.so也链接进来了。

当然了，如果-L指定的路径没有呢,它还会去查找其他地方，否则依赖的系统库怎么找到呢?总结大致顺序如下：

  • -L指定链接路径
  • 对于依赖库中依赖的搜索顺序通过-rpath-link或-rpath选项查找(后面会提到)
  • gcc默认链接路径(gcc --print-search-dir | grep libraries 查看)
  • 链接器配置的查找路径(ld -verbose | grep SEARCH_DIR查看)

针对具体的系统或链接器，可能有些差异，但是大致如此。

运行时查找路径

虽然前面编译成功了，但是我们运行看看，发现运行失败了。

 
 
 
    
  
  
  
  1. $ ./main
    2. 
  
  
  
  2. ./main: error while loading shared libraries: libtest.so: cannot open shared object file: No such file or directory
    3.

其实我们用ldd命令看一下也能看到：

 
 
 
    
  
  
  
  1. linux-vdso.so.1 (0x00007ffcd566e000)
    2. 
  
  
  
  2.     libtest.so => not found
    3. 
  
  
  
  3.     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f356d1f6000)
    4. 
  
  
  
  4.     /lib64/ld-linux-x86-64.so.2 (0x00007f356d7e9000)
    5.

LD_PRELOAD环境变量

这个环境变量在介绍《性能优化-使用高效内存分配器》中的时候，也有提到，用来做测试非常方便，同样的，这种方式也最好仅仅只是用于测试，因为它的优先级非常高，并且影响全局。使用也很简单：

 
 
 
    
  
  
  
  1. $ export LD_PRELOAD=./libtest.so
    2. 
  
  
  
  2. $ ./main
    3.

为了避免影响后面的验证，这里取消设置该环境变量：

 
 
 
    
  
  
  
  1. unset LD_PREALOD
    2.

查找rpath路径

上面的情况是找不到动态库，那么它首先会去rpath指定路径去查找，这需要在编译时指定：

 
 
 
    
  
  
  
  1. $ gcc test.c -fPIC -shared -o libtest.so -L. -ltest1 -Wl,-rpath $(pwd)
    2. 
  
  
  
  2. $ gcc -o main main.c -L . -ltest -Wl,-rpath $(pwd)
    3. 
  
  
  
  3. $ ./main
    4. 
  
  
  
  4. I am test；hello，编程珠玑
    5. 
  
  
  
  5. test1,needed by test
    6.

也就是说，如果我们编译时指定了路径，就可以找到了，但是这些信息被写入到了ELF文件中。

LD_LIBRARY_PATH环境变量

另外也可以通过这个环境变量来设置要搜索库的路径。

 
 
 
    
  
  
  
  1. $ gcc -o main main.c -L . -ltest
    2. 
  
  
  
  2. $ export LD_LIBRARY_PATH=./
    3. 
  
  
  
  3. $ ./main
    4.

这样运行也是没有问题的。

同样，为了避免对后面测试产生影响，取消设置该环境变量：

 
 
 
    
  
  
  
  1. unset LD_LIBRARY_PATH
    2.

/etc/ld.so.conf中的路径

我的机器上这个文件的内容如下：

 
 
 
    
  
  
  
  1. $ cat /etc/ld.so.conf
    2. 
  
  
  
  2. include /etc/ld.so.conf.d/*.conf
    3. 
  
  
  
  3. $ ls /etc/ld.so.conf.d/
    4. 
  
  
  
  4. fakeroot-x86_64-linux-gnu.conf  libc.conf  x86_64-linux-gnu.conf
    5.

所以它实际指的是/etc/ld.so.conf.d/目录下所有conf路径包含路径，打开其中一个libc.conf，它里面包含的路径为：

 
 
 
    
  
  
  
  1. $ /usr/local/lib
    2.

既然如此，我们把前面的libtest.so复制到该目录下(可能需要sudo权限)：

 
 
 
    
  
  
  
  1. $ sudo cp libtest.so /usr/local/lib
    2. 
  
  
  
  2. $ sudo ldconfig
    3. 
  
  
  
  3. $ ./main
    4. 
  
  
  
  4. I am test；hello，编程珠玑
    5. 
  
  
  
  5. test1,needed by test
    6.

注意，这里拷贝完成后，需要执行ldconfig，它会更新相应的共享库，以便可执行程序能够找到。实际上，执行完成后，你确实就能在/etc/ld.so.cache文件中找到：

 
 
 
    
  
  
  
  1. $ grep -a libtest.so /etc/ld.so.cache
    2.

同样，为了影响后面测试，记得删除：

 
 
 
    
  
  
  
  1. rm /usr/local/lib/libtest.so
    2.

实际上这里是先从/etc/ld.so.cache中的路径查找，然后再从ld.so.conf的路径中查找。后面我们可以通过命令看到。

/usr/lib，/lib/

当然了，如果以上路径都没有，最终还会在lib或/usr/lib下找，为了验证，我们将库拷贝到/lib目录下

 
 
 
    
  
  
  
  1. $ cp libtest.so /lib
    2. 
  
  
  
  2. $ ./main
    3. 
  
  
  
  3. I am test；hello，编程珠玑
    4. 
  
  
  
  4. test1,needed by test
    5.

同样能正常运行。

小结

小结一下，动态库的搜索顺序如下：

  • LD_PRELOAD环境变量指定库路径
  • -rpath链接时指定路径
  • LD_LIBRARY_PATH环境变量设置路径
  • /etc/ld.so.conf配置文件指定路径
  • 默认共享库路径，/usr/lib，lib

以上这些查找路径你很容易来验证它们的优先级，简单的做法就是这几个位置分别放置同名不同作用的库，来看看它到底先使用哪个路径下的库，可自行尝试。

LD_DEBUG

这个环境通常用来调试。例如，查看整个装载过程：

 
 
 
    
  
  
  
  1. $ LD_DEBUG=files ./main
    2.

或者查看依赖的库的查找过程：

 
 
 
    
  
  
  
  1. $ LD_DEBUG=libs ./main
    2. 
  
  
  
  2.       3557:    find library=libtest.so [0]; searching
    3. 
  
  
  
  3.       3557:     search cache=/etc/ld.so.cache
    4. 
  
  
  
  4.       3557:      trying file=/usr/local/lib/libtest.so
    5.

另外还可以显示符号的查找过程：

 
 
 
    
  
  
  
  1. $ LD_DEBUG=symbols ./main
    2.

总结

了解动态库的搜索路径，可以在开发中很好的帮助你定位找不到库的问题，同时LD_DEBUG环境变量也能够很好的帮助你调试，例如查看库搜索的路径，显示符号的查找过程等等。

虽然程序运行能够有多种途径获取动态库路径，但是并不是每种方式都合适，有的方式甚至完全不该用，但这超出了本文的讨论范围了。有兴趣的也可以点击阅文原文，查看《Why LD_LIBRARY_PATH is bad》

网页标题：程序运行时，是怎么找到动态库的？
转载源于：http://www.shufengxianlan.com/qtweb/news38/183188.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

外贸建站知识

同城分类信息

成都手机网站建设　　 　重庆电商网站定制　　 　led无边发光字　　 　成都企业网站设计　　 　郫县明安消防器材　　 　光华村机房　　 　和正兴机械　　 　网站建设公司　　 　手机网站制作　　 　绵阳服务器托管　　 　绵阳托管服务器　　 　成都创新互联　　 　温江网站设计　　 　成都移动机房　　 　买链接　　 　德阳定制网站建设　　 　渠县网站建设　　 　成都门户网站建设　　 　网站推广　　 　成都做商城网站