Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use mold as default linker? #94347

Open
SUPERCILEX opened this issue Feb 25, 2022 · 7 comments
Open

Use mold as default linker? #94347

SUPERCILEX opened this issue Feb 25, 2022 · 7 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries C-feature-request Category: A feature request, i.e: not implemented / a PR.

Comments

@SUPERCILEX
Copy link
Contributor

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 workingjubilee added A-linkage Area: linking into static, shared libraries and binaries C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Feb 27, 2022
@workingjubilee
Copy link
Member

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:

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

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:

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

@SUPERCILEX
Copy link
Contributor Author

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
Copy link
Contributor

hkratz commented Feb 28, 2022

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
Copy link
Member

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
Copy link
Contributor

Timmmm commented Jun 3, 2022

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
Copy link
Member

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries C-feature-request Category: A feature request, i.e: not implemented / a PR.
Projects
None yet
Development

No branches or pull requests

5 participants