On 3/08/2018 8:23 AM, Andrew Haley wrote:
On 08/02/2018 10:44 PM, Magnus Ihse Bursie wrote:

2 aug. 2018 kl. 14:07 skrev Andrew Haley <a...@redhat.com>:

On 08/02/2018 07:35 AM, David Holmes wrote:
In theory yes - in practice I don't know if anyone has tried it. How
would you do a native build using the ARM64 sources rather than the
aarch64 sources?

It's fine.  I used:

sh  ./configure  --with-native-debug-symbols=internal 
--disable-warnings-as-errors --disable-hotspot-gtest --enable-dtrace=no 
--with-jtreg=/home/aph/jtreg 
--with-boot-jdk=/local/jdk10-pristine/build/linux-aarch64-normal-server-release/images/jdk/
 --enable-precompiled-headers --with-debug-level=release 
--with-jvm-features=-aot,-jvmci

... but the important part is to disable aot and jvmci.

I think what David meant was that it's unclear if it's possible to build the 
ARM64 port natively, i.e. using --with-cpu-port=arm64, instead of the default 
--with-cpu-port=aarch64.

Sorry, I typo'd the configuration line.

In fact, --with-cpu-port=arm64 doesn't work at all because

/local/jdk-jdk11/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp:70:30:
 error: ‘src’ was not declared in this scope
            __ encode_heap_oop(src);

and this fails regardless of cross compilation.  So arm(64) does not matter:
it's obsolete and does not build.

Broken by:

changeset:   49950:7b916885654d
user:        shade
date:        Wed May 02 19:26:42 2018 +0200
summary: 8201786: Modularize interpreter GC barriers: leftovers for ARM32

Bob flagged the port for removal but not sure what the state of that is.

David
-----



Reply via email to