[Distutils] PEP425 - Wheel Binary Package Compatibility
cournape at gmail.com
Tue Oct 28 16:01:42 CET 2014
On Tue, Oct 28, 2014 at 10:13 AM, Matthias Hafner <hafner87 at gmail.com>
> Hi there,
> Following up on
> How should we deal with incompatibility of dynamically linked libraries?
> Doing "pip wheel numpy" on a Linux 64bit machine results in , which is
> linked dynamically against the GLIBC version installed on the build
Wheel by itself simply cannot deal with this, you need something more.
Practically speaking, there is no such a thing as ABI on Linux: even if you
somehow managed to deal with glibc, you would then need to deal with
fortran ABI, then with C++ ABI, etc... Dealing with this at the python
level is simply intractable. That needs to be handled at the distribution
level, or within a "sumo distribution" like Anaconda from Continuum or
Canopy from Enthought (disclaimer, I work for Enthought), which makes the
problem more tractable by picking up an ABI and stick with it for the full
set of packages.
In theory, you can try to emulate this by building on the oldest version of
each compiled library, and hope that your target platforms are ABI
compatible with this, but that's hard on Linux.
> So should the wheel be shipped with GLIBC, or the GLIBC version be
> specified in the wheel name (means to build a new wheel for each GLIBC
> version?). Also, maybe this is not the only library it is dynamically
> linked against?
> Why does that work on MacOS, btw? Are all library versions fixed there for
> one version of OSX?
Yes. Same for windows. The native toolchains there are fairly easy to
configure for targetting a specific minimum version.
> Thanks for putting some light into this issue.
> Best regards,
> Distutils-SIG maillist - Distutils-SIG at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG