From CallumPallett2004 at outlook.com Sun May 10 10:09:59 2020 From: CallumPallett2004 at outlook.com (Callum Pallett) Date: Sun, 10 May 2020 14:09:59 +0000 Subject: [pypy-dev] Pypy Message-ID: Dear sir/madam I'm having problems with pypy and would like some help. I have been using replicatorG-0040 on my 3d printer and it is struggling to use pypy as the interpritor. Thanks Callum Get Outlook for Android -------------- next part -------------- An HTML attachment was scrubbed... URL: From massimo.sala.71 at gmail.com Mon May 11 08:11:26 2020 From: massimo.sala.71 at gmail.com (Massimo Sala) Date: Mon, 11 May 2020 14:11:26 +0200 Subject: [pypy-dev] Fwd: Python2.7 compatible PyPy 7.3.1 on Windows In-Reply-To: References: Message-ID: Hi I just download the Windows setup pypy2.7-v7.3.1-win32.zip I am trying to install the Postgresql module psycopg2 The installation of the source module fails ... suggesting If you prefer to avoid building psycopg2 from source, please install the PyPI 'psycopg2-binary' package instead. I retry with the binary package... same error. Something is not working between pypy and this package. Could you please take a look? Is it possible to overcome this bug.. editing the egg or other files? This problem is a stopper for my daily usage of pypy. Best regards, Massimo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: psycopg2-binary.log Type: application/octet-stream Size: 2775 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: psycopg2.log Type: application/octet-stream Size: 2635 bytes Desc: not available URL: From armin.rigo at gmail.com Tue May 12 02:09:31 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Tue, 12 May 2020 08:09:31 +0200 Subject: [pypy-dev] Fwd: Python2.7 compatible PyPy 7.3.1 on Windows In-Reply-To: References: Message-ID: Hi, On Mon, 11 May 2020 at 19:24, Massimo Sala wrote: > I am trying to install the Postgresql module psycopg2 > The installation of the source module fails ... suggesting > If you prefer to avoid building psycopg2 from source, please install the PyPI > 'psycopg2-binary' package instead. The binary package can't work, because it was compiled for CPython. The source package fails to install because of this error (see psycopg2.log): Error: pg_config executable not found. i suggest you check your installation. My guess is that you need to have a C compiler and have installed with the headers necessary to compile programs using psycopg2. I don't know if there is an issue with the program pg_config on Windows. Maybe look if there are specific instructions about how to compile the psycopg2 Python package from source on Windows (instructions written with CPython in mind, but that probably work with PyPy too). Alternatively, you should look for psycopg2cffi. A bient?t, Armin From lebedevvaleras4 at gmail.com Wed May 20 22:49:02 2020 From: lebedevvaleras4 at gmail.com (=?utf-8?Q?Valerij_=E2=80=9CDerad6709=E2=80=9D_Lebedev?=) Date: Thu, 21 May 2020 05:49:02 +0300 Subject: [pypy-dev] Pypy Message-ID: Hey sorry pls I can?t install builded nightly versions to my ubuntu... i tried to create symlink but pip (pypy3 -mpip install installing packages to the Python, not to pypy with symlink) could you help me, how can I install nigthly version at my ubuntu easily? Thank you ? Sent from my iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Thu May 21 04:06:37 2020 From: matti.picus at gmail.com (Matti Picus) Date: Thu, 21 May 2020 11:06:37 +0300 Subject: [pypy-dev] Pypy In-Reply-To: References: Message-ID: <699647a7-9a4f-5765-c89c-be96333a308d@gmail.com> On 21/5/20 5:49 am, Valerij ?Derad6709? Lebedev wrote: > Hey sorry pls I can?t install builded nightly versions to my ubuntu... > i tried to create symlink but pip (pypy3 -mpip install installing > packages to the Python, not to pypy with symlink) could you help me, > how can I install nigthly version at my ubuntu easily? Thank you ? > If you mean that `pypy -mpip install ...` is installing to a different python, perhaps you have some environment variables such as PYTHONPATH set. Does `set | grep PYTHON` show anything? What is the full output from the comand you are executing? Matti From dholth at gmail.com Tue May 26 23:18:34 2020 From: dholth at gmail.com (Daniel Holth) Date: Tue, 26 May 2020 23:18:34 -0400 Subject: [pypy-dev] cffi embedding interface uwsgi plugin In-Reply-To: References: Message-ID: Is anyone else interested in using uwsgi + pypy? My cffi plugin https://github.com/unbit/uwsgi/pull/2170 is working fairly well now in ordinary WSGI mode, with --mount=/app=hello.py support. I spent a while trying to port uwsgi's experimental asyncio loop over to pypy using pypy's builtin greenlets. In this mode an external event loop drives uwsgi's i/o.The uwsgi async API demo https://github.com/unbit/uwsgi/blob/master/tests/websockets_chat_async.py was enough to get working with continulets, but I mostly got segfaults trying to rewrite the more complicated and experimental asyncio event loop "asyncio.c" to an "asyncio.py" using pypy's greenlets. So I gave up on async for now. I'm developing against a nightly build of pypy Python 3.6.9 (d011d093933c, May 20 2020, 01:00:25), PyPy 7.3.2-alpha0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcardon at tranquil.it Thu May 28 11:58:46 2020 From: dcardon at tranquil.it (Denis Cardon) Date: Thu, 28 May 2020 17:58:46 +0200 Subject: [pypy-dev] pypy 3.6 and WinXP Message-ID: <42461124-5a7d-01ce-af40-a8e501704902@tranquil.it> Hi everyone, sorry if this is not the best place to ask the question, feel free to forward me to a better place for this kind of question :-) I was wondering PyPy 3.6 is supposed to run on WinXP SP3 32bit. Running the pypy3.exe says that it not a valid win32 app (but it runs fine on win7), like if it was a 64bit application only... The vc2015 dependency install fine on WinXP however there is no mention on PyPy website if it supposed to work... WinXP is actually still very common in industrial setups and it would be great if it would work with PyPy as CPython has drop WinXP support after 3.4. Cheers, Denis -- Denis Cardon Tranquil IT 12 avenue Jules Verne (Bat. A) 44230 Saint S?bastien sur Loire (FRANCE) tel : +33 (0) 240 975 755 http://www.tranquil.it Tranquil IT recrute! https://www.tranquil.it/nous-rejoindre/ Samba install wiki for Frenchies : https://dev.tranquil.it WAPT, software deployment made easy : https://wapt.fr From jjenne025 at go.tahomasd.us Thu May 28 16:56:23 2020 From: jjenne025 at go.tahomasd.us (Joseph Jenne) Date: Thu, 28 May 2020 13:56:23 -0700 Subject: [pypy-dev] pypy 3.6 and WinXP In-Reply-To: <42461124-5a7d-01ce-af40-a8e501704902@tranquil.it> References: <42461124-5a7d-01ce-af40-a8e501704902@tranquil.it> Message-ID: <4353f6f5-7df5-f4ef-8ab8-4bdc241b8411@go.tahomasd.us> On 5/28/20 8:58 AM, Denis Cardon wrote: > Hi everyone, > > sorry if this is not the best place to ask the question, feel free to > forward me to a better place for this kind of question :-) > > I was wondering PyPy 3.6 is supposed to run on WinXP SP3 32bit. > Running the pypy3.exe says that it not a valid win32 app (but it runs > fine on win7), like if it was a 64bit application only... The vc2015 > dependency install fine on WinXP however there is no mention on PyPy > website if it supposed to work... > > WinXP is actually still very common in industrial setups and it would > be great if it would work with PyPy as CPython has drop WinXP support > after 3.4. > > Cheers, > > Denis Although it may make sense to support it, Windows XP is long past end of life, and so continued support for it should not be expected, since even Microsoft doesn't support it anymore. From armin.rigo at gmail.com Fri May 29 04:15:27 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Fri, 29 May 2020 10:15:27 +0200 Subject: [pypy-dev] pypy 3.6 and WinXP In-Reply-To: <42461124-5a7d-01ce-af40-a8e501704902@tranquil.it> References: <42461124-5a7d-01ce-af40-a8e501704902@tranquil.it> Message-ID: Hi Denis, On Thu, 28 May 2020 at 18:05, Denis Cardon wrote: > WinXP is actually still very common in industrial setups and it would be > great if it would work with PyPy as CPython has drop WinXP support after > 3.4. I see the point. If some parts of the industry want a modern version of Python but are otherwise stuck on WinXP, then it can be problematic for them. I am rather sure that no-one among the core developers will do it for free. I suppose that a contract job could be arranged if there is enough money, though. The correct place to discuss this is probably pypy-z at python.org . A bient?t, Armin. From dcardon at tranquil.it Fri May 29 04:44:49 2020 From: dcardon at tranquil.it (Denis Cardon) Date: Fri, 29 May 2020 10:44:49 +0200 Subject: [pypy-dev] pypy 3.6 and WinXP In-Reply-To: <4353f6f5-7df5-f4ef-8ab8-4bdc241b8411@go.tahomasd.us> References: <42461124-5a7d-01ce-af40-a8e501704902@tranquil.it> <4353f6f5-7df5-f4ef-8ab8-4bdc241b8411@go.tahomasd.us> Message-ID: <40b3a20a-7564-de08-c1d7-3965624309e5@tranquil.it> Hi Joseph, Le 05/28/2020 ? 10:56 PM, Joseph Jenne via pypy-dev a ?crit : > On 5/28/20 8:58 AM, Denis Cardon wrote: >> Hi everyone, >> >> sorry if this is not the best place to ask the question, feel free to >> forward me to a better place for this kind of question :-) >> >> I was wondering PyPy 3.6 is supposed to run on WinXP SP3 32bit. >> Running the pypy3.exe says that it not a valid win32 app (but it runs >> fine on win7), like if it was a 64bit application only... The vc2015 >> dependency install fine on WinXP however there is no mention on PyPy >> website if it supposed to work... >> >> WinXP is actually still very common in industrial setups and it would >> be great if it would work with PyPy as CPython has drop WinXP support >> after 3.4. >> >> Cheers, >> >> Denis > Although it may make sense to support it, Windows XP is long past end of > life, and so continued support for it should not be expected, since even > Microsoft doesn't support it anymore. thanks for your answer. I completely agree that WinXP shouldn't be used in office setup anymore. However in industrial setups it is still a very common (perhaps the most common?) operating system. In this kind of industrial setup change of OS is very costly (you may need to change hardware, connectivity card, or even the whole CNC machine). Those system are obviously not connected to the internet... Actually seeing a MSDOS, a QNX or NT4 machine in factory is not that uncommon... With that in perspective WinXP seems modern :-) CPython>3.4 is not compatible with WinXP anymore, and as it is more reliant on C code and on recent VCRedist, I guess there is not much hope on this side. On the other hand PyPy is using vcredist2015 (which is still compatible with XP) and and is less reliant on C Code. So I was wondering if there is any reasons for PyPy3.6 not to work on XP? If you think it is just a compile time issue, I'll be happy try to rebuild it on WinXP. If it has some more tricky issues, I'd be willing to spend some time / money on this. The use case is for WAPT, a Software Deployment solution that use Python as its packaging scripting language. Cheers, Denis [1] https://www.wapt.fr/en/doc/ > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev -- Denis Cardon Tranquil IT 12 avenue Jules Verne (Bat. A) 44230 Saint S?bastien sur Loire (FRANCE) tel : +33 (0) 240 975 755 http://www.tranquil.it Tranquil IT recrute! https://www.tranquil.it/nous-rejoindre/ Samba install wiki for Frenchies : https://dev.tranquil.it WAPT, software deployment made easy : https://wapt.fr From jjenne025 at go.tahomasd.us Fri May 29 14:09:39 2020 From: jjenne025 at go.tahomasd.us (Joseph Jenne) Date: Fri, 29 May 2020 11:09:39 -0700 Subject: [pypy-dev] pypy 3.6 and WinXP In-Reply-To: <40b3a20a-7564-de08-c1d7-3965624309e5@tranquil.it> References: <42461124-5a7d-01ce-af40-a8e501704902@tranquil.it> <4353f6f5-7df5-f4ef-8ab8-4bdc241b8411@go.tahomasd.us> <40b3a20a-7564-de08-c1d7-3965624309e5@tranquil.it> Message-ID: <5b0cde27-5c49-dbb7-8ca9-5397e209d4de@go.tahomasd.us> I don't have much experience with the windows side of pypy, especially on XP, but I would suggest trying to compile for your system, as I do not know of any reasons for incompatibility. That said, perhaps using a somewhat older version might be preferable, depending on the specifics of your use case On 5/29/20 1:44 AM, Denis Cardon wrote: > Hi Joseph, > > Le 05/28/2020 ? 10:56 PM, Joseph Jenne via pypy-dev a ?crit : >> On 5/28/20 8:58 AM, Denis Cardon wrote: >>> Hi everyone, >>> >>> sorry if this is not the best place to ask the question, feel free to >>> forward me to a better place for this kind of question :-) >>> >>> I was wondering PyPy 3.6 is supposed to run on WinXP SP3 32bit. >>> Running the pypy3.exe says that it not a valid win32 app (but it runs >>> fine on win7), like if it was a 64bit application only... The vc2015 >>> dependency install fine on WinXP however there is no mention on PyPy >>> website if it supposed to work... >>> >>> WinXP is actually still very common in industrial setups and it would >>> be great if it would work with PyPy as CPython has drop WinXP support >>> after 3.4. >>> >>> Cheers, >>> >>> Denis >> Although it may make sense to support it, Windows XP is long past end of >> life, and so continued support for it should not be expected, since even >> Microsoft doesn't support it anymore. > > thanks for your answer. I completely agree that WinXP shouldn't be > used in office setup anymore. However in industrial setups it is still > a very common (perhaps the most common?) operating system. In this > kind of industrial setup change of OS is very costly (you may need to > change hardware, connectivity card, or even the whole CNC machine). > Those system are obviously not connected to the internet... Actually > seeing a MSDOS, a QNX or NT4 machine in factory is not that > uncommon... With that in perspective WinXP seems modern :-) > > CPython>3.4 is not compatible with WinXP anymore, and as it is more > reliant on C code and on recent VCRedist, I guess there is not much > hope on this side. > > On the other hand PyPy is using vcredist2015 (which is still > compatible with XP) and and is less reliant on C Code. > > So I was wondering if there is any reasons for PyPy3.6 not to work on > XP? If you think it is just a compile time issue, I'll be happy try to > rebuild it on WinXP. If it has some more tricky issues, I'd be willing > to spend some time / money on this. > > The use case is for WAPT, a Software Deployment solution that use > Python as its packaging scripting language. > > Cheers, > > Denis > > [1] https://www.wapt.fr/en/doc/ > > >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev at python.org >> https://mail.python.org/mailman/listinfo/pypy-dev > From matti.picus at gmail.com Sat May 30 18:09:11 2020 From: matti.picus at gmail.com (Matti Picus) Date: Sun, 31 May 2020 01:09:11 +0300 Subject: [pypy-dev] help needed: libffi and recent macOS Message-ID: <028f67b2-73d5-499f-3131-ddac0f7d45b7@gmail.com> An HTML attachment was scrubbed... URL: From yury at shurup.com Sat May 30 18:37:50 2020 From: yury at shurup.com (Yury V. Zaytsev) Date: Sun, 31 May 2020 00:37:50 +0200 (CEST) Subject: [pypy-dev] help needed: libffi and recent macOS In-Reply-To: <028f67b2-73d5-499f-3131-ddac0f7d45b7@gmail.com> References: <028f67b2-73d5-499f-3131-ddac0f7d45b7@gmail.com> Message-ID: On Sun, 31 May 2020, Matti Picus wrote: > This is due to macOS 10.15.3 not shipping its own libffi (is this > true?), so the buildbot owner (CC) had to install it via homebrew. I > don't know anything about macOS: 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 From armin.rigo at gmail.com Sun May 31 03:03:29 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Sun, 31 May 2020 09:03:29 +0200 Subject: [pypy-dev] pypy 3.6 and WinXP In-Reply-To: <5b0cde27-5c49-dbb7-8ca9-5397e209d4de@go.tahomasd.us> References: <42461124-5a7d-01ce-af40-a8e501704902@tranquil.it> <4353f6f5-7df5-f4ef-8ab8-4bdc241b8411@go.tahomasd.us> <40b3a20a-7564-de08-c1d7-3965624309e5@tranquil.it> <5b0cde27-5c49-dbb7-8ca9-5397e209d4de@go.tahomasd.us> Message-ID: Hi, On Fri, 29 May 2020 at 20:10, Joseph Jenne via pypy-dev wrote: > I don't have much experience with the windows side of pypy, especially > on XP, but I would suggest trying to compile for your system, as I do > not know of any reasons for incompatibility. That said, perhaps using a > somewhat older version might be preferable, depending on the specifics > of your use case Joseph, this sounds like very generic advise, of which Denis is likely aware. Denis, my offer to discuss things concretely on pypy-z at python.org still stand. We are not aware of any WinXP-specific issues because we have never tried to build PyPy there. Likely, it doesn't work out of the box. My guess is that we need to remove some WinAPI calls along with the corresponding Python-level functions, and we'd end up with a separate build that misses some functions (likely obscure and specific ones from the 'os' module, for example). Ideally we wouldn't rebuild ourselves every release but let you do it. Whatever the result, we wouldn't do it for free, but if it's only a matter of carefully removing a bit of functionality then it can probably be done at a reasonable price. If you want to give it a go yourself, you're welcome too, and we'd be happy to merge a branch which adds a translation flag to remove dependencies on non-WinXP functionality, for example. A bient?t, Armin. From matt at vazor.com Sun May 31 17:14:31 2020 From: matt at vazor.com (Matt Billenstein) Date: Sun, 31 May 2020 14:14:31 -0700 Subject: [pypy-dev] help needed: libffi and recent macOS In-Reply-To: <028f67b2-73d5-499f-3131-ddac0f7d45b7@gmail.com> References: <028f67b2-73d5-499f-3131-ddac0f7d45b7@gmail.com> Message-ID: <20200531211431.GB240@Zed.localdomain> On Sun, May 31, 2020 at 01:09:11AM +0300, Matti Picus wrote: > It seems the pypy 7.3.1 tarball is broken on macOS since it links to an > installation of libffi in the non-standard location `/usr/local/opt/libffi/lib/ > libffi.6.dylib`, see issue 3229[0]. 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 at vazor.com http://www.vazor.com/ From yury at shurup.com Sun May 31 17:39:31 2020 From: yury at shurup.com (Yury V. Zaytsev) Date: Sun, 31 May 2020 23:39:31 +0200 (CEST) Subject: [pypy-dev] help needed: libffi and recent macOS In-Reply-To: <20200531211431.GB240@Zed.localdomain> References: <028f67b2-73d5-499f-3131-ddac0f7d45b7@gmail.com> <20200531211431.GB240@Zed.localdomain> Message-ID: On Sun, 31 May 2020, Matt Billenstein via pypy-dev wrote: > 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. 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 From matt at vazor.com Sun May 31 18:20:52 2020 From: matt at vazor.com (Matt Billenstein) Date: Sun, 31 May 2020 15:20:52 -0700 Subject: [pypy-dev] help needed: libffi and recent macOS In-Reply-To: References: <028f67b2-73d5-499f-3131-ddac0f7d45b7@gmail.com> <20200531211431.GB240@Zed.localdomain> Message-ID: <20200531222052.GC240@Zed.localdomain> On Sun, May 31, 2020 at 11:39:31PM +0200, Yury V. Zaytsev wrote: > On Sun, 31 May 2020, Matt Billenstein via pypy-dev wrote: > > > 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. > > 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. 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. > > > 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. Yeah, may need to do some hackery, I think the default paths should include, but who knows. m -- Matt Billenstein matt at vazor.com http://www.vazor.com/ From matt at vazor.com Sun May 31 20:33:58 2020 From: matt at vazor.com (Matt Billenstein) Date: Sun, 31 May 2020 17:33:58 -0700 Subject: [pypy-dev] help needed: libffi and recent macOS In-Reply-To: <028f67b2-73d5-499f-3131-ddac0f7d45b7@gmail.com> References: <028f67b2-73d5-499f-3131-ddac0f7d45b7@gmail.com> Message-ID: <20200601003358.GD240@Zed.localdomain> 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: > It seems the pypy 7.3.1 tarball is broken on macOS since it links to an > installation of libffi in the non-standard location `/usr/local/opt/libffi/lib/ > libffi.6.dylib`, see issue 3229[0]. > > This is due to macOS 10.15.3 not shipping its own libffi (is this true?), so > the buildbot owner (CC) had to install it via homebrew. I don't know anything > about macOS: > > > - should we bundle libffi together in the tarball we supply? > > - is there a way to tell clang to statically link libffi.a rather than > dynamically link to libffi.dylib? Is that desirable? > > > Any help would be appreciated, even better would be a pull request > > - to pypy/tool/release/packaging.py to make the equivalent of a "portable PyPy" > for macOS, or to at least bundle libffi.dylib so the runtime loader could find > it > > or > > - to statically link libffi.a when building PyPY. > > Thanks, > > Matti > > > > [0] https://foss.heptapod.net/pypy/pypy/issues/3229. > -- Matt Billenstein matt at vazor.com http://www.vazor.com/