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.

[breun (Nils Breunese)]

I meant a pull request for a (hopefully temporary) patch for the openjdk21 port.

Reporting the bug upstream is also generally a good idea. If you have a link for the upstream issue, please include that in a comment with the patch.

[sambthompson (Sam Thompson)]

OK, will need to get set up for this on Mojave; have just migrated from El Capitan in the last few days...

Issue will also affect other openjdkXX versions the upstream fix for JDK-8266242 was backported to, so anticipate patch for openjdk17 and possibly openjdk11.

[sambthompson (Sam Thompson)]

Temporary patch PR submitted for openjdk17 and openjdk21. openjdk11 not affected as the ​JDK-8266242 backport was only applied to the openjdk11-oracle version upstream.

Have also reported to upstream (including the patch) and am awaiting the issue of a report ID or follow-up questions.

Further review of ​Oracle's build instructions suggests building with less than Xcode 13 is not supported, so a possibility the report will be rejected and the patches won't be temporary (although hopefully considered minor enough to accept):

Notable comments:

It is recommended that you use at least macOS 13 (Ventura) and Xcode 14, but earlier versions may also work.

...

The oldest supported version of Xcode is 13.0.

[Sam Thompson <sambthompson@…>]

In d2696dcd1dc202c54bc0e4ab020b32ac5777ed58/macports-ports (master):

openjdk{17,21}: workaround for regression in JDK-8266242 (​https://github.com/macports/macports-ports/pull/26116)

Adds temporary patch to CGraphicsDevice.m to guard use of undeclared
architecture ARM64 unknown to macOS SDKs before macOS 11.

openjdk versions before 22 support build on 10.12 - 10.15, but when
backporting the fix for 22 to 17 and 21, this support was broken.
This patch should be removed once upstream regression is addressed.

See: #71049

[breun (Nils Breunese)]

Thanks for the PR, Sam, I merged it.

I've now also adjusted the platforms line for opendjk21 to indicate that building should succeed on macOS 10.12.0+, because I noticed that wasn't included in the PR.

[sambthompson (Sam Thompson)]

Thanks for that, Nils; sorry I was going to enquire about whether to update platforms line at this point since I wasn't sure about other blockers for building 10.12.x and/or 10.13.x (e.g. #69213).

[breun (Nils Breunese)]

ticket:69213 is about building with trace mode, which is not a regular build case. But I also don't know if the current state of the port will now build on 10.12 and 10.13.

[sambthompson (Sam Thompson)]

OK, I see. Looking at the port health reports since the latest changes, 10.15 has succeeded, but 10.12 has failed, seemingly with a new problem /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_java_openjdk21/openjdk21/work/jdk-21.0.4+7/build/release/hotspot/variant-server/tools/adlc/adlc: invalid or unsupported format for signature, so probably should be a separate ticket; opened ticket:71072. I think this one can be closed now, though. Thanks for all the support!

[sambthompson (Sam Thompson)]

Oracle have now issued Bug ID for the upstream report: ​JDK-8342071.

[Nils Breunese <breun@…>]

In ddb5ccb09c2133b26186b003cfd8a4da281b7f41/macports-ports (master):

openjdk17: update patches (​https://github.com/macports/macports-ports/pull/26266)

closes #71049