For upstream

[totaam]

Replaces #80 with the following changes:

• rebased
• also updating: GStreamer 1.22.0, gobject-introspection 1.72.1, libffi 3.4.4 and libpng 1.6.39
• squashed Python 3.10 commits as requested

As for why I chose Python 3.10.10 over 3.11.2 - I'm just being conservative here, I could bump it too if you like.

FWIW: works for me(tm).

[jralls]

Thanks.

BTW, you don't have to make a new PR after a rebase, just force-push to the original PR's branch to replace the commits.

[totaam]

I'm afraid that the libffi commit in there is causing problems with ctypes and pyobjc: Xpra-org#22
I have reverted it here: Xpra-org@8e58672
Which was much easier than trying to figure out the autotools magic needed to get Python to pick up the correct libffi for building and linking.

Sorry about that!
Will send a PR to revert it tomorrow.

[jralls]

@totaam Xpra-org#22 looks a bit confused. The crash report shows libpython3.9 while in the first comment you talk about a problem with libffi-3.4 vs. 3.3 and something being fixed in libpython 3.10.1; the modulesets before your PR had python 3.10.2 and libffi 3.4.3.

It seems possible, likely even, that you have at least one library conflict. Try a completely fresh build in an empty prefix before you decide that the problem is really with the upgrade from libffi 3.4.3 to libffi 3.4.4.

[totaam]

@jralls the github issue was created at a time when python3.9 was the version I was using for building but I have switched to python3.10 a while back now.

I did do a fresh build in an empty prefix, not just once, but twice - once on a MacOS 10.14.x VM and once on a MacOS 12.x VM. In both cases, downgrading libffi resolved the crashes.

The downgrade I did was from 3.4.4 back to 3.3, I don't know yet if earlier versions of 3.4.x are affected - based on the links in Xpra-org#22, I suspect that they are. Hence: #85

No worries if you want to wait for more evidence before applying a downgrade.

[jralls]

@totaam i took the time to read through your xpra bug and the very interesting conda-forge one. You mentioned on your xpra one yesterday

Alternatively, we could try building Python ./configure --with-system-ffi as per https://bugs.python.org/issue44556

Have you tried that? Maybe the right answer is to not build libffi at all and always depend on the SDK one. I looked through my archived Xcodes and found that libffi was first included in Xcode 8. ffi.h in that through Xcode 10 indicate an ancient version:

libffi PyOBJC - Copyright (c) 1996-2003 Red Hat, Inc.

Xcode 11 and 12 say

libffi 3.3-rc0 - Copyright (c) 2011, 2014 Anthony Green
- Copyright (c) 1996-2003, 2007, 2008 Red Hat, Inc.

I don't have an Xcode 13 handy, but Xcode 14's starts with

libffi 3.4-rc1
- Copyright (c) 2011, 2014, 2019, 2021 Anthony Green
- Copyright (c) 1996-2003, 2007, 2008 Red Hat, Inc.

Indicating that builds on Xcode 14 (and maybe 13) might have the opposite problem.

Yeah, more exploration is necessary before deciding on the right fix.

[totaam]

./configure --with-system-ffi as per https://bugs.python.org/issue44556

Have you tried that?

Not yet, I was going to but I am seriously overloaded ATM and not helped by the fact that my MacOS VMs only run on a single core (of an old CPU at that) so trying anything takes a looong time.

FYI, in xpra libffi is used by python3, gobject-introspection, python-cffi and pyobjc - and maybe more I haven't spotted yet.

[jralls]

FYI, in xpra libffi is used by python3, gobject-introspection, python-cffi and pyobjc - and maybe more I haven't spotted yet.

IIUC the problem is the "more you haven't spotted", in particular something in the SDK that's compiled with the version there. I just looked at python-cffi and python3.10's built-in libffi: Both are the pre-2.0 version that used to be the SDKs before Xcode 11; the python3 one was apparently lifted from opensource.apple.com; I didn't see that in the python-cffi one but maybe I didn't notice it.

[totaam]

@jralls I've side-stepped the libffi issue but you may be interested in this comment: Xpra-org#27 (comment)

[jralls]

@totaam I did. You should post that in an issue to libffi; I haven't done a comprehensive search to see if there's already an open one, but there are a lot, many appear to be quite serious.

but I found the next comment even more interesting: " I raised the minimum requirements to MacOS 12: ". Since that has libffi 3.4 what does that imply for your preferred version of libffi here?

[jralls]

One more thing: For any rollback we have to take Apple Silicon support into account. I imagine that's why the version in Xcode got bumped to 3.4.0-rc1.