【原创】Linux下编译链接中常见问题总结
前言
一直以来对Linux下编译链接产生的问题没有好好重视起来，出现问题就度娘一下，很多时候的确是在搜索帮助下解决了BUG，但由于对原因不求甚解，没有细细研究，结果总是在遇到在BUG时弄得手忙脚乱得。
甚至有时候为了一个问题查了半天的资料，好不容易解决了，却因为没有记录下来或者没有弄清楚真实原因，结果第二次碰到还是要去重复前次的折腾，很是尴尬无奈。
虽然，同样的错误信息，其产生的原因不一而足，但是，总结一下终归是好的，使不知变知之，只要不在同一件事情上重复同样的错误，发现的问题越多，解决的问题越多，未知的问题也就越少，不是吗？
针对Linux下编译链接的问题，网络上不乏有牛人经典的原创好文，不得不说，现在网络的发达让人们：不足出户，就可以万事不求人。废话少说，言归正传罢：
一，解决思路
总结了一下当BUG出现时，一般解决的思路：
（1）仔细查看BUG信息
很多问题可以从BUG信息本身就可以知晓原因的，不要忽略这个基础而有有效的方法。
（2）深入挖掘BUG信息上现的提示信息，
这是产生BUG的依据，深入研究一下具体细节，往往可以分析到BUG产生的原因。
（3）寻求同事及网络的帮助，找到答案。
二，几个概念：
2.1） 环境变量：LD_LIBRARY_PATH
用于指定动态库的除了默认目录之外的其它搜索目录，
注意：LD_LIBRARY_PATH最后如果带":"号则意味着多出一个搜索目录，这个目录代表的是运行程序的当前目录。
LD_LIBRARY_PATH=path1:path2:path3
与
LD_LIBRARY_PATH=path1:path2:path3:
是有区别的，区别就在后者多了一个搜索路径：当前路径
2.2）多级嵌套依赖：
如果LibA引用（依赖）LibB，我们说LibA是“引用库”，LibB是“被引用库”。
如果“被引用库”是内部库，那么在制作“引用库”时只需要把“被引用库”包含进来即可。
如果“被引用库”是外部库，那么在制作“引用库”时要把“被引用库”和其所依赖的库一起包含进来，不然当“被引用库”做“引用库”用时，会出现找不到库的问题。
举例来说：
这里为了表述方便，这里[]内容为内部程序及库，{}内容为外部依赖库，并把加载依赖库Lib的App简写成: App(Lib)，
现在有一个级嵌套依赖关系：[InnerApp<1-N>] --> [InnnerLib] --> {OuterLib} -->{outerLibDep<1-N>}
InnerLib1(OuterLib) is OK ==》 InnerApp(InnerLib) is NG
InnerLib1(OuterLib, OuterLibDep<1-N>) is OK ==》 InnerApp(InnerLib) is OK
2.3）头文件与库文件的搜索目录
这里只说结论：
库文件的默认搜索目录：
结论：
动态库的搜索路径搜索的先后顺序是，（大致是这样子）：
1.编译目标代码时指定的动态库搜索路径；
2.环境变量LD_LIBRARY_PATH指定的动态库搜索路径；
3.配置文件/etc/ld.so.conf中指定的动态库搜索路径；
4.默认的动态库搜索路径/lib；
5.默认的动态库搜索路径/usr/lib。
应注意动态库搜寻路径并不包括当前文件夹，所以当即使可执行文件和其所需的so文件在同一文件夹，也会出现找不到so的问题，类同#include <header_file>不搜索当前目录
头文件的默认搜索目录：
1.由参数-I指定的路径(指定路径有多个路径时，按指定路径的顺序搜索)
2.然后找gcc的环境变量 C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH
3.再找内定目录
/usr/include
/usr/local/include
/usr/lib/gcc-lib/i386-linux/2.95.2/include
/usr/lib/gcc-lib/i386-linux/2.95.2/../../../../include/g++-3
/usr/lib/gcc-lib/i386-linux/2.95.2/../../../../i386-linux/include
库文件，但是如果装gcc的时候，是有给定的prefix的话，那么就是
/usr/include
prefix/include
prefix/xxx-xxx-xxx-gnulibc/include
prefix/lib/gcc-lib/xxxx-xxx-xxx-gnulibc/2.8.1/include
三，几种常见的链接错误及产生原因
3.1） undefined reference to symbol '<AAA>::<func>'
说明：引用符号未定义，
原因：编译选项中-l参数加载的依赖库不全，因为库文件不存在，所以找不到库中的任何接口。
如果依赖库接口是被库间接调用，你可以查看“被引用库”的-l选项，如果没有依赖库的话就加进来。
3.2) /usr/bin/ld: <AAA>: undefined reference '<BBB>::<func>'
说明：引用接口未定义。
原因1：编译选项问题：
-l中遗漏了该库，也就是没有库的lib文件，
-l中库名有白字，当然也找不到.so文件了。
备注：在添加-l选项下，头文件和库文件都存在了，这至少保证了文件资源是没有问题的，
如果编译器找不到Lib文件的话，将会提示，/usr/bin/ld: cannot find -lpkg，这时候你再添加-L选项指定库目录即可
原因2：库.h文件与库.so文件不匹配，.h文件有接口声明，但.so文件没有做接口实现。
造成这种原因有很多种因素：
（1）.h文件没问题，.so文件有问题
.so文件存在于多个目录且版本不同，系统在搜索.so文件时优先在错误的目录下找到了.so文件，引发在链接阶段报错。
（2）.so文件没问题，.h文件有问题
在修改代码时，如果不小心更改了.so所依赖的.h文件，这也会在链接或运行阶段引发一些莫名其妙的异常。。
（3）跨系统移植时库移植不完整，
比如说centos的程序放到rhel上运行，copy了库文件却没有copy头文件，用centos的ACE.so文件与rhel的ACE.h文件匹配就会出现这种问题。
原因3：引用的接口未导出
造成这种原因也有很多种因素：
（1）跨语言调用接口，
比如说在C++应用程序中调用C语言库，就要在调用接口前添加导出符号（"extern C"），不然会引起匹配问题。
（2) 接口未导出，
比如说你在接口声明处没有添加导出符号("extern")，外部程序调用时该接口时当然是找不到了。
检查一下声明和定义是否一致，哪怕是函数中的参数类型不一致，是否只有只有声明没有定义，缺少其中任何一样，接口一样是无法正常导出的。
辅助命令：ldd 检查依赖库及对应目录
3.3）/usr/bin/ld: warning: <AAA>.so, needed by <BBB>.so, not found (try using -rpath or -rpath-link)
说明：多级嵌套依赖：
原因：见概念一节内容
3.4）symbol lookup error: ../lib/xxx.so: undefined symbol:<AAA_>
说明：找不到接口符号
原因：在so库中没有找到某接口符号，ldd一下，检查App的依赖库，目录及版本是否正确？
