Skip to content

Commit

Permalink
Handle dlopen(NULL) failure in glibc fallback
Browse files Browse the repository at this point in the history
  • Loading branch information
charliermarsh committed May 20, 2024
1 parent 612515d commit daddc6e
Showing 1 changed file with 14 additions and 1 deletion.
15 changes: 14 additions & 1 deletion src/pip/_internal/utils/glibc.py
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,20 @@ def glibc_version_string_ctypes() -> Optional[str]:
# manpage says, "If filename is NULL, then the returned handle is for the
# main program". This way we can let the linker do the work to figure out
# which libc our process is actually using.
process_namespace = ctypes.CDLL(None)
#
# We must also handle the special case where the executable is not a
# dynamically linked executable. This can occur when using musl libc,
# for example. In this situation, dlopen() will error, leading to an
# OSError. Interestingly, at least in the case of musl, there is no
# errno set on the OSError. The single string argument used to construct
# OSError comes from libc itself and is therefore not portable to
# hard code here. In any case, failure to call dlopen() means we
# can proceed, so we bail on our attempt.
try:
process_namespace = ctypes.CDLL(None)
except OSError:
return None

try:
gnu_get_libc_version = process_namespace.gnu_get_libc_version
except AttributeError:
Expand Down

0 comments on commit daddc6e

Please sign in to comment.