[pypy-dev] pypy 5.10 release

Nathaniel Smith njs at pobox.com
Tue Jan 2 18:25:17 EST 2018


I'm pretty sure that the right solution is to ship your own copy of openssl
with the build, so that you're totally independent from Apple's ssl
shenanigans. Maybe look at how CPython handles this.

On Jan 2, 2018 2:28 PM, "Matt Billenstein" <matt at vazor.com> wrote:

> Hi all,
>
> So the general issue seems to be Apple not shipping the header files for
> these
> shared libs-- not linking to the brew libffi works (I'm not sure it's
> linking
> to the system libffi at all now however -- or if it needs to), but then the
> problem became openssl headers.  I've hacked around this by manually
> placing
> the LibreSSL 2.2.7 headers in /usr/include -- this is what matches the
> 'openssl' binary on my High Sierra system.
>
> mattb at mattb-mbp2:/Users/pypy/buildarea $ openssl version
> LibreSSL 2.2.7
>
> So now I have a build with no brew linkage dependencies:
>
> mattb at mattb-mbp2:/Users/pypy/buildarea $ find . -name 'libpypy*' -type f
> | xargs otool -L
> ./pypy-c-jit-macosx-x86-64/build/pypy/goal/libpypy-c.dylib:
>         @rpath/libpypy-c.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         /usr/lib/libutil.dylib (compatibility version 1.0.0, current
> version 1.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>         /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current
> version 1.0.5)
>         /usr/lib/libz.1.dylib (compatibility version 1.0.0, current
> version 1.2.11)
>         /usr/lib/libssl.35.dylib (compatibility version 36.0.0, current
> version 36.0.0)
>         /usr/lib/libcrypto.35.dylib (compatibility version 36.0.0, current
> version 36.0.0)
>         /usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current
> version 8.0.0)
>         /usr/lib/libffi.dylib (compatibility version 1.0.0, current
> version 1.0.0)
>         /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0,
> current version 5.4.0)
>
> Which is closer to an older release:
>
> mattb at mattb-mbp2:/Users/pypy/buildarea $ otool -L
> ~pypy/pypy2-v5.9.0-osx64/bin/libpypy-c.dylib
> /Users/pypy/pypy2-v5.9.0-osx64/bin/libpypy-c.dylib:
>         @rpath/libpypy-c.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         /usr/lib/libutil.dylib (compatibility version 1.0.0, current
> version 1.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1197.1.1)
>         /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current
> version 1.0.5)
>         /usr/lib/libz.1.dylib (compatibility version 1.0.0, current
> version 1.2.5)
>         /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current
> version 0.9.8)
>         /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8,
> current version 0.9.8)
>         /usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current
> version 7.2.0)
>         /usr/lib/libffi.dylib (compatibility version 1.0.0, current
> version 1.0.0)
>         /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0,
> current version 5.4.0)
>
> The problem now is that probably this build won't work on older OSX
> releases
> with only older openssl versions...  Apple does ship the older dylib:
>
> mattb at mattb-mbp2:/Users/pypy/buildarea $ ls -l /usr/lib/*ssl*
> -rwxr-xr-x 1 root wheel 1217072 Oct 25 09:37 /usr/lib/libboringssl.dylib
> -rwxr-xr-x 1 root wheel  392912 Oct 25 09:37 /usr/lib/libssl.0.9.7.dylib
> -rwxr-xr-x 1 root wheel  630144 Oct 25 09:37 /usr/lib/libssl.0.9.8.dylib
> -rw-r--r-- 1 root wheel  947104 Oct 25 09:37 /usr/lib/libssl.35.dylib
> -rw-r--r-- 1 root wheel  890800 Oct 25 09:37 /usr/lib/libssl.43.dylib
> lrwxr-xr-x 1 root wheel      15 Nov  3 01:59 /usr/lib/libssl.dylib ->
> libssl.35.dylib
>
> So maybe linking to that and manually supplying the openssl 0.9.8 headers
> is
> desirable?
>
> Let me know if anyone has a better idea of how to go about this.
>
> thx
>
> m
>
> > On 31/12/2017 10:59 AM, blanch wrote:
> >
> > > hello, thanks for the 5.10 release!
> > >
> > > just a problem on the mac: it seems that the pypy3 binaries are linked
> against a libffi provided by a package manager (homebrew?), since dyld is
> looking for /usr/local/opt/libffi/lib/libffi.6.dylib (see below the error
> reported and otool output).
> > > since i do not use homebrew, it fails to execute on my mac.
> > > i have the problem with the pypy3 pre-sierra version, but according to
> a comment on the morepypy blog [0], the problem exist for high sierra
> version of pypy3 and for pypy2 (which looks for /usr/local/opt/openssl/lib/
> libssl.1.0.0.dylib)
> > >
> > > thanks again for your work, and best wishes for 2018!
> > >
> > > renaud
> > >
> > > 0. https://www.blogger.com/comment.g?blogID=
> 3971202189709462152&postID=3223396318213306071&bpli=1
> > We need someone who uses that OS and knows how to fix it to help us out.
> > Any ideas? SInce the same buildslave creates our pypy2 binaries as well,
> > I guess the problem occurs there too.
> > If anyone can help out, please issue a pull request or at least file an
> > issue on  https://bitbucket.org/pypy/pypy/issues (login required) with a
> > proposal for a fix.
>
> --
> Matt Billenstein
> matt at vazor.com
> http://www.vazor.com/
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20180102/a54f90f6/attachment.html>


More information about the pypy-dev mailing list