On Sun, 31 May 2020, Matti Picus wrote:
It still seems to be included with the Command Line Tools, which can be installed using `xcode-select --install`: zaytsev:~ zaytsev$ locate ffi.h /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/ffi/ffi.h
- should we bundle libffi together in the tarball we supply?
Well, if you opt for using homebrew version, you'd have to do that, unless you want to force all users to install libffi via homebrew.
- is there a way to tell clang to statically link libffi.a rather than dynamically link to libffi.dylib? Is that desirable?
Try giving a full path like -l/usr/local/Cellar/libffi/3.2.1/lib/libffi.a It is probably easier, than copying libffi.6.dylib in your distribution and setting RPATH on the executable to make sure the loader is able to find it. -- Sincerely yours, Yury V. Zaytsev
On Sun, May 31, 2020 at 01:09:11AM +0300, Matti Picus wrote:
I'm going to remove the homebrew ffi from the PKG_CONFIG_PATH - should cause the system ffi to get used. I think if you want to ship portable binary packages, they should be self-contained - you can't really know what Apple is going to include or remove from release to release. I think this principle holds on the various Linux distros as well - you can't know what version of the various dependencies is going to be installed. m -- Matt Billenstein matt@vazor.com http://www.vazor.com/
On Sun, 31 May 2020, Matt Billenstein via pypy-dev wrote:
Well, the principled approach would be to do something like https://github.com/squeaky-pl/portable-pypy ... only it's a hell a lot of work, and the current package is "portable enough", so not sure this effort even makes a lot of sense.
I'm going to remove the homebrew ffi from the PKG_CONFIG_PATH - should cause the system ffi to get used.
Sounds great - probably one can do some trickery with -L & -I to force the build script to pick the system version over brew, but it's surely a lot of hassle and not really desirable. -- Sincerely yours, Yury V. Zaytsev
On Sun, May 31, 2020 at 11:39:31PM +0200, Yury V. Zaytsev wrote:
Hmm, yes, but the work done to support macos can be leveraged on Linux as well - so a given release of pypy could use the same source versions of all the dependencies across all platforms.
Yeah, may need to do some hackery, I think the default paths should include, but who knows. m -- Matt Billenstein matt@vazor.com http://www.vazor.com/
On 6/1/20 12:39 AM, Yury V. Zaytsev wrote:
| | |I think porting the current make_portable to macOS would not be so terrible. Since most of the work has been done for linux64/linux32, it is "just" a matter of adjusting the workflow. I opened https://foss.heptapod.net/pypy/pypy/issues/3240 which only requires devop-level python skills to fix. Help is welcome.| | | |Matti | ||
On Mon, Jun 01, 2020 at 08:49:29AM +0300, Matti Picus wrote:
I've made some progress on this $ otool -L bin/libpypy3-c.dylib bin/libpypy3-c.dylib: @rpath/libpypy3-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) @rpath/libintl.8.dylib (compatibility version 10.0.0, current version 10.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) @rpath/libexpat.1.dylib (compatibility version 7.0.0, current version 8.0.0) @rpath/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) @rpath/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11) @rpath/libffi.dylib (compatibility version 1.0.0, current version 26.0.0) @rpath/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) $ DYLD_PRINT_LIBRARIES=1 bin/pypy3 -c '1' 2>&1 | egrep 'expat|ffi' dyld: loaded: <1ED53818-578C-3D17-8761-68792CCAD685> /private/tmp/usession-unknown-35/build/mattb/bin/../lib/libexpat.1.dylib dyld: loaded: <2AACAE86-FCF4-3613-89A4-5F822BD92AA9> /private/tmp/usession-unknown-35/build/mattb/bin/../lib/libffi.dylib Trying to commit changes to make_portable.py -- I cloned the pypy repo, but getting stuck at 'hg topic issue3240' -- do I need a newer version of mercurial or something? thx m -- Matt Billenstein matt@vazor.com http://www.vazor.com/
On 6/2/20 1:46 AM, Matt Billenstein wrote:
You need to install the "topic" extension: https://heptapod.net/pages/quick-start-guide.html If you are still stuck, try posting the result of `hg version -v` Thanks Matti
On 6/2/20 1:46 AM, Matt Billenstein wrote:
Just to follow up here: thanks to Matt we have a "portable build" candidate available here http://buildbot.pypy.org/nightly/issue3240 It would be nice if someone who could not use the 7.3.1 release tarball would give this a try and let us know if it works. Still to do: I think we need to include the tc/tkl runtime, maybe in a different PR. Matti
Attempting a custom build outside of the buildbot and I'm linking system libffi, but it's not picking up gettext out of /usr/local - is there any way to tell the toolchain to not link anything in /usr/local? $ otool -L libpypy3-c.dylib libpypy3-c.dylib: @rpath/libpypy3-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/local/opt/gettext/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) /usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 8.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/libffi.dylib (compatibility version 1.0.0, current version 26.0.0) /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) $ ls -l /usr/local/lib/libintl.8.dylib lrwxr-xr-x 1 mattb staff 46 Apr 29 16:54 /usr/local/lib/libintl.8.dylib -> ../Cellar/gettext/0.20.2_1/lib/libintl.8.dylib m On Sun, May 31, 2020 at 01:09:11AM +0300, Matti Picus wrote:
-- Matt Billenstein matt@vazor.com http://www.vazor.com/
On Sun, 31 May 2020, Matti Picus wrote:
It still seems to be included with the Command Line Tools, which can be installed using `xcode-select --install`: zaytsev:~ zaytsev$ locate ffi.h /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/ffi/ffi.h
- should we bundle libffi together in the tarball we supply?
Well, if you opt for using homebrew version, you'd have to do that, unless you want to force all users to install libffi via homebrew.
- is there a way to tell clang to statically link libffi.a rather than dynamically link to libffi.dylib? Is that desirable?
Try giving a full path like -l/usr/local/Cellar/libffi/3.2.1/lib/libffi.a It is probably easier, than copying libffi.6.dylib in your distribution and setting RPATH on the executable to make sure the loader is able to find it. -- Sincerely yours, Yury V. Zaytsev
On Sun, May 31, 2020 at 01:09:11AM +0300, Matti Picus wrote:
I'm going to remove the homebrew ffi from the PKG_CONFIG_PATH - should cause the system ffi to get used. I think if you want to ship portable binary packages, they should be self-contained - you can't really know what Apple is going to include or remove from release to release. I think this principle holds on the various Linux distros as well - you can't know what version of the various dependencies is going to be installed. m -- Matt Billenstein matt@vazor.com http://www.vazor.com/
On Sun, 31 May 2020, Matt Billenstein via pypy-dev wrote:
Well, the principled approach would be to do something like https://github.com/squeaky-pl/portable-pypy ... only it's a hell a lot of work, and the current package is "portable enough", so not sure this effort even makes a lot of sense.
I'm going to remove the homebrew ffi from the PKG_CONFIG_PATH - should cause the system ffi to get used.
Sounds great - probably one can do some trickery with -L & -I to force the build script to pick the system version over brew, but it's surely a lot of hassle and not really desirable. -- Sincerely yours, Yury V. Zaytsev
On Sun, May 31, 2020 at 11:39:31PM +0200, Yury V. Zaytsev wrote:
Hmm, yes, but the work done to support macos can be leveraged on Linux as well - so a given release of pypy could use the same source versions of all the dependencies across all platforms.
Yeah, may need to do some hackery, I think the default paths should include, but who knows. m -- Matt Billenstein matt@vazor.com http://www.vazor.com/
On 6/1/20 12:39 AM, Yury V. Zaytsev wrote:
| | |I think porting the current make_portable to macOS would not be so terrible. Since most of the work has been done for linux64/linux32, it is "just" a matter of adjusting the workflow. I opened https://foss.heptapod.net/pypy/pypy/issues/3240 which only requires devop-level python skills to fix. Help is welcome.| | | |Matti | ||
On Mon, Jun 01, 2020 at 08:49:29AM +0300, Matti Picus wrote:
I've made some progress on this $ otool -L bin/libpypy3-c.dylib bin/libpypy3-c.dylib: @rpath/libpypy3-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) @rpath/libintl.8.dylib (compatibility version 10.0.0, current version 10.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) @rpath/libexpat.1.dylib (compatibility version 7.0.0, current version 8.0.0) @rpath/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) @rpath/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11) @rpath/libffi.dylib (compatibility version 1.0.0, current version 26.0.0) @rpath/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) $ DYLD_PRINT_LIBRARIES=1 bin/pypy3 -c '1' 2>&1 | egrep 'expat|ffi' dyld: loaded: <1ED53818-578C-3D17-8761-68792CCAD685> /private/tmp/usession-unknown-35/build/mattb/bin/../lib/libexpat.1.dylib dyld: loaded: <2AACAE86-FCF4-3613-89A4-5F822BD92AA9> /private/tmp/usession-unknown-35/build/mattb/bin/../lib/libffi.dylib Trying to commit changes to make_portable.py -- I cloned the pypy repo, but getting stuck at 'hg topic issue3240' -- do I need a newer version of mercurial or something? thx m -- Matt Billenstein matt@vazor.com http://www.vazor.com/
On 6/2/20 1:46 AM, Matt Billenstein wrote:
You need to install the "topic" extension: https://heptapod.net/pages/quick-start-guide.html If you are still stuck, try posting the result of `hg version -v` Thanks Matti
On 6/2/20 1:46 AM, Matt Billenstein wrote:
Just to follow up here: thanks to Matt we have a "portable build" candidate available here http://buildbot.pypy.org/nightly/issue3240 It would be nice if someone who could not use the 7.3.1 release tarball would give this a try and let us know if it works. Still to do: I think we need to include the tc/tkl runtime, maybe in a different PR. Matti
Attempting a custom build outside of the buildbot and I'm linking system libffi, but it's not picking up gettext out of /usr/local - is there any way to tell the toolchain to not link anything in /usr/local? $ otool -L libpypy3-c.dylib libpypy3-c.dylib: @rpath/libpypy3-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/local/opt/gettext/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) /usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 8.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/libffi.dylib (compatibility version 1.0.0, current version 26.0.0) /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) $ ls -l /usr/local/lib/libintl.8.dylib lrwxr-xr-x 1 mattb staff 46 Apr 29 16:54 /usr/local/lib/libintl.8.dylib -> ../Cellar/gettext/0.20.2_1/lib/libintl.8.dylib m On Sun, May 31, 2020 at 01:09:11AM +0300, Matti Picus wrote:
-- Matt Billenstein matt@vazor.com http://www.vazor.com/
participants (3)
-
Matt Billenstein -
Matti Picus -
Yury V. Zaytsev