最近项目正经历着一次更新,一系列编译工具都进行了大版本的升级,随时而来的是,原本正常编译的代码出现了大量的warning,最终编译失败,其 中一个问题困扰了比较长的时间,虽然fix的方法不难,但是一直不清楚根本原因,通过大量的google,终于找到的原因,特地记录一下。
先把主要的参考文章写一下:
Understanding DSO link change
Tool Chain Transition
主要是下面这行错误:
error adding symbols: DSO missing from command line
场景是:
- 我们有一个shared libA中,定义了函数foo()
- 另一个静态库libB显示地链接了libA
- 一个可执行文件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中也举了一个相应的例子。
时间: 2024-10-12 18:46:50