关于库的深入思考[探讨原创]

晨想

我写的只是一些心得而已，希望对理解楼主的文章有所帮助。

Skymoon

呵呵，谢谢大家的支持了^^很高兴能给大家些许帮助^^

至于分段，幻想版主已经给出了很好的整理(谢谢)，我也说不好怎么分，其实写的时候还是很认真的，希望能写的清晰易懂些，可能是在语文功底欠佳，这篇文章早想写了，直到最近才动笔（应该说是动键盘，呵呵），因为马上就又要开学了，估计半年内没太多时间常来了。也算是最后献给大家的一份礼物吧，想尽力做好，希望大家喜欢。我有机会就会来看看大家的，呵呵^^

augustusqing

很不错！学到不少东西，谢谢Skymoon了

幻想老大,你后面说的“configure 的 --lib-path 参数”应该就是configure中的--with-lib-path指定的路径吧？
按照LFS Book在第二遍binutils时说的“--with-lib-path=/tools/lib，这个选项指示 configure 脚本在 Binutils 编译过程中将传递给连接器的库搜索路径设为 /tools/lib ，以防止连接器搜索宿主系统的库目录”，这个选项只是控制ld的库搜索路径，而根据Skymoon说的ld和ld-linux.so.2的区别，那么这个路径就跟ldconfig，ld-linux.so.2搜索库的路径应该没关系啊，你认为了？

augustusqing

对Skymoon兄的文章我学习了一天多，确实够得上深入思考啊
现在才勉强有点顺序感了，我的理解是
say.c源程序调用say.so共享库到test可执行文件，到test的执行，把这个过程分为三步走
第一步：  gcc -c say.c                                     -->    say.o    编译
第二步：  gcc test.c say.o ./say.so -o test     -->    test       链接
第三步：  ./test                                                      把test载入,获得test内存映象
第一步，没话说，gcc是主角
第二步，ld是主角，ld是binutils中安装的工具，他只要搜到了say.so,就能生成test，而gcc test.c ./say.so -o test中的./路径信息，跟ld的LIB_PATH,configure的--with-lib-path(应该就是幻想版主的--lib-path),还有gcc中的-lsay（必须以libsay.so的文件名，存在于ld的默认搜索路径下，就是ld –verbose|grep SEARCH中列出的目录下），-L/aaa/bbb(libsay.so存在/aaa/bbb),这里5个路径信息（欢迎补充），都是告诉ld如何搜索say.so(libsay.so)。至于生成的可执行文件test用哪个ld-linux.so.2由gcc的spec规定，存在于test程序头的PT_INTERP类型的段（segment）中，与ld无关。ld找say.so的顺序我认为无关紧要，因为ld的工作是它找到相应库和库中的函数名后，在可执行文件里标记这些符号，而整个事情最关键的在于程序载入时ld-linux.so.2找到的say.so.
第三步，主角是ld-linux.so.2，test要载入内存来运行，需由这个ld-linux.so.2载入必须的共享库，而它搜索库的路径跟上面ld的搜索路径相关的地方就是gcc test.c ./say.so -o test中say.so前面的./会硬编码进test中的动态节（.dynamic section）的DT_NEEDED类型入口中，然而当ld在其他路径信息找到了say.so，却不会把路径信息硬编码进DT_NEED入口。然后就是ld-linux.so.2搜索库的顺序
1    DT_NEED入口中包含的路径
2    DT_RPATH入口给出的路径（存在的话）
3    环境变量LD_LIBRARY_PATH路径（setuid类的程序排除）
4    LD_RUNPATH入口给出的路径（存在的话）
5.   库高速缓存文件ld.so.conf中给出的路径
6.   /lib,/usr/lib
补充：2  test中的DT_RPATH由什么传递进来，我不清楚。
3        对于setuid类程序，忽略；链接时有—library-path PATH选项时会被override
4        同2，这两处路径，当有链接选项--ignore-rpath LIST时会把LIST中的RPATH和RUNPATH信息忽略掉。
5中ld-linux.so.2找的ld.so.conf则在生成glibc库时的--prefix/etc目录下, ld-linux.so.2其实是找搜索ld.so.cache,由ldconfig生成。
6 当链接时加入了  -z nodeflib 选项，此处路径信息被忽略
第二步中ld找到了say.so,而ld-linux.so.2却找不到时，仅能得到test，却不能生成进程映象。

好想和各位再探讨探讨！

晨想

Post by augustusqing
很不错！学到不少东西，谢谢Skymoon了

幻想老大,你后面说的“configure 的 --lib-path 参数”应该就是configure中的--with-lib-path指定的路径吧？
按照LFS Book在第二遍binutils时说的“--with-lib-path=/tools/lib，这个选项指示 configure 脚本在 Binutils 编译过程中将传递给连接器的库搜索路径设为 /tools/lib ，以防止连接器搜索宿主系统的库目录”，这个选项只是控制ld的库搜索路径，而根据Skymoon说的ld和ld-linux.so.2的区别，那么这个路径就跟ldconfig，ld-linux.so.2搜索库的路径应该没关系啊，你认为了？

恩，就是 --with-lib-path，我写漏了。。。

应该是没关系的，，ldconfig 是 glibc 的部件。。

augustusqing

哈哈，昨天我对ld搜索库的路径和顺序的理解很多错误啊
还把Makefile变量LIB_PATH理解成环境变量，好差劲
汗颜。。。

dyfduck

Post by augustusqing
哈哈，昨天我对ld搜索库的路径和顺序的理解很多错误啊
还把Makefile变量LIB_PATH理解成环境变量，好差劲
汗颜。。。

悄悄告诉你一下，我按你的思路去理解楼主的文章，恰好就是在你对于LIB_PATH的说法让我抓了一夜的狂~~~~晕~~~

augustusqing

Post by dyfduck
悄悄告诉你一下，我按你的思路去理解楼主的文章，恰好就是在你对于LIB_PATH的说法让我抓了一夜的狂~~~~晕~~~

哈哈，悄悄话收到！艾，GCC博大精深啊

dec1985

Post by augustusqing
对Skymoon兄的文章我学习了一天多，确实够得上深入思考啊
现在才勉强有点顺序感了，我的理解是
say.c源程序调用say.so共享库到test可执行文件，到test的执行，把这个过程分为三步走
第一步：  gcc -c say.c                                     -->    say.o    编译
第二步：  gcc test.c say.o ./say.so -o test     -->    test       链接
第三步：  ./test                                                      把test载入,获得test内存映象
第一步，没话说，gcc是主角
第二步，ld是主角，ld是binutils中安装的工具，他只要搜到了say.so,就能生成test，而gcc test.c ./say.so -o test中的./路径信息，跟ld的LIB_PATH,configure的--with-lib-path(应该就是幻想版主的--lib-path),还有gcc中的-lsay（必须以libsay.so的文件名，存在于ld的默认搜索路径下，就是ld –verbose|grep SEARCH中列出的目录下），-L/aaa/bbb(libsay.so存在/aaa/bbb),这里5个路径信息（欢迎补充），都是告诉ld如何搜索say.so(libsay.so)。至于生成的可执行文件test用哪个ld-linux.so.2由gcc的spec规定，存在于test程序头的PT_INTERP类型的段（segment）中，与ld无关。ld找say.so的顺序我认为无关紧要，因为ld的工作是它找到相应库和库中的函数名后，在可执行文件里标记这些符号，而整个事情最关键的在于程序载入时ld-linux.so.2找到的say.so.

给你补充一下,凑个数哈,ld寻找动态库的时候还要包括./
gcc test.c say.so -o test
是吧?

augustusqing

当前目录肯定是 要 搜索的，但关键是怎样的顺序了