Path: blob/master/venv/Lib/site-packages/pip/_internal/utils/glibc.py
811 views
# The following comment should be removed at some point in the future.1# mypy: strict-optional=False23from __future__ import absolute_import45import os6import sys78from pip._internal.utils.typing import MYPY_CHECK_RUNNING910if MYPY_CHECK_RUNNING:11from typing import Optional, Tuple121314def glibc_version_string():15# type: () -> Optional[str]16"Returns glibc version string, or None if not using glibc."17return glibc_version_string_confstr() or glibc_version_string_ctypes()181920def glibc_version_string_confstr():21# type: () -> Optional[str]22"Primary implementation of glibc_version_string using os.confstr."23# os.confstr is quite a bit faster than ctypes.DLL. It's also less likely24# to be broken or missing. This strategy is used in the standard library25# platform module:26# https://github.com/python/cpython/blob/fcf1d003bf4f0100c9d0921ff3d70e1127ca1b71/Lib/platform.py#L175-L18327if sys.platform == "win32":28return None29try:30# os.confstr("CS_GNU_LIBC_VERSION") returns a string like "glibc 2.17":31_, version = os.confstr("CS_GNU_LIBC_VERSION").split()32except (AttributeError, OSError, ValueError):33# os.confstr() or CS_GNU_LIBC_VERSION not available (or a bad value)...34return None35return version363738def glibc_version_string_ctypes():39# type: () -> Optional[str]40"Fallback implementation of glibc_version_string using ctypes."4142try:43import ctypes44except ImportError:45return None4647# ctypes.CDLL(None) internally calls dlopen(NULL), and as the dlopen48# manpage says, "If filename is NULL, then the returned handle is for the49# main program". This way we can let the linker do the work to figure out50# which libc our process is actually using.51process_namespace = ctypes.CDLL(None)52try:53gnu_get_libc_version = process_namespace.gnu_get_libc_version54except AttributeError:55# Symbol doesn't exist -> therefore, we are not linked to56# glibc.57return None5859# Call gnu_get_libc_version, which returns a string like "2.5"60gnu_get_libc_version.restype = ctypes.c_char_p61version_str = gnu_get_libc_version()62# py2 / py3 compatibility:63if not isinstance(version_str, str):64version_str = version_str.decode("ascii")6566return version_str676869# platform.libc_ver regularly returns completely nonsensical glibc70# versions. E.g. on my computer, platform says:71#72# ~$ python2.7 -c 'import platform; print(platform.libc_ver())'73# ('glibc', '2.7')74# ~$ python3.5 -c 'import platform; print(platform.libc_ver())'75# ('glibc', '2.9')76#77# But the truth is:78#79# ~$ ldd --version80# ldd (Debian GLIBC 2.22-11) 2.2281#82# This is unfortunate, because it means that the linehaul data on libc83# versions that was generated by pip 8.1.2 and earlier is useless and84# misleading. Solution: instead of using platform, use our code that actually85# works.86def libc_ver():87# type: () -> Tuple[str, str]88"""Try to determine the glibc version8990Returns a tuple of strings (lib, version) which default to empty strings91in case the lookup fails.92"""93glibc_version = glibc_version_string()94if glibc_version is None:95return ("", "")96else:97return ("glibc", glibc_version)9899100