On Tue, 7 Jul 2015 11:02:40 -0400
Donald Stufft <don...@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.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
