1. 项目概述从AGPL到MITmold 2.0.0的变与不变如果你是一名在Unix/Linux环境下搞C/C开发的程序员那么“链接”这个步骤对你来说一定不陌生。每次编译大型项目看着进度条在链接阶段缓慢爬行那种等待的焦灼感我深有体会。尤其是在“修改代码-编译-调试”这个循环里链接时间哪怕只缩短几秒钟对开发效率的提升都是实实在在的。今天要聊的mold就是为了解决这个痛点而生的。简单说mold是一个旨在取代传统GNU ld、gold乃至LLVM lld的高性能链接器。它的核心卖点就一个字快。有多快根据官方和社区的基准测试在链接大型应用程序比如Chrome浏览器、Clang编译器自身时mold的速度可以比GNU gold快5倍以上比已经很优秀的LLVM lld也要快上2到4倍。这个性能提升对于动辄需要链接数万个目标文件、生成数GB调试信息的现代软件项目来说意味着构建时间可以从分钟级缩短到秒级。最近mold迎来了它的2.0.0正式版。这个版本号的大跳跃除了常规的功能修复和性能优化最引人注目的变化莫过于其开源许可证从AGPL v3变更为MIT。对于不熟悉开源许可证的朋友这里简单打个比方AGPL像是一份带有“传染性”条款的协议要求任何基于该代码提供网络服务的衍生作品也必须开源而MIT许可证则极其宽松几乎允许任何形式的包括商业闭源的使用、修改和分发。mold创始人Rui Ueyama在发布公告中坦言此前采用AGPL是希望探索一种“开源核心商业许可”的双重授权模式为项目可持续发展寻找资金支持但实际效果未达预期。因此团队决定拥抱更开放的MIT许可证以最大化项目的采用率和社区影响力。这个决定对于广大开发者而言无疑是个好消息意味着我们可以更无顾虑地将mold集成到各种开发环境和商业产品中。除了许可证变更2.0.0版本也修复了一些关键问题比如之前无法处理包含超过65520个“节区”section的重定位目标文件这在大规模项目链接时可能成为瓶颈。同时为了提升与现有构建脚本的兼容性mold也调整了一些命令行参数的解释方式向GNU ld和LLVM lld的行为看齐。接下来我们就深入拆解一下mold的设计思路、它为何能这么快以及在实际项目中如何上手使用和避坑。2. 高性能链接器的设计哲学与实现原理要理解mold为什么快我们得先看看传统链接器慢在哪里。链接器的工作通俗讲就是把一堆编译好的目标文件.o文件和库文件像拼拼图一样组合成一个最终的可执行程序或共享库。这个过程主要包含几个耗时的步骤符号解析解决谁调用谁的问题、节区合并把相同类型的数据堆到一起、重定位修正代码中的地址引用。传统链接器如GNU ld在设计之初并没有充分考虑如今动辄数百万行代码、极度复杂的项目结构其算法和数据结构在应对大规模输入时效率不高尤其是大量使用线程局部存储TLS或调试信息时。2.1 核心加速策略并行化与高效数据结构mold的性能秘诀核心在于极致的并行化和精心设计的数据结构。我把它总结为以下三个层面全链路并行处理这是mold最显著的加速点。从读取输入文件开始mold就尝试并行化所有可能的工作。例如解析多个目标文件的符号表、处理重定位条目、甚至生成输出文件的某些部分都可以在多个CPU核心上同时进行。相比之下GNU ld和gold的并行化支持有限lld虽然也支持并行但mold在任务划分和调度上更为激进和高效。它特别针对多核处理器进行了优化能够充分利用现代CPU的所有核心。内存映射文件mmap的广泛使用mold大量使用mmap系统调用来处理输入文件。mmap允许程序将文件直接映射到进程的虚拟内存空间避免了传统的read/write系统调用带来的数据拷贝开销。当链接器需要读取目标文件中的代码、数据或调试信息时直接访问内存映射区域即可这大大减少了I/O等待时间尤其是在处理大量小文件时优势明显。定制化的高效数据结构链接过程中需要频繁进行符号查找、节区管理和地址计算。mold没有使用C标准库中通用的容器如std::unordered_map而是为链接这个特定场景量身定制了哈希表、向量等数据结构。这些定制容器减少了内存分配次数、优化了缓存局部性使得高频操作的速度得到数量级的提升。2.2 与LLVM lld的差异化竞争很多人会问LLVM项目下的lld链接器也已经很快了mold还有必要吗我的体会是两者在设计目标和优化侧重点上有所不同。lld作为LLVM生态系统的一部分强调与Clang编译器的深度集成、跨平台支持支持Linux/macOS/Windows以及对LLVM位码bitcode的良好支持。它的代码非常严谨可移植性强。而mold则更像一个“偏科生”它最初的目标就是成为在Unix-like系统主要是Linux上最快的链接器。因此它可以为了极致的性能采用一些更激进、更依赖特定系统特性的优化手段。例如mold在内存分配策略、线程池的实现上更加“赤裸”直接追求最低延迟。在实际基准测试中对于纯ELF格式Linux标准格式的链接任务mold通常能比lld再快上一截。当然这种极致的优化有时会以牺牲一些可移植性或代码的简洁性为代价。注意mold目前主要专注于支持ELF格式用于Linux和大多数Unix系统。虽然已有实验性的macOSMach-O格式支持但其稳定性和性能尚未达到生产级别。如果你的主战场是Linux服务器或桌面开发mold是绝佳选择如果涉及跨平台构建可能需要评估lld或保持原有链接器。3. 从零开始mold的安装与基础使用指南说了这么多不如亲手试试。下面我将以Ubuntu 22.04 LTS为例带你完成mold的安装和基本使用。其他Linux发行版的步骤也大同小异。3.1 安装mold最推荐的方式是通过系统的包管理器安装这能确保依赖关系被正确管理。# 对于 Ubuntu/Debian 及其衍生版 sudo apt update sudo apt install mold # 对于 Fedora/RHEL/CentOS (需要启用EPEL) sudo dnf install mold安装完成后你可以通过mold --version来验证安装。如果你想尝试最新的2.x版本而系统仓库中的版本较旧可以考虑从源码编译。源码编译需要安装一些开发工具链# 安装编译依赖 sudo apt install build-essential git clang cmake libstdc-12-dev zlib1g-dev # 克隆仓库并编译 (以2.0.0为例) git clone https://github.com/rui314/mold.git cd mold git checkout v2.0.0 make -j$(nproc) CXXclang sudo make install从源码编译默认会安装到/usr/local/bin。使用make编译时我强烈建议指定CXXclang因为mold的代码基对Clang编译器的优化更加友好通常能生成比GCC更高效的二进制文件。3.2 在项目中启用mold使用mold链接你的项目主要有三种方式推荐程度由高到低方法一直接调用最灵活在链接命令中将原本的ld、gold或lld替换为mold即可。# 例如直接链接目标文件 clang -o myapp main.o utils.o -fuse-ldmold # 或者在完整的构建命令中 clang -stdc17 -O2 main.cpp utils.cpp -o myapp -fuse-ldmold-fuse-ldmold这个编译器选项告诉Clang/GCC使用mold作为链接器。这是我最常用的方式可以针对单个构建命令进行切换。方法二通过环境变量覆盖全局或会话级你可以设置环境变量让系统默认使用mold。这适用于你想在某个终端会话或用户范围内全局替换链接器。# 对于GCC export GCC_LDmold # 对于Clang export LDld.mold # 或者更通用的覆盖默认的ld export LD/usr/bin/ld.mold设置后在此终端中运行的构建系统如make、cmake就会自动使用mold。但要注意这可能会影响系统中其他软件的编译建议仅在项目开发目录下使用。方法三替换系统默认链接器不推荐通过符号链接将/usr/bin/ld指向mold。这种方法最激进可能造成系统软件包管理如dpkg出现问题除非你非常清楚自己在做什么否则应避免在生产系统上这样操作。3.3 验证与基准测试安装并启用后如何确认mold真的在干活并且效果如何呢首先检查链接器身份# 查看最终可执行文件使用的链接器 readelf -p .comment your_program | grep -i linker # 或者在链接时添加 -Wl,--version 参数输出会更直接 clang -o test test.c -fuse-ldmold -Wl,--version其次做一个简单的速度对比。创建一个包含多个源文件的小项目或者直接找一个现有的中型项目。分别用默认链接器和mold进行完整构建确保先make clean用time命令记录时间time make -j$(nproc) CCclang CXXclang LDFLAGS-fuse-ldbfd # 使用GNU ld time make -j$(nproc) CCclang CXXclang LDFLAGS-fuse-ldmold # 使用mold你会看到链接阶段linking的时间差异。对于大型项目差异可能从数秒到数分钟不等。4. 深入解析mold 2.0.0的关键更新与兼容性实践mold 2.0.0版本除了许可证变更还包含了一些重要的功能修复和兼容性改进这些变化直接影响着我们在复杂项目中的使用体验。4.1 许可证变更的深远影响从AGPL v3切换到MIT这个变化的技术含量为零但生态影响巨大。我梳理了一下这对不同角色的意义对于个人开发者和开源项目这是纯粹的利好。你可以毫无顾忌地在任何项目中使用mold无论是个人工具、学术研究还是其他开源软件无需担心许可证“传染”问题。你可以自由地修改mold的代码并将其集成到你的专有构建系统中而无需开源你的系统。对于企业用户之前AGPL条款是许多公司法律部门审核开源软件时的“红色警报”。即使只是内部使用一些保守的公司也会避免引入AGPL依赖。变更为MIT后这个最大的法律障碍消失了预计会有更多企业愿意在开发流水线中采用mold以加速其CI/CD流程。对于mold项目本身创始人坦言商业化的尝试未达预期。转向MIT是一种务实的策略旨在通过扩大用户基础来构建更强大的社区从而通过捐赠、赞助或未来的其他模式如提供商业支持服务来获得可持续性。一个更庞大的用户群意味着更多的bug报告、补丁和特性贡献这对项目长期健康有益。4.2 重要问题修复处理超多节区的目标文件在2.0.0之前mold有一个限制无法使用--relocatable或-r选项生成包含超过65520个“节区”的目标文件。--relocatable选项用于生成可重定位的输出它本身也是一个目标文件.o常用于创建静态库.a文件。当你的项目非常庞大模块极多时合并后的重定位目标文件可能会超过这个节区数量限制。这个限制源于ELF格式规范中用于索引节区的字段sh_info在某些上下文中的宽度限制。mold 2.0.0修复了内部逻辑现在能够正确地处理这种情况。这对于构建像Linux内核这样超大型静态库的场景至关重要。如果你在之前版本中遇到类似“too many sections”的错误升级到2.0.0即可解决。4.3 命令行兼容性调整为了降低用户的迁移成本mold 2.0.0在命令行参数解析上做了些微调更贴近GNU ld和LLVM lld的行为-undefined的行为现在-undefined被当作--undefined的同义词处理而不是被解析为-u ndefined。这听起来有点绕我举个例子在GNU ld中-u symbol是--undefinedsymbol的缩写意思是“强制将symbol视为未定义符号以触发从库中链接它”。而-undefined本身是一个独立的选项在某些链接器如ld64中常见。mold现在遵循了GNU ld/lld的惯例将-undefined整体视为一个选项需要接参数如-undefined dynamic_lookup。这修复了之前一些从其他构建系统尤其是源自macOS的移植过来的脚本可能遇到的问题。-no-pie的支持现在-no-pie可以作为--no-pie的同义词。PIEPosition-Independent Executable是一种安全编译技术但某些旧的或特殊的程序可能需要禁用PIE。这个改动使得那些原本为GNU ld编写的、使用了-no-pie参数的构建脚本无需修改就能与mold协同工作。这些改动体现了mold开发团队的务实态度在追求极致性能的同时不牺牲与现有生态的兼容性。毕竟让用户无缝切换才是推广新技术的关键。5. 实战集成将mold融入现代构建系统与CI/CD单独使用mold命令链接很简单但我们的项目通常由CMake、Meson、Bazel等构建系统管理或者运行在GitLab CI、GitHub Actions等自动化流水线中。如何在这些场景中优雅地集成mold呢5.1 与CMake集成CMake是目前最流行的C/C构建系统生成器。集成mold非常直观主要有两种方式方式A通过CMAKE_EXE_LINKER_FLAGS变量项目级在你的CMakeLists.txt中最好在project()命令之后添加链接器标志。为了兼容性可以检查mold是否存在。# 查找mold链接器 find_program(MOLD_EXECUTABLE mold PATHS /usr/bin /usr/local/bin) if(MOLD_EXECUTABLE) # 为所有目标设置使用mold链接 set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -fuse-ldmold) set(CMAKE_SHARED_LINKER_FLAGS ${CMAKE_SHARED_LINKER_FLAGS} -fuse-ldmold) set(CMAKE_MODULE_LINKER_FLAGS ${CMAKE_MODULE_LINKER_FLAGS} -fuse-ldmold) message(STATUS Using mold linker: ${MOLD_EXECUTABLE}) else() message(WARNING mold linker not found, using default linker.) endif()这种方式会影响到该CMake项目中构建的所有可执行文件和库。方式B通过编译器缓存用户级如果你不想修改每个项目的CMakeLists.txt可以设置一个全局的编译器包装脚本或者使用像ccache这样的工具。更简单的方法是在调用cmake时通过环境变量传递工具链文件或缓存变量# 在命令行中指定 cmake -B build -DCMAKE_CXX_FLAGS-fuse-ldmold -DCMAKE_C_FLAGS-fuse-ldmold # 或者使用工具链文件更规范创建一个mold-toolchain.cmake文件内容如下set(CMAKE_C_COMPILER clang) set(CMAKE_CXX_COMPILER clang) set(CMAKE_EXE_LINKER_FLAGS -fuse-ldmold) set(CMAKE_SHARED_LINKER_FLAGS -fuse-ldmold) set(CMAKE_MODULE_LINKER_FLAGS -fuse-ldmold)然后使用cmake -B build -DCMAKE_TOOLCHAIN_FILE/path/to/mold-toolchain.cmake。5.2 与Meson集成Meson的集成同样简单。在你的meson.build文件中可以这样设置# 在project()定义之后 if meson.get_compiler(c).has_argument(-fuse-ldmold) add_project_link_arguments(-fuse-ldmold, language: [c, cpp]) endif或者在配置构建目录时通过meson setup传递参数meson setup build --native-file (echo [binaries]\n c [clang, -fuse-ldmold]\n cpp [clang, -fuse-ldmold])5.3 在CI/CD流水线中使用在自动化构建环境中为了确保一致性通常需要在CI脚本中显式指定使用mold。以GitHub Actions为例你可以在工作流文件中这样配置jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Install mold run: sudo apt-get update sudo apt-get install -y mold - name: Configure with CMake run: | cmake -B build \ -DCMAKE_C_COMPILERclang \ -DCMAKE_CXX_COMPILERclang \ -DCMAKE_C_FLAGS-fuse-ldmold \ -DCMAKE_CXX_FLAGS-fuse-ldmold - name: Build run: cmake --build build --parallel关键点在于CI环境中需要先安装mold包然后在调用CMake或直接调用编译器时确保-fuse-ldmold参数被正确传递。这样就能保证CI构建和本地开发使用相同的高速链接器。5.4 处理静态库与复杂依赖对于大型项目经常需要先构建静态库.a文件然后再链接成最终可执行文件。mold在链接最终目标时表现出色但生成静态库本身即ar命令打包.o文件并非链接器的工作。因此mold的优势主要体现在最终链接阶段。如果你的项目结构是“编译大量源文件 - 生成静态库 - 链接静态库成可执行文件”那么mold加速的是最后一步。为了最大化收益可以考虑调整项目结构减少中间静态库的数量和粒度让更多的目标文件直接参与最终链接但这需要权衡模块化和构建速度。6. 性能调优与疑难问题排查实录即便mold已经很快了但在某些极端场景下我们仍可能遇到性能瓶颈或奇怪的错误。以下是我在实际使用和社区交流中积累的一些调优经验和常见问题解决方法。6.1 监控与诊断链接过程想知道链接时间到底花在哪里了吗mold提供了一些有用的诊断选项--stats在链接结束后打印详细的统计信息包括各个阶段如读取输入文件、解析符号、重定位、写输出文件所花费的时间。这对于定位性能瓶颈至关重要。mold --stats -o program *.o--verbose或-v输出更详细的处理过程包括正在读取的文件、解析的符号等。输出信息较多适合调试复杂问题。--thread-countN手动指定mold使用的线程数量。默认情况下mold会尝试使用所有可用的CPU核心。但在一些共享的构建服务器上或者当你同时运行多个构建任务时限制线程数可能避免系统过载有时反而能获得更好的整体吞吐量。mold --thread-count4 -o program *.o6.2 常见问题与解决方案下面是一个快速排错指南列出了我从社区和自身实践中总结的几个典型问题问题现象可能原因解决方案链接错误undefined reference to ...1. 库文件路径未指定或顺序错误。2. 使用了mold但某些依赖库是用旧链接器生成的存在不兼容的符号格式罕见。1. 检查-L和-l参数确保库路径和顺序正确。GCC/Clang链接时依赖的库需要放在引用它的源文件或库之后。2. 尝试用默认链接器-fuse-ldbfd链接一次如果成功则可能是mod的bug。可向mold项目提交issue并附上最小复现代码。链接速度没有明显提升1. 项目本身很小链接不是瓶颈。2. 输入文件数量少并行优势无法发挥。3. 使用了-g调试信息且项目巨大写调试信息到输出文件成为瓶颈。1. 对于小项目链接本身很快加速感知不强这很正常。2. 尝试合并构建步骤减少中间静态库让更多.o文件直接参与最终链接。3. 考虑使用-gz选项生成压缩的调试信息如-gzzlib这能显著减少输出文件大小和I/O时间。mold处理压缩调试信息的效率也很高。生成的可执行文件无法运行报错Segmentation fault或Invalid ELF header1. mold本身存在bug在早期版本中更常见。2. 使用了不兼容的链接器选项组合。3. 输入的目标文件已损坏。1.首先回退验证使用系统默认链接器如-fuse-ldbfd重新链接如果程序运行正常则基本确定是mold问题。2. 升级到mold的最新稳定版如2.0.0。3. 简化链接选项移除如-flto链接时优化等高级选项看问题是否消失。4. 使用objdump或readelf检查输入.o文件的完整性。内存使用量过高项目极其庞大同时链接数万个目标文件和大型静态库。1. 使用--thread-count减少并行线程数可以降低峰值内存占用。2. 检查是否开启了-ffunction-sections -fdata-sections并配合--gc-sections。这些选项会产生大量小section增加链接器内存开销。对于超大型项目权衡是否值得开启。3. 考虑增加系统物理内存或交换空间。mold为追求速度会积极地将文件映射到内存。6.3 与链接时优化LTO的配合链接时优化LTO是一种强大的优化技术它允许编译器在链接阶段看到所有代码进行跨模块的优化。Clang/LLVM和GCC都支持LTO。当同时使用LTO和mold时流程通常是编译器将代码编译成中间位码bitcode链接器此时充当“链接时编译器”的角色读取所有位码进行全局优化再生成最终代码。mold本身不执行LTO优化但它可以与LLVM的LTO实现协同工作。当你使用Clang的-flto选项时实际上是由LLVM的libLTO库在链接器内部完成优化。mold通过插件机制支持这一点。确保你的系统安装了LLVM开发包如llvm-dev、liblto-dev。使用命令大致如下clang -flto -fuse-ldmold -o program main.cpp utils.cpp在这种情况下链接时间会比不使用LTO时长很多因为增加了全局编译优化的开销。但mold在读取、调度这些位码文件以及写最终输出时其高效的I/O和并行处理能力仍然能带来收益。我的经验是对于追求极致运行速度的发布版本开启LTO是值得的尽管构建时间会增加而对于日常调试构建关闭LTO并使用mold能获得最快的编辑-编译-调试循环。7. 开源生态下的思考与未来展望mold从诞生到2.0.0其发展路径折射出高性能基础设施软件在开源生态中的一些典型挑战和选择。最初采用AGPL反映了开发者对项目可持续性的担忧希望借助“双许可”模式从商业用户那里获得资金。这条路在许多数据库如MySQL、大数据工具中走得通但对于链接器这类更底层、更“工具化”的软件企业付费购买商业许可的意愿可能低得多。最终转向MIT是一种回归开源本质的策略拥抱最广泛的社区通过创造不可替代的价值来吸引贡献和支持。从技术角度看mold的成功证明了在看似成熟的工具链领域依然存在通过架构创新实现数量级性能提升的空间。它刺激了LLVM lld等竞争对手的进一步优化最终受益的是整个开发者社区。对于开发者而言mold 2.0.0的发布和MIT许可证的采用消除了采用它的最后一道心理和法律门槛。它不再仅仅是一个“更快”的选项而是一个可以放心推荐、广泛部署的标准工具。我个人在多个C项目中全面切换到mold已经超过一年整体的体验非常稳定。构建时间的减少尤其是CI流水线上时间的节省直接提升了团队的工作效率。偶尔遇到边缘案例的兼容性问题在社区和issue列表中通常都能找到解决方案或快速得到响应。随着2.0.0版本的发布和许可证的放宽我预计mold会更快地进入各大Linux发行版的默认仓库并被更多的开源项目如Rust的rustc其实也在评估集成mold作为链接后端和商业产品所采用。最后给想尝试的朋友一个切实的建议如果你的开发环境是Linux主要开发语言是C/C/Rust并且项目规模达到一定程度链接时间超过5秒那么花上半小时配置并切换到mold很可能是一项投入产出比极高的投资。从今天发布的2.0.0版本开始你可以毫无顾虑地这么做了。
mold 2.0.0发布：从AGPL转向MIT，高性能链接器如何加速C/C++构建
发布时间：2026/5/23 19:17:21
1. 项目概述从AGPL到MITmold 2.0.0的变与不变如果你是一名在Unix/Linux环境下搞C/C开发的程序员那么“链接”这个步骤对你来说一定不陌生。每次编译大型项目看着进度条在链接阶段缓慢爬行那种等待的焦灼感我深有体会。尤其是在“修改代码-编译-调试”这个循环里链接时间哪怕只缩短几秒钟对开发效率的提升都是实实在在的。今天要聊的mold就是为了解决这个痛点而生的。简单说mold是一个旨在取代传统GNU ld、gold乃至LLVM lld的高性能链接器。它的核心卖点就一个字快。有多快根据官方和社区的基准测试在链接大型应用程序比如Chrome浏览器、Clang编译器自身时mold的速度可以比GNU gold快5倍以上比已经很优秀的LLVM lld也要快上2到4倍。这个性能提升对于动辄需要链接数万个目标文件、生成数GB调试信息的现代软件项目来说意味着构建时间可以从分钟级缩短到秒级。最近mold迎来了它的2.0.0正式版。这个版本号的大跳跃除了常规的功能修复和性能优化最引人注目的变化莫过于其开源许可证从AGPL v3变更为MIT。对于不熟悉开源许可证的朋友这里简单打个比方AGPL像是一份带有“传染性”条款的协议要求任何基于该代码提供网络服务的衍生作品也必须开源而MIT许可证则极其宽松几乎允许任何形式的包括商业闭源的使用、修改和分发。mold创始人Rui Ueyama在发布公告中坦言此前采用AGPL是希望探索一种“开源核心商业许可”的双重授权模式为项目可持续发展寻找资金支持但实际效果未达预期。因此团队决定拥抱更开放的MIT许可证以最大化项目的采用率和社区影响力。这个决定对于广大开发者而言无疑是个好消息意味着我们可以更无顾虑地将mold集成到各种开发环境和商业产品中。除了许可证变更2.0.0版本也修复了一些关键问题比如之前无法处理包含超过65520个“节区”section的重定位目标文件这在大规模项目链接时可能成为瓶颈。同时为了提升与现有构建脚本的兼容性mold也调整了一些命令行参数的解释方式向GNU ld和LLVM lld的行为看齐。接下来我们就深入拆解一下mold的设计思路、它为何能这么快以及在实际项目中如何上手使用和避坑。2. 高性能链接器的设计哲学与实现原理要理解mold为什么快我们得先看看传统链接器慢在哪里。链接器的工作通俗讲就是把一堆编译好的目标文件.o文件和库文件像拼拼图一样组合成一个最终的可执行程序或共享库。这个过程主要包含几个耗时的步骤符号解析解决谁调用谁的问题、节区合并把相同类型的数据堆到一起、重定位修正代码中的地址引用。传统链接器如GNU ld在设计之初并没有充分考虑如今动辄数百万行代码、极度复杂的项目结构其算法和数据结构在应对大规模输入时效率不高尤其是大量使用线程局部存储TLS或调试信息时。2.1 核心加速策略并行化与高效数据结构mold的性能秘诀核心在于极致的并行化和精心设计的数据结构。我把它总结为以下三个层面全链路并行处理这是mold最显著的加速点。从读取输入文件开始mold就尝试并行化所有可能的工作。例如解析多个目标文件的符号表、处理重定位条目、甚至生成输出文件的某些部分都可以在多个CPU核心上同时进行。相比之下GNU ld和gold的并行化支持有限lld虽然也支持并行但mold在任务划分和调度上更为激进和高效。它特别针对多核处理器进行了优化能够充分利用现代CPU的所有核心。内存映射文件mmap的广泛使用mold大量使用mmap系统调用来处理输入文件。mmap允许程序将文件直接映射到进程的虚拟内存空间避免了传统的read/write系统调用带来的数据拷贝开销。当链接器需要读取目标文件中的代码、数据或调试信息时直接访问内存映射区域即可这大大减少了I/O等待时间尤其是在处理大量小文件时优势明显。定制化的高效数据结构链接过程中需要频繁进行符号查找、节区管理和地址计算。mold没有使用C标准库中通用的容器如std::unordered_map而是为链接这个特定场景量身定制了哈希表、向量等数据结构。这些定制容器减少了内存分配次数、优化了缓存局部性使得高频操作的速度得到数量级的提升。2.2 与LLVM lld的差异化竞争很多人会问LLVM项目下的lld链接器也已经很快了mold还有必要吗我的体会是两者在设计目标和优化侧重点上有所不同。lld作为LLVM生态系统的一部分强调与Clang编译器的深度集成、跨平台支持支持Linux/macOS/Windows以及对LLVM位码bitcode的良好支持。它的代码非常严谨可移植性强。而mold则更像一个“偏科生”它最初的目标就是成为在Unix-like系统主要是Linux上最快的链接器。因此它可以为了极致的性能采用一些更激进、更依赖特定系统特性的优化手段。例如mold在内存分配策略、线程池的实现上更加“赤裸”直接追求最低延迟。在实际基准测试中对于纯ELF格式Linux标准格式的链接任务mold通常能比lld再快上一截。当然这种极致的优化有时会以牺牲一些可移植性或代码的简洁性为代价。注意mold目前主要专注于支持ELF格式用于Linux和大多数Unix系统。虽然已有实验性的macOSMach-O格式支持但其稳定性和性能尚未达到生产级别。如果你的主战场是Linux服务器或桌面开发mold是绝佳选择如果涉及跨平台构建可能需要评估lld或保持原有链接器。3. 从零开始mold的安装与基础使用指南说了这么多不如亲手试试。下面我将以Ubuntu 22.04 LTS为例带你完成mold的安装和基本使用。其他Linux发行版的步骤也大同小异。3.1 安装mold最推荐的方式是通过系统的包管理器安装这能确保依赖关系被正确管理。# 对于 Ubuntu/Debian 及其衍生版 sudo apt update sudo apt install mold # 对于 Fedora/RHEL/CentOS (需要启用EPEL) sudo dnf install mold安装完成后你可以通过mold --version来验证安装。如果你想尝试最新的2.x版本而系统仓库中的版本较旧可以考虑从源码编译。源码编译需要安装一些开发工具链# 安装编译依赖 sudo apt install build-essential git clang cmake libstdc-12-dev zlib1g-dev # 克隆仓库并编译 (以2.0.0为例) git clone https://github.com/rui314/mold.git cd mold git checkout v2.0.0 make -j$(nproc) CXXclang sudo make install从源码编译默认会安装到/usr/local/bin。使用make编译时我强烈建议指定CXXclang因为mold的代码基对Clang编译器的优化更加友好通常能生成比GCC更高效的二进制文件。3.2 在项目中启用mold使用mold链接你的项目主要有三种方式推荐程度由高到低方法一直接调用最灵活在链接命令中将原本的ld、gold或lld替换为mold即可。# 例如直接链接目标文件 clang -o myapp main.o utils.o -fuse-ldmold # 或者在完整的构建命令中 clang -stdc17 -O2 main.cpp utils.cpp -o myapp -fuse-ldmold-fuse-ldmold这个编译器选项告诉Clang/GCC使用mold作为链接器。这是我最常用的方式可以针对单个构建命令进行切换。方法二通过环境变量覆盖全局或会话级你可以设置环境变量让系统默认使用mold。这适用于你想在某个终端会话或用户范围内全局替换链接器。# 对于GCC export GCC_LDmold # 对于Clang export LDld.mold # 或者更通用的覆盖默认的ld export LD/usr/bin/ld.mold设置后在此终端中运行的构建系统如make、cmake就会自动使用mold。但要注意这可能会影响系统中其他软件的编译建议仅在项目开发目录下使用。方法三替换系统默认链接器不推荐通过符号链接将/usr/bin/ld指向mold。这种方法最激进可能造成系统软件包管理如dpkg出现问题除非你非常清楚自己在做什么否则应避免在生产系统上这样操作。3.3 验证与基准测试安装并启用后如何确认mold真的在干活并且效果如何呢首先检查链接器身份# 查看最终可执行文件使用的链接器 readelf -p .comment your_program | grep -i linker # 或者在链接时添加 -Wl,--version 参数输出会更直接 clang -o test test.c -fuse-ldmold -Wl,--version其次做一个简单的速度对比。创建一个包含多个源文件的小项目或者直接找一个现有的中型项目。分别用默认链接器和mold进行完整构建确保先make clean用time命令记录时间time make -j$(nproc) CCclang CXXclang LDFLAGS-fuse-ldbfd # 使用GNU ld time make -j$(nproc) CCclang CXXclang LDFLAGS-fuse-ldmold # 使用mold你会看到链接阶段linking的时间差异。对于大型项目差异可能从数秒到数分钟不等。4. 深入解析mold 2.0.0的关键更新与兼容性实践mold 2.0.0版本除了许可证变更还包含了一些重要的功能修复和兼容性改进这些变化直接影响着我们在复杂项目中的使用体验。4.1 许可证变更的深远影响从AGPL v3切换到MIT这个变化的技术含量为零但生态影响巨大。我梳理了一下这对不同角色的意义对于个人开发者和开源项目这是纯粹的利好。你可以毫无顾忌地在任何项目中使用mold无论是个人工具、学术研究还是其他开源软件无需担心许可证“传染”问题。你可以自由地修改mold的代码并将其集成到你的专有构建系统中而无需开源你的系统。对于企业用户之前AGPL条款是许多公司法律部门审核开源软件时的“红色警报”。即使只是内部使用一些保守的公司也会避免引入AGPL依赖。变更为MIT后这个最大的法律障碍消失了预计会有更多企业愿意在开发流水线中采用mold以加速其CI/CD流程。对于mold项目本身创始人坦言商业化的尝试未达预期。转向MIT是一种务实的策略旨在通过扩大用户基础来构建更强大的社区从而通过捐赠、赞助或未来的其他模式如提供商业支持服务来获得可持续性。一个更庞大的用户群意味着更多的bug报告、补丁和特性贡献这对项目长期健康有益。4.2 重要问题修复处理超多节区的目标文件在2.0.0之前mold有一个限制无法使用--relocatable或-r选项生成包含超过65520个“节区”的目标文件。--relocatable选项用于生成可重定位的输出它本身也是一个目标文件.o常用于创建静态库.a文件。当你的项目非常庞大模块极多时合并后的重定位目标文件可能会超过这个节区数量限制。这个限制源于ELF格式规范中用于索引节区的字段sh_info在某些上下文中的宽度限制。mold 2.0.0修复了内部逻辑现在能够正确地处理这种情况。这对于构建像Linux内核这样超大型静态库的场景至关重要。如果你在之前版本中遇到类似“too many sections”的错误升级到2.0.0即可解决。4.3 命令行兼容性调整为了降低用户的迁移成本mold 2.0.0在命令行参数解析上做了些微调更贴近GNU ld和LLVM lld的行为-undefined的行为现在-undefined被当作--undefined的同义词处理而不是被解析为-u ndefined。这听起来有点绕我举个例子在GNU ld中-u symbol是--undefinedsymbol的缩写意思是“强制将symbol视为未定义符号以触发从库中链接它”。而-undefined本身是一个独立的选项在某些链接器如ld64中常见。mold现在遵循了GNU ld/lld的惯例将-undefined整体视为一个选项需要接参数如-undefined dynamic_lookup。这修复了之前一些从其他构建系统尤其是源自macOS的移植过来的脚本可能遇到的问题。-no-pie的支持现在-no-pie可以作为--no-pie的同义词。PIEPosition-Independent Executable是一种安全编译技术但某些旧的或特殊的程序可能需要禁用PIE。这个改动使得那些原本为GNU ld编写的、使用了-no-pie参数的构建脚本无需修改就能与mold协同工作。这些改动体现了mold开发团队的务实态度在追求极致性能的同时不牺牲与现有生态的兼容性。毕竟让用户无缝切换才是推广新技术的关键。5. 实战集成将mold融入现代构建系统与CI/CD单独使用mold命令链接很简单但我们的项目通常由CMake、Meson、Bazel等构建系统管理或者运行在GitLab CI、GitHub Actions等自动化流水线中。如何在这些场景中优雅地集成mold呢5.1 与CMake集成CMake是目前最流行的C/C构建系统生成器。集成mold非常直观主要有两种方式方式A通过CMAKE_EXE_LINKER_FLAGS变量项目级在你的CMakeLists.txt中最好在project()命令之后添加链接器标志。为了兼容性可以检查mold是否存在。# 查找mold链接器 find_program(MOLD_EXECUTABLE mold PATHS /usr/bin /usr/local/bin) if(MOLD_EXECUTABLE) # 为所有目标设置使用mold链接 set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -fuse-ldmold) set(CMAKE_SHARED_LINKER_FLAGS ${CMAKE_SHARED_LINKER_FLAGS} -fuse-ldmold) set(CMAKE_MODULE_LINKER_FLAGS ${CMAKE_MODULE_LINKER_FLAGS} -fuse-ldmold) message(STATUS Using mold linker: ${MOLD_EXECUTABLE}) else() message(WARNING mold linker not found, using default linker.) endif()这种方式会影响到该CMake项目中构建的所有可执行文件和库。方式B通过编译器缓存用户级如果你不想修改每个项目的CMakeLists.txt可以设置一个全局的编译器包装脚本或者使用像ccache这样的工具。更简单的方法是在调用cmake时通过环境变量传递工具链文件或缓存变量# 在命令行中指定 cmake -B build -DCMAKE_CXX_FLAGS-fuse-ldmold -DCMAKE_C_FLAGS-fuse-ldmold # 或者使用工具链文件更规范创建一个mold-toolchain.cmake文件内容如下set(CMAKE_C_COMPILER clang) set(CMAKE_CXX_COMPILER clang) set(CMAKE_EXE_LINKER_FLAGS -fuse-ldmold) set(CMAKE_SHARED_LINKER_FLAGS -fuse-ldmold) set(CMAKE_MODULE_LINKER_FLAGS -fuse-ldmold)然后使用cmake -B build -DCMAKE_TOOLCHAIN_FILE/path/to/mold-toolchain.cmake。5.2 与Meson集成Meson的集成同样简单。在你的meson.build文件中可以这样设置# 在project()定义之后 if meson.get_compiler(c).has_argument(-fuse-ldmold) add_project_link_arguments(-fuse-ldmold, language: [c, cpp]) endif或者在配置构建目录时通过meson setup传递参数meson setup build --native-file (echo [binaries]\n c [clang, -fuse-ldmold]\n cpp [clang, -fuse-ldmold])5.3 在CI/CD流水线中使用在自动化构建环境中为了确保一致性通常需要在CI脚本中显式指定使用mold。以GitHub Actions为例你可以在工作流文件中这样配置jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Install mold run: sudo apt-get update sudo apt-get install -y mold - name: Configure with CMake run: | cmake -B build \ -DCMAKE_C_COMPILERclang \ -DCMAKE_CXX_COMPILERclang \ -DCMAKE_C_FLAGS-fuse-ldmold \ -DCMAKE_CXX_FLAGS-fuse-ldmold - name: Build run: cmake --build build --parallel关键点在于CI环境中需要先安装mold包然后在调用CMake或直接调用编译器时确保-fuse-ldmold参数被正确传递。这样就能保证CI构建和本地开发使用相同的高速链接器。5.4 处理静态库与复杂依赖对于大型项目经常需要先构建静态库.a文件然后再链接成最终可执行文件。mold在链接最终目标时表现出色但生成静态库本身即ar命令打包.o文件并非链接器的工作。因此mold的优势主要体现在最终链接阶段。如果你的项目结构是“编译大量源文件 - 生成静态库 - 链接静态库成可执行文件”那么mold加速的是最后一步。为了最大化收益可以考虑调整项目结构减少中间静态库的数量和粒度让更多的目标文件直接参与最终链接但这需要权衡模块化和构建速度。6. 性能调优与疑难问题排查实录即便mold已经很快了但在某些极端场景下我们仍可能遇到性能瓶颈或奇怪的错误。以下是我在实际使用和社区交流中积累的一些调优经验和常见问题解决方法。6.1 监控与诊断链接过程想知道链接时间到底花在哪里了吗mold提供了一些有用的诊断选项--stats在链接结束后打印详细的统计信息包括各个阶段如读取输入文件、解析符号、重定位、写输出文件所花费的时间。这对于定位性能瓶颈至关重要。mold --stats -o program *.o--verbose或-v输出更详细的处理过程包括正在读取的文件、解析的符号等。输出信息较多适合调试复杂问题。--thread-countN手动指定mold使用的线程数量。默认情况下mold会尝试使用所有可用的CPU核心。但在一些共享的构建服务器上或者当你同时运行多个构建任务时限制线程数可能避免系统过载有时反而能获得更好的整体吞吐量。mold --thread-count4 -o program *.o6.2 常见问题与解决方案下面是一个快速排错指南列出了我从社区和自身实践中总结的几个典型问题问题现象可能原因解决方案链接错误undefined reference to ...1. 库文件路径未指定或顺序错误。2. 使用了mold但某些依赖库是用旧链接器生成的存在不兼容的符号格式罕见。1. 检查-L和-l参数确保库路径和顺序正确。GCC/Clang链接时依赖的库需要放在引用它的源文件或库之后。2. 尝试用默认链接器-fuse-ldbfd链接一次如果成功则可能是mod的bug。可向mold项目提交issue并附上最小复现代码。链接速度没有明显提升1. 项目本身很小链接不是瓶颈。2. 输入文件数量少并行优势无法发挥。3. 使用了-g调试信息且项目巨大写调试信息到输出文件成为瓶颈。1. 对于小项目链接本身很快加速感知不强这很正常。2. 尝试合并构建步骤减少中间静态库让更多.o文件直接参与最终链接。3. 考虑使用-gz选项生成压缩的调试信息如-gzzlib这能显著减少输出文件大小和I/O时间。mold处理压缩调试信息的效率也很高。生成的可执行文件无法运行报错Segmentation fault或Invalid ELF header1. mold本身存在bug在早期版本中更常见。2. 使用了不兼容的链接器选项组合。3. 输入的目标文件已损坏。1.首先回退验证使用系统默认链接器如-fuse-ldbfd重新链接如果程序运行正常则基本确定是mold问题。2. 升级到mold的最新稳定版如2.0.0。3. 简化链接选项移除如-flto链接时优化等高级选项看问题是否消失。4. 使用objdump或readelf检查输入.o文件的完整性。内存使用量过高项目极其庞大同时链接数万个目标文件和大型静态库。1. 使用--thread-count减少并行线程数可以降低峰值内存占用。2. 检查是否开启了-ffunction-sections -fdata-sections并配合--gc-sections。这些选项会产生大量小section增加链接器内存开销。对于超大型项目权衡是否值得开启。3. 考虑增加系统物理内存或交换空间。mold为追求速度会积极地将文件映射到内存。6.3 与链接时优化LTO的配合链接时优化LTO是一种强大的优化技术它允许编译器在链接阶段看到所有代码进行跨模块的优化。Clang/LLVM和GCC都支持LTO。当同时使用LTO和mold时流程通常是编译器将代码编译成中间位码bitcode链接器此时充当“链接时编译器”的角色读取所有位码进行全局优化再生成最终代码。mold本身不执行LTO优化但它可以与LLVM的LTO实现协同工作。当你使用Clang的-flto选项时实际上是由LLVM的libLTO库在链接器内部完成优化。mold通过插件机制支持这一点。确保你的系统安装了LLVM开发包如llvm-dev、liblto-dev。使用命令大致如下clang -flto -fuse-ldmold -o program main.cpp utils.cpp在这种情况下链接时间会比不使用LTO时长很多因为增加了全局编译优化的开销。但mold在读取、调度这些位码文件以及写最终输出时其高效的I/O和并行处理能力仍然能带来收益。我的经验是对于追求极致运行速度的发布版本开启LTO是值得的尽管构建时间会增加而对于日常调试构建关闭LTO并使用mold能获得最快的编辑-编译-调试循环。7. 开源生态下的思考与未来展望mold从诞生到2.0.0其发展路径折射出高性能基础设施软件在开源生态中的一些典型挑战和选择。最初采用AGPL反映了开发者对项目可持续性的担忧希望借助“双许可”模式从商业用户那里获得资金。这条路在许多数据库如MySQL、大数据工具中走得通但对于链接器这类更底层、更“工具化”的软件企业付费购买商业许可的意愿可能低得多。最终转向MIT是一种回归开源本质的策略拥抱最广泛的社区通过创造不可替代的价值来吸引贡献和支持。从技术角度看mold的成功证明了在看似成熟的工具链领域依然存在通过架构创新实现数量级性能提升的空间。它刺激了LLVM lld等竞争对手的进一步优化最终受益的是整个开发者社区。对于开发者而言mold 2.0.0的发布和MIT许可证的采用消除了采用它的最后一道心理和法律门槛。它不再仅仅是一个“更快”的选项而是一个可以放心推荐、广泛部署的标准工具。我个人在多个C项目中全面切换到mold已经超过一年整体的体验非常稳定。构建时间的减少尤其是CI流水线上时间的节省直接提升了团队的工作效率。偶尔遇到边缘案例的兼容性问题在社区和issue列表中通常都能找到解决方案或快速得到响应。随着2.0.0版本的发布和许可证的放宽我预计mold会更快地进入各大Linux发行版的默认仓库并被更多的开源项目如Rust的rustc其实也在评估集成mold作为链接后端和商业产品所采用。最后给想尝试的朋友一个切实的建议如果你的开发环境是Linux主要开发语言是C/C/Rust并且项目规模达到一定程度链接时间超过5秒那么花上半小时配置并切换到mold很可能是一项投入产出比极高的投资。从今天发布的2.0.0版本开始你可以毫无顾虑地这么做了。
