RFR: JDK-8182733 aarch64 build documentation misleading

[Magnus Ihse Bursie]

> 2 aug. 2018 kl. 17:38 skrev David Holmes <david.holmes at oracle.com>:
> 
>> 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 <aph at 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.

Maybe it's not worth confounding the build README about the arm64 port, then? That is, just take my doc fix as it is..?

/Magnus

> 
> David
> -----
> 
> 
>