1 前言
这两天在编写一个插件系统Demo的时候，发现了个很奇怪的问题：插件加载器中已经链接了ld库，但是应用程序在链接插件加载器的时候，却还需要显式的来链接ld库。否则就会报：DSO missing from command line。这个报错翻译过来就是没有在命令行中指定该动态库。
这个报错就很搞事了，你说你明明知道需要哪个库，为什么不直接帮我链接呢，非得我显示的在命令行中指定呢？
2 现象描述
问题可以简单描述为：当链接可执行文件时，依赖于libA.so，而libA.so又依赖于libB.so，而且可执行文件中还直接调用了libB.so中的函数，那么此时链接就会出现错误。
2.1 问题发生的前置条件
- libA.so在编译过程中显式的链接了libB.so
- 可执行文件中使用了libB.so的函数
- binuntils版本 ≥ 2.22
2.2 Talk is cheap. Show me the code
话不多说，先看看可以复现改问题的代码吧
libB.so的源码：
#include <stdio.h>
int funB1(){
printf("in funB1");
return 0;
}
int funB2(){
printf("in funB2");
return 0;
}
这里面有两个函数：funB1和funB2。
其中funB1函数会被libA调用，而funB2会被可执行文件调用。
编译libB.so:
$ gcc libB.cpp -fPIC -shared -o libB.so
libA.so的源码：
#include <stdio.h>
int funB1();
int funA1(){
printf("in funA1 \n");
funB1();
return 0;
}
该库中只有一个函数funA1，该函数在内部调用了libB中的funB1函数。且该函数会被可执行文件调用。
编译libA.so:
$ gcc libA.cpp -fPIC -shared -o libA.so -Wl,-rpath=./ -L./ -lB
main.cpp的源码：
int funA1();
int funB2();
int main(){
funA1();
funB2();
return 0;
}
编译main.cpp:(复现错误的编译方法)
gcc main.cpp -L./ -lA
当我们按照上面的指令编译main.cpp的时候，便报错了。
/usr/bin/ld: /tmp/ccDQXTKy.o: undefined reference to symbol '_Z5funB2v'
.//libB.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
（问号.jpg）这，这GCC不是搞事吗，你明明知道我需要连接libB.so为啥就不帮我链接上去呢？难道我libA.so没有指明要使用libB.so?我们使用下面的指令来看一下
$ ldd libA.so
得到如下信息：
linux-vdso.so.1 => (0x00007ffd09def000)
libB.so => ./libB.so (0x00007fc513d7d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc5139b3000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc514181000)
明明libA.so已经显式的指明我要依赖libB.so了，那为啥在编译main.cpp的时候链接了libA.so，GCC却还要我们显式的链接libB.so呢？
3 答案
答案很简单，那就是GCC就是想要你显式链接呗。（你是编译器，你牛好吧。）那这是为啥呢？
官方一点的答案就是，自从binutils 2.22版本以后，如果你在程序中使用了你依赖的动态库所依赖的动态库中的函数时，你就必须显式的指定你依赖的动态库所依赖的动态库。
说那么多，我们更想知道的是，通过修改什么参数可以解决这个问题呢？因为你可能不想在编译程序的时候要把动态库所依赖的所有动态库都显示链接一遍。
4 究极答案
实际上，这是binutils在2.22版本以后，默认把--no-copy-dt-needed-entries这个选项打开了。当打开了这个选项的时候，编译器在链接的时候是不会递归的去获取依赖动态库的依赖项的，于是就会出现上述的问题。关于该配置项的详细说明如下：
--copy-dt-needed-entries
--no-copy-dt-needed-entries
This option affects the treatment of dynamic libraries referred to by DT_NEEDED tags inside ELF dynamic libraries mentioned on the command line. Normally the linker won't add a DT_NEEDED
tag to the output binary for each library mentioned in a DT_NEEDED tag in an input dynamic library. With --copy-dt-needed-entries specified on the command line however any dynamic
libraries that follow it will have their DT_NEEDED entries added. The default behaviour can be restored with --no-copy-dt-needed-entries.
This option also has an effect on the resolution of symbols in dynamic libraries. With --copy-dt-needed-entries dynamic libraries mentioned on the command line will be recursively
searched, following their DT_NEEDED tags to other libraries, in order to resolve symbols required by the output binary. With the default setting however the searching of dynamic
libraries that follow it will stop with the dynamic library itself. No DT_NEEDED links will be traversed to resolve symbols.
大概意思就是，跟在--no-copy-dt-needed-entries它后面的库都不会遍历其依赖项，使用--copy-dt-needed-entries则相反。也就是使用下面的指令来编译mian.cpp就可以避免该问题了。
$ gcc main.cpp -L./ -Wl,--copy-dt-needed-entries -lA
题外话
在Linux的ELF文件中，如果依赖于其他的动态库，那么改ELF文件会存在一个
.dynamic的段，这个段里面会记录其依赖的动态库信息，其标志位为DT_NEEDED。
最近为公司开发的开源超级轻量级插件系统（https://github.com/HSRobot/HPlugin），欢迎大家交流讨论。
5 参考文档
1，DSO missing from command line原因及解决办法：https://segmentfault.com/a/1190000002462705
2，折腾gcc/g++链接时.o文件及库的顺序问题： https://www.cnblogs.com/OCaml/archive/2012/06/18/2554086.html#sec-1-4-1