Use mold as default linker?

Opened by Alex Saveau at 2025-01-07 09:55:02

https://github.com/rui314/mold/releases/tag/v1.1

1.1 now supports LTO... is there anything else missing? Or could mold become the default linker?

Why?

"It is possible" is not enough. Even "it is faster" is not enough. It is also buggier at the moment, such as with this miscompilation found on Zulip

It has limited cross-platform support:
- https://github.com/rui314/mold/issues/189
- https://github.com/rui314/mold/issues/190
and may contend for resources in more complex multitasking situations (though sometimes LLD does also, being designed by the same hand):
- https://github.com/rui314/mold/issues/117
We have not even finished moving over to lld by default everywhere we can, the process of which would also be somewhat similar to the model for moving over to mold by default anyways, so it's not exactly clear we should be skipping ahead:
- https://github.com/rust-lang/rust/issues/39915
- https://github.com/rust-lang/rust/issues/71515
- https://github.com/rust-lang/rust/issues/71520
And we do not even support using it directly at the moment via an argument like linker-flavor.
Jubilee at 2022-02-27 08:21:49
Thanks for those details! So step 1 then would be supporting mold as an official linker flavor? Would that be desirable? I do think the performance gains are at least worth making it easy for people to switch if it fits their use case.
Alex Saveau at 2022-02-28 20:58:35
Mold is "designed to be a drop-in replacement for the GNU linkers", so a new linker flavor does not seem to be necessary. There already is documentation on how to use it with Rust at https://github.com/rui314/mold#how-to-use, I don't think we could make it much simpler without bundling it. mold -run cargo build also worked fine for me.

Also, I don't know what the stance on redistributing software licensed under the GNU AGPL v3 is.
Hans Kratz at 2022-02-28 22:56:19
Ah, I thought -Clinker-flavor was for controlling the linker selection in general. Yes, if that's not the intent then there is probably nothing to be done, it seems?
Jubilee at 2022-03-01 00:34:37
Even "it is faster" is not enough.

Why not? Compile time has repeatedly been a top issue for Rust users. Linking is often extremely slow and can dominate build time for incremental compilation.

When it becomes as mature as LLD then "it is faster" definitely seems like a reason to set it as the default.
Tim Hutt at 2022-06-03 18:13:46
It may still be unwise to use it by default due to lack of jobserver integration. We could certainly consider shipping it along with the compiler, though, if it were not for the legal issues. I have no idea how those will shake out, positive or negative, mind, but I will make the observation has been that legal questions have been answered... slowly. Granted, so will a linker maturing.

If someone sponsored rui314 sufficiently (he is apparently soliciting for sufficient sponsorship so as to allow continuing to work on it and relicensing it under a permissive license), that would stop being an issue, however.
Jubilee at 2022-07-18 00:40:34
mold 2.0.0 (released today) has been re-licensed to MIT: https://github.com/rui314/mold/releases/tag/v2.0.0
Ted Kaminski at 2023-07-26 15:18:41
Just to clarify for anyone who needs it, you can enable usage of mold by creating

.cargo/config.toml in your project directory like this (pick your target accordingly):
```
[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "link-arg=-fuse-ld=mold"]
```
You still need gcc installed for that as a higher interface around the linker.
Shmerl at 2025-01-07 03:29:07
IMHO using mold for debug build makes sense, since it provides faster link time and it's unlikely any people want LTO for their debug build.
Jiahao XU at 2025-01-07 09:38:11
LTO is supported by mold now. And unless you use -Clinker-plugin-lto rustc doesn't depend on the linker for LTO anyway.
bjorn3 at 2025-01-07 09:55:02