<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 2, 2016 at 11:05 AM, Nate Coraor <span dir="ltr"><<a href="mailto:nate@bx.psu.edu" target="_blank">nate@bx.psu.edu</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"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Tue, Mar 1, 2016 at 4:58 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On Tue, Mar 1, 2016 at 11:18 AM, Nate Coraor <<a href="mailto:nate@bx.psu.edu" target="_blank">nate@bx.psu.edu</a>> wrote:<br>
> So I am working on building my first set of manylinux1 wheels. The first<br>
> candidate is psycopg2. I was able to generate the wheel which brings in all<br>
> the necessary libs:<br>
</span>[...]<br>
<span>> However, attempting to use this wheel on Ubuntu 14.04 results in a failure<br>
> to load libpython2.7.so.1:<br>
><br>
>   ImportError: libpython2.7.so.1.0: cannot open shared object file: No such<br>
> file or directory<br>
><br>
> PEP 513 addresses libpythonX.Y.so.1 but only to say that it does not need to<br>
> be linked, nor should it be. Is my understanding correct, then, that I would<br>
> need to fix psycopg2 myself to *not* link to libpython (if this works -<br>
> won't there be unresolved symbols at link time?)? Is there a more general<br>
> solution to this problem?<br>
<br>
</span>Right, you need to not link to libpython. This does work -- it turns<br>
out that the linker doesn't check for unresolved symbols unless you<br>
specifically ask it to (via -Wl,--no-undefined or similar), I guess<br>
because the people who write linkers consider what we're doing here to<br>
be a valid use case :-).<br>
<br>
Are you using the docker images to build these? I thought we fixed it<br>
to not link to libpython by default, but if not then we should... (If<br>
your python is built with --disable-shared, which is the default when<br>
building from source, then by default any wheels you build with that<br>
python will not link to libpython. Unfortunately CentOS's python is<br>
built with --enable-shared. This is one of the reasons that the docker<br>
images build their own python instead of using the one shipped by<br>
CentOS.)<br></blockquote><div><br></div></div></div><div>I'm using the docker image and the purpose-built Python, yeah. It's a container that I started a few weeks ago though, so I can pull a new version of the image and see if it's fixed. The Python in my version of the image definitely has a shared libpython in the purpose-built Python build:</div><div><br></div><div><div><span style="white-space:pre-wrap">    </span>libpython2.7.so.1.0 => /opt/2.7.11/lib/libpython2.7.so.1.0 (0x00007fab9bdfd000)</div></div></div></div></div></blockquote><div><br></div><div>Yeah, sure enough, this is just due to an out-of-date image. The one I was using only had the shared libpython, the latest one only has the static. A psycopg2 wheel built in the new image is working.</div><div><br></div><div>Two further questions now that this works for me:</div><div><br></div><div>1. With SOABI tag support now available for Python 2.X, would a PR adding UCS-2 builds of Python to the docker image be accepted?</div><div><br></div><div>2. Is anyone working on the pip side of the changes necessary to install manylinux1 wheels? If not, I'll do this. </div><div><br></div><div>Also, I wonder if we should vendor auditwheel into wheel itself so you can directly build manylinux1 wheels.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Also, I guess Robert is a bit distracted by thesis-ing, but I think he<br>
was at least planning to make auditwheel check for and reject wheels<br>
that link to libpython (or possibly repair them -- I think patchelf<br>
can do that). Perhaps he'll speak up about that, or I'm sure he'd<br>
welcome a pull request :-). I guess that's the more-general solution<br>
you're looking for.<br></blockquote><div><br></div></span><div>A good idea, but if the docker image isn't supposed to produce wheels that link libpython, that's also a good general solution for me. =)</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><br>
> Related, some of these are concerning to me. Although CentOS 5 receives<br>
> updates, so its OpenSSL should be secure and bug-free, this is still OpenSSL<br>
> 0.9.8e. And bundling SELinux and Kerberos/GSSAPI libs also makes me a bit<br>
> worried.<br>
<br>
</span>I agree, it is worrying! But there's not much that can be done about<br>
it: if you want to make a single wheel that works across lots of linux<br>
distributions, and you need openssl, then you need to ship openssl,<br>
and that means that you need to take responsibility for keeping an eye<br>
out for security releases and respin your wheels when they happen.<br>
<br>
I guess the psycopg2 developers are already doing this for their<br>
Windows wheels, so perhaps they'll be willing to take on that<br>
responsibility for Linux wheels too? Or there might be things we can<br>
do to mitigate this somewhat: e.g., one can imagine the different<br>
folks who need to ship openssl getting together and building some<br>
shared infrastructure, so that they can share the burden -- like have<br>
one set of build scripts to update openssl and rebuild all their<br>
packages. Or once the native-libraries-in-wheels effort gets off the<br>
ground (sorry, I've been meaning to send out an email to kick that off<br>
but have been distracted by other things), then they'll be able to<br>
share a single openssl wheel and then that'll also centralize the<br>
update process. But fundamentally, the unavoidable fact is that if<br>
someone's not willing to take on responsibility for this somehow, then<br>
probably it's a bad idea for that person to ship manylinux wheels (or<br>
windows wheels, for that matter).<br></blockquote><div><br></div></span><div>Sure, this makes sense to me. I wonder if it would be a good idea to have something like Conda in the docker image that would make installing up-to-date versions of these sorts of dependencies trivial.</div><div><br></div><div>Thanks,</div><div>--nate</div><div><br></div><div>P.S., the archives for this list aren't showing up on <a href="http://mail.python.org" target="_blank">mail.python.org</a>, could you take a look in the list admin settings and see if they're enabled?</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><font color="#888888"><br>
-n<br>
<br>
--<br>
Nathaniel J. Smith -- <a href="https://vorpus.org" rel="noreferrer" target="_blank">https://vorpus.org</a><br>
</font></span></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>