libc not found in musllinux (or more generally when libc is statically linked)

[lesteve]

Not sure this is very high priority, but a variant of the warning seen in #167 happens on musllinux. My very crude understanding is that things are statically linked in musllinux.

For example in an Alpine container:

docker run -it python:3.12-alpine3.19 sh -c 'pip install threadpoolctl; python -c "import threadpoolctl; print(threadpoolctl.threadpool_info())"'

Output:

Collecting threadpoolctl
  Downloading threadpoolctl-3.3.0-py3-none-any.whl.metadata (13 kB)
Downloading threadpoolctl-3.3.0-py3-none-any.whl (17 kB)
Installing collected packages: threadpoolctl
Successfully installed threadpoolctl-3.3.0
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
/usr/local/lib/python3.12/site-packages/threadpoolctl.py:1195: RuntimeWarning: libc not found. The ctypes module in Python 3.12 is maybe too old for this OS.
  warnings.warn(
[]

Context I bumped into this when playing with Alpine containers related to scikit-learn/scikit-learn#27004

Using dllist the list of loaded shared libraries are given below:

docker run -it python:3.12-alpine3.19 sh -c 'pip install dllist; python -c "import dllist; print(dllist.dllist())"' 

Output:

Collecting dllist
  Downloading dllist-1.1.0-py3-none-any.whl.metadata (1.5 kB)
Downloading dllist-1.1.0-py3-none-any.whl (5.9 kB)
Installing collected packages: dllist
Successfully installed dllist-1.1.0
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
['/usr/local/bin/../lib/libpython3.12.so.1.0', '/lib/ld-musl-x86_64.so.1', '', '/usr/local/lib/python3.12/lib-dynload/_ctypes.cpython-312-x86_64-linux-musl.so', '/usr/lib/libffi.so.8', '/usr/local/lib/python3.12/lib-dynload/_struct.cpython-312-x86_64-linux-musl.so', '/usr/local/lib/python3.12/lib-dynload/zlib.cpython-312-x86_64-linux-musl.so', '/lib/libz.so.1', '/usr/local/lib/python3.12/lib-dynload/_bz2.cpython-312-x86_64-linux-musl.so', '/usr/lib/libbz2.so.1', '/usr/local/lib/python3.12/lib-dynload/_lzma.cpython-312-x86_64-linux-musl.so', '/usr/lib/liblzma.so.5', '/usr/local/lib/python3.12/lib-dynload/fcntl.cpython-312-x86_64-linux-musl.so', '/usr/local/lib/python3.12/lib-dynload/_posixsubprocess.cpython-312-x86_64-linux-musl.so', '/usr/local/lib/python3.12/lib-dynload/select.cpython-312-x86_64-linux-musl.so', '/usr/local/lib/python3.12/lib-dynload/math.cpython-312-x86_64-linux-musl.so', '/usr/local/lib/python3.12/lib-dynload/_bisect.cpython-312-x86_64-linux-musl.so', '/usr/local/lib/python3.12/lib-dynload/_random.cpython-312-x86_64-linux-musl.so', '/usr/local/lib/python3.12/lib-dynload/_sha2.cpython-312-x86_64-linux-musl.so']

[jeremiedbb]

I was surprised because dllist relies on libc, but not exactly like us. They do libc = ctype.CDLL(find_library("c")).
However, if libc is not found, find_library("c") will return None and apparently in that case CDLL will return the handle of the executable itself, so if libc is statically linked it will work.

I think it would make sense to have a 2 tries mechanism. First we look for a dynamically linked libc and if we don't find it, we directly look for dl_iterate_phdr (or _dyld_image_count on macos).