Wild linker: a Rust drop-in linker for faster Linux builds

What Wild replaces, and who it is for

A linker takes object files and libraries and produces an executable or shared object. On Linux, the default is usually GNU ld, often reached through GCC or Clang. Wild is a replacement for that step. The README states the goal directly: "Wild is a linker with the goal of being very fast for iterative development."

The audience is people who rebuild large C, C++ or Rust projects many times a day and who feel the link step in that loop. Wild is not a new build system and not a compiler. It slots in where ld would be invoked, which is why the README calls it a drop-in replacement. If your build already works with mold or lld, the integration path is the same shape: point the compiler driver at a different linker binary.

The name is explained in the Q&A. Linkers traditionally end in "ld" (GNU ld, gold, lld, mold), and since the end-goal is incremental linking, an "I" is added. The "W" stands for Wild.

The incremental-linking goal and what actually ships in 0.10.0

This is the part worth reading carefully, because the project's framing and its current capability differ. The README says: "The plan is to eventually make it incremental, however that isn't yet implemented." Incremental linking also appears first in the list of things not yet supported, described as roughly sorted by current priority. So the feature that motivates the project's name and its reason for existing over mold is not in the 0.10.0 release.

What is claimed to work is broad but explicitly caveated. The README lists output to statically linked non-relocatable binaries, static-PIE, dynamically linked binaries and shared objects, all "with the caveat that there may be bugs." Rust proc-macros are said to work when linked with Wild. Debug info and GNU jobserver support are listed. Most of the top downloaded crates on crates.io have been tested against Wild and pass their tests, according to the README.

Linker scripts are the sharp edge. The README describes only "partial linker script support" and points to LINKER_SCRIPT_SUPPORT.md for a matrix. Anything that relies on a non-trivial script, which includes a lot of embedded, kernel and distro packaging work, needs that file read before adoption, not after.

Platform support: Linux only, five architectures

The supported list is short and specific. x86-64 on Linux, ARM64 on Linux, RISC-V (riscv64gc) on Linux, plus initial support for LoongArch64 and PPC64LE on Linux. Mach-O and Windows support are both listed under what is not yet done.

That rules out a large set of users immediately. If you develop on macOS and cross-compile to Linux, Wild may still be useful on the Linux side, but it will not replace the host linker. If you build for Windows, there is nothing here for you. The related search interest in a mold linker for Windows does not transfer to Wild, because Wild does not target Windows at all.

There is one platform-specific wrinkle documented in the README for Illumos. On x86_64-unknown-illumos, the Cargo configuration must set an absolute path to clang and pass an absolute path to Wild, because otherwise the flag "will silently delegate to GNU ld or Sun ld". That is a general risk with -fuse-ld: if the driver cannot find the named linker, some configurations fall back rather than fail.

Installing Wild and linking a Rust build with it

The README gives five installation routes: a tarball from the GitHub releases page, cargo-binstall, Homebrew, cargo install from crates.io, and a build from git head. Nix users get a pkgs.useWildLinker wrapper. The crates.io install is the most reproducible for a pinned version:

cargo install --locked wild-linker

If you prefer prebuilt binaries, cargo-binstall resolves the release artifacts:

cargo binstall wild-linker

Homebrew installs from the project's own tap:

brew install wild-linker/wild/wild

Once the wild binary is on your path, the Cargo integration is a config file. The README shows this for x86_64-unknown-linux-gnu, using Clang's --ld-path option:

[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-Clink-arg=--ld-path=wild"]

The alternative form uses -fuse-ld, which requires GCC 16.1 or later, or a Clang setup with an ld.wild binary or symlink:

[target.x86_64-unknown-linux-gnu]
# linker = "clang" # Uncomment this line if your GCC is older than version 16.
rustflags = ["-Clink-arg=-fuse-ld=wild"]

After a build, do not assume it worked. The README's verification step uses binutils:

readelf --string-dump .comment my-executable

You should see a line of the form "Linker: Wild version 0.1.0". A grep against strings works too. If that line is absent, the driver linked with something else and your config did not take effect.

C, C++ and CMake: where the integration gets messy

CMake 4.4 or later supports Wild directly when used with Clang or GCC 16 or later. The README gives the switch as a single flag on the configure line:

cmake -DCMAKE_LINKER_TYPE=WILD

For anything older, the generic path is LDFLAGS:

export LDFLAGS="${LDFLAGS} -fuse-ld=wild"

Autotools, meson and older CMake projects sometimes ignore LDFLAGS or implement their own linker detection, so the README offers a fallback: create a symlink named ld pointing at wild, then pass its directory to the compiler with -B.

ln -s /usr/bin/wild /tmp/ld

export CFLAGS="${CFLAGS} -B/tmp"
export CXXFLAGS="${CXXFLAGS} -B/tmp"
export LDFLAGS="${LDFLAGS} -B/tmp"

The README warns that you may need to remove the configuration cache first, and that you should verify with readelf afterwards. That warning is the honest part of this section. Build systems that cache linker detection will happily keep using the old linker while your environment variables suggest otherwise.

Where Wild is the wrong choice

Three cases stand out. First, anything that needs incremental linking today. The README is unambiguous that it is not implemented, and mold's author has stated they do not intend to add it, which is the stated reason Wild exists. If you are choosing a linker now for the incremental property specifically, you are choosing a roadmap, not a feature.

Second, complex linker scripts. The README says support is partial and defers to LINKER_SCRIPT_SUPPORT.md. Kernel builds, embedded targets and many distribution packages rely on scripts that go well beyond the simple cases. Testing on crates.io's most downloaded crates does not cover that ground.

Third, LTO through linker plugins. The README lists plugin LTO as working "with the caveat that there may be bugs" and links to an open-issue query filtered by the LTO label. If your release profile depends on fat LTO, treat that as an area to test rather than assume.

The README also does not document rollback. Reverting is a matter of removing the rustflags entry or the CMAKE_LINKER_TYPE flag and rebuilding, but the project itself does not describe a procedure for it.

Wild against mold and GNU ld

GNU ld is the baseline: universally available, handles the full range of linker scripts, and slow enough on large binaries that alternatives exist. Wild targets the same command-line surface, which is what makes the drop-in claim possible.

Mold is the closer comparison and the one the README addresses by name. The README says mold "is already very fast, however it doesn't do incremental linking and the author has stated that they don't intend to." Wild's argument is not that mold is slow. It is that mold has decided against the feature Wild is built to eventually deliver, and that writing in Rust makes the complexity of incremental linking achievable. That is a bet on future capability, and the README presents it as one.

So the practical difference today is narrower than the framing suggests. Both are fast Linux linkers that replace ld. Mold has a longer track record and broader platform coverage; Wild has a written roadmap toward incremental linking and a Rust codebase. If you need the feature now, neither has it in the form you want.

Maintenance, licence and upgrade cost

The last push to the default branch was on 2026-08-04, the same date as the 0.10.0 release. The preceding releases were 0.9.0 on 2026-05-23 and 0.8.0 on 2026-01-16. That cadence, roughly every two to three months, is what the release history shows. The repository is not archived.

Licensing is dual: the workspace Cargo.toml declares license = "MIT OR Apache-2.0", and both LICENSE-MIT and LICENSE-APACHE are present at the top level. That is the standard Rust ecosystem arrangement, and it means you choose which of the two terms applies to your use. This is not legal advice; if your organisation has a policy on which of MIT or Apache-2.0 it accepts, check it against the file you rely on.

Upgrade cost is mostly the Rust toolchain floor. The workspace sets rust-version = "1.97.1" and edition = "2024", so building from source with cargo install --locked requires a toolchain at or above that version. Prebuilt release tarballs and the Homebrew formula avoid that constraint. The changelog lives in CHANGELOG.md and the release process is described in RELEASING.md, both at the top level.

Editorial conclusion

Adopt Wild if you build Rust, C or C++ on x86-64, ARM64, RISC-V, LoongArch64 or PPC64LE Linux and you want a drop-in linker you can select per project through Cargo config or CMAKE_LINKER_TYPE=WILD. Do not adopt it if you need incremental linking, Mach-O or Windows, or if your build depends on complex linker scripts, since the README lists those as unsupported. Before switching a production build, verify with readelf --string-dump .comment that Wild actually linked the binary, and check your build system against LINKER_SCRIPT_SUPPORT.md.

Frequently asked questions

Official sources

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