mold 3.0.0 released: high-speed linker rewritten in Rust with GNU ld compatibility push

The high-speed linker mold has reached version 3.0.0, the first release built entirely in Rust and the end of the line for the C++ codebase. According to the release notes published on GitHub, and currently on the front page of Hacker News, version 2.42.1 was the last C++ release, and the rewrite had already been announced in that release's notes.

The maintainers describe mold 3.0 as a drop-in replacement for 2.42.1: it accepts the same command-line options, supports the same target architectures and produces the same output apart from the bug fixes in this release. Linking performance remains on par with the previous version. To back the compatibility claim, the project says it ran its test suite on every supported target, compared linker output across a broad range of real-world workloads and option combinations, and built all Gentoo packages, finding no regressions.

Safer on corrupted input

One behavioral change comes directly from the language switch. The C++ implementation could read memory out of bounds when handed a corrupted input file and crash with a segmentation fault. In the Rust version those reads are bounds-checked, so mold now stops with a panic at the faulty access rather than touching memory it should not.

Build system moves to Cargo

For anyone building mold from source, the toolchain has changed considerably:

• mold is now built with Cargo instead of CMake, requiring Rust 1.95 or later plus a C compiler. cargo build --release produces the binary and ./install-mold.sh installs it, with the script accepting PREFIX and DESTDIR. The old CMake options are gone.
• The MOLD_TARGETS CMake variable has been replaced by Cargo features, and distributions are still advised to build for all targets.
• The dependency on oneTBB has been dropped. mold continues to statically link mimalloc 3.5.3, with a --features system-allocator escape hatch, and links the system zlib when available while bundling zstd and BLAKE3. Setting ZSTD_SYS_USE_PKG_CONFIG=1 switches to the system zstd.
• The test suite now runs under cargo test, and install-build-deps.sh has been replaced by install-test-deps.sh.

The notes also warn that if mold's libraries are installed outside $PREFIX/lib, the MOLD_LIBDIR environment variable must be set during both build and install so that mold -run can locate mold-wrapper.so.

Bug fixes and compatibility cleanup

The release carries a long fix list. A few entries stand out:

• Options written with a single dash are now parsed the way GNU ld parses them; previously -entry=main was misread as -e ntry=main.
• mold no longer reserves 8 GiB of virtual address space at startup, which means it now works under ulimit -v restrictions.
• Common symbols sharing a name but with different sizes now receive the largest size and the strictest alignment, matching GNU ld and lld.
• --gc-sections no longer discards the functions named by --init and --fini, and several previously nondeterministic outputs, involving --dependency-file, --repro and certain COMDAT and dynamic relocation cases, are now deterministic.
• A number of failure modes that used to yield corrupted output or crashes now raise errors instead, including --defsym aliasing a symbol defined in a shared library and combining --strip-all with --emit-relocs.

Architecture-specific work includes fixing range extension thunks on AArch64, ARM32 and PPC32, a bug that produced wrong jump addresses in large programs, with the ARM64 debug build of Chromium cited as an example. There are additional relocation types for AArch64 and ARM32, LoongArch TLSDESC support in the extreme code model, IFUNC fixes for statically linked PPC64 executables, and fixes for SH4 and SPARC64 corner cases.

The road to a default linker

Beyond this release, the stated goal of the mold 3.x series is to close the remaining compatibility gaps with GNU ld, particularly in linker script support, and to prepare mold for adoption as the default linker in Linux distributions. The release notes also thank the project's sponsors for this cycle, among them Cybozu, SAP, Mercedes-Benz Group and Ahrefs.

Why it matters

Linkers sit at the bottom of the build stack, and swapping one in demands near-perfect compatibility with GNU ld, whose behavior, quirks included, effectively functions as a specification. mold 3.0 shows that a full memory-safety rewrite of a performance-critical system tool can land without measured regressions, and the build-all-of-Gentoo verification is exactly the kind of evidence distribution maintainers look for. The Rust switch also converts a class of memory-corruption failures into clean, bounded panics. The trade-off is operational: packagers now need a Rust toolchain and a Cargo-based build where CMake used to suffice. If the 3.x series closes the linker script gaps as planned, mold becomes a credible candidate for default-linker status, which would shorten link times across entire distributions.