Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

openjdk: add ARM version #68946

Merged
merged 1 commit into from
Jan 14, 2021
Merged

openjdk: add ARM version #68946

merged 1 commit into from
Jan 14, 2021

Conversation

fxcoudert
Copy link
Member

Trying to rework #65670 into the direction decided by the TSC (see #65670 (comment) and below)

@fxcoudert fxcoudert added the CI-force-arm [DEPRECATED] Don't pass --skip-unbottled-arm to brew test-bot. label Jan 13, 2021
@BrewTestBot BrewTestBot added the no ARM bottle Formula has no ARM bottle label Jan 13, 2021
@fxcoudert fxcoudert force-pushed the openjdk branch 3 times, most recently from a05a528 to 80791f0 Compare January 13, 2021 19:25
@carlocab
Copy link
Member

Looks like you need

# Calculate Xcode's dual-arch JavaNativeFoundation.framework path
def framework_path
File.expand_path("../SharedFrameworks/ContentDeliveryServices.framework/Versions/Current/itms/java/Frameworks",
MacOS::Xcode.prefix)
end

?

url "https://download.java.net/java/GA/jdk14.0.2/205943a0976c4ed48cb16f1043c5c647/12/GPL/openjdk-14.0.2_osx-x64_bin.tar.gz"
sha256 "386a96eeef63bf94b450809d69ceaa1c9e32a97230e0a120c1b41786b743ae84"
if Hardware::CPU.arm?
url "https://download.java.net/java/early_access/jdk16/29/GPL/openjdk-16-ea+29_osx-x64_bin.tar.gz"
Copy link
Contributor

@tresf tresf Jan 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quoting an outstanding task from #65670:

Before merge, [we'll] need a reliable 16-ea URL or can just hard-link any 16 build if @VladimirKempik thinks it'll be OK.

@VladimirKempik replied with the following information:

jep391 branch will soon be merged with upstream and become 17-ea

I'm not sure how soon this would happen, but working from upstream (and not a sandbox) is obviously preferred, but we'll need a boot-jdk that won't be pulled down days or weeks after this PR is merged.

@VladimirKempik I'm sorry if I asked this before, but is it absolutely mandatory that the boot-jdk has JEP-391 code? If not, we can probably find a more reliable link.

If it is mandatory that we have a JEP-391 enabled boot-jdk, I'd need some guidance from Homebrew as to where to retrieve this from. From my experience with other formulae, I understand volatile links are not uncommon, but I don't know if it's OK here? Once the bottles are created, it would only affect the source builds, I'm just not sure if that's acceptable.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How often would the link break?

Copy link

@VladimirKempik VladimirKempik Jan 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

boot-jdk has to be either jdkX or jdkX-1 ( where X is jdk version you build)
build-jdk has to be the same version of jdk you build
both doesn't have to have jep-391 code in it.
so you can just have some fixed version of upstream(jdk/jdk) to be used as boot/build jdk. this will exist forever

Copy link
Contributor

@tresf tresf Jan 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How often would the link break?

It broke while the old PR was open (26-29, now 31), so they change frequently, I'm not sure how long they maintain the old URLs for though.

Although any JDK16 version will do, I'm unsure where to find a stable link. Of the commercial providers, Zulu has an EA link that we could potentially borrow -- just for boot-jdk purposes, but I assume this is frowned upon.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've switched it to the latest (openjdk-16-ea+31) and I've mirror it on our side.

@fxcoudert
Copy link
Member Author

I thought I hadn't changed anything on Intel, but we get:

configure: Potential Build JDK found at /private/tmp/openjdk-20210113-63129-k3mi50/jdk15u-jdk-15.0.1-ga/boot-jdk/Contents/Home is incorrect JDK version (openjdk version "14.0.2" 2020-07-14); ignoring
configure: (Your Build JDK must be version 15)

@tresf
Copy link
Contributor

tresf commented Jan 13, 2021

I thought I hadn't changed anything on Intel, but we get:

configure: Potential Build JDK found at /private/tmp/openjdk-20210113-63129-k3mi50/jdk15u-jdk-15.0.1-ga/boot-jdk/Contents/Home is incorrect JDK version (openjdk version "14.0.2" 2020-07-14); ignoring
configure: (Your Build JDK must be version 15)

Agreed, that doesn't appear to be newly introduced with this PR. I'll fire a vanilla source build on Intel and see if the same error occurs.

@tresf
Copy link
Contributor

tresf commented Jan 13, 2021

Hmm... oddly, it doesn't fail on the vanilla formula.

...
checking for Boot JDK... /private/tmp/openjdk-20210113-59114-1t9ow2k/jdk15u-jdk-15.0.1-ga/boot-jdk/Contents/Home
checking Boot JDK version... openjdk version "14.0.2" 2020-07-14 OpenJDK Runtime Environment (build 14.0.2+12-46) OpenJDK 64-Bit Server VM (build 14.0.2+12-46, mixed mode, sharing) 
checking for java in Boot JDK... ok
...

@VladimirKempik
Copy link

Hmm... oddly, it doesn't fail on the vanilla formula.

...
checking for Boot JDK... /private/tmp/openjdk-20210113-59114-1t9ow2k/jdk15u-jdk-15.0.1-ga/boot-jdk/Contents/Home
checking Boot JDK version... openjdk version "14.0.2" 2020-07-14 OpenJDK Runtime Environment (build 14.0.2+12-46) OpenJDK 64-Bit Server VM (build 14.0.2+12-46, mixed mode, sharing) 
checking for java in Boot JDK... ok
...

you build jdk15 using jdk14 as boot jdk - this is fine

when you try to build jdk16 using jdk14 as boot jdk - it will fail

@carlocab
Copy link
Member

when you try to build jdk16 using jdk14 as boot jdk - it will fail

Where does the formula do this? I don't see it...

@VladimirKempik
Copy link

when you try to build jdk16 using jdk14 as boot jdk - it will fail

Where does the formula do this? I don't see it...

#68946 (comment)

jdk15u-jdk-15.0.1-ga/boot-jdk/Contents/Home is incorrect JDK version (openjdk version "14.0.2" 2020-07-14); ignoring

@fxcoudert
Copy link
Member Author

@VladimirKempik this is not building jdk16, it's building jdk15 (and it definitely used to work)

@carlocab
Copy link
Member

when you try to build jdk16 using jdk14 as boot jdk - it will fail

Where does the formula do this? I don't see it...

#68946 (comment)

jdk15u-jdk-15.0.1-ga/boot-jdk/Contents/Home is incorrect JDK version (openjdk version "14.0.2" 2020-07-14); ignoring

yes, but where in the formula code is this coming from?

@VladimirKempik
Copy link

VladimirKempik commented Jan 13, 2021

excuse me, I missed one word there:

configure: Potential Build JDK found at /private/tmp/openjdk-20210113-63129-k3mi50/jdk15u-jdk-15.0.1-ga/boot-jdk/Contents/Home is incorrect JDK version (openjdk version "14.0.2" 2020-07-14); ignoring

build jdk has to match the version of jdk you building

but one doesnt need build-jdk if not cross-compiling

@tresf
Copy link
Contributor

tresf commented Jan 13, 2021

but one doesnt need build-jdk if not cross-compiling

@VladimirKempik's right, good catch. I added that for all builds, it's a mistake and should be moved to the arm-only block.

This is what master looks like, notice there's no build-jdk provided.

"--with-boot-jdk=#{boot_jdk}",

@fxcoudert
Copy link
Member Author

fxcoudert commented Jan 13, 2021

@tresf I think you mean build, not boot

Updated, and pushed for a new round of testing.

@fxcoudert fxcoudert force-pushed the openjdk branch 2 times, most recently from 632d575 to d7b7565 Compare January 13, 2021 23:23
@fxcoudert fxcoudert added the ready to merge PR can be merged once CI is green label Jan 13, 2021
@carlocab
Copy link
Member

Are we not doing ARM caveats like with go and rust?

Formula/openjdk.rb Outdated Show resolved Hide resolved
@jonchang
Copy link
Contributor

on_macos blocks within resource blocks must contain only a url and sha256 or a url, version, and sha256 (in those orders).

Homebrew/brew#10320

@tresf
Copy link
Contributor

tresf commented Jan 14, 2021

on_macos blocks within resource blocks must contain only a url and sha256 or a url, version, and sha256 (in those orders).

Homebrew/brew#10320

You may find out more about this predicament here: #65670 (comment)

@jonchang
Copy link
Contributor

I've restarted CI now that Homebrew/brew#10320 is merged.

@fxcoudert
Copy link
Member Author

Thanks @jonchang you rock!

.max
raise "cannot find build number in .hg_archival.txt" if build.nil?
if Hardware::CPU.arm?
build = File.read(".hgtags")
Copy link
Contributor

@tresf tresf Jan 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was testing this approach on 15.0.1 (to allow us to clean up the comment above) and it reports incorrectly. It will report 15.0.1+8 instead of 15.0.1+9. @VladimirKempik moving forward, should we add +1 to the last tag in .hgtags or is this handled automatically in newer releases? How should we calculate this value moving forward?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How much of a deal-breaker is that? Testing has been progressing nicely so far, so I planned to merge this tomorrow. Should I wait for a solution to this, or is it a minor issue?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How much of a deal-breaker is that? Testing has been progressing nicely so far, so I planned to merge this tomorrow. Should I wait for a solution to this, or is it a minor issue?

I was thinking the same thing when I saw the "ready to merge" tag. I suppose it can be tackled at some future time when this is consolidated, but I'd still like to know moving forward as the comment suggests the old versioning information will eventually go away.

@fxcoudert
Copy link
Member Author

The ARM testing was stuck on mockserver; many formulas before that worked, and several failed (mostly for cross-dependencies to older openjdk). I am merging, will build a bottle, and then queue bottling of dependents.

@fxcoudert fxcoudert merged commit da9e9e5 into Homebrew:master Jan 14, 2021
@fxcoudert fxcoudert deleted the openjdk branch January 14, 2021 21:41
@fxcoudert
Copy link
Member Author

Oops. https://github.com/Homebrew/homebrew-core/runs/1705106711?check_suite_focus=true

Error: Bottles are for openjdk 15.99.99 but formula is version 15.0.1!

So we actually can't have arch-dependent version.

@fxcoudert
Copy link
Member Author

First few builds of openjdk-dependent formulas on ARM are a mixed bag:

@fxcoudert
Copy link
Member Author

fxcoudert commented Jan 15, 2021

OK, here are better stats

ARM bottling worked:

jmeter, abcl, anjuta, apache-forrest, apollo, cfr-decompiler, duck, fastbit, htmlcleaner, javacc, jdnssec-tools, jhipster, jollie, joshua, jsvc, lcm, leiningen, link-grammar, liquigraph, midgard2, nesc, onscripter, parquet-tools, sleuthkit, swagger-codegen, tomcat-native

ARM bottling failed:

Audit failures, probably fixable on Homebrew side:

@fxcoudert
Copy link
Member Author

@tresf @VladimirKempik regarding openjdk@8 and openjdk@11, I understand there may not be a backport to the official openjdk (I've read the redhat position on that, which you posted on the previous PR). However, for each of those two versions: is there a set of patches, or a fork (or downstream distribution, I don't know how they're called) that we could switch to?

That would be on ARM only, we would keep the official source on Intel. The idea being that for our ARM users, it's better to distribute a patch or branch from a well-known vendor, than nothing from the official branch.

(Excuse my ignorance about the whole openjdk ecosystem…)

@unitof
Copy link
Contributor

unitof commented Jan 15, 2021

Bottle installs!

However I get the error

Error: Failed applying an ad-hoc signature to /opt/homebrew/Cellar/openjdk/15.0.1/libexec/openjdk.jdk/Contents/MacOS/libjli.dylib

during the Pouring step, and postinstall does not complete successfully, though I don't see an obvious error:

~ ▶ brew postinstall openjdk -v
==> Postinstalling openjdk
/usr/bin/sandbox-exec -f /private/tmp/homebrew20210115-96559-wci16w.sb nice ruby -W0 -I $LOAD_PATH -- /opt/homebrew/Library/Homebrew/postinstall.rb /opt/homebrew/Library/Taps/homebrew/homebrew-core/Formula/openjdk.rb
Warning: The post-install step did not complete successfully
You can try again using `brew postinstall openjdk`

@VladimirKempik
Copy link

@tresf @VladimirKempik regarding openjdk@8 and openjdk@11, I understand there may not be a backport to the official openjdk (I've read the redhat position on that, which you posted on the previous PR). However, for each of those two versions: is there a set of patches, or a fork (or downstream distribution, I don't know how they're called) that we could switch to?

That would be on ARM only, we would keep the official source on Intel. The idea being that for our ARM users, it's better to distribute a patch or branch from a well-known vendor, than nothing from the official branch.

(Excuse my ignorance about the whole openjdk ecosystem…)

You will need to wait for the answer here while we will think about it.

@fxcoudert
Copy link
Member Author

@unitof weird, can you please file an issue about it, and provide all the requested information? I'll try to debug that

@tresf
Copy link
Contributor

tresf commented Jan 15, 2021

@tresf @VladimirKempik regarding openjdk@8 and openjdk@11 [...] is there a set of patches [...] that we could switch to?

@VladimirKempik kindly provided ARM64 patches for openjdk@11 here: #65670 (comment) (the patch is > 4K lines, it won't apply cleanly as he's warned).

I haven't seen any publicly available patches for openjdk@8 land yet.

@carlocab carlocab mentioned this pull request Jan 21, 2021
@BrewTestBot BrewTestBot added the outdated PR was locked due to age label Feb 15, 2021
@Homebrew Homebrew locked as resolved and limited conversation to collaborators Feb 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
CI-force-arm [DEPRECATED] Don't pass --skip-unbottled-arm to brew test-bot. no ARM bottle Formula has no ARM bottle outdated PR was locked due to age ready to merge PR can be merged once CI is green
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants