2008: Gold, a new linker, intended to be faster than Gnu LD
2015(?): Lld a drop in replacement linker, at least 2x as fast as Gold
2021: mold, a new linker, several times faster than lld
2025: wild, a new linker...
Wild – A fast linker for Linux
81–90 of 222 posts
Re: Wild – A fast linker for Linux
#822008: Gold, a new linker, intended to be faster than Gnu LD 2015(?): Lld a drop in replacement linker, at least 2x as fast as Gold 2021: mold, a new linker, several times faster than lld 2025: wild, a new linker...
For windows, there is also [The RAD Linker](https://github.com/EpicGamesExt/raddebugger?tab=readme-ov-fi...) though quite early days.
Re: Wild – A fast linker for Linux
#83What would be refreshing would be a C/C++ compiler that did away with the intermediate step of linking and built the whole program as a unit. LTO doesn't even have to be a thing if the compiler can see the entire program in the first place. It would still have to save some build products so that incremental builds are possible, but not as object files, the compiler would need metadata to know of the origin and depend…
[flagged]
> if you think any compiler is meaningfully doing anything optimal ("whole program analysis") on a TU scale greater than say ~50kloc (ie ~10 files) relative to compiling individually you're dreaming.
You can build the Linux kernel with LTO: simply diff the LTO vs non-LTO outputs and it will be obvious you're wrong.
Re: Wild – A fast linker for Linux
#84There’s been a lot of interest in faster linkers spurred by the adoption and popularity of rust. Even modest statically linked rust binaries can take a couple of minutes in the link stage of compilation in release mode (using mold). It’s not a rust-specific issue but an amalgam of (usually) strictly static linking, advanced link-time optimizations enabled by llvm like LTO and bolt, and a general dissatisfaction with…
I solved this by using Wasm. Your outer application shell calls into Wasm business logic, only the inner logic needs to get recompiled, the outer app shell doesn't even need to restart.
How is this different than dynamically linking the business logic library?
Re: Wild – A fast linker for Linux
#85That looks promising. In Rust to begin with and with the goal of being fast and support incremental linking. To use it with Rust, this can probbaly also work using gcc as linker driver. In project's .cargo/config.toml: [target.x86_64-unknown-linux-gnu] rustflags = ["-C", "link-arg=-fuse-ld=wild"] Side note, but why does Rust need to plug into gcc or clang for that? Some missing functionality?
Unfortunately gcc doesn't accept arbitrary linkers via the `-fuse-ld=` flag. The only linkers it accepts are bfd, gold lld and mold. It is possible to use gcc to invoke wild as the linker, but currently to do that, you need to create a directory containing the wild linker and rename the binary (or a symlink) to "ld", then pass `-B/path/to/directory/containing/wild` to gcc.
As for why Rust uses gcc or clang to invoke the linker rather than invoking the linker directly - it's because the C compiler knows what linker flags are needed on the current platform in order to link against libc and the C runtime. Things like `Scrt1.o`, `crti.o`, `crtbeginS.o`, `crtendS.o` and `crtn.o`.
Re: Wild – A fast linker for Linux
#86What a coincidence. :) Just an hour ago I compared the performance of wild, mold, and (plain-old) ld on a C project I'm working on. 23 kloc and 172 files. Takes about 23.4 s of user time to compile with gcc+ld, 22.5 s with gcc+mold, and 21.8 s with gcc+wild. Which leads me to believe that link time shouldn't be that much of a problem for well-structured projects.
Re: Wild – A fast linker for Linux
#87What a coincidence. :) Just an hour ago I compared the performance of wild, mold, and (plain-old) ld on a C project I'm working on. 23 kloc and 172 files. Takes about 23.4 s of user time to compile with gcc+ld, 22.5 s with gcc+mold, and 21.8 s with gcc+wild. Which leads me to believe that link time shouldn't be that much of a problem for well-structured projects.
How about ld.lld?
Re: Wild – A fast linker for Linux
#882008: Gold, a new linker, intended to be faster than Gnu LD 2015(?): Lld a drop in replacement linker, at least 2x as fast as Gold 2021: mold, a new linker, several times faster than lld 2025: wild, a new linker...
I’m not sure if you’re intending to leave a negative or positive remark, or just a brief history, but the fact that people are still managing to squeeze better performance into linkers is very encouraging to me.
Re: Wild – A fast linker for Linux
#89Ever since mold relicensed from AGPL to MIT (as part of mold 2.0 release), the worldwide need for making another fast linker has been greatly reduced, so I wasn't expecting a project like this to appear. And definitely wasn't expecting it to already be 2x faster than mold in some cases. Will keep an eye on this project to see how it evolves, best of luck to the author.
Note that Mold has no interest in becoming incremental, so there is a big reason there for another linker to exist. I find it kind of embarrassing that MS' linker has been incremental by default for decades, yet there's no production ready incremental linker on Linux yet.
Additionally the way precompiled headers are handled in Visual C++ and C++ Builder have always been much better than traditional UNIX compilers, and now we have modules as well.
Re: Wild – A fast linker for Linux
#90Can it link the Linux kernel yet? Was a useful milestone for LLD.