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