Cargo error after installing last nightly on aarch64-unknown-linux-musl (Alpine 3.15 based docker container)

[yogh333]

Problem

After upgrading to the last nightly rustup update nightly, I have an error when trying to use cargo:

cargo +nightly
Error relocating /opt/rustup/toolchains/nightly-aarch64-unknown-linux-musl/bin/cargo: pthread_getname_np: symbol not found

Same issue with rustc

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

No response

[weihanglo]

Please include the version of the toolchain via cargo -vV, and also the steps to reproduce. Thank you.

[yogh333]

cargo -vV
cargo 1.75.0 (1d8b05cdd 2023-11-20)
release: 1.75.0
commit-hash: 1d8b05cdd1287c64467306cf3ca2c8ac60c11eb0
commit-date: 2023-11-20
host: aarch64-unknown-linux-musl
libgit2: 1.7.1 (sys:0.18.1 vendored)
libcurl: 8.4.0-DEV (sys:0.4.68+curl-8.4.0 vendored ssl:OpenSSL/1.1.1u)
ssl: OpenSSL 1.1.1u  30 May 2023
os: Alpine Linux 3.15.11 [64-bit]

Steps to reproduce:

• rustup update nightly
• cargo +nightly -vV => Error relocating /opt/rustup/toolchains/nightly-aarch64-unknown-linux-musl/bin/cargo: pthread_getname_np: symbol not found

[ehuss]

Transferred to rust-lang/rust, since this was a change via #121666.

cc @ChrisDenton

[ehuss]

I believe the issue is that pthread_getname_np was added in musl 1.2.3, but that version of Alpine has musl 1.2.2.

[ChrisDenton]

Hm I thought our minimum support was for 1.2.3? E.g. https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/src/ci/docker/scripts/musl-toolchain.sh#L48C53-L48C58

Edit: Ah rust-lang/compiler-team#572

[ehuss]

Ah. Yea, the minimum requirements were updated to musl 1.2.3 in Rust 1.71.

Should the minimum version be specified in https://doc.rust-lang.org/nightly/rustc/platform-support.html? cc @wesleywiser if you had a reason to not document that?

[wesleywiser]

@ehuss No reason not to document it, the platform support doc just slipped my mind when I did the change. I've opened #121994 to document it.

[ehuss]

Unless someone knows of a way for the binary to produce a better error message when a too-old environment is used for the -linux-musl target, I would suggest this issue be closed as resolved. I'm not familiar with musl or how to handle versioning with its .so.

[wesleywiser]

I'm not aware of an option here either so I'm going to close this. The proper solution is probably to have musl's loader detect the situation and offer a better error message.