Upgrade `*-linux-musl` targets to musl 1.2.5

[Gankra]

Proposal

PR implementing this MCP

I propose to update all currently support musl targets to use musl 1.2.5 (February 2024) instead of musl 1.2.3 (April 2022). This update comes with several fixes and improvements, and a breaking change that affects the Rust ecosystem.

For the Rust ecosystem, the primary motivation for this update is to receive major improvements to musl's DNS resolver which shipped in 1.2.4 and received bug fixes in 1.2.5. When using musl targets for static linking, this should make portable linux binaries that do networking more reliable, particularly in the face of large DNS records and recursive nameservers. This is expected to acutely help with ongoing issues with rootless docker images of Rust applications.

However, 1.2.4 also comes with a breaking change: the removal of several legacy compatibility symbols that the Rust libc crate was using. A fix for this was shipped in libc 0.2.146 in June 2023 (2 years ago), and we have been waiting for newer versions of the libc crate to propagate throughout the ecosystem before shipping the musl update.

A crater run in July 2024 (a year ago) found only about 2% of rust projects were still affected. At this point we expect there will be minimal breakage, and most breakage should be resolved by a cargo update.

I believe this update shouldn't be held back any longer, as it contains critical fixes for the musl target, especially since we statically link musl on these targets, we're the only way our users get fixes for the target.

Updated targets

The following targets will be updated (this is just "all musl targets except loongarch64-unknown-linux-musl which already was on 1.2.5, and WALI which doesn't use our bundled musl"):

Tier 2 with Host Tools

target	notes
aarch64-unknown-linux-musl	ARM64 Linux with musl 1.2.3
powerpc64le-unknown-linux-musl	PPC64LE Linux (kernel 4.19, musl 1.2.3)
riscv64gc-unknown-linux-musl	RISC-V Linux (kernel 4.20, musl 1.2.3)
x86_64-unknown-linux-musl	64-bit Linux with musl 1.2.3

Tier 2 without Host Tools

target	std	notes
arm-unknown-linux-musleabi	✓	Armv6 Linux with musl 1.2.3
arm-unknown-linux-musleabihf	✓	Armv6 Linux with musl 1.2.3, hardfloat
armv5te-unknown-linux-musleabi	✓	Armv5TE Linux with musl 1.2.3
armv7-unknown-linux-musleabi	✓	Armv7-A Linux with musl 1.2.3
armv7-unknown-linux-musleabihf	✓	Armv7-A Linux with musl 1.2.3, hardfloat
i586-unknown-linux-musl	✓	32-bit Linux (musl 1.2.3, original Pentium)
i686-unknown-linux-musl	✓	32-bit Linux with musl 1.2.3 (Pentium 4)

Tier 3

target	std	host	notes
hexagon-unknown-linux-musl	✓		Hexagon Linux with musl 1.2.3
mips-unknown-linux-musl	✓		MIPS Linux with musl 1.2.3
mips64-openwrt-linux-musl	?		MIPS64 for OpenWrt Linux musl 1.2.3
mips64-unknown-linux-muslabi64	✓		MIPS64 Linux, N64 ABI, musl 1.2.3
mips64el-unknown-linux-muslabi64	✓		MIPS64 (little endian) Linux, N64 ABI, musl 1.2.3
mipsel-unknown-linux-musl	✓		MIPS (little endian) Linux with musl 1.2.3
powerpc-unknown-linux-musl	?		PowerPC Linux with musl 1.2.3
powerpc-unknown-linux-muslspe	?		PowerPC SPE Linux with musl 1.2.3
powerpc64-unknown-linux-musl	✓	✓	PPC64 Linux (kernel 4.19, musl 1.2.3)
riscv32gc-unknown-linux-musl	?		RISC-V Linux (kernel 5.4, musl 1.2.3 + RISCV32 support patches)
s390x-unknown-linux-musl	✓		S390x Linux (kernel 3.2, musl 1.2.3)
thumbv7neon-unknown-linux-musleabihf	?		Thumb2-mode Armv7-A Linux with NEON, musl 1.2.3
x86_64-unikraft-linux-musl	✓		64-bit Unikraft with musl 1.2.3

Next Steps

Per the Target Tier Policy, this MCP expresses the intent of the compiler team to ship these changes but is not the only signoff required to do so. The PR which implements these changes to the targets will be FCP'd by T-compiler, T-infra and T-release. A blog post explaining the change, the rationale and the expected fallout will be written and published on the Rust blog coinciding with the merge of the implementation PR.

(I have written such a blogpost, this MCP is actually just a tweaked version of it for the target audience.)

Mentors or Reviewers

This change does not require mentorship, just reviews from the usual teams.

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 merge on either the MCP or the PR.
• 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.

[rustbot]

Important

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.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[Noratrieb]

@mkroening @Itus-Shield @Amanieu @kraj @Gelbpunkt @famfo @neuschaefer @androm3da @uweigand
You maintain some *-musl targets (though the musl part is not the focus of any of your targets, as far as I understand), so I'm pinging you in case you have anything to say about this change.
DO NOT REPLY ON GITHUB, reply in the Zulip stream instead.

[Noratrieb]

@arjunr2 @BKPepe as well, see above