一个关于loader如何在运行时定位库的问题

链接器在编译时只做最less量的工作; 它只logging程序需要的库例程和库中例程的索引名称或编号。 （ 来源 ）

所以这意味着ld.so不会检查数据库中的所有库，只检查应用程序本身logging的那些库，也就是说只检查由gcc -lxxx指定的那些库。

这与我以前的知识相矛盾， ld.so会逐个检查数据库中的所有库，直到find。

确切的情况是哪一个？

如何与两个具有许多冲突函数的共享库链接

更新共享库而不重新启动进程

共享对象的开销

在Linux上使用C ++编写的纯C项目库？

LSB AppChecker：GCC与未使用的库链接

为什么gcc强制PIC为x64共享库？

了解dynamic链接如何在UNIX上工作

如何确定文件是否已经被加载？

用两个共享库dlopen，导出符号

依赖于相同静态链接库的可执行文件和共享库

我会刺探回答这个问题…

在链接时，链接器（而不是ld.so）将确保链接在一起的.o文件的所有符号都被程序所链接的库所满足。 如果这些库中的任何一个都是动态库，那么它也将检查它们所依赖的库（不需要将它们包含在-l列表中）以确保满足那些库中的所有符号。 它会递归地做到这一点。

只有链接时通过提供的-l参数直接依赖的库将被记录在可执行文件中。 如果库本身声明了依赖关系，那么这些依赖关系将不会被记录在可执行文件中，除非这些库在链接时也用-l标志指定。

链接发生在运行链接器时。 对于gcc，这通常看起来像gcc ao bo co -lm -o myprogram 。 这通常发生在编译过程的最后。 在封面下面通常会运行一个名为ld的程序。 但是ld与ld.so （这是运行时加载器）完全不一样。 尽管它们是不同的实体，但是它们的命名也是相似的，因为它们在不同的时间做类似的工作。

加载是运行程序时发生的步骤。 对于动态库，加载程序会执行很多链接器在使用静态库时会执行的作业。

程序运行时，ld.so（运行时加载程序）实际上将可执行文件上的符号挂接到共享库中的定义。 如果共享库依赖于其他共享库（库中记录的事实），那么它也将加载这些库并将它们连接到它们。 如果毕竟这样做，还有未解决的符号，加载器将中止程序。

所以，可执行文件说明它直接依赖哪个动态库。 这些库中的每一个都说他们直接依赖于哪个动态库，等等。 加载器（ld.so）使用它来决定寻找符号的库。 它不会通过随机搜索“数据库”中的其他库来找到合适的符号。 它们必须位于依赖链中的库中。