gcc 链接器工作原理
问题
在编译源代码为可执行文件的时候，如果需要链接静态库，我们可能会遇到如下错误提示：
: In function 'main' // 或者其他函数名
(.text+0x7): undefined reference to "foo" // 或其他变量名
编译出现了失败，提示找不到某些函数或变量的定义。但经过仔细检查核对，发现我们已经在编译命令中，提供了完整的库名称和库路径，因此找不到问题出在哪里
原因分析
出现这种问题的原因，很可能是在于静态库之间存在相互依赖，以及链接器的工作方式与我们预期不同造成的，在找出解决办法前，我们可以先了解一下编译器的工作流程
编译及链接流程
假设我们的编译命令如下，
gcc f.c libx.a liby.a libz.a
编译
编译器检查命令行中列出的文件，如果发现有 .c 文件，先将所有 .c 的文件翻译成 .o 文件，确保最后只剩下 .o 文件和 .a 文件
链接
链接器出场，从左到右开始扫描，进行符号解析工作
1. 建立三个空的集合
E 空文件集合：放入该集合中的文件，后续将用于合成最终的可执行文件；
U 空符号集合：用来存放在当前目标文件中引用，但没有定义的符号；
D 空符号集合：用来存放 E 集合的文件中那些已经定义的符号
注：E\U\D，此处分别表示 Empty, Undefined, Defined
2. 从左到右依次扫描每一个文件
假设当前扫描到的第一个文件为 f
如果 f 是一个 .o 结尾的目标文件
将 f 放入 E 文件集合中
将 f 文件中定义的符号添加到 D 符号集合中
将 f 文件中引用却未定义的符号，添加到 U 符号集合中；
如果 f 是一个 .a 结尾的存档文件
注：存档文件即静态库文件，它由一个或多个目标文件做为成员打包组成的，假设 f 中的第一个目标文件叫 m
第一步：匹配
检查 U 集合中未定义的符号是否在 m 的符号表中
如果没有
- 抛弃 m，继续扫描 f 中的下一个成员文件；
如果有
- 将 m 加入 E 集合中；
- 将 m 中定义的符号添加到 D 符号集合中
- 将 m 中引用却未定义的符号，添加到 U 符号集合中；
第二步：重复
继续扫描 f 中的下一个成员文件，重复上一步的匹配过程，直到 U 和 D 都不再发生变化；
第三步：筛选
将所有在 f 中但却不包含在 E 集合中的目标文件成员，抛弃；
3. 重复上一步，直到扫描完所有的输入文件
4. 检查 U 符号集合
如果 U 非空，则抛出错误，表示存在未定义的引用，并终止；
如果 U 为空，则合并和重定位 E 文件集合中的所有目标文件，生成最终的可执行文件，成功；
问题解决思路
在了解了编译器工作的流程后，我们会发现，当我们有多个静态库需要链接时，如果这些静态库之间存在依赖关系时，则对静态库的放置顺序是有要求的，即被依赖的库必须放置在依赖者的后面，否则链接器就会找不到未定义的符号；
例如 x.a 中引用了 y.a 中定义的函数，则 x.a 必须放置在 y.a 的前面，即正确的顺序应为
gcc main.c libx.a liby.a
库的顺序规则
- 惯例：将所有库文件放在命令行的末尾，即在所有 .c 和 .o 文件的后面
- 如果所有库之间相互独立，那么天下太平，正常编译，回家睡觉
- 如果所有库之间存在引用，那么需要排列这些库的顺序
- 确保被引用的库排在引用者的后面
- 如果二者相互引用，则需要重复输入库名
例如：假设 foo 引用 x 库，x 库引用了 y 库，y 库又引用了 x 库，即
foo -> x -> y -> x，那么编译命令的顺序如下，其中 x 库需要输入两次
gcc foo.c libx.a liby.a libx.a
