Bug report

Bug description:

The functionplatform.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 calledmusl or a library calledlibc.musl with some arch-specific suffix. A glance at an Alpine container suggests thatlibc.musl*.so.* is just a symlink to the linker atld-musl-${arch}.so.${version}.

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

Expanding the second regex fromlibc.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 thelibc.musl alternative superfluous. However, as I don't use Alpine, I am not comfortable saying that simply replacinglibc.musl withld-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