Merging this PR will not alter performance

✅ 5 untouched benchmarks

_{Comparing nooscraft:bugfix/19137 (13b038c) with main (3e9c333)}

Okay, I looked into this a bit more and I'm pretty there's a larger and nontrivial concern here:

• The original, underlying problem is that we're appending eabihf unconditionally on armv7 variants. This was already incorrect, but probably went unnoticed for a long time because it was only affecting the uv format upgrade pathway.
• Resolve official uv self-update versions before axoupdater #18674 changed that by using the same as_cargo_dist_triple logic that's used in the uv format upgrade pathway as part of uv's own upgrade logic, surfacing the long-standing bug on a hotter pathway.

In the happy path, this means we can probably just remove the eabihf append and things will work correctly for the gnu* case. However, that won't work for the musl* case, since our Libc::from_env detection currently only returns the base Musl variant rather than doing FP detection. It also won't work for the (probably rare) bare Gnu case, which can happen if FP detection fails (e.g. during reading/parsing /proc/cpuinfo).

I think the fix to the above is to properly emit Musleabi and Musleabihf variants in Libc::from_env, similarly to how gnu* detection works. Then, for the bare Gnu and Musl cases (FP detection failure), we can silently append the eabihf suffix (maybe with a warning to the user).

This will still be wrong for soft-float ARMv7 hosts that fail FP detection, but that's the existing behavior anyways (and is probably okay given how uncommon those are in 2026). It'll also be more correct for any unicorns out there running ARMv7 softfloat + musl, since they'll get an explicit matching failure rather than silently being given a hardfloat binary that'll SIGILL.

One wrinkle with the above though: fixing it at the Libc layer means that it'll affect PBS installation keys as well, so anybody on ARMv7+musl will start getting -musleabihf paths instead of -musl ones. I suspect that'll cause confusion if the host has other, older versions of uv installed, since those older versions won't be able to "see" the corrected paths. I'm not sure if this matters in practice.

TL;DR: I think this PR acts as a hotfix, but there's a larger (and more general) way we should probably handle this at the libc detection layer/in the Libc::from_env API.

I saw #19157 and agree that handling this at the Libc::from_env layer is the more complete fix.

I’ve force-pushed the inline-comment refactor here using the typed match guard for Gnueabihf | Musleabihf | Eabihf, and added the Musleabihf regression test by constructing the variant directly, since Libc::from_str doesn’t parse musleabihf today. Happy to defer to you on whether it’s worth keeping this PR open as the focused hotfix, or whether I should close it in favor of #19157.