add dynamically-linked musl targets

[kaniini]

This pull request adds $arch-unknown-linux-dynmusl targets as a generic replacement for Alpine's $arch-alpine-linux-musl targets. The name dynmusl was chosen based on discussion in rust-lang/rfcs#2695 and #59302.

The platform support entries are based on the current state of the equivalent $arch-alpine-linux-musl targets.

Rationale copied from down-thread...

---

The dynmusl targets are intended to provide a set of targets intended for use on dynamically-linked musl distros. They are intended to act the same as the glibc targets. The dynmusl targets are based on Alpine's previous set of targets which did the same thing (and review has found some deficiencies, thanks everyone!).

I believe the dynmusl targets provide a compromise that is minimally intrusive to the rust compiler team, while providing musl-based distros like Alpine with a set of targets that meet their requirements. While not perfect (in an ideal world, the -musl targets would not assume static linking and work like glibc), it does solve the problem in a way I believe we can all live with.

These targets are required because Linux distributions generally consider static linking by default to be a policy violation. It is a policy violation in Alpine, Void and Adelie Linux, which are the top three musl-based distributions. Though it should also be said that there are staticly-linked musl distributions such as Sabotage, which would continue to be served by the -musl targets directly (if they ship Rust at all, I haven't checked).

[rust-highfive]

r? @davidtwco

(rust-highfive has picked a reviewer for you, use r? to override)

[kaniini]

r? @nagisa

[alex]

Build failure looks relevant.

The docs entries have toolchain entries marked as being built, but I don't see any CI changes. Is there a reason those wouldn't be necessary?

[jyn514]

The docs entries have toolchain entries marked as being built, but I don't see any CI changes. Is there a reason those wouldn't be necessary?

Yeah, I think the checkmarks should be removed from the new entries in platform-support.md.

[ericonr]

I have already requested this over IRC, but for completeness sake, i686 dynmusl would complete the target matrix for Void Linux as well.

[kaniini]

@ericonr added in ff1825a 👍

[12101111]

rustbuild also need to update as dynmusl target don't need to ship rustlib/$target/lib/self-contained/*.o.

[estebank]

@petrochenkov we could change the default behavior and when detecting we are in a non-musl platform (the opposite check you linked to earlier) emit an unconditional warning letting you know that if you meant to build a statically compiled musl binary, to be explicit by passing +crt-static or to silence the warning by explicitly passing -crt-static. The run to see what breaks would still be needed and the communication effort will be significant. We wouldn't be able to remove the warning for years due to the existing, out of date documentation out there that is not under our control.

[kaniini]

I think what @estebank proposes makes the most sense. What would be involved in adding a warning for this?

[michaelforney]

Note also that some build recipes are already broken with the current static-by-default behavior.

The main question is - why is -C target-feature=-crt-static not enough and why do we need a separate target?

Here's an example: firefox requires its build scripts to be dynamically linked, but it uses cargo --target=... which makes it impossible set flags for the build scripts, thus it is currently impossible to build firefox with *-unknown-linux-musl rust toolchains.

I think everyone in the musl community would really just like to see this fixed using the standard toolchain names. It has been a huge barrier for people trying to use rust on musl-based systems for years now.

[petrochenkov]

@michaelforney

requires its build scripts to be dynamically linked, but it uses cargo --target=... which makes it impossible set flags for the build scripts

This is exactly the kind of issue that I meant in

If cargo makes passing such options inconvenient, then it should be pushed to make compiler option support more convenient and fine-grained instead.

in #82556 (comment) (regardless of the musl specifics).

[bors]

☔ The latest upstream changes (presumably #82663) made this pull request unmergeable. Please resolve the merge conflicts.

[kaniini]

I agree that it should be easier to override target behaviour but in this case the default behaviour is completely broken for musl-based distributions, which should be the primary use case for a -musl target, like glibc-based distros are the primary use case for the -gnu targets.

[workingjubilee]

Wait, does setting RUSTFLAGS="-Ctarget-feature=-crt-static" with cargo build --target x86_64-unknown-linux-musl override RUSTFLAGS? I just want to make sure if I am understanding the existing behavior correctly.

[bjorn3]

If you pass --target, cargo ignores RUSTFLAGS for crates build for the host like build scripts and proc macros.

[richfelker]

I agree that it should be easier to override target behaviour but in this case the default behaviour is completely broken for musl-based distributions, which should be the primary use case for a -musl target, like glibc-based distros are the primary use case for the -gnu targets.

Yes. This is the case where the application being compiled and build script being used to compile it have no reason to know anything about musl or that the target is musl-based, and they can't be expected to do anything to override the wrong default of static linking that might break what they're trying to do.

If on the other hand youre trying to make static binaries using musl to distribute and run on systems where they're foreign, you're in the case where you're not just using a target fed to you as whatever the host default is, but working with a specific known system. In that case you can reasonably be expected to take care of your own target options.

[nagisa]

@rfcbot fcp cancel

Given the discussion is ongoing and appears to have leaned towards an alternate approach, I'm going to cancel the FCP proposing the merge of this PR as it is written currently.

[rfcbot]

@nagisa proposal cancelled.

[estebank]

@kaniini just want to let you know that fcp cancellation is about the specifics of this PR's approach, given that there are multiple possible courses of action and we need to reach an agreement on which one to pursue. We still want to see this fixed in a way that everybody involved is happy with!

[apiraino]

Given this comment I'm removing also the "waiting on team" label for now.

@rustbot label -S-waiting-on-team

[petrochenkov]

This is still waiting-on-team, the issue was nominated for discussion, but not discussed yet. Summary.

[apiraino]

@petrochenkov ah sorry then I have misunderstood the discussion from last week T-compiler meeting about this. Thanks for fixing!

[wesleywiser]

Hi everyone! We have a compiler team design meeting scheduled to discuss what to do to resolve this issue on March 26 10am EDT (14:00 UTC). Meetings are held in the #t-compiler/meetings Zulip stream.

[pnkfelix]

The compiler team had a design team meeting and have proposed an MCP with an alternative solution to this problem: rust-lang/compiler-team#422

[kaniini]

I think we can close this PR and focus on the other solution.