《程序员的自我修养》第四章静态链接是我读这本书时划重点最多的章节之一。很多人写了好几年代码直到某天编译链接阶段冒出一堆 undefined reference 或者 multiple definition才意识到自己对链接这件事其实只停留在表面。这一章恰恰把静态链接的完整过程拆开了从空间分配、符号决议到重定位再到静态库的按需链接每一环都能对应到真实的编译报错和排查手段。想弄懂链接器到底在想什么的人想搞清楚 .a 文件为什么有时链接不上的人甚至是准备进一步学动态链接的读者这一章都值得反复读几遍。静态链接听起来像是编译器的一部分实际上编译和链接是两个完全分离的阶段。编译器只负责把源码翻译成目标文件.o真正把多个目标文件缝合成可执行文件的是链接器ld 或者 GCC 背后的 collect2。这一章讲的就是链接器缝合的完整过程。下面我把读这一章的收获、实际踩过的坑、以及平时排查链接问题的经验整理一下希望能帮你少走一些弯路。1. 静态链接到底在做什么1.1 链接器接手之前编译器留下了什么一个 C 文件经过预处理、编译、汇编之后生成一个目标文件。这个目标文件里最重要的就是各种段section.text放代码.data放已初始化的全局变量和静态变量.bss只是占位符描述未初始化全局变量需要多大空间。加上一个符号表symbol table记录这个目标文件里定义了哪些符号和引用了哪些外部符号。换句话说每个 .o 文件都是半成品里面的机器指令已经生成完毕但所有涉及外部地址的地方都是空着的等着链接器来填。比如你的代码里调用了外部函数编译器并不知道那个函数最终会在哪个地址只能先在 call 指令里放一个占位值同时往重定位表里记一笔这里引用了一个外部符号需要在链接阶段修正。理解这一点特别重要。很多人以为编译过了就万事大吉结果链接报错时一头雾水。其实编译通过只说明语法和类型检查过了目标文件之间的拼图逻辑还没核对过链接器才是最后那个检查全局拼图的人。第四章开篇就点明所谓静态链接本质上就是把多个目标文件打包成一个可执行文件并解决它们之间的相互引用。1.2 两条主线空间分配 符号解析与重定位链接器做的工作可以拆成两大步。第一步是空间与地址分配把所有目标文件的同名段合并起来比如 3 个 .o 文件的.text段拼成一个大的.text段.data段同理然后为合并后的每个段确定它在最终可执行文件中的虚拟地址。这一步相当于先画好整栋楼的楼层平面图确定每个房间在什么位置。第二步是符号决议与重定位有了每个符号的最终地址之后链接器扫描所有重定位条目把指令里那些占位值改成真实的地址。这一步相当于照着平面图去接水电线路——每个插座、每个开关都要接到正确的房间。这两步是有先后依赖的。你不可能在不知道最终地址的情况下做修正所以地址分配必须先完成。书中用两遍扫描来描述这种工作模式实际上的链接器也确实会先做符号收集和地址布局的预处理再做真正的重定位写入。这里我建议你用一个小例子感受一下写两个简单的 C 文件一个调用另一个的函数然后用gcc -c分别编译再用readelf -r看目标文件里的重定位表。你能非常直观地看到哪个位置引用了外部符号、引用类型是什么。这一步做完后面所有概念都会好理解很多。2. 空间与地址分配链接器的第一步2.1 相似段为什么要合并不同目标文件的同名段会被合并到一起这背后的原因不只是整洁这么简单。可执行文件加载进内存时操作系统是按页进行权限控制的代码段需要可读可执行数据段需要可读可写。如果把所有代码放在一起、所有数据放在一起那么整个文件可以用很少的权限类别来管理加载时也方便按区域映射。书里把这个过程讲得很清楚链接器会把各个 .o 的.text合并成一个可执行文件的.text把.data合并成可执行文件的.data。这样做的好处是最终可执行文件的布局很紧凑加载器只需要把几个连续的段映射到内存里就能让程序跑起来。想象一下如果每个 .o 的代码段都单独占一块区域执行文件里会散落几十个小段无论对加载效率还是内存利用率都是灾难。另外.bss段比较特殊它本身不占文件空间只记录大小。合并时链接器把所有未初始化全局变量的空间需求加到一起生成一段零初始化的区域。你可以用readelf -S看一下可执行文件通常会发现.bss的 Size 可能不小但它在文件里没有对应内容这正好对应了未初始化全局变量默认值 0的实现方式。2.2 可执行文件的地址从哪来链接器在分配地址时并不是随便找一个地址就开始排。Linux 下 x86-64 的可执行文件默认代码段往往从虚拟地址0x400000附近开始这个默认值来自链接器脚本里的配置。链接器会把合并后的各个段按顺序排布在指定基址之后并给每个段、每个符号分配具体的虚拟地址。这里有一个很容易踩的认知误区编译期生成的每个 .o 文件里自己段的地址都是从 0 开始的相对地址。所以单个目标文件里的指令跳转很多用的是段内偏移而一旦多个段合并成一个段原来段内的偏移依然有效因为段内相对位置没变。真正要改的是跨目标文件的符号引用比如 A.o 里调用 B.o 里的函数这个引用在合并后的可执行文件里需要指向 B 函数在全局虚拟地址空间中的最终位置。书里有一个很有价值的细节在可执行文件里每个段都会有明确的虚拟地址VMA和加载地址LMA这两个地址在很多嵌入式场景下不一样但在 Linux 普通应用里通常是相同的。如果你以后有机会做裸机程序或者写操作系统引导代码VMA 和 LMA 的区别就会变得极其重要。我在读第四章时就把这段反复看了几遍因为它是理解后续链接脚本章节的基础。2.3 用 readelf 观察地址分配结果学这一节最好的方式不是背概念而是动手看。编译一个小程序后执行readelf -S你会看到每个段的 Address 列那些地址就是链接器分配好的虚拟地址。对比编译生成的 .o 文件你会发现 .o 里段的地址全是 0 或者小块偏移而可执行文件里已经是完整的地址了。再看readelf -l也就是程序头program header它描述的是段如何加载到内存。你会看到 LOAD 类型的条目每个条目指定了文件的某个区域应该映射到哪个虚拟地址以及需要什么权限。这个视角非常直观可执行文件不是一串孤立的字节而是被划分为若干加载区域的文件。理解了段section和程序头segment的区别你才算真正摸到 ELF 格式的骨架这也是第四章反复强调的基础认知。3. 符号决议与重定位链接器的核心动作3.1 强符号、弱符号与 multiple definition符号决议解决的核心问题是多个目标文件里出现了同名的符号到底该用哪个。C 和 C 里普遍存在的规则是强符号strong symbol指的是函数、已初始化的全局变量弱符号weak symbol指的是未初始化的全局变量在某些编译器约定下。当多个目标文件定义同名符号时链接器按以下规则处理两个强符号同名——直接报 multiple definition 错误一个强符号一个弱符号——选择强符号两个弱符号同名——选择其中一个通常是占用空间较大的那个。我在实际开发中遇到最多的就是两个 .o 文件里都定义了同一个全局变量。比如一个头文件里写了int global_val;而没有加extern然后两个 .c 文件都包含了这个头文件每个 .c 编译出的目标文件里都会有一个global_val的定义。如果两个都是未初始化的它们会被当作弱符号某些编译器默认情况下可能只给一个警告但如果一边初始化了、另一边没初始化就可能出现强符号与弱符号混合的情况行为会比较微妙。为了避免这类问题最佳实践很明确全局变量的声明永远放在头文件里加extern定义只出现在一个 .c 文件中。这看起来是常识但很多人包括曾经的我因为图省事把一个简单的变量直接定义在头文件里结果项目一变大就出现各种诡异的链接问题。第四章对这部分讲得很细甚至提到了 COMMON 块的历史原因。3.2 COMMON 块为什么未初始化全局变量有特殊待遇书里专门有一节讲 COMMON 块这是早期 Fortran 留下的遗产但现代链接器依然遵循相关规则。简单来说未初始化的全局变量弱符号会被放进一个可合并的机制里多个弱符号同名时链接器选最大的那一个分配空间而不会报错。这个设计本意是方便早期编程语言里多个文件共享公共数据块的用法但到了 C 语言里反而让不少新手困惑。更麻烦的是GCC 在不同版本里对未初始化全局变量是否进 COMMON的行为有变化老版本可能默认-fcommon新版本有的发行版默认-fno-common。这就导致同一份代码在不同环境下的链接行为不一样——在 A 机器上编译运行正常在 B 机器上直接 multiple definition。我在一个跨平台项目里就遇到过这种情况两个源文件都因头文件包含关系而各自定义了一个未初始化全局变量在旧工具链上只是警告升级工具链后变成链接错误。排查到最后根因就是 COMMON 块规则的变化。所以我的建议是不要依赖弱符号合并这种隐式行为该用 extern 就用 extern该用 static 就用 static把符号的作用域控制得越明确越好。3.3 重定位表链接器怎么知道哪里要改符号决议完成之后链接器知道了每个符号的最终地址接下来就是重定位。重定位的信息来源是每个目标文件里的重定位表.rel.text和.rel.data分别记录代码段和数据段里需要修正的位置。一个重定位条目通常包含三个核心字段需要修正的位置在段内的偏移offset、要引用哪个符号symbol、以及重定位类型type。你可以用readelf -r demo.o看到类似这样的输出Relocation section .rela.text at offset 0x270 contains 2 entries: Offset Info Type Sym. Value Sym. Name 000000000019 000800000002 R_X86_64_PC32 0000000000000000 foo看到这个输出你就能确定目标文件里 offset 0x19 处需要根据符号 foo 的最终地址做一次 PC 相对重定位。链接器拿到这个条目后会去计算S A - PS 是符号最终地址A 是加数P 是修正位置地址把计算结果写进那 4 个或 8 个字节里。3.4 相对重定位与绝对重定位的区别x86-64 下最常见的两种重定位类型是R_X86_64_PC32和R_X86_64_32。PC 相对重定位R_X86_64_PC32算出的结果是目标地址与当前指令地址的差值。因为 x86-64 的call、jmp指令本身就是按相对偏移来编码的所以链接器只要把差值填进去就行。这种方式最大的好处是代码段如果整体被移动位置比如被加载到别的地址指令内部的相对关系不变程序照样能跑这为后面的动态链接和地址无关代码PIC打下了基础。绝对重定位R_X86_64_32则直接把符号的绝对地址填进去适合访问全局变量这类场景。需要注意的是x86-64 下绝对地址写入 32 位字段是有约束的这就是为什么默认情况下链接器不让你把可执行文件加载到超过 2GB 的地址空间默认的 0x400000 远低于这个限制。如果哪个符号无法保证落在低 2GB 范围内你就可能看到relocation truncated to fit之类让人摸不着头脑的报错。这个错误我在做大型 C 项目时遇到过好几次。根本原因通常是某个模块启用了-fPIC而另一个模块没有或者某些大数组把数据段推得太大导致跳转距离超过了相对寻址的范围。解决办法一般是统一加-fPIC或者在链接时调整布局但对于大部分普通场景理解PC 相对 vs 绝对的区别就已经够用了。3.5 两条指令之间的重定位实例我建议每个读者都亲手做一次这个实验。写一个 b.cint shared 42; int add(int a, int b) { return a b shared; }再写一个 a.cextern int shared; extern int add(int, int); int main() { return add(1, 2) shared; }分别用gcc -c a.c b.c编译然后objdump -dr a.o看反汇编。你会看到类似这样的内容call 4004fc add在目标文件里call 指令后面跟的是 0同时在-r输出里能看到这条指令的重定位条目指向add符号。等你用gcc a.o b.o -o app完成链接再objdump -d app会发现 call 后面的值已经被替换成了真实的偏移。亲眼看到这个变化你对重定位的理解会比读十遍概念都深刻。4. 静态库链接.a 文件到底是怎么回事4.1 静态库的本质是一堆 .o 的压缩包.a文件在 Linux 下通常叫静态库但你把它当成多个目标文件的集合包更准确。它本质上是用 ar 工具打包的多个 .o 文件再带一个符号索引可以用 ranlib 生成或者 ar 打包时自动生成。ar t libfoo.a可以列出包含哪些成员文件ar x libfoo.a可以解包出来。书中重点强调了一个很多人不知道的机制链接器在链接静态库时只会取出那些解决了当前未定义符号的目标文件而不是把整个库全部链接进来。也就是说如果你的可执行文件只用到 libfoo.a 里的一个函数最终可执行文件里只包含那个函数所在的 .o 文件的代码其他 .o 不会被纳入。这个机制是一把双刃剑。好处是可执行文件不会平白无故变大坏处是它带来了一系列链接顺序的问题。很多人看官方文档里调整库的链接顺序不知所以然一旦理解了链接器按需提取 .o顺序问题的本质就一目了然了。4.2 链接顺序为什么会导致 undefined reference链接器在处理命令行参数里的目标文件和静态库时基本是从左到右单遍扫描的。当它遇到一个 .o 文件会把其中未定义的符号记在待解决符号表里当它遇到一个静态库会检查库里有哪些 .o 能解决当前待解决符号表里的符号如果有就提取对应的 .o同时把这个新 .o 里引用的新符号也加入待解决列表。问题就出在这个单遍上。如果 libA.a 里的某个 .o 引用了 libB.a 里的符号但命令行里 B 排在 A 前面那么链接器扫过 libB.a 时还没有 libA 引入的未定义符号于是不会提取 B 里的相关 .o等扫到 libA.a 提取了那个 .o产生对 B 的未定义引用时B 已经路过了。最终结果就是 undefined reference。我当年第一次遇到这个报错时百思不解因为库文件明明就在链接命令里。后来才明白静态库的链接顺序和依赖方向要相反——被依赖的库放在后面。如果 A 依赖 B链接命令应该是A.a B.a。遇到循环依赖时可以用--start-group和--end-group把相关库包起来让链接器反复扫描直到没有新符号加入gcc main.o -Wl,--start-group -lfoo -lbar -Wl,--end-group -o app在大型项目里循环依赖几乎是家常便饭。我在维护一个较老的项目时就经常用这个参数临时绕开顺序问题。不过话说回来组参数只是缓解手段治本的方法还是理清模块依赖关系把库划分得干净一些。4.3 静态库与重复符号的坑静态库按需提取机制还带来一个容易忽略的现象同一个符号可能在库里存在多个版本。比如你有一个 libcommon.a里面有两个 .o 都定义了同名函数。链接器提取其中一个 .o 后发现另一个 .o 也定义了同名符号可能直接报 multiple definition。还有一种更隐蔽的情况你的代码里定义了一个函数同时一个静态库里也有同名的强符号函数。链接器在处理你的 .o 时先把这个符号标记为已定义。等扫到静态库时发现库里有同名强符号如果已经解析过的符号是强符号链接器会报冲突如果你的符号恰好是弱符号库里的强符号反而会覆盖你的定义。这类问题在大型项目里非常难排查因为你往往要花很长时间才能定位到到底是哪个库里的哪个符号跟我冲突了。此时最实用的工具是nm -A加目标模式列出所有目标文件中匹配的符号定义来源比如nm -A *.o lib*.a | grep T foo$一行的输出就能告诉你 foo 的强符号定义出现在哪些文件里。这个排查技巧我在后面会再详细展开。5. 链接脚本与自定义布局5.1 链接脚本到底控制什么第四章在末尾介绍了链接脚本linker script。链接脚本是链接器的施工图纸控制段的合并顺序、输出段的名字、每个段加载到的地址、入口点entry等。默认情况下GCC/ld 使用内置的链接脚本你可以在命令行加-Wl,--verbose让链接器把脚本内容打印出来内容很长但开头部分基本是各种段的排布规则。大多数应用开发者不需要手写链接脚本因为默认布局已经够用。但一旦你接触嵌入式开发、内核模块、引导程序或者需要把某些特殊数据固定放到指定内存地址的场景链接脚本就变得不可或缺。我见过不少做 MCU 开发的朋友最初对 link.ld 一脸懵后来搞懂了*(.text*)这种通配符的含义后才明白把所有目标文件的 .text 段合并到这里是什么意思。5.2 一个最简链接脚本长什么样一个最小可用的链接脚本大致长这样SECTIONS { . 0x10000; .text : { *(.text) } .data : { *(.data) } .bss : { *(.bss) } }这里.表示当前地址也就是位置计数器赋值为0x10000相当于把代码段起点定在 0x10000*(.text)表示所有目标文件中的 .text 段都在这里展开。如果你写过一个简单的裸机程序把这段脚本稍加修改就能用起来了。理解链接脚本不只是为了写脚本本身更深层的价值是让你反过来理解默认链接行为默认脚本也是这么做的只不过加了大量细节。6. 常见链接问题排查实录6.1 undefined reference 的五种常见原因链接报错里最常见的就是 undefined reference但原因往往各不相同这里整理一份我见过的高频情况。第一库没链接上。函数声明了头文件也包含了但编译命令里少了-lxxx或者库文件路径不对。第二链接顺序反了。这在上文已经详细说过A 依赖 BB 却放在 A 前面。第三库文件架构不匹配。比如 64 位程序链 32 位库或者交叉编译时库的工具链版本不一致链接器找不到合适的目标代码。第四C 名字改编name mangling导致符号对不上。C 编译器会把函数名改成带参数类型信息的形式如果你用extern C的时机不对链接器自然找不到那个符号。第五符号被裁剪了。编译目标文件时如果用了-ffunction-sections配合-Wl,--gc-sections未引用的函数会被丢弃某些依赖该函数必须存在的代码就会出问题。排查这种问题我惯用的套路是先确认符号真的存在直接对 .o 或 .a 文件用 nm 查看。一个常见的命令组合是nm -C libfoo.a | grep 函数名-C把 C 修饰过的名字还原成可读形式能少掉很多头发。6.2 multiple definition 怎么定位是哪个文件在捣乱multiple definition 的报错信息通常会指明这个符号来自哪几个目标文件比如/usr/bin/ld: a.o: b.o: multiple definition of shared如果你遇到的是这种直接看报错就能修。但如果项目很大报错里只会给出一堆库文件的路径这时候就得用 nm 把所有候选文件过一遍。我通常这样做先写一个只包含符号名的临时文件然后对所有 .o 和 .a 文件执行nm -A输出里看哪些行匹配到这个符号且类型是 T、D、B、C 等定义型标识。这一步能快速锁定符号的源产地再沿着源产地去看代码的组织方式多半会发现问题来自头文件里的非 extern 定义、两个文件用了同名全局变量、或者弱符号和强符号的混合定义。6.3 符号裁剪、可见性与 --as-needed现代链接器还有一些隐形的坑最典型的是--as-needed和--gc-sections。一些发行版默认开启了--as-needed这意味着你-lfoo之后如果链接器发现没有任何符号从 libfoo 里被解开它就不会真的把这个库记入 DT_NEEDED动态链接场景或加入最终链接。结果就是某些程序运行时报找不到符号但编译时一切正常。解决思路也很简单确保命令行里库确实被用到了或者必要时手动关闭这个选项。另一个常见的是-Wl,--gc-sections配合-ffunction-sections。它能把未被引用的函数和段从最终文件里剔除减小二进制的体积。代价是如果你通过函数指针、汇编跳转或者反射某种方式引用了某个函数链接器未必能感知到这个引用就会把它误删。排查这类问题时症状往往是编译链接都通过一运行就崩或者找不到函数。这时候检查一下编译选项里有没有这个裁剪组合是一个非常值得优先怀疑的方向。6.4 排查工具速查把几个常用工具整理成表方便随时查阅。工具 / 参数用途使用场景readelf -S查看目标文件或可执行文件的段表观察各段地址、大小、权限readelf -r查看重定位表定位哪个位置引用了哪个符号readelf -l查看程序头段加载信息了解可执行文件如何加载nm -A列出文件中定义的符号定位符号定义在哪个文件objdump -dr反汇编并显示重定位信息查看指令级别待修正位置objdump -t查看符号表检查符号类型和可见性ar t列出静态库中的成员查看 .a 包里有哪些 .o这些工具基本都是 binutils 自带的任何一个 Linux 开发机上都有。每次链接报错时先用readelf -r和nm把符号层面的信息摸清楚往往比瞎猜选项更高效。6.5 我的实操建议把链接过程打回原型最后分享一个我屡试不爽的方法不要直接面对大型项目的复杂链接报错而是先做一个最小复现。把问题涉及的几个源文件抽出来写一个只有几十行的 main 函数再手动指定那些库文件重新跑一遍链接。最小复现往往几秒钟就能出结果排查起来也轻松得多。当年我在排查一个极其复杂的 undefined reference 时就是在完整项目里反复改了十几次编译参数都没效果。后来狠下心把相关代码化简成一个 30 行的test.c和一个只有 3 个源文件的libmini.a不出一顿饭的功夫就锁定了原因库内部两个对象文件之间存在循环依赖而链接命令里只传了一个库。这个教训让我从此养成了出问题先做最小复现的习惯。7. 读完这一章我印象最深的三个点理解静态链接之后很多平时觉得玄学的东西变得顺理成章。这里挑三个对我后续工作影响最大的点说说。第一链接错误和编译错误是完全不同维度的问题。编译错误关心语法和类型链接错误关心符号和地址。排查链接问题不能靠看代码的表面逻辑要看符号层面的真实情况。这个认知转变帮我节省了大量盲目试错的时间。第二编译器选项和链接器选项要分开看。-c只是编译不链接-shared和-static是链接阶段的事-l只是告诉链接器去哪里找库而不是把库内容直接塞进文件。很多初学者把这些混为一谈遇到问题就乱改参数自然是越改越乱。第三动手做实验远比空读概念有效。第四章光是重定位这一节就可以用两三个小文件加几条命令完整复现。我建议你花一个下午写几个小目标文件用readelf和objdump把每个细节过一遍。等你亲眼看到重定位表里那些条目以及链接前后指令字节的变化你对整个工具链的理解会彻底上一个台阶。这本书后面对动态链接、装载器的讲解很多地方都建立在静态链接的知识之上。所以第四章虽然只是整本书的一环却值得反复琢磨。我个人在实际项目中的体会是链接器不是黑盒它每一步都有迹可循只要你愿意停下来用工具去看大多数链接问题都能在十分钟内定位到根本原因。最后再分享一个小习惯每当项目新增一个源文件或多个静态库我会顺手跑一遍readelf -S和nm -A看看结果这个习惯帮我提前拦下了好几次本会在集成阶段爆发的链接事故。