#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)
Change History (21)
Changed 3 years ago by tonywong94 (Tony Wong)
comment:1 Changed 3 years ago by reneeotten (Renee Otten)
Cc: | michaelld added |
---|---|
Keywords: | mojave python removed |
Owner: | set to danchr |
Priority: | High → Normal |
Status: | new → assigned |
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)
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 follow-up: 8 Changed 3 years ago by danchr (Dan Villiom Podlaski Christiansen)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Changed 3 years ago by macdeport
Attachment: | py39-pyobjc-main.log-2.tbz added |
---|
hidden errors after fixe
comment:8 follow-up: 9 Changed 3 years ago by macdeport
Replying to danchr:
In 83b6d8a5476aebdd3c0f10a284cf4a0b3636b40a/macports-ports (master):
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 follow-up: 17 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?
comment:10 follow-up: 12 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)
comment:12 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…
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.
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 follow-up: 18 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...
comment:18 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)...
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:
-Werror
from the build.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?