Add Wild linker as a preview component for x86_64 and AArch64 Linux GNU

[mati865]

Proposal

DISCLAIMER: As a contributor and collaborator of Wild linker project, I'm biased despite my attempts to write this in a neutral way.

Goal of this proposal

Include Wild linker as optional, preview component for x86_64 and AArch64 Linux GNU hosts (obviously this part has to be also accepted by other teams), and unstable flag that would enable Wild linker.

What Wild linker is?

Wild is a new linker supporting only ELF format (used on Linux) for now, but that might change in the future. It's written in Rust, with focus on the performance via parallelism and future incremental linkage, and uses Rust-friendly licence MIT OR Apache-2.0".
Wild's repo: https://github.com/davidlattimore/wild

The benefit to Rust

Internal benchmarks indicate nice performance improvements over the other linkers for the big binaries: https://davidlattimore.github.io/posts/2025/09/23/wild-update-0.6.0.html
Running Rust's smaller benchmarks shows smaller but consistent improvements*: rust-lang/rust#146421 (comment)
*With some regressions: wild-linker/wild#1082

Downsides and limitations of Wild

Based on perf.rlo in rust-lang/rust#146421, building Wild adds up over 40s, that doesn't include archive creation. Locally built Wild binary weights of about 6 MiB.

Since this is still a young linker, it doesn't have feature parity with other linkers. It's also not clear how much it's going to catch up - the goal is to focus on the features that are used by the projects, and not all the obscure flags that nobody uses any more.

Mentors or Reviewers

None

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Caution

Concerns (1 active)

• unofficial project

Managed by @rustbot—see help for details.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[Kobzol]

@rustbot concern unofficial project

As noted on Zulip, wild is currently not an official rust-lang project, and we (as the Project) don't maintain it in any way. It would thus have to be included in the rust-lang CI repository as a sort of a bystander external project just for distribution. I don't think that we should be doing that (as much as I like wild!). This could change in the future if wild becomes more associated with the rust-lang organization, for example.

[mati865]

As per Zulip discussions outcome, this MCP was rejected in the current state.