[Distutils] 400 Client Error: Binary wheel for an unsupported platform

[David Cournapeau]

On Fri, Jul 10, 2015 at 1:53 PM, Olivier Grisel <olivier.grisel at ensta.org>
wrote:

> 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.
>

This is too restrictive if you want plotting-related packages (which I
suspsect you are interested in ;) ).

The libraries we at Enthought depend on for our packages are:

* glibc (IMO if you use a system w/o glibc, you are expected to be on your
own to build packages from sources)
* X11/fontconfig
* libstdc++

Those are the ones you really do not want to ship.

I don't know the proportion of packages that would work from pypi if you
could assume the system has those available through some kind of
ABI/Platform specifier following pep425.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150710/9b8d503c/attachment.html>