Wild linker：用 Rust 重写链接器，目标直指增量链接
Linux 的非常快的链接器。 Rust (Cargo) 您可以在 ~/.cargo/config.toml 中使用上面提到的选项之一： 或者：CMake CMake 4.4 或更高版本与 Clang 或 GCC 16 或更高版本一起使用时直接支持 Wild。
秒懂
- 它是什么？
- Wild 是一个面向 Linux 的快速链接器，用 Rust 编写，目前已经能作为 GCC 或 Clang 的替代链接器使用。它的最终目标是实现增量链接，但现阶段还没有做到。
- 适合谁用？
- Wild 适合那些正在用 GNU ld 或 lld 做日常开发、且对链接时间敏感的人，尤其是 Rust 和 C++ 项目。它不适合需要复杂链接脚本、Mach-O 或 Windows 支持的用户，也不适合对增量链接有硬需求的人，因为那个功能还没实现。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 5 天前。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
为什么还需要一个新的链接器
链接器在构建流程里往往是最后一步，但它的速度直接决定了迭代开发的节奏。mold 已经很快了，但作者明确表示不做增量链接，而增量链接恰恰是缩短重复构建时间的关键。Wild 的出发点就是补上这个空缺。它用 Rust 写，因为作者认为 Rust 的内存安全和并发模型能让增量链接的复杂度变得可控。目前 Wild 还没有增量链接，但它的架构设计已经在为这个目标铺路。对开发者来说，Wild 现在能提供的价值是：在非增量场景下，它已经足够快，而且未来有明确的性能提升空间。
Wild 是怎么工作的
Wild 是一个 drop-in 的链接器，意思是它可以直接被 GCC 或 Clang 调用，替换掉默认的 GNU ld 或 lld。它的工作方式不是自己解析编译命令，而是通过编译器传递的参数被激活。Clang 可以用 --ld-path=wild 直接指定，GCC 16.1 以上和 Clang 都支持 -fuse-ld=wild，但 Clang 要求存在 ld.wild 这个二进制或符号链接。更通用的方式是 -B 参数，它告诉 GCC 在指定目录里找链接器，你只要把 wild 软链成 ld 放在那个目录里就行。这种设计让 Wild 能融入现有的构建系统，而不需要改动编译流程。
安装和接入 Cargo 的具体步骤
安装 Wild 有几种途径。最简单的是用 cargo-binstall，执行 cargo binstall wild-linker。也可以用 brew install wild-linker/wild/wild，或者从 crates.io 用 cargo install --locked wild-linker 编译安装。想用最新未发布代码，可以从 git 仓库安装。装好之后，在 ~/.cargo/config.toml 里配置链接器。一种方式是设 linker 为 clang，然后加 rustflags 参数 -Clink-arg=--ld-path=wild。另一种方式是直接用 -fuse-ld=wild，但如果你用的 GCC 版本低于 16，需要先取消注释 linker = "clang" 那行，因为 GCC 16 以下不支持这个参数。配置完，cargo build 就会调用 Wild 来链接。
CMake 和传统构建系统的接入方式
CMake 4.4 或更高版本直接支持 Wild，只要在命令行加 -DCMAKE_LINKER_TYPE=WILD，配合 Clang 或 GCC 16 以上就能用。对于更老的 CMake，或者 autotools、meson 这类构建系统，通常设置 LDFLAGS 环境变量就行，比如 export LDFLAGS="${LDFLAGS} -fuse-ld=wild"。但有些项目会自己实现链接器调用逻辑，这时候更可靠的办法是创建一个符号链接：ln -s /usr/bin/wild /tmp/ld，然后把 -B/tmp 加到 CFLAGS、CXXFLAGS 和 LDFLAGS 里。这样 GCC 会在 /tmp 目录下找到名为 ld 的链接器，也就是 Wild。文档提醒说，配置完最好用 readelf --string-dump .comment 检查二进制，确认链接器确实是 Wild。
支持范围和已知的坑
Wild 目前支持的平台包括 x86-64、ARM64、RISC-V (riscv64gc) 在 Linux 上，LoongArch64 和 PPC64LE 是初步支持。输出方面，它支持静态链接、静态 PIE、动态链接和共享库。调试信息也能处理。但它不支持增量链接，这是最大的缺口。更复杂的链接脚本也还没实现，文档里有一个支持矩阵可以查。Mach-O 和 Windows 支持完全没做。另外，链接器插件 LTO 有已知问题，在 GitHub 的 issue 列表里可以找到。如果你依赖这些功能，Wild 目前不是合适的选择。
性能测试和验证方法
Wild 的 README 里给出了基准测试链接，包括 Ryzen 9955HX、老旧 Intel 笔记本和树莓派 5 上的数据。测试对象有 Chromium、librustc-driver 和 Wild 自身。所有基准都跑在 tmpfs 上，这是为了消除磁盘 I/O 的影响。文档强调，如果你想自己跑基准，可以参考 BENCHMARKING.md。一个值得注意的点是，Wild 的链接时间在版本迭代中持续下降，这说明它在非增量场景下也在优化。验证 Wild 是否真的被用上，可以用 readelf --string-dump .comment 查看 .comment 段，里面会有一行类似 Linker: Wild version 0.1.0 的内容。
维护成本和许可证
Wild 采用 Apache-2.0 许可证，这对商业项目相对友好，但如果你需要修改后闭源分发，要注意 Apache 2.0 的条款。项目最近一次发布是 0.10.0，更新频率看起来是几个月一个版本。由于它是 Rust 写的，安装时如果选择从源码编译，需要 Rust 工具链。作为链接器，Wild 的维护成本主要体现在：它需要跟上 GCC 和 Clang 的参数变化，以及处理不同架构的 ABI 差异。文档里提到 GNU jobserver 支持，说明它在并行构建环境下能正常工作。如果你打算长期依赖它，建议关注它的 release 节奏和 issue 列表，特别是 LTO 相关的已知问题。
编辑结论
Wild 适合那些正在用 GNU ld 或 lld 做日常开发、且对链接时间敏感的人，尤其是 Rust 和 C++ 项目。它不适合需要复杂链接脚本、Mach-O 或 Windows 支持的用户，也不适合对增量链接有硬需求的人，因为那个功能还没实现。采用前先确认你的平台是否在支持列表里，比如 x86-64 和 ARM64 没问题，但 LoongArch64 和 PPC64LE 还只是初步支持。另外，如果你用 GCC 版本低于 16，就得靠 -B 参数或 clang 的 --ld-path 来调用 Wild，否则不会生效。最后，用 readelf 检查 .comment 段，确认链接器确实被用上了。
社区笔记