Wild, the Rust linker built around the idea that most links are relinks, released version 0.10 on August 4. The headline feature is --gdb-index, which precomputes the symbol index GDB would otherwise build at startup and embeds it in the binary. The more surprising entry is a default change: on btrfs and vfat, Wild now stops memory mapping its output file, because doing so was making links slower. Most of the rest of the release is linker script work and bug fixes, which is exactly what a linker at this stage of its life should be shipping.
The short answer
Wild is a fast Linux linker written in Rust and aimed at iterative development. Version 0.10 adds --gdb-index, precomputing the .gdb_index section so the debugger does not rebuild it at every start, implemented with parallel symbol processing and concurrent writing. On btrfs and vfat, Wild now defaults to not memory mapping the output file, which the release notes say gives a speed-up. The rest is a large batch of linker script features, initial 32 bit work, expanded WebAssembly linking, Mach-O progress and in memory file support in libwild.
Linkers are the part of the build nobody thinks about until they do, and then they think about nothing else. Wild exists because of that moment: it is a Linux linker written in Rust whose stated purpose is to be very fast at the thing you actually do a hundred times a day, which is not linking a project from scratch but relinking it after changing one file.
Version 0.10 arrived on August 4. The release notes set expectations honestly: "This release comes with a lot of bug fixes. Most of the new features are linker-script related." That is a maturing project talking, and two entries are worth pulling out of it.
gdb-index, finally
The flag is --gdb-index, and it does what the equivalent in GNU gold, LLD and Mold does: it builds the .gdb_index section at link time and embeds it in the binary.
The value is straightforward once you see where the cost sits. Debug information is spread across every compilation unit in the binary. When GDB starts without an index, it has to read through that to build a picture of where symbols are defined before it can usefully answer anything. On a large binary that is a noticeable pause every single session. The linker has already read all of it and knows where everything landed, so it can write the answer down once instead of making the debugger recompute it every time.
Wild's implementation is worth a note of its own. The feature has been requested since 2025, and the release describes it as parallelised, with symbol processing spread across threads and the index written concurrently, plus reduced heap allocation. That matters for a linker whose entire pitch is speed. Adding an index that made every link measurably slower would have been a bad trade.
The btrfs finding
The other entry is the kind of detail you only discover by profiling on real machines: Wild now avoids memory mapping the output file when that file lives on btrfs or vfat, and this makes links faster.
The default technique for a linker is to map the output into memory and write the finished binary through the mapping, leaving writeback to the kernel. On ext4 or xfs that is an efficient path. On btrfs, a copy on write filesystem, dirtying mapped pages drags the filesystem into bookkeeping that a plain sequential write would avoid, and the cost lands on your build time. vfat is slow here for older and simpler reasons.
Wild 0.10 detects both and switches to --no-mmap-output-file automatically. The project's own advice, stated in the release, goes further than the workaround: where you have the choice, do not put build output on either filesystem at all. That is good advice regardless of which linker you use, and most people running btrfs as their root filesystem have never thought about which subvolume their target/ directory lives on.
The unglamorous majority
Everything else in this release is compatibility work, and it is the reason the project is usable at all.
The linker script additions are the bulk: DISCARD for throwing sections away, SORT directives for controlling section order, the DEFINED command for testing symbol existence, ternary expressions in address arithmetic. None of this is exciting to read. All of it is the difference between a linker you can point at an embedded or kernel adjacent project and one you cannot, because those projects carry linker scripts written years ago against GNU ld and are not going to rewrite them for you.
Beyond that: initial work on 32 bit support, expanded WebAssembly program linking, continued Mach-O progress, and in memory file support in libwild so build tools can call Wild as a library and hand it inputs that never hit disk. Benchmarks in the release show performance broadly in line with 0.9, which is the correct outcome for a release that added an index writer.
What we would do
Try it, measure it, keep the revert handy.
Swapping linkers is one of the cheapest experiments available to a developer: a single flag in your build configuration, and a single flag to undo it. If your project links slowly and you spend your day in the edit, build, debug loop, Wild is aimed directly at you and 0.10 removes one of the standing objections by supporting the debugger index.
The one thing we would check first has nothing to do with Wild. Find out what filesystem your build directory is on. If the answer is btrfs, you have been paying for that with every link you have run, on any linker, and that is worth knowing whether or not you switch.
Sources and further reading
- Wild 0.10.0 release notes on GitHub
- Wild Linker 0.10 released with GDB index support, mitigation for btrfs performance, Phoronix, August 4, 2026
- The Wild linker project repository
- GDB documentation on the index and the .gdb_index section
Frequently asked questions
What does --gdb-index actually save me?
Debugger startup time, and on a large binary that is not a small number. Without an index, GDB has to walk the debug information across every compilation unit in the binary before it can answer a question about a symbol, and you pay that cost each time you start a session. The .gdb_index section is a precomputed map from names to the places that define them, so the debugger can jump straight in. The linker is the right place to build it because the linker is the only thing that has already read all the debug information and knows where everything ended up. GNU gold introduced the idea, LLD and Mold both carry it, and Wild adding it removes one of the remaining reasons a debugging heavy project would not switch.
Why would memory mapping the output file be slower on btrfs?
Because copy on write filesystems and mmap based output are a poor fit. The usual linker trick is to map the output file into memory and write the finished binary through that mapping, letting the kernel handle the writeback. That works well on ext4 and xfs. On a copy on write filesystem like btrfs, dirtying pages through a mapping forces the filesystem into work it would not do for a plain sequential write, and the accounting overhead shows up as wall clock time. vfat has its own reasons, mostly that it was never designed for this access pattern. Wild 0.10 detects both cases and defaults to --no-mmap-output-file, which the release notes describe as giving a bit of a speed-up. The project's own recommendation goes further: if you can, do not put your build directory on either filesystem.
Is Wild ready to replace my current linker?
It depends on which axis you care about. For iterative development on Linux x86 64, which is the case Wild was designed for, it is credible today and people do use it in that role. For anything else, treat it as promising rather than finished: 32 bit support is described as initial work in this release, Mach-O is under development, and WebAssembly linking is expanding but not complete. The honest summary is that Wild is a fast Linux linker with a specific ambition, incremental linking, that it has not fully delivered yet. Our advice is the same as for any linker swap: it is a one line change to try and a one line change to revert, so measure it on your own build rather than on someone else's benchmark.
What are all the linker script changes for?
Compatibility, which is the unglamorous half of writing a linker. Anything replacing GNU ld has to cope with the linker scripts that already exist in the wild, and those scripts use a long tail of features: DISCARD to throw sections away, SORT directives to control section ordering, DEFINED to test whether a symbol exists, ternary expressions in address arithmetic. Embedded projects and kernels lean on these heavily. Each one Wild implements is one more project that can try it without rewriting its build. The release notes say plainly that most of the new features this cycle are linker script related, which tells you where the remaining friction was.
What is libwild and why does in memory file support matter?
libwild is Wild exposed as a library rather than a command line binary, so a build tool can link by calling into it instead of spawning a process. In memory file support means the caller can hand it inputs that never touched the disk. That combination is aimed squarely at build systems and language toolchains that generate object code and immediately want it linked: skipping the write to a temporary file, the process spawn and the read back removes real overhead on builds that link many small artifacts. It is infrastructure for other people's tools rather than a feature you use directly, and it is a reasonable signal of where the project expects to be embedded.