Opened 8 hours ago
Last modified 2 hours ago
#71049 assigned defect
openjdk21 @21.0.4+7: error: use of undeclared identifier 'NSBundleExecutableArchitectureARM64' on 10.14 and 10.15
Reported by: | sambthompson (Sam Thompson) | Owned by: | breun (Nils Breunese) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.10.2 |
Keywords: | catalina mojave | Cc: | |
Port: | openjdk21 |
Description (last modified by sambthompson (Sam Thompson))
:info:build src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m:69:29: error: use of undeclared identifier 'NSBundleExecutableArchitectureARM64'; did you mean 'NSBundleExecutableArchitecturePPC64'? :info:build if (architecture == NSBundleExecutableArchitectureARM64) { :info:build ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :info:build NSBundleExecutableArchitecturePPC64 :info:build /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSBundle.h:123:5: note: 'NSBundleExecutableArchitecturePPC64' declared here :info:build NSBundleExecutableArchitecturePPC64 = 0x01000012 :info:build ^ :info:build 1 error generated.
It's unclear whether this is an upstream issue; the failing code in question is not tagged upstream for EDIT: Was backported.
openjdk21
, but is delivered in the tarball anyway. Upstream still claims to support from 10.12
for openjdk21
.
However, I don't think it should not fail in any case (and clearly other builds of EDIT: Wrong again, doesn't work like openjdk21
e.g. from IBM, Azul, etc. are successful/usable on 10.15
and 10.14
), because the fragment in question is guarded with Objective C pragma @available
, viz.#ifdef
.
static BOOL isValidDisplayMode(CGDisplayModeRef mode) { // Workaround for apple bug FB13261205, since it only affects arm based macs // and arm support started with macOS 11 ignore the workaround for previous versions if (@available(macOS 11, *)) { if (architecture == -1) { architecture = [[NSRunningApplication currentApplication] executableArchitecture]; } if (architecture == NSBundleExecutableArchitectureARM64) { return (CGDisplayModeGetPixelWidth(mode) >= 800); } } return (1 < CGDisplayModeGetWidth(mode) && 1 < CGDisplayModeGetHeight(mode)); }
However, it's not clear why this is not being honoured on builds on 10.14 and 10.15. I have to assume there is compiler support for this
@available
syntax (apparently since Xcode 9 / LLVM 5), since that does not generate an error.
Change History (8)
comment:1 Changed 7 hours ago by sambthompson (Sam Thompson)
comment:2 Changed 7 hours ago by sambthompson (Sam Thompson)
Description: | modified (diff) |
---|
comment:3 Changed 5 hours ago by jmroot (Joshua Root)
The fix is easy enough at least: wrap the section requiring macOS 11+ in #if MAC_OS_X_VERSION_MAX_ALLOWED >= 110000
.
comment:4 Changed 5 hours ago by sambthompson (Sam Thompson)
Thanks, Joshua; that worked (with matching #endif
). I was expecting MAC_OS_X_VERSION_MAX_ALLOWED
to be set higher since the port supports it, but clearly this is also constrained by the build compiler/SDK version, which is great. Hopefully this can be upstreamed and the Portfile adjusted again to reflect building works for 10.14 and 10.15 (there is still #69440 for 10.12 and 10.13).
comment:5 Changed 3 hours ago by ryandesign (Ryan Carsten Schmidt)
MAC_OS_X_VERSION_MAX_ALLOWED
always refers to the SDK version used when compiling.
MAC_OS_X_VERSION_MIN_REQUIRED
always refers to the deployment target used when compiling.
comment:7 Changed 3 hours ago by breun (Nils Breunese)
Hi Sam, would you be able and willing to create a pull request for the fix?
comment:8 Changed 3 hours ago by sambthompson (Sam Thompson)
Do you mean upstream? Sadly they're not on github and looks like you need an account with openjdk.org to open tickets there. I could do a local patch, but I think as an upstream issue, the preference is not to patch MacPorts?
This fix was backported to openjdk21 on March 11, so earlier comment about shipping in error was in error.
According to this thread,
@available
still needs the symbols defined in the SDK. Sigh.The orginal upstream report that resulted in this change is: JDK-8266242. The back-porting process apparently didn't pick up the issue with building using older Xcodes on 10.12 - 10.15, without later SDKs defining this enum. I also note that this code appears to be only use of
@availability
in the whole source.