mold: a drop-in Unix linker that shortens the link step of C, C++ and Rust builds

The link step mold targets, and who feels it

A build in a compiled language has two phases. The compiler turns source files into object files, and the linker then combines those object files into one executable or shared library. The README is explicit that the second phase can be time-consuming when the build output is large, and that shortening it matters most during rapid debug-edit-rebuild cycles. That is the audience: developers who rebuild a big binary dozens of times a day and spend the wait watching a terminal.

The README frames mold as a high-performance drop-in replacement for existing Unix linkers. Drop-in is the operative word. You are not rewriting a build system; you are pointing the existing one at a different linker binary. The project has been in production use since 2021, according to the README, and the README states it is the default linker of many large open-source projects and is used internally by many companies. The author is the original developer of LLVM lld, and the README describes mold as an effort to build a faster linker from scratch, free of the architectural limits encountered while optimizing lld. That history is a reason to take the design seriously, not a reason to trust the numbers.

Supported targets, per the README: x86-64, i386, ARM 32/64, RISC-V 32/64, PowerPC 32/64, s390x, LoongArch 32/64, SPARC64, m68k, and SH-4. Windows is not on that list, which matters for anyone arriving from search results that mention mold on Windows.

How mold gets its speed: parallelism plus data structure choices

The README attributes the speedup to pervasive parallelism and to efficient data structures and algorithms, and points to a paper titled "mold: A Massively Parallel Linker" for the details. That is the level of mechanism the README itself gives; the paper is where the concrete algorithms live, and the repository README does not reproduce them.

The practical consequence of a parallel linker is that link time scales with available cores rather than being dominated by a single-threaded pass. The benchmark tables in the README bear this out in shape, even if you treat the absolute numbers with suspicion: the gap between mold and lld is far larger on the 64-core Threadripper than on the M1 Ultra, where the benchmark is restricted to performance cores. On the Threadripper, debug Chromium 145 goes from 16.64s with lld to 1.65s with mold. On the M1 Ultra the same program goes from 9.54s to 2.22s. Both are wins, but the workstation result is the one that looks like a different category of tool.

One row deserves attention because it undercuts a simple story. On the M1 Ultra debug build of Clang 21, mold is 2.96s against wild's 2.78s, so mold is slower there. The README's headline figure is a median across nine programs on two machines, and medians hide rows like that. If your build is a single mid-sized binary rather than a huge one, the margin you actually see may be much smaller than the headline.

Building mold from source and what the repository documents

The README does not give a package-manager install command, and it does not walk through a first link. What the repository does provide is the build scaffolding: a top-level CMakeLists.txt, an install-build-deps.sh script, an install-cross-tools.sh script for cross toolchains, and a dist.sh script. The benchmark section of the README says the three linkers were built from source in release configuration as of 2026-08-28. So the documented path to a mold binary is building the repository, and the dependency script is the piece specific to this project.

Because the README does not publish a command sequence, the honest statement is that the install procedure is not documented in the README. The files that exist are the ones above, and the two scripts are named so that their purpose is evident from the filename. If you want mold, start by reading install-build-deps.sh and CMakeLists.txt rather than looking for a documented one-liner.

The same gap applies to using it. The README describes mold as a drop-in replacement for existing Unix linkers, which tells you the integration model but not the exact invocation. How you select a linker is a property of your compiler driver and build system, not of mold, and the README does not spell it out. Treat the integration step as something to work out against your own toolchain, and check your distribution's package index before building from source, since a packaged mold would avoid the dependency script entirely.

Where mold is the wrong tool

The clearest boundary is the target list. mold supports Unix linkers on the architectures the README enumerates; Windows is absent. If you ship a Windows build, mold is not part of that pipeline, and no amount of build-system configuration changes that.

The second boundary is less obvious and more dangerous. A drop-in replacement is only drop-in for the features it implements. The benchmark table gives a direct example of a linker capability that not every tool has: wild's Chromium release links are marked N/A because wild does not implement --icf=all and links without identical code folding. That tells you that linkers in this space differ in which options they support, and that a missing option can make a link impossible rather than merely slower. The README does not publish a list of options mold does not implement, so the only reliable check is your own build: if your link line uses an unusual flag or a vendor-specific linker script, confirm mold accepts it before committing to the switch.

Third, the benefit is not uniform. The M1 Ultra rows show smaller ratios than the Threadripper rows, and at least one row where mold loses to wild. If your link step is already short, the absolute saving is small, and the cost of adding a second linker to your toolchain, plus the CI images that must carry it, may not be worth the change.

mold against LLVM lld and wild

The README benchmarks three linkers: LLVM lld, wild, and mold. lld is the more established option and the one most build systems already know how to select, which is why it is the natural default to compare against. The README's framing is that mold started from scratch to escape architectural limits its author hit while optimizing lld, so the difference in approach is not a set of flags but the internal design, which the README summarizes as pervasive parallelism with efficient data structures and algorithms.

wild is the more interesting comparison because it is the newer entrant and the README reports it as consistently faster than lld where it can link at all. The measured relationship in the Threadripper debug table is roughly 2.3x to 4.5x in mold's favor over wild, and the README's summary figure is 1.9x faster than wild at the median. But wild's coverage is narrower: several rows are N/A, including all the Firefox rows and TensorFlow, and the Chromium release rows are excluded because of the missing --icf=all. So the real difference is not just speed. wild is faster than lld on the programs it supports; mold is faster than both and supports more of the benchmark suite. If you are choosing between them, the deciding question is whether your link line needs an option only one of them implements.

Both comparisons come from the project's own benchmark, run on the project's own inputs. The suite is published on Zenodo, which means you can inspect the inputs, but the numbers are still the author's.

Licence, maintenance and the cost of upgrading

mold is MIT licensed. That is a permissive licence, and for most teams it removes the question entirely: you can link it into a build pipeline, redistribute the binary, and ship the resulting executables without a copyleft obligation on your own code. This is not legal advice; if your organisation has a policy on which licences are acceptable in build tooling, MIT is normally on the allowed list, but the decision is yours to confirm.

The repository is not archived, and the last push was on 2026-08-12, which is when v2.42.0 was released. The release before that, v2.41.0, was on 2026-04-13, and v2.40.4 was on 2025-08-17. So the cadence is roughly a minor release every few months with patch releases in between. That matters for upgrade cost in a specific way: a linker sits underneath every binary you produce, so a regression in it can look like a bug in your code. Pinning a known-good mold version in CI and bumping it deliberately, rather than tracking the newest tag, is the cheaper habit.

Upgrading also means rebuilding the tool itself if you install from source, since the repository ships dependency and build scripts rather than a documented binary distribution. On a large CI fleet that is a build step you now own. A packaged mold from your distribution avoids that, at the cost of running whatever version the distribution shipped.

Editorial conclusion

Adopt mold if you build large C, C++ or Rust programs on a Unix-like system and the link step shows up in your build times; the README presents it as a drop-in replacement, so selecting it is often the whole change. Skip it if you target Windows, or if your toolchain depends on a linker feature mold does not implement. Before rolling it out, verify your target triple is in the supported list and that your build system can be told to use mold, then compare one full build with and without it rather than trusting any published table.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes