If linking is the slow step of your Rust or C++ build, mold 3.0 is the fastest direct replacement out there, and it’s activated with three lines of configuration. Version 3.0.0 of this fast linker for Linux came out on October 5th and rewrites the C++ linker to Rust without changing anything about how you use it. It accepts the same command-line options as 2.42.1, supports the same architectures, and generates the same output, except for bug fixes.
What is a linker and why does linking time matter?
A linker is the program that joins all the object files from your project into a single executable or shared library. Compiling a language like C, C++, or Rust happens in two phases. First, the compiler converts each source file into an object file (.o). Then, the linker combines all those objects.
In large projects, that second phase becomes slow, and you notice it most in the edit, recompile, and test cycle. If you change a single line, the compiler does very little rework, but the linker often has to redo everything.
mold is the work of Rui Ueyama, the original developer of lld, the LLVM linker used to build Android, Chrome, and FreeBSD, among others. mold was born as his attempt to create something faster from scratch, without the architectural limitations he encountered optimizing lld. It’s been in production since 2021, has over 140 contributors and 17.5k stars on GitHub, and is the default linker for many large open source projects.
What changes in mold 3.0?
The main change is the language. Version 3.0 is the first version of mold in Rust, and 2.42.1 is the last in C++. If you compile mold from source, here’s what changes:
- Cargo replaces CMake.
cargo build --releasecompiles it and./install-mold.shinstalls it. The old CMake options disappear. - oneTBB is no longer a dependency. mold continues to link mimalloc statically by default, and you can compile it with
--features system-allocatorto use the system malloc. - A corrupted file no longer causes a segfault. The C++ version could read out of bounds with a malformed object file and crash with a segmentation fault. In 3.0 those reads have bounds checking, so mold stops with a panic right at the bad access.
If you just use mold, nothing changes. Linking performance is on par with 2.42.1: the rewrite brings safety and maintainability, not speed. To verify compatibility, the maintainers ran the test suite on all supported architectures, compared output on real workloads, and compiled all Gentoo packages. They report zero regressions. The release also includes a long list of fixes, especially for relocatable output (-r) and less common architectures.
The big ambition lies ahead. The stated goal of the 3.x series is to close the remaining compatibility gaps with GNU ld, especially support for linker scripts. That would make mold a practical option as the default /usr/bin/ld for a Linux distribution, and open the door to linking kernels and embedded firmware. At the time of publishing this note, that’s a roadmap, not a feature of 3.0.
Was mold rewritten in Rust with AI help?
Yes, in part, and it’s documented in the repository itself. At the time of publishing this note, dozens of commits in mold’s history carry the signature Co-Authored-By: Claude. Ueyama’s cite Claude Fable 5, and Chris Allen’s contributions cite Claude Opus 5.5.
These aren’t cosmetic commits. One from August, for example, parallelizes sorting of the 44,683 input files in a Chromium link, a step that previously took 7 ms in a single thread. Others fix an infinite loop in thin archive files or a dangling pointer in the LTO plugin.
It’s one of the most visible cases so far of an expert maintainer using a code agent to port a critical systems tool. And he publishes it with a level of verification few projects match: the entire Gentoo tree compiled with mold, with GNU ld as a control, before each release.
mold or lld: which is faster?
mold is faster than lld by a wide margin, according to the project’s own benchmarks. These are self-reported figures, published in mold’s README and measured in August 2026 on two machines. The three linkers compared were compiled from source and run with their default options. At the median, the README reports mold as 4.9× faster than lld and 1.9× faster than wild.
Some representative links from debug builds on a 64-core AMD Threadripper 7980X:
| Program | lld | mold |
|---|---|---|
| Chromium 145 | 16.64 s | 1.65 s |
| Clang 21 | 6.19 s | 1.34 s |
| Godot 4.6 | 1.77 s | 0.46 s |
| TensorFlow 2.21 | 50.73 s | 3.15 s |
Two caveats keep the mold vs lld comparison honest:
- The difference shrinks with fewer cores. On an Apple M1 Ultra limited to its 16 performance cores, the debug link of Clang 21 goes from 4.40 s with lld to 2.96 s with mold. That’s 1.5×, not 4.6×. mold’s speed comes from parallelism, so the more cores, the more it wins.
- wild sometimes ties or wins. wild is another fast linker written in Rust, Linux-only. On the M1 Ultra it beats mold on some release builds; Blender, for example, takes 0.20 s with wild versus 0.25 s with mold. That said, wild can’t link several of the benchmark programs.
The table compares mold with lld and wild, not with GNU ld, which is the default linker on most Linux systems. If you’ve never changed linkers, your starting point is GNU ld, and that’s the comparison you should measure on your own project.
How to use mold with Rust and Cargo?
Create the .cargo/config.toml file in your project directory:
[target.'cfg(target_os = "linux")']
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=/path/to/mold"]
Replace /path/to/mold with the absolute path to the mold executable. The example uses clang as a linker driver because it always accepts -fuse-ld. If your GCC is recent enough to recognize that option, you can remove the linker line and use the short form:
[target.'cfg(target_os = "linux")']
rustflags = ["-C", "link-arg=-fuse-ld=mold"]
To use mold in all your Rust projects, put the same block in ~/.cargo/config.toml.
How to use mold with C or C++ in GCC and Clang?
Just add an option to your compiler driver:
- Clang:
-fuse-ld=mold - GCC 12.1.0 or later:
-fuse-ld=mold - GCC before 12.1.0: older versions don’t accept
moldas a value for-fuse-ld, so use-Binstead. If you installed mold with its script, pass-B/usr/local/libexec/moldand adjust the prefix if you installed it elsewhere.
If you can’t touch your build system options, mold can intercept the linker for you:
mold -run make <make-options>
This redirects any call to ld, ld.bfd, ld.gold, or ld.lld to mold. It works on Linux and FreeBSD. For CI, the project maintains a GitHub Action called setup-mold.
How to install mold?
The easiest way is through your distribution’s package manager, because mold is widely packaged. Check on Repology what version your distribution offers, since 3.0 will take time to reach all repositories. Each GitHub release also includes precompiled binaries for Linux on x86-64, ARM64, ARM32, RISC-V, PPC64LE, s390x, and LoongArch.
To build it from source you need a stable and recent Rust toolchain and a C compiler. The release notes indicate the exact minimum version.
git clone https://github.com/rui314/mold.git
cd mold
cargo build --release
sudo ./install-mold.sh
The script installs mold in /usr/local. Set PREFIX to install it elsewhere, for example sudo PREFIX=/usr ./install-mold.sh.
How to verify that mold linked your binary?
mold leaves an identification string in the .comment section of the output file:
readelf -p .comment <executable-file>
If the output includes a line starting with mold, that binary was linked by mold. Run this check once after changing the configuration: an option that wasn’t silently applied looks exactly the same as a linker that isn’t any faster.
Does mold work on macOS or Windows?
No. At the time this note was published, the README documents Linux, with mold -run also available on FreeBSD. Its precompiled binaries are Linux-only, and there is no documented path for macOS or Windows. On those platforms, mold is not an option today.
What breaks with the Rust rewrite?
For most developers, nothing, because 3.0 is a drop-in replacement. The cost falls on a small group: Linux distributions that compile their entire toolchain from source and used mold as a linker in the early stages.
The problem is one of order. When a distribution builds everything from scratch, the C and C++ toolchain goes first and Rust comes much later. A C++ linker could be compiled early and used to link everything else, including Rust itself. A Rust linker can’t be compiled until Rust exists.
In the version discussion on Hacker News, the co-maintainer of a distribution that uses mold as the system linker explained the impact. Their distribution will have to continue maintaining the C++ version, which they called “mold2”, for the bootstrap stage, and will only be able to switch to mold 3 for software built after Rust.
This matters for bootstrapping from source and for builds hardened against supply chain attacks. It doesn’t affect you if you install mold from a package or a release binary.
What about you? How long does linking take in your heaviest build today, and have you ever measured it?
- The default one (GNU ld)
- lld
- mold
- I prefer another option (tell us which)
Comment below or, if you got this article by email, reply directly to the email: your response will be published here.
Related: Zig 0.17: what breaks in your build.zig and how to enable incremental compilation