8320942: Only set openjdk-target when cross compiling linux-aarch64

[vidmik]

When building linux-aarch64 at Oracle using jib, --openjdk-target=aarch64-linux-gnu is always specified regardless of if building natively or cross compiling (on linux-x64). Among other things this has the (harmless) effect of tricking configure into thinking that it's cross compiling even for native builds:

checking whether we are cross compiling... yes

The reason is that the target value (aarch64-linux-gnu) doesn't match what config.guess returns (aarch64-unknown-linux-gnu). An explicit target is only needed when cross compiling and should not be specified for native builds.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8320942: Only set openjdk-target when cross compiling linux-aarch64 (Bug - P4)

Reviewers

• Magnus Ihse Bursie (@magicus - Reviewer)
• Erik Joelsson (@erikj79 - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/16873/head:pull/16873
$ git checkout pull/16873

Update a local copy of the PR:
$ git checkout pull/16873
$ git pull https://git.openjdk.org/jdk.git pull/16873/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 16873

View PR using the GUI difftool:
$ git pr show -t 16873

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/16873.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back mikael! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@vidmik The following label will be automatically applied to this pull request:

• build

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (fc86819b)

[magicus]

LGTM

[openjdk]

@vidmik This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8320942: Only set openjdk-target when cross compiling linux-aarch64

Reviewed-by: ihse, erikj

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 14 new commits pushed to the master branch:

• a2c5f1f: 8319417: (dc) DatagramChannel.connect undocumented behavior
• abf2e49: 8320859: gtest high malloc footprint caused by BufferNodeAllocator stress test
• 033cced: 8320368: Per-CPU optimization of Klass range reservation
• 48960df: 8316734: URLEncoder should specify that replacement bytes will be used in case of coding error
• 1594653: 8310644: Make panama memory segment close use async handshakes
• 65dfcae: 8308399: Recommend --release when -source and -target are misused
• 335f5db: 8320911: RISC-V: Enable hotspot/jtreg/compiler/intrinsics/chacha/TestChaCha20.java
• 77d604a: 8319373: Serial: Refactor dirty cards scanning during Young GC
• 38cfb22: 8318706: Implement JEP 423: Region Pinning for G1
• e44d4b2: 8320858: Move jpackage tests to tier3
• ... and 4 more: https://git.openjdk.org/jdk/compare/a657aa38a56056211a9d2773b30e8fe1a89c128e...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[theRealAph]

I'm not objecting to this patch, which is fine as it goes, but I think that the real test for cross compiling isn't a different build and target platform, but a different build and target sysroot. You're often building for EL 9 on an EL 8 machine, and that really does need to be treated as cross compilation.

[magicus]

@theRealAph This is probably a discussion we should continue separately on the mailing list, since it is not really related to this patch.

Are you suggesting that we should basically consider the build a "cross-compile" if we supply a sysroot? What do you expect to happen if the build think we're doing a cross compilation? One of the most basic things is that we need to compile build helpers for the build platform, not the target platform. It this something you'd like to see in your scenario?

Maybe the concept of cross-compilation is too coarse, and we need to separate it into cross-cpu, cross-os, or something like that.

[theRealAph]

@theRealAph This is probably a discussion we should continue separately on the mailing list, since it is not really related to this patch.

Are you suggesting that we should basically consider the build a "cross-compile" if we supply a sysroot? What do you expect to happen if the build think we're doing a cross compilation? One of the most basic things is that we need to compile build helpers for the build platform, not the target platform. It this something you'd like to see in your scenario?

Well, it sort-of is cross compilation. We get away with it, mostly, because we tend to link against in-tree libraries, and the few system libraries we link against are very stable. But the JDK we're building won't run on the host if any of the system libraries the JDK links against have changed ABI version. Or in extremis, sometimes the system ABI might change; that doesn't happen very often, but I've seen it.

Maybe the concept of cross-compilation is too coarse, and we need to separate it into cross-cpu, cross-os, or something like that.

We need some way to be able to tell the build system "This is a cross compiler." --openjdk-target= is not a bad way to do that.

[vidmik]

Thank you for the reviews!

Since the question of what exactly constitutes cross compilation is orthogonal to this change I'll go ahead and integrate it.

/integrate

[openjdk]

Going to push as commit 454b116.
Since your change was applied there have been 22 commits pushed to the master branch:

• eb44baf: 8320937: support latest VS2022 MSC_VER in abstract_vm_version.cpp
• 62418c6: 8319444: Unhelpful failure output in TestLegalNotices
• cdd1a6e: 8313816: Accessing jmethodID might lead to spurious crashes
• b65ccff: 8320877: Shenandoah: Remove ShenandoahUnloadClassesFrequency support
• b68356b: 8320806: Augment test/langtools/tools/javac/versions/Versions.java for JDK 22 language changes
• d783aa3: 8320940: Fix typo in java.lang.Double
• 43c7f6a: 8320907: Shenandoah: Remove ShenandoahSelfFixing flag
• da7bcfc: 8319935: Ensure only one JvmtiThreadState is created for one JavaThread associated with attached native thread
• a2c5f1f: 8319417: (dc) DatagramChannel.connect undocumented behavior
• abf2e49: 8320859: gtest high malloc footprint caused by BufferNodeAllocator stress test
• ... and 12 more: https://git.openjdk.org/jdk/compare/a657aa38a56056211a9d2773b30e8fe1a89c128e...master

Your commit was automatically rebased without conflicts.

[openjdk]

@vidmik Pushed as commit 454b116.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.