gh-138130: Fix return value of libc_ver() on Emscripten

[hoodmane]

• Issue: On Emscripten, libc_ver reports glibc 2.14 #138130

[freakboy3742]

!buildbot emscripten

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @freakboy3742 for commit 29fb6c0 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F138132%2Fmerge

The command will test the builders whose names match following regular expression: emscripten

The builders matched are:

• WASM Emscripten PR

[freakboy3742]

Implementation looks good to me. It's also exciting to see the buildbot back in the green - although it highlights a new problem with the PyRepl test...

The only missing part is testing. There's an existing test in Lib/test/test_platform.py that validates the output of libc_ver, which is skipped on emscripten. This seems like as good an opportunity as any to add an extra test (or modify the existing one) that (a) verifies the new implementation works, and (b) formally validates that the build is returning the right Emscripten version. Since our 3.14 builds must always return Emscripten 4.0.12 (and for now, so do 3.15 builds), we can add a formal check for that.

On top of straightforward coverage, this has the added advantage that it protects us from inadvertently bumping a server configuration and rendering an Emscripten build unusable because of an ABI change.

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[Zheaoli]

Actually, I'm not sure if this is a good idea to return the emscripten version in libc_ver

For me, the doc is clean enough

Tries to determine the libc version against which the file executable (defaults to the Python interpreter) is linked. 

If we return the emscripten version in this function. I think we will make it more confusing.

[hoodmane]

Emscripten includes a funky libc with it, so I think it makes sense.

[freakboy3742]

Emscripten includes a funky libc with it, so I think it makes sense.

Agreed. The alternative would be to return ('musl', '...'), which would misrepresent the libc that is in use unless there was something in the version number specifier that made it clear it was a "patched musl" or something like that.. at which point, why not make it easier on yourself and just say it's not musl?

For me, it's analogous to the situation with Android. Yes, technically, Android is "a Linux" - but blurring Android in to a Linux descriptor hides a significant platform distinction in the hope that code that is "pure" Linux will "just work". It's better to provide a clear distinction, and require a "if Linux or Android" check as an opt-in.

[hoodmane]

Before I would have said call it musl but now Emscripten is using a hybrid of musl and llvm libc and is trying to transition all the way to an unpatched llvm libc in the long term. Once they are done with this process we can say it's llvm libc. For now, I think Emscripten libc is the best answer.