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

 阅读约 3 分钟

最近项目正经历着一次更新,一系列编译工具都进行了大版本的升级,随时而来的是,原本正常编译的代码出现了大量的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中也举了一个相应的例子。

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

阅读 74k更新于 2015-01-05

推荐阅读
renweihub
用户专栏

learner, coder

0 人关注
4 篇文章
专栏主页
目录