from Hacker News

Wild – A fast linker for Linux

by hkalbasi on 1/24/25, 4:25 PM with 208 comments

  • by pzmarzly on 1/24/25, 4:55 PM

    Ever 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.

  • by satvikpendem on 1/24/25, 4:52 PM

    I looked at this before, is it ready for production? I thought not based on the readme, so I'm still using mold.

    For those on macOS, Apple released a new linker about a year or two ago (which is why the mold author stopped working on their macOS version), and if you're using it with Rust, put this in your config.toml:

        [target.aarch64-apple-darwin]
    rustflags = [ 
        "-C",
        "link-arg=-fuse-ld=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld",
        "-C",
        "link-arg=-ld_new",
    ]

  • by kryptiskt on 1/24/25, 6:23 PM

    What 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 dependencies of all the generated code so it would be able to replace the right things.

    External libs are most often linked dynamically these days, so they don't need to be built from source, so eliminating the linker doesn't pose a problem for non-open source dependencies. And if that's not enough letting the compiler also consume object files could provide for legacy use cases or edge cases where you must statically link to a binary.

  • by ComputerGuru on 1/24/25, 4:52 PM

    There’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 compile times in the rust community. Rust’s (clinically) strong relationship with(read: dependency on) LLVM makes it the most popular language where LLVM link-time magic has been most heavily universally adopted; you could face these issues with C++ but it wouldn’t be chalked up to the language rather than your toolchain.

    I’ve been eyeing wild for some time as I’m excited by the promise of an optimizing incremental linker, but to be frank, see zero incentive to even fiddle with it until it can actually, you know, link incrementally.

  • by ajb on 1/24/25, 8:44 PM

    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...

  • by fuzztester on 1/24/25, 10:19 PM

    Related, and a good one, though old:

    The book Linkers and Loaders by John Levine.

    Last book in the list here:

    https://www.johnlevine.com/books.phtml

    I had read it some years ago, and found it quite interesting.

    It's a standard one in the field.

    He has also written some other popular computer books (see link above - pun not intended, but noticed).

  • by shmerl on 1/24/25, 7:04 PM

    That 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?

  • by KerrAvon on 1/24/25, 9:59 PM

    I'm curious: what's the theory behind why this would be faster than mold in the non-incremental case? "Because Rust" is a fine explanation for a bunch of things, but doesn't explain expected performance benefits.

    "Because there's low hanging concurrent fruit that Rust can help us get?" would be interesting but that's not explicitly stated or even implied.

  • by bjourne on 1/24/25, 9:25 PM

    What 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.

  • by 1vuio0pswjnm7 on 1/24/25, 11:23 PM

    "These benchmark were run on David Lattimore's laptop (2020 model System76 Lemur pro), which has 4 cores (8 threads) and 42 GB of RAM."

    https://news.ycombinator.com/item?id=33330499

    NB. This is not to suggest wild is bloated. The issue if any is the software being developed with it and the computers of those who might use such software.

  • by sylware on 1/24/25, 7:47 PM

    The real issue is actually runtime ELF (and PE) which are obsolete on modern hardware architecture.

  • by ndesaulniers on 1/24/25, 9:34 PM

    Can it link the Linux kernel yet? Was a useful milestone for LLD.

  • by juujian on 1/25/25, 12:15 AM

    Is it too late to ask what a linker is?

  • by Mikhail_K on 1/25/25, 1:19 PM

    I just knew it's going to be Rust as soon as I've read the title.

  • by devit on 1/24/25, 4:49 PM

    I think the optimal approach for development would be to not produce a traditional linked executable at all, but instead just place the object files in memory, and then produce a loader executable that hooks page faults in those memory areas and on-demand mmaps the relevant object elsewhere, applies relocations to it, and then moves it in place with mremap.

    Symbols would be resolved based on an index where only updated object files are reindexed. It could also eagerly relocate in the background, in order depending on previous usage data.

    This would basically make a copyless lazy incremental linker.

  • by throwaway106382 on 1/24/25, 4:43 PM

    > 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.

    Can someone explain what is so special about Rust for this?