py37-pyobjc fails to build

[tonywong94 (Tony Wong)]

py37-pyobjc-7.3_1 fails to build on Mojave with this error:

Modules/objc/libffi_support.m:4444:10: error: 'ffi_prep_closure' is deprecated

Version 7.2.0 does build, but when I try to install astropy it tries to upgrade pyobjc to 7.3.1 and fails again.

[danchr (Dan Villiom Podlaski Christiansen)]

Sigh… So, the issue was that previously, PyObjC would build with the system headers for libffi, and link against MacPort's libffi. Through mostly happenstance, I'd say, that worked until now. That changed with Big Sur, however, which added some symbols — mostly for arm64, but used everywhere — that Apple has yet to fully contribute upstream.

I can think of a few ways to fix this:

1. Go back to previous way of including things on anything but Big Sur, even if it's conceptually broken.
2. Always use the system libffi, and hope that it fixes things. PyObjC is much more likely to actually test and fix bugs with system libraries than whatever we provide.
3. Just fix this particular error, which is caused by a deprecation warning, and remove -Werror from the build.
4. If possible, fix the deprecation warning and contribute it upstream.

Personally, I'd rather not do the first option, even if it seems tempting. My inclination is to use the third or fourth option: Properly fix PyObjC to work with MacPorts' libffi, however possible, but do keep using it. With correct includes and all.

I'm not entirely certain which way is best; perhaps some of you could provide some feedback?

[kencu (Ken)]

in general, I think we find -Werror is more of a dev thing, to be removed for deployed software.

Upstream will fix the deprecation warning in due course, but if you want to fix it and PR the fix, I'm sure they would be receptive.

They certainly were receptive to some darwin PowerPC fixes I sent upstream last year.

[macdeport]

main.log <= py39-pyobjc-7.3_1.darwin_14.x86_64.tbz2

[danchr (Dan Villiom Podlaski Christiansen)]

In 83b6d8a5476aebdd3c0f10a284cf4a0b3636b40a/macports-ports (master):

py-pyobjc: unbreak building on older systems

Now that we're actually using the right headers on these systems, we
run into the fact that PyObjC uses a deprecated symbol. As the build
system passes -Werror when compiling C sources, that triggers an
error.

The breakage affects users, so I've applied the quick fix to simply
suppress the error and live with the warning.

Closer inspection of the sources reveals that PyObjC also uses these
features on Catalina, so I enabled them there too.

Fixes: #63084

[macdeport]

hidden errors after fixe

[macdeport]

Replying to danchr:

In 83b6d8a5476aebdd3c0f10a284cf4a0b3636b40a/macports-ports (master):

py-pyobjc: unbreak building on older systems

Now that we're actually using the right headers on these systems, we
run into the fact that PyObjC uses a deprecated symbol. As the build
system passes -Werror when compiling C sources, that triggers an
error.

The breakage affects users, so I've applied the quick fix to simply
suppress the error and live with the warning.

Closer inspection of the sources reveals that PyObjC also uses these
features on Catalina, so I enabled them there too.

Fixes: #63084

But unfortunately at least here there is apparently hidden errors:

:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-pyobjc/py39-pyobjc/work/compwrap/cc/usr/bin/clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -pipe -Os -arch x86_64 -isysroot/ -I/opt/local/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c Modules/_HIServices.m -o build/temp.macosx-10.10-x86_64-3.9/Modules/_HIServices.o -Wno-deprecated-declarations -DPyObjC_BUILD_RELEASE=1010
:info:build Modules/_HIServices.m:29:10: error: use of undeclared identifier 'kAXValueTypeCGPoint'
:info:build     case kAXValueTypeCGPoint:
:info:build          ^
:info:build Modules/_HIServices.m:36:10: error: use of undeclared identifier 'kAXValueTypeCGSize'
:info:build     case kAXValueTypeCGSize:
:info:build          ^
:info:build Modules/_HIServices.m:43:10: error: use of undeclared identifier 'kAXValueTypeCGRect'
:info:build     case kAXValueTypeCGRect:
:info:build          ^
:info:build Modules/_HIServices.m:50:10: error: use of undeclared identifier 'kAXValueTypeCFRange'
:info:build     case kAXValueTypeCFRange:
:info:build          ^
:info:build Modules/_HIServices.m:57:10: error: use of undeclared identifier 'kAXValueTypeAXError'
:info:build     case kAXValueTypeAXError:
:info:build          ^
:info:build Modules/_HIServices.m:111:10: error: use of undeclared identifier 'kAXValueTypeCGPoint'
:info:build     case kAXValueTypeCGPoint:
:info:build          ^
:info:build Modules/_HIServices.m:115:10: error: use of undeclared identifier 'kAXValueTypeCGSize'
:info:build     case kAXValueTypeCGSize:
:info:build          ^
:info:build Modules/_HIServices.m:119:10: error: use of undeclared identifier 'kAXValueTypeCGRect'
:info:build     case kAXValueTypeCGRect:
:info:build          ^
:info:build Modules/_HIServices.m:123:10: error: use of undeclared identifier 'kAXValueTypeCFRange'
:info:build     case kAXValueTypeCFRange:
:info:build          ^
:info:build Modules/_HIServices.m:127:10: error: use of undeclared identifier 'kAXValueTypeAXError'
:info:build     case kAXValueTypeAXError:
:info:build          ^
:info:build Modules/_HIServices.m:141:14: error: use of undeclared identifier 'kAXValueTypeCGPoint'
:info:build         case kAXValueTypeCGPoint:
:info:build              ^
:info:build Modules/_HIServices.m:144:14: error: use of undeclared identifier 'kAXValueTypeCGSize'
:info:build         case kAXValueTypeCGSize:
:info:build              ^
:info:build Modules/_HIServices.m:147:14: error: use of undeclared identifier 'kAXValueTypeCGRect'
:info:build         case kAXValueTypeCGRect:
:info:build              ^
:info:build Modules/_HIServices.m:150:14: error: use of undeclared identifier 'kAXValueTypeCFRange'
:info:build         case kAXValueTypeCFRange:
:info:build              ^
:info:build Modules/_HIServices.m:153:14: error: use of undeclared identifier 'kAXValueTypeAXError'
:info:build         case kAXValueTypeAXError:
:info:build              ^
:info:build 15 errors generated.
:info:build error: command 

[danchr (Dan Villiom Podlaski Christiansen)]

Replying to macdeport:

But unfortunately at least here there is apparently hidden errors:

Ugh. So, those errors also occurred previously, but passed silently and just stopped building any following wrapper. I'll restrict most of the patches to Big Sur and Catalina, for now.

I tried in vain setting up a 10.10 or 10.11 VM, so I can't fix this myself. I'm tempted to write a py-pyobjc-devel so that we can help upstream get this fixed, but I'd appreciate if you could help, since you obviously have access to one of the releases that fails. I posted a ​pull request containing most of these changes; would you be able to try it out and report back?

[kencu (Ken)]

It looks like most (all?) of those kAXValue* errors are just due to someone updating older deprecated names.

eg.

MacOSX10.13.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Headers/AXValue.h
40:  @constant kAXValueTypeCGSize a wrapper for CGSize; see CoreGraphics.h
48:    kAXValueTypeCGSize       CF_ENUM_AVAILABLE_MAC(10_11) = 2,
57:static const UInt32 kAXValueCGSizeType = kAXValueTypeCGSize;

So kAXValueTypeCGSize is just a rename of kAXValueCGSizeType, and that is present in old SDKs:

$ ag kAXValueCGSizeType

MacOSX10.6.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Headers/AXValue.h
24:    kAXValueCGSizeType = 2,

MacOSX10.7.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Headers/AXValue.h
24:    kAXValueCGSizeType = 2,

MacOSX10.13.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Headers/AXAttributeConstants.h
633:	Value: An AXValueRef with type kAXValueCGSizeType. Units are points.

MacOSX10.13.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Headers/AXValue.h
57:static const UInt32 kAXValueCGSizeType = kAXValueTypeCGSize;

MacOSX10.14.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Headers/AXAttributeConstants.h
633:	Value: An AXValueRef with type kAXValueCGSizeType. Units are points.

MacOSX10.14.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Headers/AXValue.h
57:static const UInt32 kAXValueCGSizeType = kAXValueTypeCGSize;

MacOSX10.15.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Headers/AXAttributeConstants.h
633:	Value: An AXValueRef with type kAXValueCGSizeType. Units are points.

MacOSX10.15.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Headers/AXValue.h
57:static const UInt32 kAXValueCGSizeType = kAXValueTypeCGSize;

(I don't have all the SDKs in this folder -- most likely it is in all of them).

[danchr (Dan Villiom Podlaski Christiansen)]

In fe54f1efd433a461af0141b945e794e589398271/macports-ports (master):

py-pyobjc: make build more lenient on older OSes, but drop 10.6

The core module currently doesn't build on 10.6, so there's no point
in trying to offer the port.

Fixes: #63084

(Hopefully.)

[danchr (Dan Villiom Podlaski Christiansen)]

Replying to kencu:

It looks like most (all?) of those kAXValue* errors are just due to someone updating older deprecated names.

I don't have any older releases at all, so I have to rely on the MacPorts builders catching this — which doesn't feel right. Did you download them from Apple somewhere?

[kencu (Ken)]

I have every Apple system there is running on various hardware back to 68030 MacOS 6.x (1989) on an SE/30, when I first signed up as an Apple Developer.

So I just copied them over from one of the 2,000 (or so) CDs I have sitting here.

It is pretty hard to fix things by running them past the buildbot, but I guess better than nothing.

If I want it fixed, I'll fix it and update the system blacklisting you put in.

[danchr (Dan Villiom Podlaski Christiansen)]

Ah. That's definitely more hardware than I have 🙂 It's worth noting that 10.13 as well as 10.11 and earlier are subtly broken: They don't include all the wrappers they could. But the core modules build, though.

[mascguy (Christopher Nielsen)]

Like Ken, I also have a full suite of macOS VMs. Mine encompass 10.6 through 10.15, so if you ever need someone to help with testing on these older macOS releases, don't hesitate to reach out.

In terms of hypervisor, we're both using Parallels 16. Dunno what you're trying to use, but older macOS releases are trivial to setup with Parallels.

[macdeport]

Replying to danchr:

I tried in vain setting up a 10.10 or 10.11 VM, so I can't fix this myself. I'm tempted to write a py-pyobjc-devel so that we can help upstream get this fixed, but I'd appreciate if you could help, since you obviously have access to one of the releases that fails. I posted a ​pull request containing most of these changes; would you be able to try it out and report back?

Of course it will be a pleasure, but as it is the 1st time, please just tell me how to do it...

[macdeport]

Replying to danchr:

I tried in vain setting up a 10.10 or 10.11 VM, so I can't fix this myself. I'm tempted to write a py-pyobjc-devel so that we can help upstream get this fixed, but I'd appreciate if you could help, since you obviously have access to one of the releases that fails. I posted a ​pull request containing most of these changes; would you be able to try it out and report back?

Today, at least on my side and Python 3.9, fixed by py39-pyobjc @7.3_2.

However, while py38-pyobjc @7.3_2 installs without problem, Python 3.8 is disturbed (starting with warning)...