Speed Up C++ Build Times with the mold Linker

The slowest part of a big C++ build used to be the moment I’d stand up, walk to the kitchen, and pour myself a coffee while the linker chewed through hundreds of object files. The compile step had already finished. It was that final combine-into-one-binary step that kept dragging on. If you work with C++ or Rust on Linux, you know exactly the wait I mean.

There’s a cleaner fix than a bigger coffee mug: swap the linker. mold is a drop-in replacement for the standard Unix linkers, and for a lot of real projects it finishes the same job in a fraction of the time. I tested it on my own machine today, and it’s worth the five minutes it takes to set up.

What a linker does, and why it can hog your day

When you build a compiled program, the compiler turns each source file into an object file (.o). The linker then takes all those object files and merges them into a single executable or shared library, resolving which function calls point to which addresses and laying everything out. On a huge project, that second phase is not a rounding error.

The problem is that classic linkers don’t parallelize well. They’ve been around for decades, and they mostly walk through the work on one core while the other fifteen sit idle. So the machine looks busy, but it isn’t really. That’s the inefficiency mold targets directly.

mold is the work of Rui Ueyama, who also wrote the LLVM lld linker — so this is someone who looked at the fastest open-source linker out there and decided it still wasn’t fast enough. If you enjoy DIY infra projects like the model router I built with LiteLLM, this is the same spirit: a focused tool that does one job extremely well.

What makes mold different

mold applies data parallelism across the whole linking pipeline instead of just in isolated stages. Roughly, it figures out how to split the work up front and then throws every core at it, the way a properly parallel build already does for compilation. The paper behind it, “mold: A Massively Parallel Linker” (accepted to ASPLOS 2027), reports that no single trick dominates — the speedup is the cumulative effect of parallelizing every pass.

In practice, the headline numbers are striking. On a simulated 16-core machine, linking a 1.35 GiB Chromium executable took LLVM lld 6.1 seconds and mold 1.52 seconds. A 0.47 GiB MySQL binary went from 10.84 seconds with GNU ld down to 0.46 seconds with mold. The author’s own claim is that mold is roughly 2.4–16× faster than lld and up to 112× faster than the traditional GNU ld on large debug binaries.

Installing mold — and the version trap

The straightforward path is your distro’s package manager. On Ubuntu I’d normally reach for sudo apt install mold. But there’s a catch worth knowing about: the Ubuntu 22.04 package is stuck at an old 1.0.x release, while current mold is 2.42.0. For the latest, grab the official prebuilt binary from the mold GitHub repository:

curl -L -o mold.tar.gz \
  https://github.com/rui314/mold/releases/latest/download/mold-2.42.0-x86_64-linux.tar.gz
tar -xzf mold.tar.gz
sudo cp -r mold-2.42.0-x86_64-linux/* /usr/local/

I ran that exact 2.42.0 binary on Ubuntu 22.04 (glibc 2.35) and it worked with no container, no compilation, nothing extra. If you’d rather build from source, you’ll need a recent C++ compiler — GCC 10.2 or Clang 16 or later — because mold is written in modern C++20. On macOS, brew install mold gets you there too.

Wiring mold into your build

How you turn mold on depends on your compiler and build system. This is where people get tripped up, so here’s the practical version for each case.

Clang, and GCC 12.1 or newer

If you’re on Clang, or a GCC release from 12.1 onward, it’s one flag:

g++ -fuse-ld=mold -o app *.o
clang++ -fuse-ld=mold -o app *.o

GCC 11 and older — the -B road

Older GCC versions don’t accept mold as an argument to -fuse-ld. I hit this live: the GCC 11.4 that ships on Ubuntu 22.04 rejects the flag outright with collect2: fatal error: cannot find 'ld'. For those compilers you use -B, which tells GCC where to look for its internal ld command instead:

g++ -B/usr/local/libexec/mold -o app *.o

That path contains an ld symlink that points to mold, so GCC’s driver finds it and hands the whole job over. If your mold install lives somewhere else, point -B at whichever directory holds that ld symlink.

CMake projects

For CMake, pass the flag through the linker flags for whatever compiler you’re using:

cmake -B build -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=mold"
cmake --build build -j$(nproc)

Rust and Cargo

Rust uses your system linker by default, so you can hand it mold too. Drop this in .cargo/config.toml for a project (or in ~/.cargo/config.toml to make it global):

[target.'cfg(target_os = "linux")']
rustflags = ["-C", "link-arg=-fuse-ld=/path/to/mold"]

I’d still test it per-project first — the fastest linker only matters if the build crosses the size threshold where linking is actually the bottleneck.

The mold -run escape hatch

Sometimes you can’t easily pass a flag through a build system. mold has a trick for exactly that situation: it intercepts every call to ld, ld.bfd, ld.gold, or ld.lld and redirects it to itself. Wrap your build command like this:

mold -run make

Under the hood it uses LD_PRELOAD to rewrite argv[0] when a linker is about to run. It’s a workaround, but a handy one when you’re dealing with a build you don’t control.

The numbers, and my honest benchmark

The dramatic charts come from multi-gigabyte projects, and I wanted to see what it did on something closer to what I actually compile. I wrote a small synthetic program with 501 translation units, linked it the plain way and then with mold, and measured each five times.

GNU ld (default):  median 0.72s
mold (-B):         median 0.60s   (~1.2x faster)

So on a toy-sized link, mold was measurably faster but not life-changing — about 1.2×. That’s the honest picture: mold’s real advantage shows up on big C++ codebases, where the paper’s 16×+ improvements live, not on a 500-file hello-world. If your project links in well under a second, switching linkers won’t matter much to you. If you’re waiting 30 seconds to several minutes on every rebuild, it absolutely will. The win also compounds in those rapid edit-test-debug loops I wrote about the tradeoffs of in a weekend build project — the less dead time per iteration, the more you can actually get done.

Verify mold is actually running

mold leaves a signature in a strip you can read after the fact, so you’re not just trusting a log line. Link your binary, then check its .comment section:

readelf -p .comment ./app

If mold did the work, you’ll see its name and version in the output — on my test it printed mold 2.42.0 (…; compatible with GNU ld), right next to the GCC version line. That’s a clean, objective way to confirm your build actually used mold instead of silently falling back to GNU ld. It’s the same reflex I’d apply to verifying any tool actually did what you asked, like checking whether an install hook has your back.

When mold makes sense — and when to skip it

Use mold when you can feel the wait: large C++ libraries, game engines, Chromium-scale components, or CI jobs where linking time multiplies across every runner. It’s a drop-in, so the risk is low and you can always flip back. You also get an easy win if you run a lot of my self-hosted infrastructure that builds from source, where a few saved minutes add up across upgrades.

Skip it when your links are already sub-second, when you’re on a platform mold doesn’t cover, or when your toolchain has a specific requirement to use the system linker. mold supports a broad set of architectures — x86-64, ARM, RISC-V, PowerPC, s390x and more — so the main thing blocking you is whether your distro ships a recent-enough package or you’re willing to take the prebuilt binary.

If you’ve got a slow link in your life, the ten minutes to add mold to your toolchain is one of the better returns on setup time. I keep coming back to the same lesson: a lot of the tools I reach for most — like the single-purpose CLI utilities that do one job and vanish — pay off precisely because they’re small and focused. mold is the same breed, except the job it does fast is one you’ve been waiting on.