Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#63084 closed defect (fixed)

py37-pyobjc fails to build

Reported by: tonywong94 (Tony Wong) Owned by: danchr (Dan Villiom Podlaski Christiansen)
Priority: Normal Milestone:
Component: ports Version: 2.7.1
Keywords: Cc: macdeport, Schamschula (Marius Schamschula), mascguy (Christopher Nielsen)
Port: py-pyobjc

Description

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.

Attachments (3)

main.log (174.6 KB) - added by tonywong94 (Tony Wong) 3 years ago.
py39-pyobjc-main.log.tbz (9.5 KB) - added by macdeport 3 years ago.
main.log <= py39-pyobjc-7.3_1.darwin_14.x86_64.tbz2
py39-pyobjc-main.log-2.tbz (16.7 KB) - added by macdeport 3 years ago.
hidden errors after fixe

Download all attachments as: .zip

Change History (21)

Changed 3 years ago by tonywong94 (Tony Wong)

Attachment: main.log added

comment:1 Changed 3 years ago by reneeotten (Renee Otten)

Cc: michaelld added
Keywords: mojave python removed
Owner: set to danchr
Priority: HighNormal
Status: newassigned

comment:2 Changed 3 years ago by reneeotten (Renee Otten)

Cc: michaelld removed

comment:3 Changed 3 years ago by 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?

Last edited 3 years ago by danchr (Dan Villiom Podlaski Christiansen) (previous) (diff)

comment:4 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by macdeport

Cc: macdeport added

Changed 3 years ago by macdeport

Attachment: py39-pyobjc-main.log.tbz added

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

comment:6 Changed 3 years ago by Schamschula (Marius Schamschula)

Cc: Schamschula added

comment:7 Changed 3 years ago by danchr (Dan Villiom Podlaski Christiansen)

Resolution: fixed
Status: assignedclosed

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

Changed 3 years ago by macdeport

Attachment: py39-pyobjc-main.log-2.tbz added

hidden errors after fixe

comment:8 in reply to:  7 ; Changed 3 years ago by 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 

comment:9 in reply to:  8 ; Changed 3 years ago by 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?

Version 0, edited 3 years ago by danchr (Dan Villiom Podlaski Christiansen) (next)

comment:10 Changed 3 years ago by 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).

comment:11 Changed 3 years ago by 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.)

comment:12 in reply to:  10 Changed 3 years ago by 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?

EDIT: I checked the build logs, and it seems each version has a unique failure. So yes, this is probably relatively simple to fix, but it might very well shadow some other error…

Last edited 3 years ago by danchr (Dan Villiom Podlaski Christiansen) (previous) (diff)

comment:13 Changed 3 years ago by 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.

comment:14 Changed 3 years ago by 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.

Last edited 3 years ago by danchr (Dan Villiom Podlaski Christiansen) (previous) (diff)

comment:15 Changed 3 years ago by 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.

comment:16 Changed 3 years ago by mascguy (Christopher Nielsen)

Cc: mascguy added

comment:17 in reply to:  9 ; Changed 3 years ago by 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...

Last edited 3 years ago by macdeport (previous) (diff)

comment:18 in reply to:  17 Changed 3 years ago by 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)...

Last edited 3 years ago by macdeport (previous) (diff)
Note: See TracTickets for help on using tickets.