I just checked and indeed the python exec installed by miniconda does
not work on Alpine linux (launch via docker from the gliderlabs/alpine
image):
# ldd /root/miniconda3/pkgs/python-3.4.3-0/bin/python3.4
/lib64/ld-linux-x86-64.so.2 (0x7f26bd5fe000)
libpython3.4m.so.1.0 =>
/root/miniconda3/pkgs/python-3.4.3-0/bin/../lib/libpython3.4m.so.1.0
(0x7f26bd153000)
libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f26bd5fe000)
libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f26bd5fe000)
libutil.so.1 => /lib64/ld-linux-x86-64.so.2 (0x7f26bd5fe000)
libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f26bd5fe000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f26bd5fe000)
Error relocating
/root/miniconda3/pkgs/python-3.4.3-0/bin/../lib/libpython3.4m.so.1.0:
__finite: symbol not found
Error relocating
/root/miniconda3/pkgs/python-3.4.3-0/bin/../lib/libpython3.4m.so.1.0:
__rawmemchr: symbol not found
Error relocating
/root/miniconda3/pkgs/python-3.4.3-0/bin/../lib/libpython3.4m.so.1.0:
__isinff: symbol not found
Error relocating
/root/miniconda3/pkgs/python-3.4.3-0/bin/../lib/libpython3.4m.so.1.0:
__isnan: symbol not found
Error relocating
/root/miniconda3/pkgs/python-3.4.3-0/bin/../lib/libpython3.4m.so.1.0:
__isinf: symbol not found
We could still have a platform or ABI tag for linux that would include
some libc information to ensure that it points to a compatible glibc
and provide a reference docker image to build such wheels.
We could assume that wheel binary packages should not link to any .so
file from the system besides the libc.
I think the packages that have specific kernel ABI requirements are
rare enough to be explicitly left outside of this first effort and let
the user build those from source directly. Is there an easy way to
introspect a binary to detect such kernel dependencies?
--
Olivier
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
