为何GNU ld链接器无法记录所有已识别的符号？

ld的链接顺序特性 #

GNU ld在链接时对文件顺序要求严格，依赖库必须放在被依赖库之后——这和直觉完全相反。比如file1.a里的函数调用了file2.a的函数，链接命令得写成ld ... file1.a file2.a。原因是ld只会从后续文件中提取当前未解析的符号，不会提前扫描所有文件的符号。

循环依赖的特殊处理 #

如果出现循环依赖，比如file1::fn1()调用file2::fn2()，同时file2::fn2()调用file1::fn3()，就得重复指定库：ld -lfile1 -lfile2 -lfile1。甚至CMake专门加了LINK_INTERFACE_MULTIPLICITY参数来应对这种场景，这明显是ld设计限制下的妥协方案。

不少人会疑惑：为什么ld不先扫描所有文件构建完整的符号索引，再统一进行符号解析？以下是ld采用当前设计的核心考量：

设计背后的核心原因 #

• 历史资源限制：ld的设计起源于早期Unix系统，当时内存和存储资源极度匮乏。一次性扫描所有文件并构建全局符号索引会占用大量内存，在当年的硬件条件下根本无法实现。这种"按需加载未解析符号"的方式能最小化内存占用，让链接过程在有限资源下正常运行。
• 链接效率优化：即使在硬件资源充足的现在，这种设计在处理大型项目时仍有优势——ld只需要关注当前未解析的符号，无需处理所有符号，减少了不必要的扫描和计算，能有效加快链接速度。
• 符号解析的确定性：按顺序处理文件能保证符号解析规则的确定性。如果采用全局索引模式，当多个文件存在同名符号时，需要额外规则来确定优先级；而顺序处理的逻辑下，先遇到的符号会被优先选用，规则简单明确，契合早期Unix"简洁、明确"的设计哲学。
• 适配静态库特性：静态库是目标文件的归档包，ld处理静态库时只会提取包含未解析符号的目标文件，这种按需提取的逻辑和顺序处理机制天然契合，能避免链接不必要的目标文件，最终减小可执行文件的体积。

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