DSO missing from command line原因及解决办法

renweihub 120 1月5日 发布

• 推荐 1 推荐
• 收藏 3 收藏，5.2k 浏览

最近项目正经历着一次更新，一系列编译工具都进行了大版本的升级，随时而来的是，原本正常编译的代码出现了大量的warning，最终编译失败，其中一个问题困扰了比较长的时间，虽然fix的方法不难，但是一直不清楚根本原因，通过大量的google，终于找到的原因，特地记录一下。

先把主要的参考文章写一下：
Understanding DSO link change
Tool Chain Transition

主要是下面这行错误：

error adding symbols: DSO missing from command line

场景是：

1. 我们有一个shared libA中，定义了函数foo()
2. 另一个静态库libB显示地链接了libA
3. 一个可执行文件bin_c显示地链接了libA

那么问题来了,如果bin_c中调用了函数foo(),那么编译能不能通过？
在binutils<2.22时，ld正常完成了，bin_c对于foo的调用经由libB，传递到了libA，链接成功。
但是当binutils>=2.22时，编译出错了，ld会报上面的错，告诉你foo这个symbol解析不到，这时，我们需要编译bin_c时，显示地链接libA才可以通过。
binutils2.22开始，其中的ld开始把--no-copy-dt-needed-entries默认打开，这样一来，ld不会再自动递归地解析链接的lib，而需要由用户来一一指定。

PS:检查binutils的版本，方法很简单:

ld -v

这样做的好处在于当libA有变化，甚至foo接口发生变化时，编译时就能报错。

另外，还以一个ld的选项--allow-shlib-undefined,作用是允许在动态库中存在未解析到的函数symbol，至于理由可以自行查看man ld，因为有些项目就是在运行时才能决定使用的动态库， ld的manual中也举了一个相应的例子。

时间仓促，没有贴代码上来，而且一定还有没有深入到的地方，日后再来完善，如果有不对的地方，欢迎指正！