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

[Antoine Pitrou]

On Tue, 7 Jul 2015 11:02:40 -0400
Donald Stufft <donald at stufft.io> wrote:
> In my mind, the biggest reason to not just open up the ability to upload even
> generic linux wheels right now is the lack of a safe-ish default. I think if
> we added a few things:
> 
> * Default to per platform tags (e.g. ubuntu_14_04), but allow this to be
>   customized and also accept "Generic" Linux wheels as well.

That would be cool :)

> * Put the libc into the file name as well since it's reasonable to build a
>   "generic" linux wheel that statically links all dependencies (afaik), however
>   it does not really work to statically link glibc.

True. For example, here is the meat of a build of llvmlite on Linux:

$ ldd miniconda3/pkgs/llvmlite-0.6.0-py34_5/lib/python3.4/site-packages/llvmlite/binding/libllvmlite.so
	linux-vdso.so.1 =>  (0x00007ffeacefd000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8c9e2f5000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8c9e0d7000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8c9decf000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8c9dccb000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8c9d9c5000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8c9d7ae000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8c9d3ea000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8c9fcee000)

It embeds LLVM and has no dynamic reference to anything beside the most
basic runtime libraries (libstdc++ is statically linked in).  The .so
file doesn't even require Python (but the rest of llvmlite, which loads
the .so file using ctypes, does need Python, of course).

We use a similar strategy on Windows and OS X.

> This means that even if
>   you build against an old version of glibc if you're running on a Linux that
>   *doesnt* use glibc (like Alpine which uses MUSL) you'll run into problems.

glibc vs. non-glibc is yet a different concern IMHO. Mainstream Linux
setups use glibc.

> You have to ensure all your
> dependencies are statically linked (if you have any) and you have to ensure
> that you build against an old enough Linux (likely some form of CentOS).

Yes, we use CentOS 5...

> * Side question, since I don't actually know how a computer works: Is it even
>   possible to have a CPython extension link against a different libc than
>   CPython itself is linked against?

Half-incompetent answer here: I think link-time it would be fine. Then
at library load time it depends on whether the actual system glibc is
ABI/API-compatible with the one the C extension (and/or CPython itself)
was linked with.

Regards

Antoine.