Add support for building on AArch64 #231
Conversation
|
|
Webrevs
|
|
Mailing list message from Nick Gasson nick.gasson@arm.com Hi, What's the workflow for make changes to the PR? (the Mac build broke.)
This 404s for me - is that a known issue? Thanks, |
|
Mailing list message from Per Liden per.liden@oracle.com On 10/31/19 12:01 PM, Nick Gasson wrote:
Hmm, works fine for me. cheers, |
|
Mailing list message from Robin Westberg robin.westberg@oracle.com Hi Nick,
Usually adding another commit is the preferred choice, this will enable automatic generation of incremental webrevs. But either works fine, when integrating the branch all commits will be squashed.
Sometimes it takes a little while to update I think, but usually it is quite fast. Looks like it is working now at least. Best regards,
|
|
Mailing list message from Nick Gasson nick.gasson@arm.com Hi Robin,
Yeah it works for me now, guess I was just impatient :-) Thanks, |
Hi Nick,
first of all, thanks for contributing! We definitely want to support building the Skara tooling on AArch64, but please see my inline comments, it seems that you may have misinterpreted how the images target is meant to work.
Thanks!
Erik
| url = 'https://download.java.net/java/GA/jdk12/GPL/openjdk-12_osx-x64_bin.tar.gz' | ||
| sha256 = '52164a04db4d3fdfe128cfc7b868bc4dae52d969f03d53ae9d4239fe783e1a3a' | ||
| url = project.jdkUrl | ||
| sha256 = project.jdkSha256 |
There was a problem hiding this comment.
This is unfortunately not how the jdk property of the images target is meant to be used.
The JDK fully supports cross-platform linking, something we make use of in Skara. This means if you build the :cli:images target on a Linux x64 machine then you will actually get fully working Skara distributions for Windows, macOS and Linux (all x64), since we are downloading the JDKs for macOS, Windows and Linux. With this patch we only get Linux x64 distributions.
Fortunately the JDK not only supports cross-jlink across operating system, it also supports cross-linking across CPU architectures. So I would prefer to be able to write:
linux_x64 {
modules = ext.modules
launchers = ext.launchers
man = 'cli/resources/man'
bundles = ['zip', 'tar.gz']
jdk {
url = 'https://download.java.net/java/GA/jdk12/GPL/openjdk-12_linux-x64_bin.tar.gz'
sha256 = 'b43bc15f4934f6d321170419f2c24451486bc848a2179af5e49d10721438dd56'
}
}
linux_aarch64 {
modules = ext.modules
launchers = ext.launchers
man = 'cli/resources/man'
bundles = ['zip', 'tar.gz']
jdk {
url = 'https://github.com/AdoptOpenJDK/openjdk12-binaries/releases/download/jdk-12.0.2%2B10/OpenJDK12U-jdk_aarch64_linux_hotspot_12.0.2_10.tar.gz'
sha256 = ''855f046afc5a5230ad6da45a5c811194267acd1748f16b648bfe5710703fe8c'
}
}
This way we will always produce Linux AArch64 images on Linux x64 hosts. To get this to work you need to do some minor changes to ImagesPlugin.java (and you might have to do some adjustments to LinkTask.java). Do you want to take a stab at that? Or do you want me to try and hack something together?
There was a problem hiding this comment.
Ah ok, I see that now. I'm happy to have a go at redoing it.
| echo "error: unsupported Linux architecture ${ARCH}" | ||
| exit 1 | ||
| ;; | ||
| esac |
I'm working with OpenJDK on Arm machines so I want to be able to run
`git webrev' etc. there. At the moment we can't build the Skara tools on
AArch64 due to an implicit assumption that Linux means X86. I tried to
refactor the build scripts support multiple architectures on Linux. Only
X86 and AArch64 for now but should be trivial to add others.
Using the AdoptOpenJDK AArch64 binary build as there are no prebuilt
binaries for AArch64 on java.net.
Currently there are several Gradle sub-projects that use the image
plugin to build Java images, and each specifies the URL and SHA265 of
the binary JDK to use. Changed the top-level Gradle script to parse
deps.env and select the JDK source based on the OS and architecture
system properties. This gets rid of the duplicated URLs but now each
image { .. } block has a redundant section like the following for each
OS:
So maybe the plugin should be tweaked to move this up into the image {}
block itself?
Progress