Bug report

Bug description:

The function platform.libc_ver tries to detect the C library against which an executable is linked (sys.executable, by default) by matching a number of patterns. For musl, this includes looking for strings matching one of the regexes (irrelevant groups omitted)

musl-[0-9.]+
libc.musl(-\w+)?.so(\.\d[0-9.]*)?

These target Alpine Linux, which apparently may link against a library just called musl or a library called libc.musl with some arch-specific suffix. A glance at an Alpine container suggests that libc.musl*.so.* is just a symlink to the linker at ld-musl-${arch}.so.${version}.

On Void Linux with musl, we do not make a libc.musl symlink. Instead, libc.so is the generic name for the musl C library on Void, and ld-musl-${arch}.so.${version} is a symlink to this library. Both musl regexes fail to match this structure, so Python reports libc rather than musl.

Expanding the second regex from libc.musl to (libc.|ld-)musl will fix this. As a bonus, this also seems to match expectations on Alpine, where it will pick up the linker name and render the libc.musl alternative superfluous. However, as I don't use Alpine, I am not comfortable saying that simply replacing libc.musl with ld-musl is sufficient.

NOTE: libc.musl in the regex seems to be a mistake in itself. The . ought to be escaped to match a literal . rather than any character.

CPython versions tested on:

3.14, CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-141600: fix musl detection on Void Linux #141602
• [3.14] gh-141600: Fix musl version detection on Void Linux (GH-141602) #141850