openjdk21 @21.0.4+7: error: use of undeclared identifier 'NSBundleExecutableArchitectureARM64' on 10.14 and 10.15

[sambthompson (Sam Thompson)]

See: ​https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/196610/steps/install-port/logs/stdio

: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 openjdk21, but is delivered in the tarball anyway. Upstream still claims to support from 10.12 for openjdk21. EDIT: Was backported.

However, I don't think it should not fail in any case (and clearly other builds of 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. EDIT: Wrong again, doesn't work like #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.

[sambthompson (Sam Thompson)]

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.

[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.

[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).

[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.

[sambthompson (Sam Thompson)]

Thanks, Ryan; makes a lot of sense.

[breun (Nils Breunese)]

Hi Sam, would you be able and willing to create a pull request for the fix?

[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?

EDIT: OK, it looks like according to ​this overview of the bugs.openjdk.org system:

Users without an account can also use bugreport.java.com to submit an issue

Although their guidelines don't seem to anticipate submitting pulls/patches.