-
Notifications
You must be signed in to change notification settings - Fork 69
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
Update the existing musl targets to be dynamically linked. #422
Comments
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. cc @rust-lang/compiler @rust-lang/compiler-contributors |
The correct combination of flags to preserve the old behavior is -C target-feature=+crt-static -C link-self-contained=yes because the old musl targets not only link libc statically by default, they also link libc and crt objects shipped with rustc by default, which is also undesirable and should be avoided in the new target config. Besides that, cargo need to be convinced to pass these flags only when compiling for the target, and not for the host (proc macros, build scripts), and we must specify how to do that in the migration diagnostic and documentation. |
@rustbot second |
That's quite a pain when most users using the This should only be done once there is a more user friendly way to get the current behaviour. |
cc @emk who maintains a widely used docker image for building static musl binaries. |
For context, I use Docker simply adds far too much delay and complexity to the compilation cycle for that kind of use-case... not to mention that I've spent the last few years promoting "For pure-Rust projects, Go-like static builds are as simple as |
Not sure if that was directed at my comment, but I'm not suggesting that everyone should use the docker image, just that the author and users of that docker image would be impacted by this potential change and should know about it. |
I was unsure what your intent was, so I left whether I was replying to you ambiguous. EDIT: I don't have a Zulip account (URLO, IRLO, Matrix, Reddit, StackExchange, etc. ...but not Zulip) and I'm not really in the mood to create an account on yet another service right now (assuming I even can, given how many services seem to be restricting themselves to those who have SMS numbers these days), so I'll bow out and hope my interests get adequately represented by someone else. |
Hi all, MCP issues aren't meant for discussion, we have a separate Zulip thread for that. Let's please move the discussion to that thread. Thanks! |
I'm happy to review or contribute changes necessary for hexagon to support this change. |
Will buildability of static musl be still tested automatically on CI even if/when dynamic musl becomes default? Or will static flavour of musl effectively become Tier 3 instead of Tier 2? |
A Zulip thread/stream is very awkward to parse when it comes to searching for whether a question has already been asked, discussed, or answered. I would recommend aggregating questions as well as their answers (if any) and the salient points of the discussion (if any) together in some sort of FAQ document... for example in the above MCP itself. That is, I am fine with the discussion occurring on Zulip (or wherever) but I recommend that it be summarized in a more accessible manner (aggregated/summary) and at a more static location (nobody likes to scroll dozens of pages). |
I think adding a FAQ to the template and collecting major points raised in the conversation is a good idea. |
@rustbot label -final-comment-period +major-change-accepted |
Uhm... from the thumbs ups here it kinda looks like everyone agreed this was a bad idea (or at least premature without a simple alternative)... and then it was accepted? You guys should at least post the reasoning behind this decision. |
I skimmed the Zulip thread and it seems like the conclusion was that initially Rust will look for a system copy of Musl and dynamically link with that, if available, and fall back to static linking. And maybe there will be some kind of |
There is no ABI incompatibility between the static and dynamic version, so I don't think a separate target makes sense. Also if you are on a musl distro and want to produce statically linked executables you now need two targets installed. The dynamically linked one for rustc as otherwise it can't load proc macros, and the statically linked one for the executable to build. I think having a profile option for crt-static separate from rustflags makes more sense. You can set those per-target too as well using an env var. In addition cargo can decide to ignore it when necessary and avoid recompilation of everything when switching between the two options. Amd if you really want maybe |
I think having something like For all other That's literally the only reason why we use musl despite its poor malloc and dns implementation. |
There are multiple Linux distributions that use dynamic linking and musl libc, most notably:
|
Thanks, I didn't know that. |
|
I didn't mean a separate target, I meant a way to alias existing target + a compiler option. |
@NobodyXu if you want to read more, please read:
also, maybe too late at this point, but the place to discuss an MCP is in the zulip thread associated to it, not the github thread of the MCP. |
That's really the main point for me. We should respect the policy and decisions of the people maintaining the target we're building for. Having |
imo that would go further than just statically linking libc. I'd expect it to also statically link all the native libraries the project depends on through either build.rs or other means. cargo could set some env var or such that projects then should respect. that's usually what people want when they want static linking, they want everything to be linked statically, not just libc. |
I believe there is a cfg exported for users to determine if crt-static is used. On most targets crt-static mandates full static linking, though not all targets. There is a target spec key for this. |
Hmm yeah one can do |
Thanks @est31 will have a read of them |
It looks like the musl target will, at some point, default to be dynamically linked. This config knob should make it so that it's always statically linked. Ref rust-lang/compiler-team#422 Ref rust-lang/compiler-team#422 (comment)
Upgrades, deps, and changes the config to force musl to always be statically linked, see [this](rust-lang/compiler-team#422) for why.
It looks like the musl target will, at some point, default to be dynamically linked. This config knob should make it so that it's always statically linked. Ref rust-lang/compiler-team#422 Ref rust-lang/compiler-team#422 (comment)
We were relying on the fact that our current targets link the C runtime statically. However, this may be different for other targets and could even change in the future (e.g., see rust-lang/compiler-team#422). With this commit we adopt the current recommendation, which is enabling the crt-static target feature when building. See https://doc.rust-lang.org/reference/linkage.html#static-and-dynamic-c-runtimes for details. Given the current defaults for Rust targets, this change should be a no-op, but this shall make us safer and more resilient to Rust changes in the long run. Signed-off-by: Leandro Motta Barros <leandro@balena.io> Change-type: patch
Hi, |
Could this be done as part of the upcoming 2024 edition? |
However, don't change the behavior of any existing targets at this time. For targets that used the old default, explicitly set `crt_static_default = true`. This makes it easier for new targets to use the correct defaults while leaving the changing of individual targets to future PRs. Related to rust-lang/compiler-team#422
Update the existing musl targets to be dynamically linked.
We should change the
-musl
targets to be consistently dynamically linked to theirlibc
, rather than statically linking themusl
libc into them at compile-time. If a MUSL end-user wants the musl-libc to be statically-linked into their program, they will need to specify it explicitly (e.g. via-Ctarget-feature=+crt-static
)Proposed Mitigation Strategy: In order to give the current users a chance to prepare for this change, we will first land a lint on all hosts that target musl. This lint will warn that the defaults here are going to change (namely, that the implicit
+crt-static
is switching to-crt-static
). The lint will be silenced by explicitly providing either+crt-static
or-crt-static
.Why we should do this: This would make Rust's
-musl
targets more consistent on two axes: It would make them more consistent with Rust's non-musl targets (which likewise dynamically link to the target's libc), and it would make them consistent with what musl toolchains expect, especially the toolchains for musl-based Linux distributions. (Today, musl-based Linux distribtuons are locally patching Rust to get the behavior they expect.)Why we might not do this: It is a breaking change. The current defaults were put in place to support a specific use case of producing shippable binaries, and changing the default will break users who are not explicitly (and, with the current defaults, redundantly) requesting
+crt-static
. However, the mitigation strategy is intended to address the needs of those users.Background: Rust currently has Tier 2 targets for a number of platforms using musl for libc (various flavors of ARM, MIPS and x86) as well as some Tier 3 targets (Hexagon, PowerPC, RISC-V, S390x and ARMv7 Thumb). Currently (most of) these targets statically link to musl libc during compilation.
ts could also be added.
Mentors or Reviewers
This MCP is an outcome from the compiler-team design meeting compiler-team#416 (zulip archive)
I expect the stake-holders who participated in that meeting to be involved, though they may not be the actual mentors.
Process
The main points of the Major Change Process are as follows:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
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.
The text was updated successfully, but these errors were encountered: