PIMP MY IDE
Build systems / 05 OCT 2026

A rewrite does not inherit its proof.

mold 3.0 moved a production linker from C++ to Rust. The release claims drop-in behavior. Your build still needs its own acceptance lap.

Language is the least useful acceptance test

A linker rewrite invites a language debate. The deploy decision is narrower. Does the new binary accept your command line, produce the binary shape you depend on, reject damaged inputs cleanly, and fit your build chain?

The mold release reports broad testing across supported targets, real workloads, option combinations, and the Gentoo package set. That is strong upstream evidence. It is not a replay of your linker scripts, partial links, debug split, symbol versions, startup objects, or bootstrap order.

Treat "drop-in" as a testable contract, not an installation instruction.

mold 3.0 also changes failure behavior for corrupted files. A bounds violation that could become a segmentation fault in the C++ version now stops at a Rust bounds check. That improves memory handling. It does not prove that every valid object, relocation, script, or diagnostic matches what your release process needs.

Artifact check

We downloaded the published x86-64 Linux archive and ran its binary. It reported mold 3.0.0, commit 8de38c35, and GNU ld compatibility. That proves the release asset starts here. It does not test a project build.

Interactive replacement for a migration checklist

Linker transplant dyno

Choose the claim under review. Select the contracts your test plan covers. The rail shows selected sections, not passed evidence.

Test posture

Choose a linker review posture
Upstream evidence mapRecord what the release tested. Keep upstream results separate from your project results.

Contract rail

Command
Output
Failure
Build
Review state0 / 4 sections
TEST PLAN OPEN

No contract section is selected. The release has not been tested against this project.

Run the old and new linkers through the same lane

Start with a build whose inputs you can retain. Capture the compiler driver command, environment, linker version, wall time, exit status, and output hashes. Hash differences are a prompt to inspect. They are not an automatic failure because the 3.0 release includes output-changing bug fixes.

Inspect the parts your software consumes. Use tools such as readelf, objdump, symbol checks, loader smoke tests, and the project's own test suite. Replay at least one known failure. A new linker that accepts invalid input or changes an error into a crash has changed the contract even if the happy build passes.

Build integration deserves its own lane. mold 3.0 requires Rust 1.95 or later, uses Cargo, replaces CMake target selection with Cargo features, and changes the test command. That can matter more than link speed in a distribution bootstrap or hermetic builder.

Promote only after the same revision passes with both linkers and the differences have owners. Keep the old linker selectable until the new path survives a clean build, an incremental build, a failure replay, and one rollback drill.

Sources read

What the dyno rests on

mold 3.0.0 releaseThe C++ to Rust change, compatibility claims, build changes, bug fixes, target-specific fixes, and downloadable release assets.mold repository and manualSupported targets, benchmark method, installation routes, linker selection, output identification, and project test practice.Hacker News discussion 49963385Questions about bootstrap placement, platform support, memory safety, concurrency, and what a rewrite proves.GitHub release APIThe exact tag, commit-facing release record, publication time, assets, sizes, and published SHA-256 digests.