Use mold as default linker?

[SUPERCILEX]

View all comments

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?

[workingjubilee]

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:

• Support macOS/iOS rui314/mold#189
• Support Windows rui314/mold#190

and may contend for resources in more complex multitasking situations (though sometimes LLD does also, being designed by the same hand):

• mold concurrency issues with ninja rui314/mold#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:

• Linking with LLD #39915
• Use lld by default on x64 Ubuntu 20.04 LTS #71515
• Use lld by default on x64 msvc windows #71520

And we do not even support using it directly at the moment via an argument like linker-flavor.

[SUPERCILEX]

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.

[hkratz]

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.

[workingjubilee]

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?

[Timmmm]

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.

[workingjubilee]

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.

[tedinski]

mold 2.0.0 (released today) has been re-licensed to MIT: https://github.com/rui314/mold/releases/tag/v2.0.0

[shmerl]

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.

[NobodyXu]

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.

[bjorn3]

LTO is supported by mold now. And unless you use -Clinker-plugin-lto rustc doesn't depend on the linker for LTO anyway.