linux 下 奇怪的 动态库 依赖问题

 

总结如下:
1)当你在编译生成静态库的时候, 只需要相应的依赖库库的头文件即可. 只有在你想生成so,或可执行文件 时, 才需要lib库.
   对于你没有用到的lib, 但是不包含又编译失败, 那么只包含其头文件即可.
2)如果你同时使用了多个库,而库之间又相互依赖,那么在链接是,把最底层的依赖库放在最右侧.否则可能会链接失败
3)如果我已经把最底层的库放在最后边了,还是链接失败怎么办?
请检查是否依赖了同名的其他的库. 自己查看链接库的路径

对1)的说明
如果你不用该so, 那么你就不要将他的lib放在你的makefile里面! 否则运行时会依赖该so的.
案例:

      我的cgi, cp到正式环境, 居然开始依赖 mysql的so, 奇怪, 我的项目中并无用到mysql. 然后,makefile中去掉mysql相关的 头文件, 以及lib, 却发现 没有mysql的头文件还编译不过去, 因为我用的另一个库tlib用到了mysql, fuck, 怎么办?

答案: 只把mysql的头文件 路径等加到 makefile里面, 这样gcc有了头文件至少可以编译过去. 然后, 在连接的时候, 由于你的代码并没有真正用到mysql, 所以不会去连接mysql相关的东东. 所以, 直接链接通过.

分析: 虽然tlib用到了mysql, 但是由于tlib是一个非常庞大的静态库, 其里面依赖的内容非常多, 而我只用到了tlib里面的一小部分功能(且不含mysql), 所以, 我只需把mysql头文件加上即可. 链接时时不会真正用到mysql的没有lib. 除非我用到tlib里面的相关mysql接口.


如果你想生成静态库:
linux下, 如果你的项目(是个静态库)的依赖某个库(不管动态库还是静态库), 当你在编译生成静态库的时候, 只需要相应的依赖库库的头文件即可.
(因为, linux的.a本身就是一堆.o的集合, .o也就是一堆cpp文件的编译结果, 并没有开始执行链接)
举例:
  libcomm.a 就是这样, 虽然依赖的很多的库, 比如html_template, mysql, MARKUPSTL, 但只需他们的头文件即可.
USED = /
       MARKUPSTL /
       NETCLIENTEX /
       HTML_TEMPLATE /
       TLIB /

INC  = /
    $(foreach i, $(USED), $(INC_$(i)))

#看到没, LIB 为空!!!
LIB  =


如果你想生成so,或可执行文件
1)那么你必须包含上你需要的lib, 而且, 如果你 通过 -lxxx, 那么gcc默认后首先尝试链接 xxx的动态库libxxx.so.1(libxxx.so.1是libxxx.so的符号链接文件, 并不是真正的libxxx.so, 但是会指向libxxx.so), 如果找不到libxxx.so.1，然后寻找xxx的静态库libxxx.a.
2)同时, 如果你没有用到某个lib的话, 一定不要包含其lib, 如果编译不通过, 最多只需包含其头文件即可.
就像我上面的案例一样, 没有用到mysql, 却包含而来mysql的lib, 导致在运行机上找不到 mysql.so 而运行失败, 去掉mysql的lib, 只保留mysql的 头文件, 可以链接过去, 并且可以正常运行.

2)如果你同时使用了多个库,而库之间又相互依赖,那么在链接是,把最底层的依赖库放在最右侧.否则可能会链接失败
  g++ -o $(target) liba libb libc
  如果liba 依赖libb, libb依赖libc, 那么请把libc放在最后面.
  如果 g++ -o $(target) liba libc libb会导致libb的链接失败. 
  有一种情况离开,liba也依赖libc,并且依赖关系和libb对libc的依赖的接口一样, 那么把libc放在中间不会报错,但最好不要这么做.
 
3)如果我已经把最底层的库放在最后边了,还是链接失败怎么办?
   检查是否连接到了相同名字的其他的库.  我又一次就是如此,系统系统中存在多个network的库, 虽然我把正确的network库放在了最后面,但是由于其他库包含路径下也有老的同名的network库,导致我链接失败.