Path: blob/main/test/lib/python3.9/site-packages/pip/_internal/utils/glibc.py
4804 views
# The following comment should be removed at some point in the future.1# mypy: strict-optional=False23import os4import sys5from typing import Optional, Tuple678def glibc_version_string() -> Optional[str]:9"Returns glibc version string, or None if not using glibc."10return glibc_version_string_confstr() or glibc_version_string_ctypes()111213def glibc_version_string_confstr() -> Optional[str]:14"Primary implementation of glibc_version_string using os.confstr."15# os.confstr is quite a bit faster than ctypes.DLL. It's also less likely16# to be broken or missing. This strategy is used in the standard library17# platform module:18# https://github.com/python/cpython/blob/fcf1d003bf4f0100c9d0921ff3d70e1127ca1b71/Lib/platform.py#L175-L18319if sys.platform == "win32":20return None21try:22# os.confstr("CS_GNU_LIBC_VERSION") returns a string like "glibc 2.17":23_, version = os.confstr("CS_GNU_LIBC_VERSION").split()24except (AttributeError, OSError, ValueError):25# os.confstr() or CS_GNU_LIBC_VERSION not available (or a bad value)...26return None27return version282930def glibc_version_string_ctypes() -> Optional[str]:31"Fallback implementation of glibc_version_string using ctypes."3233try:34import ctypes35except ImportError:36return None3738# ctypes.CDLL(None) internally calls dlopen(NULL), and as the dlopen39# manpage says, "If filename is NULL, then the returned handle is for the40# main program". This way we can let the linker do the work to figure out41# which libc our process is actually using.42process_namespace = ctypes.CDLL(None)43try:44gnu_get_libc_version = process_namespace.gnu_get_libc_version45except AttributeError:46# Symbol doesn't exist -> therefore, we are not linked to47# glibc.48return None4950# Call gnu_get_libc_version, which returns a string like "2.5"51gnu_get_libc_version.restype = ctypes.c_char_p52version_str = gnu_get_libc_version()53# py2 / py3 compatibility:54if not isinstance(version_str, str):55version_str = version_str.decode("ascii")5657return version_str585960# platform.libc_ver regularly returns completely nonsensical glibc61# versions. E.g. on my computer, platform says:62#63# ~$ python2.7 -c 'import platform; print(platform.libc_ver())'64# ('glibc', '2.7')65# ~$ python3.5 -c 'import platform; print(platform.libc_ver())'66# ('glibc', '2.9')67#68# But the truth is:69#70# ~$ ldd --version71# ldd (Debian GLIBC 2.22-11) 2.2272#73# This is unfortunate, because it means that the linehaul data on libc74# versions that was generated by pip 8.1.2 and earlier is useless and75# misleading. Solution: instead of using platform, use our code that actually76# works.77def libc_ver() -> Tuple[str, str]:78"""Try to determine the glibc version7980Returns a tuple of strings (lib, version) which default to empty strings81in case the lookup fails.82"""83glibc_version = glibc_version_string()84if glibc_version is None:85return ("", "")86else:87return ("glibc", glibc_version)888990