Search code, repositories, users, issues, pull requests...

It's still very much a work-in-progress and definitely shouldn't be used for linking any production binaries. It's probably not really ready for development purposes yet, since there's a bunch of important stuff it can't yet do like debug info and dynamic linking.

Mold is already very fast, however it doesn't do incremental linking and the author has stated that they don't intend to. Wild doesn't do incremental linking yet, but that is the end-goal. By writing Wild in Rust, it's hoped that the complexity of incremental linking will be achievable.

It's somewhat of a tradition for linkers to end with the letters "ld". e.g. "GNU ld, "gold", "lld", "mold". Since the end-goal is for the linker to be incremental, an "I" is added. The "W" doesn't stand for anything and was just selected based on it giving an interesting word.

There are lots of features that Wild doesn't yet support, so I'm not sure benchmarking is super useful at this stage. That said, I have done some very preliminary comparisons. I've tried linking the binary in my warm build benchmark repository, which builds an ~80MB, non-PIE, statically linked binary with symbol tables, eh-frames and no debug info. On my laptop, I get the following times:

Leave a Comment