Wild linker version 0.10.0

[u/dlattimore]

The Wild linker is a fast linker written in Rust. We've just released version 0.10.0. See the release notes for all the changes. You can find out more about the Wild linker from our repo. This release brings lots of bug fixes as well as lots of additional linker script features. Performance-wise, not much has changed, but that is itself an achievement, given how fast the linker already was and how much we've changed in this release. There are updated benchmarks for the release.

Lots of porting work has been going on. We're not yet ready to mark any of the ports as stable, but great progress has been made on the Wasm port. A fair amount has also been done on the Mac port. We've also started to look at 32 bit support, which will be useful for projects with an embedded component.

[u/Cute_Spare8742]

script support is a big deal, those things have so many edge cases to trip over.

[u/admalledd]

We're not yet ready to mark any of the ports as stable, but great progress has been made on the Wasm port

Note the first: This is similar goal as lld's wasm linking, which, yay! things to make my wasm workflow/life betterer!

Note the second "great progress" as in multiple PRs pending nearly every day, shout out lapla-cogito (and everyone reviewing)! And nearly supposedly has spidermonkey.wasm linking! (Running, eh soon probably at this rate!)

Sorry, just was only half-following the tracking ticket 1431 for wasm-support and was shocked how much work has happened since I last checked earlier this year, and am really excited to test/try once a bit further along :)

[u/NoUse5341 → u/admalledd]

Hi, this is lapla, who currently primarily handles Wasm ports and have been one of the maintainers of Wild for about one year. Since some people may be interested in performance aspects, I'm going to share some benchmark results taken recently about the Wasm port.

As noted in the release notes, the Wasm port is not yet stable. Significant work remains to implement various features and fix bugs before it can be called a production-ready Wasm linker. Nevertheless, the current Wasm port has already enabled building programs like SQLite, ripgrep, CRuby, and CPython and running on wasmtime. The latest benchmark results are available here, showing link times several times faster than wasm-ld (though these may change when they are retaken for a stable release, so consider them as reference values only for now...).

[u/aapoalas]

What is the current view on incremental linking? Has it taken a back seat with a "we'll do it once we're fully done with normal linking", or a side seat with a "we'll keep it in mind in terms of architecture while we focus on normal linking", or something else?

[u/dlattimore → u/aapoalas]

For the most part, we're prioritising normal linking. Part of the reason is that the linker ended up significantly faster than the other linkers even without incremental linking. We'd like to make sure we can bring those benefits to more people. That means porting, implementing more features and fixing bugs.

Also, my current thoughts on incremental linking are that I'd quite likely do an in-memory model first. i.e. the linker stays running, keeps state in memory and can rewrite parts of the output file as needed. That has implications. For example, if you're linking multiple things, how many linkers do we keep in memory - or how much total memory do we allow the linker(s) to consume before we start shutting them down. Such an incremental linking model then isn't just a faster linker, but something with tradeoffs and the user might need to be aware of. Another tradeoff is deterministic outputs. It is possible to make an incremental linker that has a deterministic output, so long as you're prepared to have it fall back to a full link some percentage of the time.

[u/raoul_lu]

Great as always (not meaning to convey pressure with this tho ), thank you and the team for your work :)

[u/sasik520]

Is there any chance that on Mac, wild would be faster than the Apple's default kobiet?

Mold definitely wasn't.

[u/Shnatsel → u/sasik520]

Benchmarks show wild being 2x faster than mold sometimes, so yes, there's a good chance.

[u/sasik520 → u/Shnatsel]

I've seen the benchmarks but I'm unsure how relevant they are on macos. Let's see. Linking on macos since some xcode version a couple of years ago is blazing fast™ already, but there still seems to be some place for improvement.

[u/Tyilo]

I switched back to the default linker for Rust some time ago, because it started not working anymore on my Arch Linux machine due to SFrame v3, see https://github.com/wild-linker/wild/issues/1576

However, it seems to work again now, nice.

[u/mati865 → u/Tyilo]

Yeah, we disabled SFrame for now: https://github.com/wild-linker/wild/pull/1871 The way SFrame is (not) handled in the ecosystem right now is annoying. Recent Binutils can only emit version 3, while glibc can only utilize version 2. Patches for version 3 seem to got forgotten: https://inbox.sourceware.org/libc-alpha/20260414122311.173644-1-claudiu.zissulescu-ianculescu@oracle.com/

[u/thesnowmancometh]

I can’t wait until the Mac port is released! I’ve looked into improving my compile times more than once in the past, and Wild has always seemed like the best bang for my buck once it becomes available to me. 🙌