Currently, platform.libc_ver() opens Python binary file (ex: /usr/bin/python3) and looks for a string like "GLIBC-2.28".Maybe gnu_get_libc_version() should be exposed in Python to get the version of the running glibc version? And use it if available, or fall back on parsing the binary file (as done currenetly) otherwise.Example:$ cat x.c #include <gnu/libc-version.h>#include <stdlib.h>#include <stdio.h>intmain(int argc, char *argv[]){    printf("GNU libc version: %s\n", gnu_get_libc_version());    printf("GNU libc release: %s\n", gnu_get_libc_release());    exit(EXIT_SUCCESS);}$ ./xGNU libc version: 2.28GNU libc release: stableI'm not sure if it's possible that Python is compiled with glibc but run with a different libc implementation?--Alternative: run a program to get the libc version which *might* be different than the libc version of Python if the libc is upgraded in the meanwhile (unlikely, but is technically possible on a server running for days):$ ldd --versionldd (GNU libc) 2.28...$ /lib64/libc.so.6 GNU C Library (GNU libc) stable release version 2.28....$ rpm -q glibcglibc-2.28-17.fc29.x86_64...etc.--See also discussions on platform.libc_ver() performance:https://github.com/python/cpython/pull/10868

You can use confstr to get (running) glibc version:>>> os.confstr('CS_GNU_LIBC_VERSION')'glibc 2.28'

> >>> os.confstr('CS_GNU_LIBC_VERSION')> 'glibc 2.28'That's cool because it doesn't require to write new C code ;-)

Currently libc_ver() can be used for other executable. Seeissue26544 for discussion about libc_ver().

> Currently libc_ver() can be used for other executable. Seeissue26544 for discussion about libc_ver().Oh, my PR had a bug: it ignores executable. Fixed: it now only uses os.confstr() if the executable argument is not set.

New changeset476b113ed8531b9fbb0bd023a05eb3af21996600 by Victor Stinner in branch 'master':bpo-35389: platform.libc_ver() uses os.confstr() (GH-10891)https://github.com/python/cpython/commit/476b113ed8531b9fbb0bd023a05eb3af21996600

> Quick benchmark on Fedora 29:> python3 -m perf command ./python -S -c 'import platform; platform.libc_ver()'> 94.9 ms +- 4.3 ms -> 33.2 ms +- 1.4 ms: 2.86x faster (-65%)Oops, my benchmark in the commit message was wrong, it includes the startup time...Correct benchmark says 44,538x faster, it's *WAY* better![regex] 56.1 ms +- 1.9 ms -> [confstr] 1.26 us +- 0.04 us: 44537.88x faster (-100%)

Nice. I never liked the "parse the executable approach", but there wasn't anything better available at the time.

> Nice. I never liked the "parse the executable approach", but there wasn't anything better available at the time.Aha. Well, it's not perfect but it works and was fast enough (since libc_ver() is never used in performance critical code) :-)I'm now curious and looked at the history of this feature."man confstr" says:> _CS_GNU_LIBC_VERSION (GNU C library only; since glibc 2.3.2)glibc 2.3.2 has been released in March 2003, so it's fine, we should get this constant in most "modern" Linux (using glibc) in 2018 :-)man gnu_get_libc_version says:> These functions first appeared in glibc in version 2.1.glibc 2.1 has been released in Feb 1999. Using this function might provide even better compatibility but I'm not sure that it's worth it to use it. As I wrote, I prefer to not write a new function C, if os.confstr() can already be used in pure Python!Sadly, these functions (confstr(_CS_GNU_LIBC_VERSION) / gnu_get_libc_version()) are specific to glibc. Sorry, I'm not interested to support other libc, I mostly care about Fedora, sorry :-)

New changeset848acf7249b5669d73d70a7cb6e5ab60689cf825 by Victor Stinner in branch 'master':bpo-35389: test.pythoninfo logs platform.libc_ver (GH-10951)https://github.com/python/cpython/commit/848acf7249b5669d73d70a7cb6e5ab60689cf825

New changeseta719c8f4bd3cc5b1d98700c15c4a818f4d5617a4 by Victor Stinner in branch 'master':bpo-35389: platform.platform() calls libc_ver() without executable (GH-14418)https://github.com/python/cpython/commit/a719c8f4bd3cc5b1d98700c15c4a818f4d5617a4