I think supporting just the more recent OS X releases (Sierra, High Sierra) is
fine. I recently had to upgrade my Mac to Sierra because I was running into
packages that wouldn't work on the older version. (There seems to be a
"get_entropy" function in Sierra, and things were failing because it wasn't
present in the older OS.)
If my experience is any guide, OS X is not a production environment, it's just
a dev environment for things that'll ultimately be deployed on Linux.
Barry
On Tuesday, January 2, 2018 5: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
