<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 28, 2014 at 10:13 AM, Matthias Hafner <span dir="ltr"><<a href="mailto:hafner87@gmail.com" target="_blank">hafner87@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi there,<div><br></div><div>Following up on <a href="https://bitbucket.org/pypa/wheel/issue/124/glibc-incompatibility" target="_blank">https://bitbucket.org/pypa/wheel/issue/124/glibc-incompatibility</a>.</div><div><br></div><div>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 machine. </div></div></blockquote><div><br></div><div>Wheel by itself simply cannot deal with this, you need something more.<br><br></div><div style="text-align:left">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.<br><br></div><div style="text-align:left">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.<br></div><div style="text-align:left"><br>David<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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?</div><div><br></div><div>Why does that work on MacOS, btw? Are all library versions fixed there for one version of OSX?</div></div></blockquote><div><br></div><div>Yes. Same for windows. The native toolchains there are fairly easy to configure for targetting a specific minimum version.<br><br>David<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks for putting some light into this issue.</div><div><br></div><div>Best regards,</div><div>Matthias</div></div>
<br>_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
<br></blockquote></div><br></div></div>