musl target change

[passcod]

musl target change

[sunshowers]

I think it would be cool to have a way of declaring in your binstall metadata that the musl target is statically linked. (I guess also the minimum glibc version required if you really want to get fancy with target resolution.)

[polarathene]

From the above I think we'll also need link-self-contained=yes

When compiling a simple hello world dynamically linked via -crt-static with the rust:alpine container, this addition was required otherwise you'd get a failure:

error: linking with `cc` failed: exit status: 1

...

  = note: /usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find Scrt1.o: No such file or directory
          /usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find crti.o: No such file or directory
          collect2: error: ld returned 1 exit status

---

However if throwing in the mimalloc crate, you'd encounter another failure with compiling that (libmimalloc-sys implicit dep).

Both are resolved with apk add musl-dev. No additional rustc flag required.

rust-lang/compiler-team#422 (comment)

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.

• -C linked-self-contained=yes is only beneficial if you want to link to the objects provided by the rust toolchain.
• I suppose that would be a more deterministic source for builds to use, but otherwise only helpful to avoid running into build errors like shown above when your build host lacks the required files to use instead.

[NobodyXu]

Thanks for the info, I checked our CI and we use cargo-zigbuild for musl targets.

Not sure how it would be affected by this change but currently it works fine.

[NobodyXu]

looks like we need to pass +crt-static rustc

[passcod]

Yeah, I think there's two action items here:

1. We should build our own musl builds with +crt-static (optional, but probably wise to avoid breaking expectations)
2. We should change detect-targets to stop suggesting the standard -unknown-musl targets as fallback on glibc systems

Later we may want to add support for cargo-dist's -static/-dynamic targets, if that eventuates, or whichever solution people land on.

[NobodyXu]

We should change detect-targets to stop suggesting the standard -unknown-musl targets as fallback on glibc systems

That's unfortunate, I am against changing this to dynamic link by default.

Is there anywhere I can file my complaint?

[passcod]

[the zulip thread linked in] rust-lang/compiler-team#422

[passcod]

From the above I think we'll also need link-self-contained=yes

[NobodyXu]

I'm thinking of adding a new target $cpu_arch-alpine-linux-musl for dynamic linked musl, since AFAIK Alpine is the only distro that uses musl libc by default and have the dynamic library installed.

For all other $cpu_arch-unknown-linux-musl, they likely don't have musl libc installed and it still makes sense to link with musl libc statically most of the time, so it will continue to contain the statically linked musl.

[NobodyXu]

P.S. It seems that void and OpenWRT also link with musl libc dynamically.

[NobodyXu]

That sounds like a really nice solution, it will also solve the glibc version without having to manually parse the downloaded binaries.

[NobodyXu]

Pinning the issue to the top, as I believe it's time to start working on this issue, before the change is in stable rust.

I think we might want some way of detecting if a binary is statically linked after downloading it, since the old musl bin is all statically linked.

If we simply prevent fallback for musl, then it would cause many of such use cases to break.

[NobodyXu]

gimli-rs/object#682

[NobodyXu]

https://stackoverflow.com/a/55664341

Found PT_INTERP and program header in https://docs.rs/goblin/latest/goblin/elf/struct.Elf.html