链接extern声明与定义：跨编译单元全局变量的链接解析流程咨询

针对你给出的t.c、tt.c编译场景，以Linux下GCC默认调用的GNU ld链接器为例，对x的解析没有抽象的“扫描玄学”，是完全基于符号表匹配的实打实的流程：

具体的逐步骤匹配过程 #

当你执行gcc tt.o t.o -o out生成可执行文件时，链接器会严格按照命令行传入目标文件的顺序处理：

• 首先加载第一个目标文件tt.o：这个文件里的int x =4;是带外部链接属性的已定义全局符号，有明确的类型（int）、大小（32位环境下4字节）、存储位置（全局数据段）。链接器会直接把这个x的所有定义信息，登记到自己维护的已定义全局符号表中。
• 接着加载第二个目标文件t.o：这个文件的main函数里对x的访问是一个未定义的外部引用——因为t.c里仅通过extern int x;做了声明，没有为x分配实际的内存空间。链接器处理到这个引用时，会直接查询刚才建立的已定义全局符号表，立刻找到tt.o中登记的x定义，随后给t.o里对应的重定位项写入修正信息：把对x的访问地址，替换成tt.o中x最终在内存里的实际虚拟地址。
  到这里x的整个解析流程就完成了，没有多余的前置收集步骤。

关于“两遍扫描”的常见误解 #

你猜测的“先收集所有带外部链接属性的全局变量，再回头匹配待解析的外部引用”的流程，是早期链接器的简化实现，现代链接器已经做了针对性优化：

• 现代链接器确实存在两个核心处理阶段，但不是你描述的全量收集逻辑：
  1. 边遍历边匹配的收集阶段：逐文件读取目标文件，把碰到的已定义全局符号加入已定义表，把碰到的未定义引用加入待匹配表，一旦发现待匹配的符号能在已定义表里找到，立刻完成关联，根本不需要等所有文件都扫完。
  2. 地址重定位阶段：把所有需要保留的代码段、数据段按照规则排布到最终可执行文件的统一虚拟地址空间中，把之前所有关联好的符号引用，全部替换成对应的实际内存地址，完成可执行文件的组装。
• 这种优化的核心目的是避免冗余加载：如果某个已定义的全局符号从来没有被任何地方引用，链接器会直接丢弃这个符号对应的代码/数据段，不会把它塞进最终的可执行文件里，大幅减小最终生成文件的体积。

这里补充一个新手特别容易踩坑的细节：这个按顺序匹配的逻辑在静态库链接时会暴露得非常明显——如果你把自定义的代码打包成静态库，一旦把命令行里库的顺序写反，链接器扫完前面的文件、再扫到静态库的时候，就会因为已经没有待匹配的未定义引用，直接跳过库里的x定义，最后报undefined reference的错误。

• 整个流程的异常判定规则也非常直接：等所有输入的目标文件、静态库都处理完，如果还有待匹配的未定义引用找不到对应定义，就抛出未定义引用错误；如果同一个符号在多个目标文件里出现了强定义（比如多个文件都写了同名字的全局初始化变量），就抛出多重定义错误。

内容的提问来源于stack exchange，提问作者samuelbrody1249