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" <m...@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@mattb-mbp2:/Users/pypy/buildarea $ openssl version > LibreSSL 2.2.7 > > So now I have a build with no brew linkage dependencies: > > mattb@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@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@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 > m...@vazor.com > http://www.vazor.com/ > _______________________________________________ > pypy-dev mailing list > pypy-dev@python.org > https://mail.python.org/mailman/listinfo/pypy-dev >
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
