Repository navigation
Update the existing musl targets to be dynamically linked. #422
Description
Update the existing musl targets to be dynamically linked.
We should change the -musl targets to be consistently dynamically linked to their libc, rather than statically linking the musl 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:
- File an issue describing the proposal.
- A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
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.
Activity
rustbot commentedon Apr 1, 2021
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
petrochenkov commentedon Apr 1, 2021
The correct combination of flags to preserve the old behavior is
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.
petrochenkov commentedon Apr 1, 2021
@rustbot second
Timmmm commentedon Apr 9, 2021
That's quite a pain when most users using the
musltargets are primarily doing it so that they get a statically linked binary and don't have to deal with glibc compatibility issues.This should only be done once there is a more user friendly way to get the current behaviour.
Diggsey commentedon Apr 9, 2021
cc @emk who maintains a widely used docker image for building static musl binaries.
ssokolow commentedon Apr 9, 2021
For context, I use
musltargets for using pure Rust to write "shell scripts" that need to meet high standards of reliability, so I consider a Docker-based solution a deal-breaker.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
rustup target addandcargo build --target" as a virtue of the language.Diggsey commentedon Apr 9, 2021
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.
ssokolow commentedon Apr 9, 2021
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.
wesleywiser commentedon Apr 9, 2021
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!
androm3da commentedon Apr 9, 2021
I'm happy to review or contribute changes necessary for hexagon to support this change.
61 remaining items
ci: Specify target and static linking of C runtime explicitly
ci/release: Specify target and static linking of C runtime explicitly
ci: Specify target and static linking of C runtime explicitly
ci/release: Specify target and static linking of C runtime explicitly
Set `RUSTFLAGS="-Ctarget-feature=+crt-static"` because of rust-lang/c…
fix(rust): force +crt-static for musl targets
fix(rust): force +crt-static for musl targets
fix(rust): force +crt-static for musl targets
fix(xtask/run): Make sure `test-distro` is built statically
fix(xtask/run): Make sure `test-distro` is built statically
fix(xtask/run): Make sure `test-distro` is built statically
fix(xtask/run): Make sure `test-distro` is built statically
fix(xtask/run): Make sure `test-distro` is built statically
fix(xtask/run): Make sure `test-distro` is built statically
fix(xtask/run): Make sure `test-distro` is built statically