Message330952
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>
int
main(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);
}
$ ./x
GNU libc version: 2.28
GNU libc release: stable
I'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 --version
ldd (GNU libc) 2.28
...
$ /lib64/libc.so.6
GNU C Library (GNU libc) stable release version 2.28.
...
$ rpm -q glibc
glibc-2.28-17.fc29.x86_64
...
etc.
--
See also discussions on platform.libc_ver() performance:
https://github.com/python/cpython/pull/10868 |
|
Date |
User |
Action |
Args |
2018-12-03 16:02:13 | vstinner | set | recipients:
+ vstinner |
2018-12-03 16:02:13 | vstinner | set | messageid: <1543852933.45.0.788709270274.issue35389@psf.upfronthosting.co.za> |
2018-12-03 16:02:13 | vstinner | link | issue35389 messages |
2018-12-03 16:02:13 | vstinner | create | |
|