博主介绍程序喵大人35 - 资深C/C/Rust/Android/iOS客户端开发10年大厂工作经验嵌入式/人工智能/自动驾驶/音视频/游戏开发入门级选手《C20高级编程》《C23高级编程》等多本书籍著译者更多原创精品文章首发gzh见文末记得订阅专栏以防走丢C基础系列专栏C语言基础系列专栏C大佬养成攻略专栏C训练营个人网站好文推荐【AIAgent项目】从零构建一个代码PRAgent【C入门】编译链接模型 - 01 一个 C 程序是怎样变成可执行文件的【C入门】编译链接模型 - 02 预处理把头文件怎样塞进源文件【C入门】编译链接模型 - 03 翻译单元才是编译器真正看到的文件【C入门】编译链接模型 - 04 声明让编译器通过检查定义给链接器提供实体【C入门】编译链接模型 - 05 ODR 为什么会让重复定义变成工程炸点【C入门】编译链接模型 - 06 目标文件里到底有什么【C入门】编译链接模型 - 07 链接器怎样把符号对上号第 7 章讲了链接器怎样把多个目标文件中的符号对上号。但如果一个项目有几十上百个.cc每次链接都在命令行里逐个列出所有.o文件显然不现实。静态库就是用来解决这个问题的把一组相关目标文件打包成一个.a文件Linux/macOS或.lib文件Windows链接时传给-l参数链接器自动从库里抽取需要的目标文件。静态库的静态指的是链接时就把库中的代码提取并合入最终可执行文件链接完成之后可执行文件不再依赖那个.a文件。静态库本质上是一组目标文件的归档archive加上一个索引index帮助链接器快速查找。用极简例子从头演示。准备math.h、add.cc、mul.cc和main.cc// math.h#ifndefMATH_H_#defineMATH_H_intAdd(intleft,intright);intMultiply(intleft,intright);#endif// add.cc#includemath.hintAdd(intleft,intright){returnleftright;}// mul.cc#includemath.hintMultiply(intleft,intright){returnleft*right;}// main.cc#includemath.h#includeiostreamintmain(){std::coutAdd(2,3) Multiply(4,5)\n;return0;}先把add.cc和mul.cc各自编译成目标文件然后用ar工具打包成静态库clang-stdc20-Wall-cadd.cc-oadd.o clang-stdc20-Wall-cmul.cc-omul.o ar rcs libmath.a add.o mul.oar是 Unix 系统上的归档工具r表示将文件插入归档替换同名成员c表示创建归档如果不存在s表示为归档建立符号索引。libmath.a现在包含了add.o和mul.o的完整内容。用ar t libmath.a可以列出归档中的所有成员用nm libmath.a可以看每个成员的符号表。编译main.cc并和静态库链接clang-stdc20-Wall-cmain.cc-omain.o clang main.o libmath.a-oapp ./app# 输出5 20main.o的符号表中有两个未定义符号需求Add和Multiply。链接器在处理libmath.a时根据符号需求从归档中抽取了add.o提供Add和mul.o提供Multiply。最终app中只包含了被抽中的目标文件的代码没有被引用的归档成员不会进入可执行文件。这个按需抽取是静态库和直接列出.o文件的核心区别。如果写成clang main.o add.o mul.o -o appadd.o和mul.o的全部内容无条件地进入最终可执行文件。如果写成clang main.o libmath.a -o applibmath.a中的add.o和mul.o只在其提供的符号被main.o或前面已处理的成员需要时才会被抽取。对于大型库这个差异决定了最终二进制的大小。链接器处理静态库的算法通常是一个按命令行顺序逐遍扫描的过程。链接器维护一个未解析符号集合初始为空。依次处理命令行上的每个输入如果是目标文件将其提供的符号加入已定义符号集合如果它引用了未定义符号且当前未解析符号集合中找不到将其加入未解析符号集合如果它解决了一些未解析符号的需求从集合中移除那些符号。如果是静态库遍历库中每个目标文件成员检查该成员是否提供了当前未解析符号集合中某个或多个符号的定义如果提供则将该成员从库中抽取出来把它当作一个独立的目标文件重新纳入符号解析流程该成员提供的符号可能解决更多未解析需求该成员引用的符号可能产生新的未解析需求。重复这个逐个成员检查、满足需求就抽取的过程直到一趟扫描结束。扫描完所有输入后如果未解析符号集合为空链接成功否则报undefined reference。这个算法模型解释了静态库使用中一条重要的规则链接顺序敏感。当链接器从左到右扫描命令行时如果库 A 中的成员需要库 B 提供的符号通常库 B 应该放在库 A 之后出现。因为在扫描到库 A 时链接器会检查库 A 中每个成员是否解决了当前已有的未解析符号需求。如果当时还没有来自库 B 的未解析符号需求库 A 就不会被充分抽取等到后面扫描到库 B 时B 中成员的符号才会被提取但 A 中对 B 的需求在前一趟扫描中可能已经被记录为未解析链接器在单趟扫描中不会回头重新扫描已经遍历过的库。实际例子如果main.o使用了A()和B()而libmath.a中的add.o定义了A()但内部调用了B()mul.o定义了B()。链接命令clang main.o libmath.a的扫描过程是先处理main.o将A和B加入未解析集合然后遍历libmath.aadd.o提供了A被抽取A从集合中移除但add.o内部对B的调用引入了对B的新需求已在集合中继续扫描库中剩余成员找到mul.o提供了B抽取mul.oB从集合中移除。一切正常。但如果add.o和mul.o分在不同的库中比如libfirst.a包含add.olibsecond.a包含mul.o命令行是clang main.o libfirst.a libsecond.amain.o引入对A和B的需求扫描libfirst.aadd.o提供A被抽取A需求解决add.o引出对B的需求继续扫描libfirst.a中剩余成员没有再提供B的成员转向libsecond.amul.o提供B被抽取。链接成功。如果顺序反过来clang main.o libsecond.a libfirst.a先扫描libsecond.a此时未解析集合中有A和Bmul.o提供B被抽取B需求解决mul.o没有引入新需求继续扫描libsecond.a剩余成员没有提供A的再扫描libfirst.aadd.o提供A被抽取。也成功了。库的顺序在两个库各自独立提供符号时可能不那么严格。真正容易出问题的是库之间有交叉依赖libfirst.a中的某个成员使用了libsecond.a中的符号而libsecond.a中的某个成员又使用了libfirst.a中的符号。这种情况下单趟扫描不够要么调整库的顺序让依赖方向从左到右一致要么在命令行中重复库名让链接器做多趟扫描要么使用 GNU ld 的分组扫描选项或 macOS 的强制加载选项让链接器对这组库执行多轮符号解析。静态链接之后可执行文件包含了被抽取的目标文件中的全部代码和数据。用nm app可以确认Add和Multiply的符号已经在可执行文件中有了确定的地址标记不再是U。此时libmath.a文件不再需要参与程序的运行。把app拷贝到另一台没有安装开发库的机器上只要能满足系统层面的兼容性相同的操作系统版本、相同的 CPU 架构程序就能直接运行。这是静态链接最大的优势部署简单没有运行时的库依赖。静态链接的代价体现在几个方面。可执行文件的体积会增长因为每个使用了该库的程序都包含了一份库代码的副本。如果十个程序都静态链接了同一个大型库磁盘上就会有十份这个库的代码。库的更新需要重新链接所有使用该库的程序。如果库修复了一个安全漏洞所有静态链接了该库的程序都需要重新编译和重新发布。相比之下动态库可以在不重新编译程序的情况下更新库文件本身。ar创建的静态库在各种 Unix 系统Linux、macOS、BSD上通用但内部格式有些细微差异。macOS 上的ar创建的是 Mach-O 格式的静态库Linux 上的ar创建的是 ELF 格式的静态库。Windows 上的静态库后缀是.lib由 MSVC 的lib.exe工具创建内部是 COFF 格式的目标文件集合。ar t、ar rcs这类命令的行为在各平台上是相通的但目标文件本身的格式不同导致 Linux 上创建的.a文件不能直接用于 macOS 链接器。静态库是 C工程中组织代码复用的基础手段。应用层的使用很简单ar rcs打包-l链接这是每个 C 程序员都应该掌握的基础操作。理解静态库在链接器内部的处理算法按需抽取和顺序扫描则能帮助你在遇到链接顺序导致的undefined reference时知道问题不在符号缺失而在库的排列顺序。常见的库链接顺序实践是把依赖关系从上到下排列主程序的目标文件放在最前面高层库紧随其后底层库放在最后。如果库 A 使用了库 B 中的符号B 应该出现在 A 之后。这条经验法则在大多数情况下都能让链接器的单趟扫描正确完成符号解析。如果项目中的库依赖关系非常复杂出现了循环依赖经验法则是把循环内的库重复列一次或启用链接器提供的库分组扫描能力。从工程管理的角度审视静态库它解决了十几上百个目标文件怎么管理和分发的问题。把一个库的内部实现拆成多个.cc文件编译成各自的目标文件再用ar打包在一起。库的使用者只需要拿到头文件接口声明和.a文件实现不需要关心库内部有多少个源文件、各自叫什么名字。头文件提供声明.a提供定义这个模型和前面四章建立的声明/定义分工以及ODR 的唯一定义要求完全吻合。静态库和 ODR 的关系也值得点一下。静态库是由多个目标文件组成的归档每个目标文件来自一个翻译单元。ODR 要求整个程序中每个外部符号只有一个定义这个要求同样适用于静态库中的目标文件。两个不同的.a文件中不能包含同名的强符号定义否则链接器在抽取过程中可能同时抽取两份触发multiple definition。排查这种跨库的重复定义时可以用nm分别查看两个静态库的符号表用ar t定位到具体是哪个目标文件提供了重复的符号。静态库的构建过程可以做到相当标准化。一个典型的 Makefile 或 CMake 模式是add.cc和mul.cc各自编译成add.o和mul.oar rcs libmath.a add.o mul.o打包。CMake 中add_library(math STATIC add.cc mul.cc)一步完成了编译和打包。这些构建系统的细节放在《图解 构建系统与工具链》中展开本章聚焦在静态库本身的机制模型上。有一个边界情况需要说明如果静态库中的某个成员目标文件没有任何符号被引用链接器不会抽取它该成员提供的全局对象构造函数也不会被执行。这在某些依赖全局对象构造函数做自动注册的模式中是一个隐藏的坑。比如一个测试框架或插件框架可能在某个.cc文件里定义全局注册对象构造函数负责把插件登记到全局表中但主程序没有显式引用这个目标文件里的任何函数或变量链接器就会认为这个成员不需要进入最终程序注册动作自然不会发生。遇到这种模式工程上通常会保留一个显式引用入口或者使用平台提供的强制加载静态库选项让链接器加载库中的全部目标文件不再按符号需求筛选。这个边界也解释了为什么我已经把库传给链接器了不等于库里的所有代码都会生效。静态库进入链接命令后只是给链接器提供了一个候选集合。真正进入可执行文件的是候选集合中被当前未解析符号需求选中的成员目标文件。没有被选中的成员继续留在.a文件里不影响最终程序。这个机制对普通函数库很友好因为它自动剔除未用代码对自动注册、反射表生成、链接期插件发现这类模式就需要额外设计入口否则代码看起来在库里实际上从未进入可执行文件。从二进制体积角度看按需抽取还有一个重要后果静态库的大小和最终可执行文件的大小没有线性关系。一个 100MB 的静态库被传给链接器并不意味着可执行文件一定增加 100MB。如果程序只引用了库里一个很小的目标文件成员链接器可能只抽取那一个成员。反过来如果库的构建方式把大量功能都放进同一个巨大.o只要程序引用其中一个符号整个目标文件成员都会被抽取未用函数也可能一起进入可执行文件。静态库的抽取粒度是成员目标文件不是单个函数。库作者把功能拆成多少个源文件会影响使用者最终链接出来的体积。这就是很多基础库会把实现拆成多个小.cc文件的原因。拆得太粗链接器按需抽取的精度差拆得太碎构建系统和归档管理成本会上升。实际工程里通常按功能边界拆分一组强相关函数放在同一个翻译单元彼此独立的模块放在不同翻译单元。这样打包成静态库后链接器既能按模块抽取又不会让源文件数量失控。静态库的像一包目标文件这个直觉需要记住一个精确的修正它不是简单的压缩包。压缩包只是把文件打包以便传输链接器需要先解压才能读取其中的目标文件。静态库是归档格式链接器可以直接在归档内部按索引查找符号并随机访问成员目标文件的内容不需要先解压整个归档。这个索引就是ar rcs中s参数的产物它在归档中写入一个符号到成员的映射表链接器读取这个映射表后能够快速判断某个未解析符号是由库中的哪个目标文件成员提供的。如果用ar r创建归档而没有s链接器可能无法正确识别库中成员的符号除非之后用ranlib补建索引。日常使用中直接用ar rcs一步到位即可。把静态库看成带索引的目标文件仓库比把它看成一个普通库文件更贴近链接器的真实行为。排查静态库问题时最有效的办法是把库拆回目标文件视角。看到undefined reference先问两个问题需要的符号在不在某个库成员里那个成员有没有机会被抽取。第一个问题用nm libmath.a看符号表确认目标符号是否标记为已定义。第二个问题看链接命令顺序确认在扫描到这个库时未解析符号集合里是否已经有对该符号的需求。很多链接错误表面像库里没有实现实际原因是库放得太早链接器扫描到它时还不知道后面会需要它。把符号存在性和抽取时机分开查能避免在错误方向上反复改命令。如果nm显示库里确实没有目标符号问题就回到库的构建过程。可能是对应.cc没有编译进库可能是函数签名和声明不一致导致 C 名字修饰后的符号名不同也可能是函数被放进了匿名命名空间或标成了内部链接只在当前目标文件内部可见。这个时候继续调换库顺序没有意义因为链接器无论扫描多少次都找不到可对外使用的定义。要回到源文件、头文件和库打包命令确认定义真的以外部可见符号进入了归档。如果nm显示两个库都提供了同一个强符号问题就变成第 5 章讲过的 ODR 冲突。静态库本身不会自动隔离同名符号。只要两个成员目标文件都被抽取进同一个程序链接器就会在全局符号表里看到两个同名强定义。工程上常见原因是把普通函数定义放进头文件或者两个库都打包了同一份公共源码。修复方向是让公共实现只存在一份或者把真正需要头文件实现的函数改成符合规则的inline。还有一类问题来自库版本不一致。头文件来自新版库.a文件还是旧版库编译阶段会通过因为新版头文件提供了声明链接阶段会失败因为旧版静态库里没有对应定义。反过来头文件是旧版、库是新版也可能在函数签名、结构体布局或命名空间上出现不匹配。静态库发布时必须把头文件和库文件当成一组产物管理不能只替换其中一个。这个习惯对动态库同样重要只是动态库还会多出运行时路径和 ABI 兼容问题。下一个要讨论的模型是动态库。动态库和静态库在链接时被链接器读取这一点上相同但动态库的代码不完整复制进可执行文件而是保留了一份运行时的依赖记录。这意味着动态库要同时面对链接期和运行期两个阶段每个阶段都有自己找库的规则和路径这个话题放在第 9 章展开。码字不易欢迎大家点赞关注评论谢谢