Description
As noted elsewhere, the Rust team is planning to change the meaning of *-unknown-linux-musl
from "+crt-static" to "-crt-static". This fixes a longstanding issue with the musl target, which should ideally default to the proper semantics for musl-libc distros like Alpine.
However this is a breaking change, and lots of people do want the static/portable binary solution that the current behaviour provides. We should introduce two new "magic" targets that cargo-dist desugars:
*-musl-static
desugars to*-musl
with the-Ctarget-feature=+crt-static -Clink-self-contained=yes
*-musl-dynamic
desugars to*-musl
with whatever the opposite of the above is
(plain *-musl
would then just be "whatever rustc says today")
Some initial sketching/prep of this design has already been made for both the shell installer and npm installer (some random excerpts):
cargo-dist/cargo-dist/src/tasks.rs
Lines 1985 to 1990 in 1fe2cb9
cargo-dist/cargo-dist/src/tasks.rs
Lines 1210 to 1240 in 1fe2cb9
cargo-dist/cargo-dist/templates/installer/installer.sh.j2
Lines 460 to 473 in e522919
In particular:
- both of those installers are aware of the concept of musl-static and musl-dynamic, and generate fallbacks for best-effort coverage of linux-gnu and linux-musl-dynamic (e.g. if there's no gnu build, say the musl-static build is a gnu build -- ditto for lack of musl-dynamic).
- both of those installers now internally do their analyses to select one of
- linux-gnu (lld reports glibc with sufficient version)
- linux-musl-dynamic (lld reports musl, no version checks yet)
- linux-musl-static (either glibc is too old, or an unknown libc is reported)
The piece that's missing is:
- Us accepting
linux-musl-static
andlinux-musl-dynamic
astargets
in[workspace.manifest.dist]
- Us desugarring those internally so that we pass the right flags/triple to cargo
- BUT keeping the sugar around in places like artifact names and the fallback/coverage logic in tasks.rs
- Also emit some metadata in dist-manifest.json indicating the crt-static-ness (may also want this for msvc targets?)
For this to work properly, work should also be done in:
- Oranda's artifact code to understand these sugars, and how to detect/select them in installer widgets
- axoproject's target triple listings / pretty-printing
- cargo-binstall's artifact name guessing, not sure where that is
Note also that we don't currently have a story for building musl-dynamic
on github CI. We might need custom infra or docker images to get a host Alpine system or something?