Re: RFR: 8270517: Add Zero support for LoongArch [v2]

[Ao Qi]

On Thu, 15 Jul 2021 07:42:33 GMT, Ao Qi  wrote:

>> LoongArch is a new RISC ISA. This issue proposes adding Zero support for 
>> LoongArch. Only 64-bit support is proposed at present.
>> 
>> linux-loongarch64-zero-{release, fastdebug} build tested:
>> 
>> $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version
>> openjdk version "18-internal" 2022-03-15
>> OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk)
>> OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, 
>> interpreted mode)
>
> Ao Qi has updated the pull request incrementally with one additional commit 
> since the last revision:
> 
>   removed redundant whitespaces

I apologized that I type "/integrate" too early. I will pay close attention to 
this issue in the next few days in case any problems arise.

-

PR: https://git.openjdk.java.net/jdk/pull/4787

Integrated: 8270517: Add Zero support for LoongArch

[Ao Qi]

On Thu, 15 Jul 2021 04:04:08 GMT, Ao Qi  wrote:

> LoongArch is a new RISC ISA. This issue proposes adding Zero support for 
> LoongArch. Only 64-bit support is proposed at present.
> 
> linux-loongarch64-zero-{release, fastdebug} build tested:
> 
> $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version
> openjdk version "18-internal" 2022-03-15
> OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk)
> OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, 
> interpreted mode)

This pull request has now been integrated.

Changeset: e92e2fd4
Author:Ao Qi 
Committer: Aleksey Shipilev 
URL:   
https://git.openjdk.java.net/jdk/commit/e92e2fd4e0bc805d8f7d70f632cce0282eb1809b
Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod

8270517: Add Zero support for LoongArch

Reviewed-by: dholmes, erikj, shade

-

PR: https://git.openjdk.java.net/jdk/pull/4787

Re: RFR: 8270517: Add Zero support for LoongArch [v2]

[Ao Qi]

On Thu, 15 Jul 2021 07:54:41 GMT, David Holmes  wrote:

>> Ao Qi has updated the pull request incrementally with one additional commit 
>> since the last revision:
>> 
>>   removed redundant whitespaces
>
> Marked as reviewed by dholmes (Reviewer).

@dholmes-ora @erikj79 and @shipilev , thanks for the fast review! I also did a 
release bootcycle-images test and a jcstress test. They are passed. Could you 
help to sponsor it?

-

PR: https://git.openjdk.java.net/jdk/pull/4787

Re: RFR: 8270517: Add Zero support for LoongArch [v2]

[Ao Qi]

> LoongArch is a new RISC ISA. This issue proposes adding Zero support for 
> LoongArch. Only 64-bit support is proposed at present.
> 
> linux-loongarch64-zero-{release, fastdebug} build tested:
> 
> $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version
> openjdk version "18-internal" 2022-03-15
> OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk)
> OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, 
> interpreted mode)

Ao Qi has updated the pull request incrementally with one additional commit 
since the last revision:

  removed redundant whitespaces

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4787/files
  - new: https://git.openjdk.java.net/jdk/pull/4787/files/bd626159..5dbfe543

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4787=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4787=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4787/head:pull/4787

PR: https://git.openjdk.java.net/jdk/pull/4787

Re: RFR: 8270517: Add Zero support for LoongArch

[Ao Qi]

On Thu, 15 Jul 2021 06:30:24 GMT, Aleksey Shipilev  wrote:

>> LoongArch is a new RISC ISA. This issue proposes adding Zero support for 
>> LoongArch. Only 64-bit support is proposed at present.
>> 
>> linux-loongarch64-zero-{release, fastdebug} build tested:
>> 
>> $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version
>> openjdk version "18-internal" 2022-03-15
>> OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk)
>> OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, 
>> interpreted mode)
>
> src/hotspot/os/linux/os_linux.cpp line 1701:
> 
>> 1699: {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, 
>> (char*)"AARCH64"},
>> 1700: {EM_RISCV,   EM_RISCV,   ELFCLASS64, ELFDATA2LSB, 
>> (char*)"RISC-V"},
>> 1701: {EM_LOONGARCH,   EM_LOONGARCH,   ELFCLASS64, ELFDATA2LSB, 
>> (char*)"LoongArch"},
> 
> Suggestion:
> 
> {EM_LOONGARCH,   EM_LOONGARCH, ELFCLASS64, ELFDATA2LSB, 
> (char*)"LoongArch"},

I added some additional whitespaces according to EM_MIPS_RS3_LE line, which is 
also too long. Your suggestion is fine to me. I will fix it.

-

PR: https://git.openjdk.java.net/jdk/pull/4787

RFR: 8270517: Add Zero support for LoongArch

[Ao Qi]

LoongArch is a new RISC ISA. This issue proposes adding Zero support for 
LoongArch. Only 64-bit support is proposed at present.

linux-loongarch64-zero-{release, fastdebug} build tested:

$ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version
openjdk version "18-internal" 2022-03-15
OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk)
OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, 
interpreted mode)

-

Commit messages:
 - 8270517: Add Zero support for LoongArch

Changes: https://git.openjdk.java.net/jdk/pull/4787/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4787=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270517
  Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4787/head:pull/4787

PR: https://git.openjdk.java.net/jdk/pull/4787

Re: RFR: 8256831: MIPS Zero builds fail with undefined __atomic_compare_exchange_8 [v3]

[Ao Qi]

On Wed, 25 Nov 2020 08:43:31 GMT, Aleksey Shipilev  wrote:

>> Marked as reviewed by ihse (Reviewer).
>
> Thanks, I'll wait for either of @glaubitz, @theaoqi or @xiangzhai to confirm 
> this fixes the native `mipsel` builds for them, and then integrate.

The native build of linux-mipsel-zero-release passed. I only have mips64el and 
64-bit OS, so I tested the patch by using a mipsel docker image.

Some messages during the build:

LOAD: .MIPS.abiflags .reginfo .note.gnu.build-id .dynamic .hash .dynsym .dynstr 
.gnu.version .gnu.version_r .rel.dyn .init .text .MIPS.stubs .fini .eh_frame
However, I think the native build issue has been solved.

-

PR: https://git.openjdk.java.net/jdk/pull/1375

Re: RFR: 8256829: GNU hash style is not available on MIPS

[Ao Qi]

On Mon, 23 Nov 2020 11:23:55 GMT, Magnus Ihse Bursie  wrote:

>> For fun, I tried to build `linux-mips64el-zero-fastdebug`, and it cannot be 
>> built, because linker complains:
>> 
>> 
>> collect2: error: ld returned 1 exit status
>> 
>> I believe it is a regression in 16, as GNU hash style was forced with 
>> [JDK-8200738](https://bugs.openjdk.java.net/browse/JDK-8200738). The way out 
>> is to special-case MIPS hash-style to `sysv`. This enumerates all MIPS 
>> targets that `make/autoconf/platform.m4` knows about.
>> 
>> Attention @DamonFool, who must be running into this problem for their MIPS 
>> builds?
>> 
>> Testing:
>>  - [x] Linux mipsel zero fastdebug build (requires additional unrelated 
>> fixes)
>>  - [x] Linux mips64el zero fastdebug build
>
> Given that it works on MIPS, it looks good to me. Too bad gnu hash style is 
> not universally accepted. :(

Sorry for the late reply. Monday is a busy day and I used a zero jdk as boot 
jdk, so the test took some time. The native build of 
linux-mips64el-zero-release has passed with this patch.

I noticed that there is some [work of MIPS support for GNU 
hash](https://sourceware.org/pipermail/binutils/2019-July/107496.html), but I 
don't know the latest progress. I tried [debian:latest 
images](https://hub.docker.com/_/debian), GNU hash is not supported yet. I 
think we should keep this patch until MIPS support for GUN hash is integrated 
into downstream toolchains one day.

@glaubitz , FYI, yes, the sigset problem was 
[solved](https://hg.openjdk.java.net/jdk/jdk/rev/3086f9259e97) :)

-

PR: https://git.openjdk.java.net/jdk/pull/1374

Re: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from target in BuildJDK when cross compiling

[Ao Qi]

On Thu, Jun 6, 2019 at 10:31 PM Erik Joelsson  wrote:
>
> Hello,
>
> On 2019-06-05 20:28, Ao Qi wrote:
> > On Thu, Jun 6, 2019 at 10:49 AM Ao Qi  wrote:
> >> On Thu, Jun 6, 2019 at 4:46 AM Erik Joelsson  
> >> wrote:
> >>> Here is a new webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.03
> > Another question: should "[bootcycle] " be displayed during make
> > bootcycle-images? If yes, should we remove line 164 "LOG_PREFIX :=" of
> > http://cr.openjdk.java.net/~erikj/8217739/webrev.03/make/common/MakeBase.gmk.html
> > ?
>
> It seems you are right. I assumed that by setting LOG_PREFIX on the make
> command line, it would override. I think it's cleaner to initiate the
> variable to empty so that any accidental setting in the environment
> doesn't interfere. This works for the buildjdk call, which calls
> Main.gmk, but doesn't seem to work for bootcycle, which calls Init.gmk.
>
> For now I will just refrain from initializing it in MakeBase.gmk.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.04

Looks good. Thanks for fixing this!

Cheers,
Ao Qi
>
> >> I (as an Author) am ok with this fix. mips64el zero cross build passed
> >> and javac (to test open a file) worked.
>
> Thanks!
>
> /Erik
>
> >>
> >> UnixConstants.java of build:
> >> .../usr/bin/cc -E -x c -I...
> >>
> >> UnixConstants.java of target:
> >> .../usr/bin/mips64el-linux-gnuabi64-gcc -E -x c
> >> --sysroot=/home/aoqi//chroots/mips64el_stretch/ -I...
> >>
> >> Thanks,
> >> Ao Qi
> >>> The change is in buildjdk-spec.gmk.in where CPP is now also overridden.
> >>>
> >>> /Erik
> >>>
> >>> On 2019-06-05 10:33, Erik Joelsson wrote:
> >>>> Never mind, I found the issue. The reason it worked for me was that we
> >>>> set SYSROOT_CFLAGS for both the target and the build compiler (from
> >>>> using devkits for them). The preprocessor for the target would then
> >>>> act correctly given the --sysroot parameter pointing to a sysroot for
> >>>> the build system.
> >>>>
> >>>> I'm working on a patch where PPC gets overridden with the build
> >>>> compiler in buildjdk-spec.gmk.
> >>>>
> >>>> /Erik
> >>>>
> >>>> On 2019-06-05 08:37, Erik Joelsson wrote:
> >>>>> Hello Ao Qi,
> >>>>>
> >>>>> In my testing, I tried building ppc64le (which I first identified as
> >>>>> generating a UnixConstants.java that differed from an x64 build).
> >>>>> With this patch, the buildjdk and target version of
> >>>>> UnixConstants.java differ the same way. How did you configure your
> >>>>> build? I'm suspecting something in the setup of the buildjdk
> >>>>> compilers is different from my configuration.
> >>>>>
> >>>>> /Erik
> >>>>>
> >>>>> On 2019-06-04 21:48, Ao Qi wrote:
> >>>>>> Hi Erik,
> >>>>>>
> >>>>>> Thank you a lot for taking care of this. I mainly like your approach.
> >>>>>> I tested the patch by cross building mips64-zero, by which we found
> >>>>>> this problem. However, it seems the problem still exists. The reason I
> >>>>>> found is that UnixConstants.java of buildjdk is generated by cross
> >>>>>> compiler, so the macro definitions are defined by the target. Here is
> >>>>>> a preliminary workaround for your reference only (only worked for
> >>>>>> gcc):
> >>>>>>
> >>>>>> $ hg diff make/gensrc/GensrcMisc.gmk
> >>>>>> diff -r f4df9d4201cc make/gensrc/GensrcMisc.gmk
> >>>>>> --- a/make/gensrc/GensrcMisc.gmk Tue Jun 04 16:50:25 2019 -0700
> >>>>>> +++ b/make/gensrc/GensrcMisc.gmk Wed Jun 05 12:39:43 2019 +0800
> >>>>>> @@ -61,6 +61,13 @@
> >>>>>>  CPP_FLAGS += -nologo
> >>>>>>endif
> >>>>>>
> >>>>>> +ifeq ($(CREATING_BUILDJDK), true)
> >>>>>> +  # Only worked for gcc
> >>>>>> +  TEMP_CPP=gcc -E
> >>>>>> +else
> >>>>>> +  TEMP_CPP=$(CPP)
> >>>>>> +endif
> >>>>>> +
> >>>>>># Generate a java source file from a templ

Re: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from target in BuildJDK when cross compiling

[Ao Qi]

On Thu, Jun 6, 2019 at 10:49 AM Ao Qi  wrote:
>
> On Thu, Jun 6, 2019 at 4:46 AM Erik Joelsson  wrote:
> >
> > Here is a new webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.03

Another question: should "[bootcycle] " be displayed during make
bootcycle-images? If yes, should we remove line 164 "LOG_PREFIX :=" of
http://cr.openjdk.java.net/~erikj/8217739/webrev.03/make/common/MakeBase.gmk.html
?

>
> I (as an Author) am ok with this fix. mips64el zero cross build passed
> and javac (to test open a file) worked.
>
> UnixConstants.java of build:
> .../usr/bin/cc -E -x c -I...
>
> UnixConstants.java of target:
> .../usr/bin/mips64el-linux-gnuabi64-gcc -E -x c
> --sysroot=/home/aoqi//chroots/mips64el_stretch/ -I...
>
> Thanks,
> Ao Qi
> >
> > The change is in buildjdk-spec.gmk.in where CPP is now also overridden.
> >
> > /Erik
> >
> > On 2019-06-05 10:33, Erik Joelsson wrote:
> > > Never mind, I found the issue. The reason it worked for me was that we
> > > set SYSROOT_CFLAGS for both the target and the build compiler (from
> > > using devkits for them). The preprocessor for the target would then
> > > act correctly given the --sysroot parameter pointing to a sysroot for
> > > the build system.
> > >
> > > I'm working on a patch where PPC gets overridden with the build
> > > compiler in buildjdk-spec.gmk.
> > >
> > > /Erik
> > >
> > > On 2019-06-05 08:37, Erik Joelsson wrote:
> > >> Hello Ao Qi,
> > >>
> > >> In my testing, I tried building ppc64le (which I first identified as
> > >> generating a UnixConstants.java that differed from an x64 build).
> > >> With this patch, the buildjdk and target version of
> > >> UnixConstants.java differ the same way. How did you configure your
> > >> build? I'm suspecting something in the setup of the buildjdk
> > >> compilers is different from my configuration.
> > >>
> > >> /Erik
> > >>
> > >> On 2019-06-04 21:48, Ao Qi wrote:
> > >>> Hi Erik,
> > >>>
> > >>> Thank you a lot for taking care of this. I mainly like your approach.
> > >>> I tested the patch by cross building mips64-zero, by which we found
> > >>> this problem. However, it seems the problem still exists. The reason I
> > >>> found is that UnixConstants.java of buildjdk is generated by cross
> > >>> compiler, so the macro definitions are defined by the target. Here is
> > >>> a preliminary workaround for your reference only (only worked for
> > >>> gcc):
> > >>>
> > >>> $ hg diff make/gensrc/GensrcMisc.gmk
> > >>> diff -r f4df9d4201cc make/gensrc/GensrcMisc.gmk
> > >>> --- a/make/gensrc/GensrcMisc.gmk Tue Jun 04 16:50:25 2019 -0700
> > >>> +++ b/make/gensrc/GensrcMisc.gmk Wed Jun 05 12:39:43 2019 +0800
> > >>> @@ -61,6 +61,13 @@
> > >>> CPP_FLAGS += -nologo
> > >>>   endif
> > >>>
> > >>> +ifeq ($(CREATING_BUILDJDK), true)
> > >>> +  # Only worked for gcc
> > >>> +  TEMP_CPP=gcc -E
> > >>> +else
> > >>> +  TEMP_CPP=$(CPP)
> > >>> +endif
> > >>> +
> > >>>   # Generate a java source file from a template through the C
> > >>> preprocessor for the
> > >>>   # target system. First extract the copyright notice at the start
> > >>> of the file.
> > >>>   # Run the preprocessor. Filter out the default compiler stderr
> > >>> output on
> > >>> @@ -71,7 +78,7 @@
> > >>>   define generate-preproc-src
> > >>>$(call MakeDir, $(@D))
> > >>>( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
> > >>> -   $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
> > >>> +   $(TEMP_CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
> > >>>  2> >($(GREP) -v '^$(&2) \
> > >>>  | $(NAWK) '/@@START_HERE@@/,0' \
> > >>>  |  $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
> > >>> FILE - DO NOT EDIT/' \
> > >>>
> > >>>
> > >>> Cheers,
> > >>> Ao Qi
> > >>>
> > >>> On Wed, Jun 5, 2019 at 12:00 AM Erik Joelsson
> > >>>  wrote:
> > >>>> Thanks!
> > >>>>
&g

Re: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from target in BuildJDK when cross compiling

[Ao Qi]

On Thu, Jun 6, 2019 at 4:46 AM Erik Joelsson  wrote:
>
> Here is a new webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.03

I (as an Author) am ok with this fix. mips64el zero cross build passed
and javac (to test open a file) worked.

UnixConstants.java of build:
.../usr/bin/cc -E -x c -I...

UnixConstants.java of target:
.../usr/bin/mips64el-linux-gnuabi64-gcc -E -x c
--sysroot=/home/aoqi//chroots/mips64el_stretch/ -I...

Thanks,
Ao Qi
>
> The change is in buildjdk-spec.gmk.in where CPP is now also overridden.
>
> /Erik
>
> On 2019-06-05 10:33, Erik Joelsson wrote:
> > Never mind, I found the issue. The reason it worked for me was that we
> > set SYSROOT_CFLAGS for both the target and the build compiler (from
> > using devkits for them). The preprocessor for the target would then
> > act correctly given the --sysroot parameter pointing to a sysroot for
> > the build system.
> >
> > I'm working on a patch where PPC gets overridden with the build
> > compiler in buildjdk-spec.gmk.
> >
> > /Erik
> >
> > On 2019-06-05 08:37, Erik Joelsson wrote:
> >> Hello Ao Qi,
> >>
> >> In my testing, I tried building ppc64le (which I first identified as
> >> generating a UnixConstants.java that differed from an x64 build).
> >> With this patch, the buildjdk and target version of
> >> UnixConstants.java differ the same way. How did you configure your
> >> build? I'm suspecting something in the setup of the buildjdk
> >> compilers is different from my configuration.
> >>
> >> /Erik
> >>
> >> On 2019-06-04 21:48, Ao Qi wrote:
> >>> Hi Erik,
> >>>
> >>> Thank you a lot for taking care of this. I mainly like your approach.
> >>> I tested the patch by cross building mips64-zero, by which we found
> >>> this problem. However, it seems the problem still exists. The reason I
> >>> found is that UnixConstants.java of buildjdk is generated by cross
> >>> compiler, so the macro definitions are defined by the target. Here is
> >>> a preliminary workaround for your reference only (only worked for
> >>> gcc):
> >>>
> >>> $ hg diff make/gensrc/GensrcMisc.gmk
> >>> diff -r f4df9d4201cc make/gensrc/GensrcMisc.gmk
> >>> --- a/make/gensrc/GensrcMisc.gmk Tue Jun 04 16:50:25 2019 -0700
> >>> +++ b/make/gensrc/GensrcMisc.gmk Wed Jun 05 12:39:43 2019 +0800
> >>> @@ -61,6 +61,13 @@
> >>> CPP_FLAGS += -nologo
> >>>   endif
> >>>
> >>> +ifeq ($(CREATING_BUILDJDK), true)
> >>> +  # Only worked for gcc
> >>> +  TEMP_CPP=gcc -E
> >>> +else
> >>> +  TEMP_CPP=$(CPP)
> >>> +endif
> >>> +
> >>>   # Generate a java source file from a template through the C
> >>> preprocessor for the
> >>>   # target system. First extract the copyright notice at the start
> >>> of the file.
> >>>   # Run the preprocessor. Filter out the default compiler stderr
> >>> output on
> >>> @@ -71,7 +78,7 @@
> >>>   define generate-preproc-src
> >>>$(call MakeDir, $(@D))
> >>>( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
> >>> -   $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
> >>> +   $(TEMP_CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
> >>>  2> >($(GREP) -v '^$(&2) \
> >>>  | $(NAWK) '/@@START_HERE@@/,0' \
> >>>  |  $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
> >>> FILE - DO NOT EDIT/' \
> >>>
> >>>
> >>> Cheers,
> >>> Ao Qi
> >>>
> >>> On Wed, Jun 5, 2019 at 12:00 AM Erik Joelsson
> >>>  wrote:
> >>>> Thanks!
> >>>>
> >>>> During testing, I found an intermittent race issue. The command line
> >>>> that runs the interim langtools version of javac still always
> >>>> points to
> >>>> the buildtools/interim-langtools dir of the normal build. This
> >>>> variable
> >>>> also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
> >>>> changed in buildjdk-spec.gmk.in:
> >>>>
> >>>> http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
> >>>>
> >>>> /Erik
> >>>>
> >>>> On 2019-06-04 07:53, Tim Bell wrote:
> >>>>> Erik:
> >>>>>
> >

Re: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from target in BuildJDK when cross compiling

[Ao Qi]

Hi Erik,

Thank you a lot for taking care of this. I mainly like your approach.
I tested the patch by cross building mips64-zero, by which we found
this problem. However, it seems the problem still exists. The reason I
found is that UnixConstants.java of buildjdk is generated by cross
compiler, so the macro definitions are defined by the target. Here is
a preliminary workaround for your reference only (only worked for
gcc):

$ hg diff make/gensrc/GensrcMisc.gmk
diff -r f4df9d4201cc make/gensrc/GensrcMisc.gmk
--- a/make/gensrc/GensrcMisc.gmk Tue Jun 04 16:50:25 2019 -0700
+++ b/make/gensrc/GensrcMisc.gmk Wed Jun 05 12:39:43 2019 +0800
@@ -61,6 +61,13 @@
   CPP_FLAGS += -nologo
 endif

+ifeq ($(CREATING_BUILDJDK), true)
+  # Only worked for gcc
+  TEMP_CPP=gcc -E
+else
+  TEMP_CPP=$(CPP)
+endif
+
 # Generate a java source file from a template through the C
preprocessor for the
 # target system. First extract the copyright notice at the start of the file.
 # Run the preprocessor. Filter out the default compiler stderr output on
@@ -71,7 +78,7 @@
 define generate-preproc-src
  $(call MakeDir, $(@D))
  ( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
-   $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
+   $(TEMP_CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
2> >($(GREP) -v '^$(&2) \
| $(NAWK) '/@@START_HERE@@/,0' \
|  $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
FILE - DO NOT EDIT/' \


Cheers,
Ao Qi

On Wed, Jun 5, 2019 at 12:00 AM Erik Joelsson  wrote:
>
> Thanks!
>
> During testing, I found an intermittent race issue. The command line
> that runs the interim langtools version of javac still always points to
> the buildtools/interim-langtools dir of the normal build. This variable
> also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
> changed in buildjdk-spec.gmk.in:
>
> http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
>
> /Erik
>
> On 2019-06-04 07:53, Tim Bell wrote:
> > Erik:
> >
> > Looks good.
> >
> > Tim
> >
> >> This is a fix for a problem brought up on this list [1]. The main issue
> >> is that when cross compiling, and creating a buildjdk during the build,
> >> the UnixConstants.java cannot necessarily be reused between the target
> >> JDK and the buildjdk. While investigating this, I came to the conclusion
> >> that we really should stop trying to reuse anything between the buildjdk
> >> and target JDK. It's just becoming too complex to maintain (due to the
> >> intricate interactions with the interim-image, generate-link-opt-data
> >> and exploded-image-optimize targets, causing circular dependencies and
> >> endless incremental rebuilds).
> >>
> >> So this fix simply removes all the reuse of buildtools, gensrc and java
> >> compilation when creating a buildjdk. Hopefully this is making Main.gmk
> >> a bit less convoluted.
> >>
> >> While working on this, I came up with the idea of adding a log prefix
> >> functionality, to more easily discern which log lines were printed by
> >> the buildjdk build and which were part of the normal build. I liked this
> >> a lot so including that in the same fix, and applied it to the bootcycle
> >> build as well.
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217739
> >>
> >> Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html
> >>
> >> /Erik
> >>
> >> [1]
> >> http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html
> >>
> >
> >
> >

Re: [DMARC FAILURE] RFR (XS): 8222510: Small cleanup for JDK launcher's make file

[Ao Qi]

Hi,

For Hotspot:
A “trivial” HotSpot change only needs one Reviewer, and doesn’t need
to wait 24 hours for other potential reviewers to chime in.
https://wiki.openjdk.java.net/display/HotSpot/HotSpot+How+To [1].
Otherwise, if I remember correctly, a hotspot change needs two
reviewers, and one should be Reviewer. It is written at
https://wiki.openjdk.java.net/display/HotSpot/HotSpot+How+To, but
https://wiki.openjdk.java.net seems under maintenance for a while.

Cheers,
Ao Qi
[1] 
https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-April/025321.html

On Tue, Apr 16, 2019 at 2:34 PM David Holmes  wrote:
>
> On 16/04/2019 4:09 pm, Langer, Christoph wrote:
> > Hi Man,
> >
> > the change looks good to me, thanks for doing this cleanup.
> >
> > As for reviewers: I thought it depends whether the author of a change is a 
> > Reviewer himself. Then only one Reviewer needs to review the change. But I 
> > might be wrong here. So, let's wait for a review from the build group and 
> > maybe these folks can answer this question, too.
>
> The rules for "number of reviews" does not depend on the status of the
> changeset author but the informal rules governing the area in which the
> change is made. The build folk typically only need one Review - but of
> course they'd like that to be from a competent build reviewer. Hotspot
> (runtime only?) like to have two reviews (but only one needs to be a
> Reviewer).
>
> Cheers,
> David
>
> > Best regards
> > Christoph
> >
> >> -Original Message-
> >> From: build-dev  On Behalf Of Man
> >> Cao
> >> Sent: Dienstag, 16. April 2019 04:04
> >> To: build-dev@openjdk.java.net
> >> Subject: [DMARC FAILURE] RFR (XS): 8222510: Small cleanup for JDK
> >> launcher's make file
> >>
> >> Hi,
> >>
> >> Can I have reviews for this small cleanup? It basically removes some dead
> >> and redundant variables and updates comment.
> >> Webrev: https://cr.openjdk.java.net/~manc/8222510/webrev.00/
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222510
> >>
> >> I found these issues while working on the tsan project (
> >> http://hg.openjdk.java.net/tsan/dev/). Some relevant changes previously
> >> touched the code include JDK-8210931, JDK-8199639, JDK-8141444.
> >>
> >> And do I need only one review for this change? It seems many build files
> >> changes only have one reviewer.
> >>
> >> -Man

Re: RFR: JDK-8219906: Update test documentation with default test jobs settings

[Ao Qi]

Yes. Thank you Magnus.

On Mon, Mar 4, 2019 at 8:06 PM Magnus Ihse Bursie
 wrote:
>
> This looks good to me. Shall I push it for you?
>
> /Magnus
>
> > 3 mars 2019 kl. 11:26 skrev Ao Qi :
> >
> > On Fri, Mar 1, 2019 at 9:39 PM Magnus Ihse Bursie
> >  wrote:
> >>
> >> On 2019-02-28 09:13, Ao Qi wrote:
> >>
> >> Hi,
> >>
> >> Test jobs setting for sparc is different with x86 (JDK-8211727).
> >> Besides, test jobs setting is based on memory size (JDK-8214003). The
> >> test documentation fails to mention these and needs update.
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219906
> >>
> >> Webrev: http://cr.openjdk.java.net/~aoqi/8219906/webrev.00/
> >>
> >> Hi Ao,
> >>
> >> The html file is generated from the markdown file. Please update 
> >> testing.md instead, and then get yourself an automatically updated 
> >> testing.html using "make update-build-docs". You will need pandoc for that 
> >> to work, version 2.3.1 or newer is recommended (but not mandated).
> >
> > Hi Magnus,
> >
> > Thanks for your review and information. I did not know "make
> > update-build-docs" before. I updated testing.md and updated
> > testing.html using "make update-build-docs".
> >
> > Webrev: http://cr.openjdk.java.net/~aoqi/8219906/webrev.01/
> >
> > My environment is Ubuntu 16.04, and I manually install pandoc 2.3.1
> > from https://github.com/jgm/pandoc/releases/tag/2.3.1
> >
> > Cheers,
> > Ao Qi
> >
> >> /Magnus
> >>
> >>
> >> Cheers,
> >> Ao Qi
> >>
> >>
>

Re: RFR: JDK-8219906: Update test documentation with default test jobs settings

[Ao Qi]

On Fri, Mar 1, 2019 at 9:39 PM Magnus Ihse Bursie
 wrote:
>
> On 2019-02-28 09:13, Ao Qi wrote:
>
> Hi,
>
> Test jobs setting for sparc is different with x86 (JDK-8211727).
> Besides, test jobs setting is based on memory size (JDK-8214003). The
> test documentation fails to mention these and needs update.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8219906
>
> Webrev: http://cr.openjdk.java.net/~aoqi/8219906/webrev.00/
>
> Hi Ao,
>
> The html file is generated from the markdown file. Please update testing.md 
> instead, and then get yourself an automatically updated testing.html using 
> "make update-build-docs". You will need pandoc for that to work, version 
> 2.3.1 or newer is recommended (but not mandated).
>

Hi Magnus,

Thanks for your review and information. I did not know "make
update-build-docs" before. I updated testing.md and updated
testing.html using "make update-build-docs".

Webrev: http://cr.openjdk.java.net/~aoqi/8219906/webrev.01/

My environment is Ubuntu 16.04, and I manually install pandoc 2.3.1
from https://github.com/jgm/pandoc/releases/tag/2.3.1

Cheers,
Ao Qi

> /Magnus
>
>
> Cheers,
> Ao Qi
>
>

RFR: JDK-8219906: Update test documentation with default test jobs settings

[Ao Qi]

Hi,

Test jobs setting for sparc is different with x86 (JDK-8211727).
Besides, test jobs setting is based on memory size (JDK-8214003). The
test documentation fails to mention these and needs update.

Bug: https://bugs.openjdk.java.net/browse/JDK-8219906

Webrev: http://cr.openjdk.java.net/~aoqi/8219906/webrev.00/

Cheers,
Ao Qi

Re: OpenJDK 11.0.2 cannot build on Solaris 11.4

[Ao Qi]

Hi Andrew Watkins,

jdk12 can be built on Solaris 11.4 x86 solarisstudio12.4, but it needs
a EM_486 patch, and configure with --disable-hotspot-gtest
--with-jvm-features=-shenandoahgc,-dtrace

Cheers,
Ao Qi

On Wed, Jan 30, 2019 at 5:10 PM Andrew Watkins  wrote:
>
>
>
> On 01/18/19 05:23 PM, Erik Joelsson wrote:
> > .
> >
> > You could try the open/make/devkit/createSolarisDevkit12.4.sh script
> > and see if that helps you build something that works better. That's
> > what we use at Oracle.
> >
> > /Erik
>
> Is there any hope of getting OpenJDK 12 to build on the Free download
> of  Solaris Studio 12.4 or 12.6, since for us Oracle Solaris 11 x86_64
> shops we are unable to get Java 12 or above with out it.
>
> OpenJDK 12 requires latest versions of solarisstudio-124 or
> developerstudio-126
>
> Of course this would not be a problem if Oracle supplied us with Solaris
> 11 x86_64 Java 11 or 12 and not just the SPARC version.
>
> Cheers,
>
> Andrew
>
> --
> Andrew Watkins * Birkbeck, University of London * Computer Science *
> * http://notallmicrosoft.blogspot.com *
> * UKOUG Systems SIG Chair *
> * UKOUG Tech committee *
> * tel: 020 7631 6720 *
>
> ::e-mails are only read & actioned between 0900 and 1800 hours (Monday - 
> Friday)
>

Re: OpenJDK 11.0.2 cannot build on Solaris 11.4

[Ao Qi]

Hi Rob,

If I recall it correctly, maybe configure with --disable-hotspot-gtest
can solve your problem.

Cheer,
Ao Qi

On Fri, Jan 18, 2019 at 5:57 AM Rob Petti  wrote:
>
> Hey Folks,
>
> I've discovered that OpenJDK 11 cannot be built on Solaris 11.4. Normally
> we would just try to rebuild our system as 11.1, but that's not possible
> since media for that base release is no longer available.
>
> Are there plans to support compilation on Oracle's latest and greatest, or
> at least provide a proper method of building in such an environment?
>
> For the record, here are the errors I'm getting. This is with solarisstudio
> 12.4 (which BTW wouldn't install on Solaris 11.4 without unfreezing the
> python version):
>
> # bash configure --with-boot-jdk=
> --with-devkit=/opt/solarisstudio12.4
> # gmake bootcycle-images
> ...
> Compiling 163 files for jdk.jfr
> "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line 1580:
> Error: EM_486 is not defined.
> "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line 1618:
> Error: The type "const arch_t[]" is incomplete.
> 2 Error(s) detected.
> gmake[3]: *** [lib/CompileJvm.gmk:151:
> /root/jdk11/jdk11u/build/solaris-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/os_solaris.o]
> Error 2
>
> After patching with http://robpetti.com/files/jdk11-sol114.patch to fix
> https://bugs.openjdk.java.net/browse/JDK-8182035, it gets a bit further,
> but still fails:
>
> Compiling 64 files for jdk.jconsole
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 161: Error: __pad is not a member of const __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 163: Error: __pad is not a member of const __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 165: Error: __pad is not a member of const __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 165: Error: __pad is not a member of const __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 167: Error: __pad is not a member of const __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 170: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 170: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 172: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 172: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 174: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 174: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 176: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 176: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 178: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 178: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 182: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 183: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 184: Error: __pad is not a member of __FILE.
> 18 Error(s) detected.
>
> It seems the "right" way to do this would be to create a sysroot with older
> 11.1 headers and libraries, and compile against that. Unfortunately the
> --with-sysroot configure option does not completely work correctly. The
> compiler still tries to include /usr/include instead of the sysroot
> headers, and that just results in more build errors. The only way it seems
> to truly get it to use the sysroot was to physically replace /usr/include
> on the machine with the version from the sysroot. This is obviously less
> than ideal.
>
> Is the --with-sysroot issue already known? Is there any other way around it
> aside from manually replacing headers in the system just to compile the JDK?
>
> --
> <https://about.me/robpetti?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api_content=thumb>
> Rob Petti
> about.me/robpetti
> <https://about.me/robpetti?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api_content=thumb>

Re: Fail to cross compiling jdk12 for mips64el-linux-gnu target

[Ao Qi]

Hi Magnus,

On Fri, Jan 25, 2019 at 10:18 PM Magnus Ihse Bursie
 wrote:
>
> On 2019-01-25 02:47, Leslie Zhai wrote:
> > Hi Magnus,
> >
> > Failed to make images:
> >
> > $ make images CONF=mips
> > Building target 'images' in configuration
> > 'linux-mips64el-normal-server-fastdebug'
> > GenerateLinkOptData.gmk:61: recipe for target
> > '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist'
> > failed
> > make[3]: ***
> > [/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist]
> > Error 1
> > make[3]: *** Deleting file
> > '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist'
> > make/Main.gmk:441: recipe for target 'generate-link-opt-data' failed
> > make[2]: *** [generate-link-opt-data] Error 2
>
> This should have worked, but sounds like something that can typically
> fail when cross-compiling. As a workaround, disable class list
> generation: "configure --disable-generate-classlist", or even "configure
> --disable-cds".
>

I tried mips zero of http://hg.openjdk.java.net/jdk/jdk using your
approach of buildjdk [1]. "make images" succeeded and javac (to test
open a file) worked on a mips machine. I tried the same approach to
build our jdk-mips, it failed. Then I used "configure
--disable-generate-classlist --disable-cds ...", "make images"
succeeded and javac worked on a mips machine. I think your approach
solved our problem! Thanks a lot, Magnus!

Cheers,
Ao Qi

[1] https://mail.openjdk.java.net/pipermail/build-dev/2019-January/024735.html


> /Magnus
> >
> > ERROR: Build failed for target 'images' in configuration
> > 'linux-mips64el-normal-server-fastdebug' (exit code 2)
> >
> > === Make failed targets repeated here ===
> > GenerateLinkOptData.gmk:61: recipe for target
> > '/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist'
> > failed
> > make/Main.gmk:441: recipe for target 'generate-link-opt-data' failed
> > === End of repeated output ===
> >
> > Hint: Try searching the build log for the name of the first failed
> > target.
> > Hint: See doc/building.html#troubleshooting for assistance.
> >
> > /home/loongson/zhaixiang/jdk12-mips/make/Init.gmk:300: recipe for
> > target 'main' failed
> > make[1]: *** [main] Error 2
> > /home/loongson/zhaixiang/jdk12-mips/make/Init.gmk:186: recipe for
> > target 'images' failed
> > make: *** [images] Error 2
> >
> > - 8<  8<  8<  8<  8<  8< ---
> >
> > My cross-compile configure option:
> >
> > CC=mips64el-linux-gnuabi64-gcc CXX=mips64el-linux-gnuabi64-g++ sh
> > ./configure \
> >   --openjdk-target=mips64el-linux-gnuabi64 \
> >   --with-sysroot=/chroots/mips64el_stretch \
> >   --with-toolchain-path=/chroots/mips64el_stretch \
> >   --with-boot-jdk=/home/loongson/aoqi/jdk-11.0.1 \
> >   --disable-warnings-as-errors \
> > --with-freetype-lib=/chroots/mips64el_stretch/usr/lib/mips64el-linux-gnuabi64
> > \
> > --with-freetype-include=/chroots/mips64el_stretch/usr/include/freetype2 \
> >   --with-debug-level=fastdebug \
> >   --with-build-jdk=build/buildjdk/jdk
> >
> > - 8<  8<  8<  8<  8<  8< ---
> >
> > buildjdk is OK:
> >
> > $ sh configure --with-conf-name=buildjdk
> > --with-boot-jdk=/home/loongson/aoqi/jdk-11.0.1
> > --disable-warnings-as-errors
> >
> > $ make jdk CONF=buildjdk
> >
> > Building target 'jdk' in configuration 'buildjdk'
> > Finished building target 'jdk' in configuration 'buildjdk'
> >
> > Regards,
> >
> > Leslie Zhai
> >
> >
> > 在 2019/1/24 下午9:30, Magnus Ihse Bursie 写道:
> >> On 2019-01-24 13:22, Leslie Zhai wrote:
> >>> Hi Magnus,
> >>>
> >>> Thanks for your kind response!
> >>>
> >>> 在 2019/1/24 下午8:05, Magnus Ihse Bursie 写道:
> >>>>
> >>>>
> >>>> On 2019-01-24 05:45, David Holmes wrote:
> >>>>> On 24/01/2019 1:51 pm, Ao Qi wrote:
> >>>>>> Hi David,
> >>>>>>
> >>>>>> On Thu, Jan 24, 2019 at 10:47 AM David Holmes
> >>>>>>  wrote:
> >>>>>>>
> >>>>>>> Hi Leslie,
> >>>>>>>
> >>&

Re: Fail to cross compiling jdk12 for mips64el-linux-gnu target

[Ao Qi]

Hi John,

On Fri, Jan 25, 2019 at 11:10 PM Ao Qi  wrote:
>
> On Fri, Jan 25, 2019 at 10:51 PM John Paul Adrian Glaubitz
>  wrote:
> >
> > On 1/25/19 3:44 PM, Ao Qi wrote:> FYI, if one wants to debug this issue, 
> > below is some sctripts I used
> > > to cross compile a mips zero jdk, which can trigger the bug.
> >
> > Native builds on Debian unstable on mips* work?
> >
>

Correction. We use Debian stable and testing to do night build (only
mips64el). We did not use Debian unstable, Is the difference big?

> Worked. We nightly native (using Loongson CPUs) build zero mips of
> jdk8-12 and jdk. But zero mips is not stable as boot jdk, some random
> crash occurs. I am not sure it is an issue of zero mips or an issue of
> MIPS for example maybe some memory consistency issue.
>
>
> > > do one patch [1] then make images
> >
> > What about the alignment patch? Is that still required?
> >
>
> We do not use this patch.
>
> > > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/hotspot-mips-align.diff
> >
> > Adrian
> >
> > --
> >  .''`.  John Paul Adrian Glaubitz
> > : :' :  Debian Developer - glaub...@debian.org
> > `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
> >   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Fail to cross compiling jdk12 for mips64el-linux-gnu target

[Ao Qi]

On Fri, Jan 25, 2019 at 10:51 PM John Paul Adrian Glaubitz
 wrote:
>
> On 1/25/19 3:44 PM, Ao Qi wrote:> FYI, if one wants to debug this issue, 
> below is some sctripts I used
> > to cross compile a mips zero jdk, which can trigger the bug.
>
> Native builds on Debian unstable on mips* work?
>

Worked. We nightly native (using Loongson CPUs) build zero mips of
jdk8-12 and jdk. But zero mips is not stable as boot jdk, some random
crash occurs. I am not sure it is an issue of zero mips or an issue of
MIPS for example maybe some memory consistency issue.


> > do one patch [1] then make images
>
> What about the alignment patch? Is that still required?
>

We do not use this patch.

> > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/hotspot-mips-align.diff
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Fail to cross compiling jdk12 for mips64el-linux-gnu target

[Ao Qi]

Hi,

On Fri, Jan 25, 2019 at 10:31 PM John Paul Adrian Glaubitz
 wrote:
>
> Hi!
>
> On 1/24/19 3:28 AM, Leslie Zhai wrote:
> > Please give me some advice about how to fix the root cause, thanks a lot!
>
> Just as a heads-up: In Debian we have two patches required for OpenJDK on the 
> mips
> targets:
>
> > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/hotspot-mips-align.diff
> > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/mips-sigset.diff
>
> I think the stuff with sigset was being worked on upstream at some point, but 
> it
> wasn't finished if I remember correctly.
>

Yes, I wish to solve this problem, I tried, and it was basically the
way Debian and AIX used [1]. But David Holmes wishes a POSIX version,
that patch failed to be pushed. I think I will go on to work on it,
however I do not have Solaris and macOS for test, I am working on
preparing these OSs.

What is 
https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/hotspot-mips-align.diff
for? We build mips zero without this patch.

Cheers,
Ao Qi

[1] 
https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-December/031839.html

> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Fail to cross compiling jdk12 for mips64el-linux-gnu target

[Ao Qi]

Hi,

FYI, if one wants to debug this issue, below is some sctripts I used
to cross compile a mips zero jdk, which can trigger the bug.

build machine: x86, debian testing (in a VirtualBox; an ubuntu may
fail to configure)

known worked targets: ppc64le/server and s390x/server (aarch64/server
may fail during make images)

repository: http://hg.openjdk.java.net/jdk/jdk

geting a sysroot:

#export arch=arm64
#export arch=ppc64el
#export arch=s390x
export arch=mips64el
export ver=stretch
apt-get install qemu-user-static sudo debootstrap binfmt-support qemu
(not sure if all of them are required)
sudo qemu-debootstrap --arch=${arch} --verbose \
   
--include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng-dev,libffi-dev
\
  --resolve-deps ${ver} /chroots/${arch}_${ver}
http://httpredir.debian.org/debian/

configure of jdk:

#arch1=aarch64 ; arch2=arm64; gnuname=gnu
#arch1=powerpc64le ; arch2=ppc64el; gnuname=gnu
#arch1=s390x ; arch2=s390x; gnuname=gnu
arch1=mips64el ; arch2=mips64el; gnuname=gnuabi64
apt install g++-${arch1}-linux-${gnuname} gcc-${arch1}-linux-${gnuname}
ver=stretch
CC=$arch1-linux-${gnuname}-gcc CXX=$arch1-linux-${gnuname}-g++ \
  sh ./configure --openjdk-target=$arch1-linux-${gnuname}
--with-sysroot=/chroots/${arch2}_${ver}/
--with-toolchain-path=/chroots/${arch2}_${ver}/ \
  --with-boot-jdk=/home/loongson/aoqi/jdk-13/ --disable-warnings-as-errors \
  --with-jvm-variants=zero \
  --x-libraries=/chroots/${arch2}_${ver}/usr/lib/$arch1-linux-${gnuname}
--x-include=/chroots/${arch2}_${ver}/usr/include/X11/ \
  --with-freetype-lib=/chroots/${arch2}_${ver}/usr/lib/$arch1-linux-${gnuname}/
--with-freetype-include=/chroots/${arch2}_${ver}/usr/include/freetype2

make:

do one patch [1] then make images

I am trying Magnus's approach. When there are results, I will reply.

[1] 
https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-December/031839.html

On Fri, Jan 25, 2019 at 1:19 AM Erik Joelsson  wrote:
>
> Hello,
>
> I agree with the conclusion here, there is certainly a bug in the build
> logic. When creating the "Build JDK" during a cross compilation build,
> we are, as Magnus said, cutting a few corners for efficiency. One of
> those corners is assuming all the java classes are the same and can
> simply be reused. It has been shown here that that assumption is not
> always correct.
>
> I think the most reasonable solution is to assume all of java.base needs
> to be built specifically for the "Build JDK". I think this can be
> reasonably easy to implement (compared to the existing Build JDK logic,
> which is arguably rather hairy).
>
> Magnus' suggested workaround should work fine for now however.
>
> Filed https://bugs.openjdk.java.net/browse/JDK-8217739
>
> /Erik
>
> On 2019-01-24 05:30, Magnus Ihse Bursie wrote:
> > On 2019-01-24 13:22, Leslie Zhai wrote:
> >> Hi Magnus,
> >>
> >> Thanks for your kind response!
> >>
> >> 在 2019/1/24 下午8:05, Magnus Ihse Bursie 写道:
> >>>
> >>>
> >>> On 2019-01-24 05:45, David Holmes wrote:
> >>>> On 24/01/2019 1:51 pm, Ao Qi wrote:
> >>>>> Hi David,
> >>>>>
> >>>>> On Thu, Jan 24, 2019 at 10:47 AM David Holmes
> >>>>>  wrote:
> >>>>>>
> >>>>>> Hi Leslie,
> >>>>>>
> >>>>>> I'm not Erik :) however 
> >>>>>>
> >>>>>> On 24/01/2019 12:28 pm, Leslie Zhai wrote:
> >>>>>>> Hi Erik,
> >>>>>>>
> >>>>>>> Because the flags' macro of MIPS is different from other
> >>>>>>> targets[1], it
> >>>>>>> will effect the `UnixConstants` of
> >>>>>>> src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template,
> >>>>>>> for
> >>>>>>> example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is
> >>>>>>> different
> >>>>>>> from other targets.  Then failed[2] to cross compiling jdk12 for
> >>>>>>> mips64el-linux-gnu target by following the document[3].
> >>>>>>
> >>>>>> It's been quite a while since we built for a platform where the
> >>>>>> flags
> >>>>>> had different values, but it is supposed to work. I suspect that
> >>>>>> the way
> >>>>>> we build now with the module system may not be quite correct in this
> >>>>>> regard - but that is just supposit

Re: NetBeans pre-build failed due to the incorrect configuration

[Ao Qi]

Hi,

I have filed a bug and posted the patch.

Bug: https://bugs.openjdk.java.net/browse/JDK-8215952

Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.00/

This is my first time to do this. If there is something wrong,
suggestion and correction are welcome:)

Cheers,
Ao Qi

On Fri, Dec 28, 2018 at 12:42 PM Fu Jie  wrote:
>
> Nice.
>
> Many thanks to you David.
>
>
> Best regards,
> Jie
>
> On 2018/12/28 上午11:47, David Holmes wrote:
> > On 28/12/2018 1:36 pm, Fu Jie wrote:
> >> Hi David,
> >>
> >> Thanks for your reply.
> >>
> >> I had tried to send the patch as an attachment last night, but the
> >> mailing lists reminded me that the size of my email with such an
> >> attachment was too big.
> >>
> >> I'm very appreciative of your help. And I'd like to follow your
> >> advice to submit the patch again later.
> >
> > Ao Qi has author status now and so can post a webrev on
> > cr.openjdk.java.net. Perhaps they could help you with this patch. They
> > can also file a bug for this issue on https://bugs.openjdk.java.net
> >
> > Thanks,
> > David
> >
> >> Best regards,
> >>
> >> Jie
> >>
> >>
> >>
> >> On 2018/12/27 下午9:01, David Holmes wrote:
> >>> Hi,
> >>>
> >>> All patches to OpenJDK must be submitted on OpenJDK infrastructure.
> >>> This means either hosted on cr.openjdk.java.net or else included
> >>> inline, or as attachments, to emails to the OpenJDK mailing lists.
> >>> Patches hosted on github are not acceptable.
> >>>
> >>> Thanks,
> >>> David
> >>>
> >>> On 27/12/2018 10:56 pm, Fu Jie wrote:
> >>>> Hi all,
> >>>>
> >>>>
> >>>> OpenJDK build with NetBeans failed during the pre-build process.
> >>>> The reason is that configuration in
> >>>> make/nb_native/nbproject/configurations.xml is wrong.
> >>>>
> >>>> The setting that leads to the failure is:
> >>>> sh ../configure
> >>>> --with-debug-level=slowdebug
> >>>> --disable-zip-debug-info
> >>>>
> >>>> Two pionts were wrong here:
> >>>>   1) the path of configure script specified was incorrect which
> >>>> should just be "sh configure" instead of "sh ../configure".
> >>>>   2) deprecated --disable-zip-debug-info was used which is now an
> >>>> unrecognized option.
> >>>>
> >>>> The pre-build succeeded with the following configuration. For more
> >>>> info., see [1].
> >>>> sh configure
> >>>> --with-debug-level=slowdebug
> >>>>
> >>>>
> >>>> Further more, there are too many invalid items in
> >>>> make/nb_native/nbproject/configurations.xml. For example
> >>>> This item is invalid since advancedThresholdPolicy.cpp had been
> >>>> removed from the project.
> >>>> 
> >>>>
> >>>>   >>>> path="../../src/hotspot/share/runtime/advancedThresholdPolicy.cpp"
> >>>>ex="false"
> >>>>tool="1"
> >>>>flavor2="0">
> >>>>  
> >>>> 
> >>>>
> >>>> For more invalid items, see [2].
> >>>>
> >>>>
> >>>> To fix the issues, make/nb_native/nbproject/configurations.xml
> >>>> needs to be updated. And I made a patch[3] for this.
> >>>> Could anyone help to review it? Thank you!
> >>>>
> >>>> [1]
> >>>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-prebuild-failed.md
> >>>>
> >>>> [2]
> >>>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-invalid-config-items.md
> >>>>
> >>>> [3]
> >>>> https://github.com/DamonFool/MyWorkspace/blob/master/others/nb-config.diff
> >>>>
> >>>>
> >>>> Best regards,
> >>>> Fu Jie
> >>>>
> >>>>
> >>
>

Re: [PATCH] Add Xrandr in build documentation

[Ao Qi]

Hi Magnus,

Thanks! By the way, I finally received that email after hours:)

Cheers,
Ao Qi

On Mon, Dec 10, 2018 at 10:20 PM Magnus Ihse Bursie
 wrote:
>
> On 2018-12-10 13:07, Ao Qi wrote:
> > Hi Magnus,
> >
> > It is strange that I saw your reply in "build-dev Archives" [1], but I
> > did not receive the email. Maybe there is something wrong with my
> > email server. I cannot reply to your email directly.
> Sometimes the mailing list servers seem to lose mail, or hold them for
> arbitrarily long time before sending them on. It's happening for me
> every once in a while. Hmm... On the other hand, this time I got my own
> mail to the list, and you were cc:ed too, so you should definitely have
> received it. Probably an issue on your side, yes.
> >
> > Thanks for your review. To answer your question:
> >
> >> I assume you need a sponsor for this? Have you signed the OCA, and do
> >> you have an OpenJDK user name? (Sorry if I asked you before.)
> > Yes. Yes. No. One of my previous patch[2] for your reference.
> >
> >
> > [1] 
> > http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024326.html
> > [2] http://hg.openjdk.java.net/jdk/jdk/rev/04c8eba70a59
> Thanks! I pushed this as JBS-8215129.
>
> /Magnus
> >
> > Cheers,
> > Ao Qi
> > On Mon, Dec 10, 2018 at 6:28 PM Ao Qi  wrote:
> >> Hi all,
> >>
> >> When I try to do a cross-compiling with qemu-deboostrap according to
> >> doc/building.html, it failed to configure (a X11 headers error,
> >> "checking for X11/extensions/Xrandr.h... no").
> >>
> >> I think it is because Xrandr became a configure check prerequisite
> >> after JDK-8213944. Could anyone please review this tiny fix for the
> >> build documentation?
> >>
> >> Cheers,
> >> Ao Qi
> >>
> >> $ hg diff -g doc
> >> diff --git a/doc/building.html b/doc/building.html
> >> --- a/doc/building.html
> >> +++ b/doc/building.html
> >> @@ -396,9 +396,9 @@
> >>   X11
> >>   Certain http://www.x.org/;>X11 libraries and include
> >> files are required on Linux and Solaris.
> >>   
> >> -To install on an apt-based Linux, try running sudo apt-get
> >> install libx11-dev libxext-dev libxrender-dev libxtst-dev
> >> libxt-dev.
> >> -To install on an rpm-based Linux, try running sudo yum
> >> install libXtst-devel libXt-devel libXrender-devel
> >> libXi-devel.
> >> -To install on Solaris, try running pkg install
> >> x11/header/x11-protocols x11/library/libice
> >> x11/library/libpthread-stubs x11/library/libsm x11/library/libx11
> >> x11/library/libxau x11/library/libxcb x11/library/libxdmcp
> >> x11/library/libxevie x11/library/libxext x11/library/libxrender
> >> x11/library/libxscrnsaver x11/library/libxtst
> >> x11/library/toolkit/libxt.
> >> +To install on an apt-based Linux, try running sudo apt-get
> >> install libx11-dev libxext-dev libxrender-dev libxrandr-dev
> >> libxtst-dev libxt-dev.
> >> +To install on an rpm-based Linux, try running sudo yum
> >> install libXtst-devel libXt-devel libXrender-devel libXrandr-devel
> >> libXi-devel.
> >> +To install on Solaris, try running pkg install
> >> x11/header/x11-protocols x11/library/libice
> >> x11/library/libpthread-stubs x11/library/libsm x11/library/libx11
> >> x11/library/libxau x11/library/libxcb x11/library/libxdmcp
> >> x11/library/libxevie x11/library/libxext x11/library/libxrender
> >> x11/library/libxrandr x11/library/libxscrnsaver x11/library/libxtst
> >> x11/library/toolkit/libxt.
> >>   
> >>   Use --with-x=path if configure
> >> does not properly locate your X11 files.
> >>   ALSA
> >> @@ -662,6 +662,7 @@
> >>   libice-dev
> >>   libxrender
> >>   libxrender-dev
> >> +libxrandr-dev
> >>   libsm-dev
> >>   libxt-dev
> >>   libx11
> >> @@ -693,7 +694,7 @@
> >>   apt install g++-aarch64-linux-gnu
> >> gcc-aarch64-linux-gnu
> >>   Create chroot on the build system, configuring it for
> >> target system:
> >>   sudo qemu-debootstrap --arch=arm64 --verbose \
> >> -   
> >> --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> >> \
> >> +   
> >> --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr

Re: [PATCH] Add Xrandr in build documentation

[Ao Qi]

Hi Magnus,

It is strange that I saw your reply in "build-dev Archives" [1], but I
did not receive the email. Maybe there is something wrong with my
email server. I cannot reply to your email directly.

Thanks for your review. To answer your question:

>I assume you need a sponsor for this? Have you signed the OCA, and do
>you have an OpenJDK user name? (Sorry if I asked you before.)
Yes. Yes. No. One of my previous patch[2] for your reference.


[1] http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024326.html
[2] http://hg.openjdk.java.net/jdk/jdk/rev/04c8eba70a59

Cheers,
Ao Qi
On Mon, Dec 10, 2018 at 6:28 PM Ao Qi  wrote:
>
> Hi all,
>
> When I try to do a cross-compiling with qemu-deboostrap according to
> doc/building.html, it failed to configure (a X11 headers error,
> "checking for X11/extensions/Xrandr.h... no").
>
> I think it is because Xrandr became a configure check prerequisite
> after JDK-8213944. Could anyone please review this tiny fix for the
> build documentation?
>
> Cheers,
> Ao Qi
>
> $ hg diff -g doc
> diff --git a/doc/building.html b/doc/building.html
> --- a/doc/building.html
> +++ b/doc/building.html
> @@ -396,9 +396,9 @@
>  X11
>  Certain http://www.x.org/;>X11 libraries and include
> files are required on Linux and Solaris.
>  
> -To install on an apt-based Linux, try running sudo apt-get
> install libx11-dev libxext-dev libxrender-dev libxtst-dev
> libxt-dev.
> -To install on an rpm-based Linux, try running sudo yum
> install libXtst-devel libXt-devel libXrender-devel
> libXi-devel.
> -To install on Solaris, try running pkg install
> x11/header/x11-protocols x11/library/libice
> x11/library/libpthread-stubs x11/library/libsm x11/library/libx11
> x11/library/libxau x11/library/libxcb x11/library/libxdmcp
> x11/library/libxevie x11/library/libxext x11/library/libxrender
> x11/library/libxscrnsaver x11/library/libxtst
> x11/library/toolkit/libxt.
> +To install on an apt-based Linux, try running sudo apt-get
> install libx11-dev libxext-dev libxrender-dev libxrandr-dev
> libxtst-dev libxt-dev.
> +To install on an rpm-based Linux, try running sudo yum
> install libXtst-devel libXt-devel libXrender-devel libXrandr-devel
> libXi-devel.
> +To install on Solaris, try running pkg install
> x11/header/x11-protocols x11/library/libice
> x11/library/libpthread-stubs x11/library/libsm x11/library/libx11
> x11/library/libxau x11/library/libxcb x11/library/libxdmcp
> x11/library/libxevie x11/library/libxext x11/library/libxrender
> x11/library/libxrandr x11/library/libxscrnsaver x11/library/libxtst
> x11/library/toolkit/libxt.
>  
>  Use --with-x=path if configure
> does not properly locate your X11 files.
>  ALSA
> @@ -662,6 +662,7 @@
>  libice-dev
>  libxrender
>  libxrender-dev
> +libxrandr-dev
>  libsm-dev
>  libxt-dev
>  libx11
> @@ -693,7 +694,7 @@
>  apt install g++-aarch64-linux-gnu
> gcc-aarch64-linux-gnu
>  Create chroot on the build system, configuring it for
> target system:
>  sudo qemu-debootstrap --arch=arm64 --verbose \
> -   
> --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> \
> +   
> --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> \
> --resolve-deps jessie /chroots/arm64
> http://httpredir.debian.org/debian/
>  Configure and build with newly created chroot as
> sysroot/toolchain-path:
>  CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ sh
> ./configure --openjdk-target=aarch64-linux-gnu
> --with-sysroot=/chroots/arm64/ --with-toolchain-path=/chroots/arm64/
> diff --git a/doc/building.md b/doc/building.md
> --- a/doc/building.md
> +++ b/doc/building.md
> @@ -488,15 +488,15 @@
>  Linux and Solaris.
>
>* To install on an apt-based Linux, try running `sudo apt-get install
> -libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev`.
> +libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev 
> libxt-dev`.
>* To install on an rpm-based Linux, try running `sudo yum install
> -libXtst-devel libXt-devel libXrender-devel libXi-devel`.
> +libXtst-devel libXt-devel libXrender-devel libXrandr-devel libXi-devel`.
>* To install on Solaris, try running `pkg install x11/header/x11-protocols
>  x11/library/libice x11/library/libpthread-stubs x11/library/libsm
>  x11/library/libx11 x11/library/libxau x11/library/libxcb
>  x11/library/libxdmcp x11/library/libxevie x11/library/libxext
> -x11/library/libxrender x11/library/lib

[PATCH] Add Xrandr in build documentation

[Ao Qi]

Hi all,

When I try to do a cross-compiling with qemu-deboostrap according to
doc/building.html, it failed to configure (a X11 headers error,
"checking for X11/extensions/Xrandr.h... no").

I think it is because Xrandr became a configure check prerequisite
after JDK-8213944. Could anyone please review this tiny fix for the
build documentation?

Cheers,
Ao Qi

$ hg diff -g doc
diff --git a/doc/building.html b/doc/building.html
--- a/doc/building.html
+++ b/doc/building.html
@@ -396,9 +396,9 @@
 X11
 Certain http://www.x.org/;>X11 libraries and include
files are required on Linux and Solaris.
 
-To install on an apt-based Linux, try running sudo apt-get
install libx11-dev libxext-dev libxrender-dev libxtst-dev
libxt-dev.
-To install on an rpm-based Linux, try running sudo yum
install libXtst-devel libXt-devel libXrender-devel
libXi-devel.
-To install on Solaris, try running pkg install
x11/header/x11-protocols x11/library/libice
x11/library/libpthread-stubs x11/library/libsm x11/library/libx11
x11/library/libxau x11/library/libxcb x11/library/libxdmcp
x11/library/libxevie x11/library/libxext x11/library/libxrender
x11/library/libxscrnsaver x11/library/libxtst
x11/library/toolkit/libxt.
+To install on an apt-based Linux, try running sudo apt-get
install libx11-dev libxext-dev libxrender-dev libxrandr-dev
libxtst-dev libxt-dev.
+To install on an rpm-based Linux, try running sudo yum
install libXtst-devel libXt-devel libXrender-devel libXrandr-devel
libXi-devel.
+To install on Solaris, try running pkg install
x11/header/x11-protocols x11/library/libice
x11/library/libpthread-stubs x11/library/libsm x11/library/libx11
x11/library/libxau x11/library/libxcb x11/library/libxdmcp
x11/library/libxevie x11/library/libxext x11/library/libxrender
x11/library/libxrandr x11/library/libxscrnsaver x11/library/libxtst
x11/library/toolkit/libxt.
 
 Use --with-x=path if configure
does not properly locate your X11 files.
 ALSA
@@ -662,6 +662,7 @@
 libice-dev
 libxrender
 libxrender-dev
+libxrandr-dev
 libsm-dev
 libxt-dev
 libx11
@@ -693,7 +694,7 @@
 apt install g++-aarch64-linux-gnu
gcc-aarch64-linux-gnu
 Create chroot on the build system, configuring it for
target system:
 sudo qemu-debootstrap --arch=arm64 --verbose \
-   
--include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
\
+   
--include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
\
--resolve-deps jessie /chroots/arm64
http://httpredir.debian.org/debian/
 Configure and build with newly created chroot as
sysroot/toolchain-path:
 CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ sh
./configure --openjdk-target=aarch64-linux-gnu
--with-sysroot=/chroots/arm64/ --with-toolchain-path=/chroots/arm64/
diff --git a/doc/building.md b/doc/building.md
--- a/doc/building.md
+++ b/doc/building.md
@@ -488,15 +488,15 @@
 Linux and Solaris.

   * To install on an apt-based Linux, try running `sudo apt-get install
-libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev`.
+libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev`.
   * To install on an rpm-based Linux, try running `sudo yum install
-libXtst-devel libXt-devel libXrender-devel libXi-devel`.
+libXtst-devel libXt-devel libXrender-devel libXrandr-devel libXi-devel`.
   * To install on Solaris, try running `pkg install x11/header/x11-protocols
 x11/library/libice x11/library/libpthread-stubs x11/library/libsm
 x11/library/libx11 x11/library/libxau x11/library/libxcb
 x11/library/libxdmcp x11/library/libxevie x11/library/libxext
-x11/library/libxrender x11/library/libxscrnsaver x11/library/libxtst
-x11/library/toolkit/libxt`.
+x11/library/libxrender x11/library/libxrandr x11/library/libxscrnsaver
+x11/library/libxtst x11/library/toolkit/libxt`.

 Use `--with-x=` if `configure` does not properly locate your X11 files.

@@ -1062,6 +1062,7 @@
   * libice-dev
   * libxrender
   * libxrender-dev
+  * libxrandr-dev
   * libsm-dev
   * libxt-dev
   * libx11
@@ -1112,7 +1113,7 @@
   * Create chroot on the *build* system, configuring it for *target* system:
 ```
 sudo qemu-debootstrap --arch=arm64 --verbose \
-   
--include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
\
+   
--include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
\
--resolve-deps jessie /chroots/arm64 http://httpredir.debian.org/debian/
 ```

Re: How to pass additional options to boot jdk during configure, _JAVA_OPTIONS does not work

[Ao Qi]

On Thu, Sep 20, 2018 at 7:36 PM Magnus Ihse Bursie
 wrote:
>
> On 2018-09-20 12:41, Ao Qi wrote:
>
> On Thu, Sep 20, 2018 at 4:10 PM Magnus Ihse Bursie
>  wrote:
>
> On 2018-09-20 09:26, Ao Qi wrote:
>
> Hi,
>
> Is there any options or methods that I can pass additional jdk options
> to the boot jdk when I configure jdk/jdk? I found
> --with-boot-jdk-jvmargs, but I think it is effective during building
> the jdk, not configuring the jdk.
>
> You are correct, the additional arguments in --with-boot-jdk-jvmargs is only 
> used during the build, not during configure.
>
> I used _JAVA_OPTIONS, but it failed to configure (fail to detect jdk
> version). I made a patch:
>
> $ hg diff
> diff -r feb4c9e03aed make/autoconf/basics.m4
> --- a/make/autoconf/basics.m4 Tue Sep 18 19:44:27 2018 -0700
> +++ b/make/autoconf/basics.m4 Wed Sep 19 11:44:54 2018 +0800
> @@ -168,7 +168,7 @@
>  [
>$ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD
>$ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD
> -  OUTPUT=`$3 $1 -version 2>&1`
> +  OUTPUT=`$3 $1 -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:"`
>FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn`
>FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""`
>if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then
> diff -r feb4c9e03aed make/autoconf/boot-jdk.m4
> --- a/make/autoconf/boot-jdk.m4 Tue Sep 18 19:44:27 2018 -0700
> +++ b/make/autoconf/boot-jdk.m4 Wed Sep 19 11:44:54 2018 +0800
> @@ -74,7 +74,7 @@
>BOOT_JDK_FOUND=no
>  else
># Oh, this is looking good! We probably have found a proper
> JDK. Is it the correct version?
> -  BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1`
> +  BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 |
> $GREP -v "^Picked up _JAVA_OPTIONS:" | $HEAD -n 1`
>
># Extra M4 quote needed to protect [] in grep expression.
>[FOUND_CORRECT_VERSION=`$ECHO $BOOT_JDK_VERSION \
> @@ -90,7 +90,7 @@
>  AC_MSG_CHECKING([for Boot JDK])
>  AC_MSG_RESULT([$BOOT_JDK])
>  AC_MSG_CHECKING([Boot JDK version])
> -BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 |
> $TR '\n\r' '  '`
> +BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 |
> $GREP -v "^Picked up _JAVA_OPTIONS:" | $TR '\n\r' '  '`
>  AC_MSG_RESULT([$BOOT_JDK_VERSION])
>fi # end check jdk version
>  fi # end check javac
>
>
>
> This works for me. The _JAVA_OPTIONS is effective during configure. Is
> there some other way to do that (without changing the code)? Or
> otherwise is it possible to accept this patch?
>
> Hm. Using _JAVA_OPTIONS is really not good. It's a very hidden way to 
> influence the behavior of a running Java process. It might fail if it is not 
> accepted on both the boot JDK and the newly built JDK.
>
> I think a better solution would be to add the --with-boot-jdk-jvmargs to the 
> boot JDK version check.
>
> Here's an alternative patch. Please try it out and see if it works for you. 
> It will apply the --with-boot-jdk-jvmargs at all calls to Java.
>
> This patch works for me, and it passed my test script. Thanks! If this
> patch is intended to push into jdk/jdk, just one minor thing: is
> JAVA_TOOL_OPTIONS also needed to be considered?
>
> I didn't even know there was a  JAVA_TOOL_OPTIONS. :) Yes, we should handle 
> that as well. I'll update the patch and put it out for review. Thanks!
>

I didn't know it either. I was cruise and grep _JAVA_OPTIONS in
hotspot, and found that there is a JAVA_TOOL_OPTIONS. :)

Ao Qi

> /Magnus
>
>
> Cheers,
> Ao Qi
>
> diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4
> --- a/make/autoconf/basics.m4
> +++ b/make/autoconf/basics.m4
> @@ -168,7 +168,7 @@
>  [
>$ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD
>$ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD
> -  OUTPUT=`$3 $1 -version 2>&1`
> +  OUTPUT=`$3 $1 $USER_BOOT_JDK_OPTIONS -version 2>&1`
>FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn`
>FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""`
>if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then
> diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4
> --- a/make/autoconf/boot-jdk.m4
> +++ b/make/autoconf/boot-jdk.m4
> @@ -74,7 +74,17 @@
>BOOT_JDK_FOUND=no
>  else
>   

Re: How to pass additional options to boot jdk during configure, _JAVA_OPTIONS does not work

[Ao Qi]

On Thu, Sep 20, 2018 at 4:10 PM Magnus Ihse Bursie
 wrote:
>
> On 2018-09-20 09:26, Ao Qi wrote:
>
> Hi,
>
> Is there any options or methods that I can pass additional jdk options
> to the boot jdk when I configure jdk/jdk? I found
> --with-boot-jdk-jvmargs, but I think it is effective during building
> the jdk, not configuring the jdk.
>
> You are correct, the additional arguments in --with-boot-jdk-jvmargs is only 
> used during the build, not during configure.
>
> I used _JAVA_OPTIONS, but it failed to configure (fail to detect jdk
> version). I made a patch:
>
> $ hg diff
> diff -r feb4c9e03aed make/autoconf/basics.m4
> --- a/make/autoconf/basics.m4 Tue Sep 18 19:44:27 2018 -0700
> +++ b/make/autoconf/basics.m4 Wed Sep 19 11:44:54 2018 +0800
> @@ -168,7 +168,7 @@
>  [
>$ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD
>$ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD
> -  OUTPUT=`$3 $1 -version 2>&1`
> +  OUTPUT=`$3 $1 -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:"`
>FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn`
>FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""`
>if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then
> diff -r feb4c9e03aed make/autoconf/boot-jdk.m4
> --- a/make/autoconf/boot-jdk.m4 Tue Sep 18 19:44:27 2018 -0700
> +++ b/make/autoconf/boot-jdk.m4 Wed Sep 19 11:44:54 2018 +0800
> @@ -74,7 +74,7 @@
>BOOT_JDK_FOUND=no
>  else
># Oh, this is looking good! We probably have found a proper
> JDK. Is it the correct version?
> -  BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1`
> +  BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 |
> $GREP -v "^Picked up _JAVA_OPTIONS:" | $HEAD -n 1`
>
># Extra M4 quote needed to protect [] in grep expression.
>[FOUND_CORRECT_VERSION=`$ECHO $BOOT_JDK_VERSION \
> @@ -90,7 +90,7 @@
>  AC_MSG_CHECKING([for Boot JDK])
>  AC_MSG_RESULT([$BOOT_JDK])
>  AC_MSG_CHECKING([Boot JDK version])
> -BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 |
> $TR '\n\r' '  '`
> +BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 |
> $GREP -v "^Picked up _JAVA_OPTIONS:" | $TR '\n\r' '  '`
>  AC_MSG_RESULT([$BOOT_JDK_VERSION])
>fi # end check jdk version
>  fi # end check javac
>
>
>
> This works for me. The _JAVA_OPTIONS is effective during configure. Is
> there some other way to do that (without changing the code)? Or
> otherwise is it possible to accept this patch?
>
> Hm. Using _JAVA_OPTIONS is really not good. It's a very hidden way to 
> influence the behavior of a running Java process. It might fail if it is not 
> accepted on both the boot JDK and the newly built JDK.
>
> I think a better solution would be to add the --with-boot-jdk-jvmargs to the 
> boot JDK version check.
>
> Here's an alternative patch. Please try it out and see if it works for you. 
> It will apply the --with-boot-jdk-jvmargs at all calls to Java.
>

This patch works for me, and it passed my test script. Thanks! If this
patch is intended to push into jdk/jdk, just one minor thing: is
JAVA_TOOL_OPTIONS also needed to be considered?

Cheers,
Ao Qi

> diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4
> --- a/make/autoconf/basics.m4
> +++ b/make/autoconf/basics.m4
> @@ -168,7 +168,7 @@
>  [
>$ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD
>$ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD
> -  OUTPUT=`$3 $1 -version 2>&1`
> +  OUTPUT=`$3 $1 $USER_BOOT_JDK_OPTIONS -version 2>&1`
>FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn`
>FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""`
>if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then
> diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4
> --- a/make/autoconf/boot-jdk.m4
> +++ b/make/autoconf/boot-jdk.m4
> @@ -74,7 +74,17 @@
>BOOT_JDK_FOUND=no
>  else
># Oh, this is looking good! We probably have found a proper JDK. 
> Is it the correct version?
> -  BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1`
> +  BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" $USER_BOOT_JDK_OPTIONS 
> -version 2>&1 | $HEAD -n 1`
> +  if [ [[ "$BOOT_JDK_VERSION" =~ "Picked up _JAVA_OPTIONS" ]] ]; then
> +AC_MSG_NOTICE

How to pass additional options to boot jdk during configure, _JAVA_OPTIONS does not work

[Ao Qi]

Hi,

Is there any options or methods that I can pass additional jdk options
to the boot jdk when I configure jdk/jdk? I found
--with-boot-jdk-jvmargs, but I think it is effective during building
the jdk, not configuring the jdk.

I used _JAVA_OPTIONS, but it failed to configure (fail to detect jdk
version). I made a patch:

$ hg diff
diff -r feb4c9e03aed make/autoconf/basics.m4
--- a/make/autoconf/basics.m4 Tue Sep 18 19:44:27 2018 -0700
+++ b/make/autoconf/basics.m4 Wed Sep 19 11:44:54 2018 +0800
@@ -168,7 +168,7 @@
 [
   $ECHO "Check if jvm arg is ok: $1" >_MESSAGE_LOG_FD
   $ECHO "Command: $3 $1 -version" >_MESSAGE_LOG_FD
-  OUTPUT=`$3 $1 -version 2>&1`
+  OUTPUT=`$3 $1 -version 2>&1 | $GREP -v "^Picked up _JAVA_OPTIONS:"`
   FOUND_WARN=`$ECHO "$OUTPUT" | $GREP -i warn`
   FOUND_VERSION=`$ECHO $OUTPUT | $GREP " version \""`
   if test "x$FOUND_VERSION" != x && test "x$FOUND_WARN" = x; then
diff -r feb4c9e03aed make/autoconf/boot-jdk.m4
--- a/make/autoconf/boot-jdk.m4 Tue Sep 18 19:44:27 2018 -0700
+++ b/make/autoconf/boot-jdk.m4 Wed Sep 19 11:44:54 2018 +0800
@@ -74,7 +74,7 @@
   BOOT_JDK_FOUND=no
 else
   # Oh, this is looking good! We probably have found a proper
JDK. Is it the correct version?
-  BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1`
+  BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 |
$GREP -v "^Picked up _JAVA_OPTIONS:" | $HEAD -n 1`

   # Extra M4 quote needed to protect [] in grep expression.
   [FOUND_CORRECT_VERSION=`$ECHO $BOOT_JDK_VERSION \
@@ -90,7 +90,7 @@
 AC_MSG_CHECKING([for Boot JDK])
 AC_MSG_RESULT([$BOOT_JDK])
 AC_MSG_CHECKING([Boot JDK version])
-BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 |
$TR '\n\r' '  '`
+BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 |
$GREP -v "^Picked up _JAVA_OPTIONS:" | $TR '\n\r' '  '`
 AC_MSG_RESULT([$BOOT_JDK_VERSION])
   fi # end check jdk version
 fi # end check javac



This works for me. The _JAVA_OPTIONS is effective during configure. Is
there some other way to do that (without changing the code)? Or
otherwise is it possible to accept this patch?

Cheers,
Ao Qi

Re: Configure broken on MIPS when uname returns mipsel or mips64el

[Ao Qi]

Hi Erik,

Thanks for reviewing and sponsoring.

2018-05-31 0:39 GMT+08:00 Erik Joelsson :
> I'll sponsor it.
>
> /Erik
>
>
>
> On 2018-05-29 23:13, Ao Qi wrote:
>>
>> Could someone help to create a bug etc?
>>
>> Thanks,
>> Ao Qi
>> Magnus Ihse Bursie  于2018年5月25日周五 下午
>> 3:42写道：
>>
>>> On 2018-05-24 03:08, Ao Qi wrote:
>>> Hi Erik,
>>> Thanks for your comments. I made a new patch:
>>> $ hg diff
>>> diff -r 31361382634b make/autoconf/build-aux/config.guess
>>> --- a/make/autoconf/build-aux/config.guess Tue May 22 10:08:04 2018 -0700
>>> +++ b/make/autoconf/build-aux/config.guess Thu May 24 09:07:17 2018 +0800
>>> @@ -86,6 +86,17 @@
>>>   fi
>>> fi
>>> +# Test and fix little endian MIPS.
>>> +if [ "x$OUT" = x ]; then
>>> +  if [ `uname -s` = Linux ]; then
>>> +if [ `uname -m` = mipsel ]; then
>>> +  OUT=mipsel-unknown-linux-gnu
>>> +elif [ `uname -m` = mips64el ]; then
>>> +  OUT=mips64el-unknown-linux-gnu
>>> +fi
>>> +  fi
>>> +fi
>>> +
>>> # Test and fix cpu on Macosx when C preprocessor is not on the path
>>> echo $OUT | grep i386-apple-darwin > /dev/null 2> /dev/null
>>> if test $? = 0; then
>>
>>
>>> Looks good to me.

Hi Magnus,

Thanks for reviewing.

>>> /Magnus
>>> Cheers,
>>> Ao Qi
>>> 2018-05-24 0:19 GMT+08:00 Erik Joelsson :
>>> Hello Ao Qi,
>>> Due to licensing reasons, we are unable to directly update the
>>> autoconf-config.guess file. Instead we have the wrapper, config.guess in
>>> which we make adjustments to the result returned by
>>> autoconf-config.guess.
>>> Your fix needs to go in the wrapper file.
>>> /Erik

Re: Configure broken on MIPS when uname returns mipsel or mips64el

[Ao Qi]

Could someone help to create a bug etc?

Thanks,
Ao Qi
Magnus Ihse Bursie  于2018年5月25日周五 下午
3:42写道：

> On 2018-05-24 03:08, Ao Qi wrote:

> Hi Erik,

> Thanks for your comments. I made a new patch:

> $ hg diff
> diff -r 31361382634b make/autoconf/build-aux/config.guess
> --- a/make/autoconf/build-aux/config.guess Tue May 22 10:08:04 2018 -0700
> +++ b/make/autoconf/build-aux/config.guess Thu May 24 09:07:17 2018 +0800
> @@ -86,6 +86,17 @@
>  fi
>fi

> +# Test and fix little endian MIPS.
> +if [ "x$OUT" = x ]; then
> +  if [ `uname -s` = Linux ]; then
> +if [ `uname -m` = mipsel ]; then
> +  OUT=mipsel-unknown-linux-gnu
> +elif [ `uname -m` = mips64el ]; then
> +  OUT=mips64el-unknown-linux-gnu
> +fi
> +  fi
> +fi
> +
># Test and fix cpu on Macosx when C preprocessor is not on the path
>echo $OUT | grep i386-apple-darwin > /dev/null 2> /dev/null
>if test $? = 0; then


> Looks good to me.

> /Magnus

> Cheers,
> Ao Qi

> 2018-05-24 0:19 GMT+08:00 Erik Joelsson :

> Hello Ao Qi,

> Due to licensing reasons, we are unable to directly update the
> autoconf-config.guess file. Instead we have the wrapper, config.guess in
> which we make adjustments to the result returned by autoconf-config.guess.
> Your fix needs to go in the wrapper file.

> /Erik



> On 2018-05-23 03:18, Ao Qi wrote:

> Hi all,
> I tried to configure jdk/jdk on MIPS, but I failed. The output of
> configure:
> ...
> checking for pandoc... no
> checking build system type...
> /home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess: unable
> to guess system type

> This script, last modified 2012-02-10, has failed to recognize
> the operating system you are using. It is advised that you
> download the most up to date version of the config scripts from



http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
> and


http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

> If the version you run
> (/home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess) is
> already up to date, please
> send the following data and any information you think might be
> pertinent to  in order to provide the needed
> information to handle your system.

> config.guess timestamp = 2012-02-10

> uname -m = mips64el
> uname -r = 3.10.0-693.5.2.ns7.032.mips64el
> uname -s = Linux
> uname -v = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017

> /usr/bin/uname -p = mips64el
> /bin/uname -X =

> hostinfo   =
> /bin/universe  =
> /usr/bin/arch -k   =
> /bin/arch  = mips64el
> /usr/bin/oslevel   =
> /usr/convex/getsysinfo =

> UNAME_MACHINE = mips64el
> UNAME_RELEASE = 3.10.0-693.5.2.ns7.032.mips64el
> UNAME_SYSTEM  = Linux
> UNAME_VERSION = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017
> configure: error: cannot guess build type; you must specify one
> configure exiting with result code 1
> ...

> I think the reason is that uname returns mips64el.
> autoconf-config.guess can handle mips and mips64, but cannot handle
> mipsel and mips64el.
> I made a patch to pass the configure:

> $ hg diff
> diff -r 31361382634b make/autoconf/build-aux/autoconf-config.guess
> --- a/make/autoconf/build-aux/autoconf-config.guess Tue May 22
> 10:08:04 2018 -0700
> +++ b/make/autoconf/build-aux/autoconf-config.guess Wed May 23
> 18:06:52 2018 +0800
> @@ -977,6 +977,9 @@
>  eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'`
>  test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; }
>      ;;
> +mipsel:Linux:*:* | mips64el:Linux:*:*)
> + echo ${UNAME_MACHINE}-unknown-linux-gnu
> + exit ;;
> or32:Linux:*:*)
>  echo ${UNAME_MACHINE}-unknown-linux-gnu
>  exit ;;


> I think ppc has the same problem, but it is fixed in
> make/autoconf/build-aux/config.guess.

> Thanks,
> Ao Qi

Re: Configure broken on MIPS when uname returns mipsel or mips64el

[Ao Qi]

Hi Erik,

Thanks for your comments. I made a new patch:

$ hg diff
diff -r 31361382634b make/autoconf/build-aux/config.guess
--- a/make/autoconf/build-aux/config.guess Tue May 22 10:08:04 2018 -0700
+++ b/make/autoconf/build-aux/config.guess Thu May 24 09:07:17 2018 +0800
@@ -86,6 +86,17 @@
   fi
 fi

+# Test and fix little endian MIPS.
+if [ "x$OUT" = x ]; then
+  if [ `uname -s` = Linux ]; then
+if [ `uname -m` = mipsel ]; then
+  OUT=mipsel-unknown-linux-gnu
+elif [ `uname -m` = mips64el ]; then
+  OUT=mips64el-unknown-linux-gnu
+fi
+  fi
+fi
+
 # Test and fix cpu on Macosx when C preprocessor is not on the path
 echo $OUT | grep i386-apple-darwin > /dev/null 2> /dev/null
 if test $? = 0; then

Cheers,
Ao Qi

2018-05-24 0:19 GMT+08:00 Erik Joelsson <erik.joels...@oracle.com>:
> Hello Ao Qi,
>
> Due to licensing reasons, we are unable to directly update the
> autoconf-config.guess file. Instead we have the wrapper, config.guess in
> which we make adjustments to the result returned by autoconf-config.guess.
> Your fix needs to go in the wrapper file.
>
> /Erik
>
>
>
> On 2018-05-23 03:18, Ao Qi wrote:
>>
>> Hi all,
>> I tried to configure jdk/jdk on MIPS, but I failed. The output of
>> configure:
>> ...
>> checking for pandoc... no
>> checking build system type...
>> /home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess: unable
>> to guess system type
>>
>> This script, last modified 2012-02-10, has failed to recognize
>> the operating system you are using. It is advised that you
>> download the most up to date version of the config scripts from
>>
>>
>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
>> and
>>
>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
>>
>> If the version you run
>> (/home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess) is
>> already up to date, please
>> send the following data and any information you think might be
>> pertinent to <config-patc...@gnu.org> in order to provide the needed
>> information to handle your system.
>>
>> config.guess timestamp = 2012-02-10
>>
>> uname -m = mips64el
>> uname -r = 3.10.0-693.5.2.ns7.032.mips64el
>> uname -s = Linux
>> uname -v = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017
>>
>> /usr/bin/uname -p = mips64el
>> /bin/uname -X =
>>
>> hostinfo   =
>> /bin/universe  =
>> /usr/bin/arch -k   =
>> /bin/arch  = mips64el
>> /usr/bin/oslevel   =
>> /usr/convex/getsysinfo =
>>
>> UNAME_MACHINE = mips64el
>> UNAME_RELEASE = 3.10.0-693.5.2.ns7.032.mips64el
>> UNAME_SYSTEM  = Linux
>> UNAME_VERSION = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017
>> configure: error: cannot guess build type; you must specify one
>> configure exiting with result code 1
>> ...
>>
>> I think the reason is that uname returns mips64el.
>> autoconf-config.guess can handle mips and mips64, but cannot handle
>> mipsel and mips64el.
>> I made a patch to pass the configure:
>>
>> $ hg diff
>> diff -r 31361382634b make/autoconf/build-aux/autoconf-config.guess
>> --- a/make/autoconf/build-aux/autoconf-config.guess Tue May 22
>> 10:08:04 2018 -0700
>> +++ b/make/autoconf/build-aux/autoconf-config.guess Wed May 23
>> 18:06:52 2018 +0800
>> @@ -977,6 +977,9 @@
>>    eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'`
>>test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; }
>>;;
>> +mipsel:Linux:*:* | mips64el:Linux:*:*)
>> + echo ${UNAME_MACHINE}-unknown-linux-gnu
>> + exit ;;
>>   or32:Linux:*:*)
>>echo ${UNAME_MACHINE}-unknown-linux-gnu
>>exit ;;
>>
>>
>> I think ppc has the same problem, but it is fixed in
>> make/autoconf/build-aux/config.guess.
>>
>> Thanks,
>> Ao Qi
>
>

Configure broken on MIPS when uname returns mipsel or mips64el

[Ao Qi]

Hi all,
I tried to configure jdk/jdk on MIPS, but I failed. The output of configure:
...
checking for pandoc... no
checking build system type...
/home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess: unable
to guess system type

This script, last modified 2012-02-10, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

  
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
  
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

If the version you run
(/home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess) is
already up to date, please
send the following data and any information you think might be
pertinent to <config-patc...@gnu.org> in order to provide the needed
information to handle your system.

config.guess timestamp = 2012-02-10

uname -m = mips64el
uname -r = 3.10.0-693.5.2.ns7.032.mips64el
uname -s = Linux
uname -v = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017

/usr/bin/uname -p = mips64el
/bin/uname -X =

hostinfo   =
/bin/universe  =
/usr/bin/arch -k   =
/bin/arch  = mips64el
/usr/bin/oslevel   =
/usr/convex/getsysinfo =

UNAME_MACHINE = mips64el
UNAME_RELEASE = 3.10.0-693.5.2.ns7.032.mips64el
UNAME_SYSTEM  = Linux
UNAME_VERSION = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017
configure: error: cannot guess build type; you must specify one
configure exiting with result code 1
...

I think the reason is that uname returns mips64el.
autoconf-config.guess can handle mips and mips64, but cannot handle
mipsel and mips64el.
I made a patch to pass the configure:

$ hg diff
diff -r 31361382634b make/autoconf/build-aux/autoconf-config.guess
--- a/make/autoconf/build-aux/autoconf-config.guess Tue May 22
10:08:04 2018 -0700
+++ b/make/autoconf/build-aux/autoconf-config.guess Wed May 23
18:06:52 2018 +0800
@@ -977,6 +977,9 @@
  eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'`
  test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; }
  ;;
+mipsel:Linux:*:* | mips64el:Linux:*:*)
+ echo ${UNAME_MACHINE}-unknown-linux-gnu
+ exit ;;
 or32:Linux:*:*)
  echo ${UNAME_MACHINE}-unknown-linux-gnu
  exit ;;


I think ppc has the same problem, but it is fixed in
make/autoconf/build-aux/config.guess.

Thanks,
Ao Qi

Re: [NEW BUG]: Configure broken on MIPS

[Ao Qi]

Thank you very much David:)

2018-03-26 12:38 GMT+08:00 David Holmes <david.hol...@oracle.com>:
> https://bugs.openjdk.java.net/browse/JDK-8200213
>
> Sponsoring.
>
> David
> -
>
>
> On 26/03/2018 12:50 PM, Ao Qi wrote:
>>
>> 2018-03-23 18:05 GMT+08:00 David Holmes <david.hol...@oracle.com>:
>>>
>>> On 23/03/2018 7:54 PM, Magnus Ihse Bursie wrote:
>>>>
>>>>
>>>>
>>>> On 2018-03-23 09:55, David Holmes wrote:
>>>>>
>>>>>
>>>>> On 23/03/2018 6:46 PM, Magnus Ihse Bursie wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2018-03-23 06:22, David Holmes wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi Thomas,
>>>>>>>
>>>>>>> On 23/03/2018 2:55 PM, Thomas Stüfe wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> would it not be pragmatic to accept Ao's patch - it looks fine to me
>>>>>>>> -
>>>>>>>> since it certainly would not make matters worse. And let Magnus
>>>>>>>> follow up
>>>>>>>> with a cleanup change later?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Well I hope Magnus's change is forthcoming.
>>>>>>
>>>>>>
>>>>>> It might be some time still. I'm working on a complete overhaul of all
>>>>>> CFLAGS and LDFLAGS, where this is a part of that picture, but I was
>>>>>> not
>>>>>> planning on addressing just this thing urgently.
>>>>>>
>>>>>> So, I think this patch will do for now. It solves the immediate
>>>>>> problem
>>>>>> for MIPS, and I can come back and make a cleaner solution later on.
>>>>>
>>>>>
>>>>>
>>>>> Isn't the best quick fix one that only adds -m64 for x86? I recall  a
>>>>> report that arm32 is similarly broken.
>>>>
>>>>
>>>> Not really, because this is also needed on some other platforms, at
>>>> least
>>>> s390x, as I recall. (This was the reason it was originally added.)
>>>
>>>
>>>
>>> According to gcc docs there are 4 archs that use m64 and we only care
>>> about
>>> 2 of them:
>>>
>>> m64: SPARC Options
>>> m64: S/390 and zSeries Options
>>> m64: RS/6000 and PowerPC Options
>>> m64: i386 and x86-64 Options
>>>
>>> But you need to know whether you are dealing with S390 or S390x as m64
>>> implies zSeries.
>>>
>>> Ao will need a sponsor to create a bug etc regardless of which way this
>>> goes.
>>>
>>
>> Is it possible to accept my patch first (before a perfect all-platform
>> solution is made)? If yes, could someone help to create a bug etc?
>> Thanks!
>>
>>> My week is over. :)
>>>
>>> Cheers,
>>> David
>>>
>>>
>>>> /Magnus
>>>>
>>>>>
>>>>> David
>>>>> -
>>>>>
>>>>>>> AFAICS it's as easy to write this only for x86 as it is to exclude it
>>>>>>> for non x86. Honestly I don't know why the Aarch64 patch was done the
>>>>>>> way it
>>>>>>> was - there must be some subtlety here that I'm not aware of.
>>>>>>
>>>>>>
>>>>>> I think it was just the smallest patch that worked for the aarch64
>>>>>> platform. I didn't spend time arguing about the fix, since it is
>>>>>> supposed to
>>>>>> be short-lived anyway.
>>>>>>
>>>>>> /Magnus
>>>>
>>>>
>>>>
>>>
>

Re: [NEW BUG]: Configure broken on MIPS

[Ao Qi]

2018-03-23 18:05 GMT+08:00 David Holmes :
> On 23/03/2018 7:54 PM, Magnus Ihse Bursie wrote:
>>
>>
>> On 2018-03-23 09:55, David Holmes wrote:
>>>
>>> On 23/03/2018 6:46 PM, Magnus Ihse Bursie wrote:


 On 2018-03-23 06:22, David Holmes wrote:
>
> Hi Thomas,
>
> On 23/03/2018 2:55 PM, Thomas Stüfe wrote:
>>
>> Hi David,
>>
>> would it not be pragmatic to accept Ao's patch - it looks fine to me -
>> since it certainly would not make matters worse. And let Magnus follow up
>> with a cleanup change later?
>
>
> Well I hope Magnus's change is forthcoming.

 It might be some time still. I'm working on a complete overhaul of all
 CFLAGS and LDFLAGS, where this is a part of that picture, but I was not
 planning on addressing just this thing urgently.

 So, I think this patch will do for now. It solves the immediate problem
 for MIPS, and I can come back and make a cleaner solution later on.
>>>
>>>
>>> Isn't the best quick fix one that only adds -m64 for x86? I recall  a
>>> report that arm32 is similarly broken.
>>
>> Not really, because this is also needed on some other platforms, at least
>> s390x, as I recall. (This was the reason it was originally added.)
>
>
> According to gcc docs there are 4 archs that use m64 and we only care about
> 2 of them:
>
> m64: SPARC Options
> m64: S/390 and zSeries Options
> m64: RS/6000 and PowerPC Options
> m64: i386 and x86-64 Options
>
> But you need to know whether you are dealing with S390 or S390x as m64
> implies zSeries.
>
> Ao will need a sponsor to create a bug etc regardless of which way this
> goes.
>

Is it possible to accept my patch first (before a perfect all-platform
solution is made)? If yes, could someone help to create a bug etc?
Thanks!

> My week is over. :)
>
> Cheers,
> David
>
>
>> /Magnus
>>
>>>
>>> David
>>> -
>>>
> AFAICS it's as easy to write this only for x86 as it is to exclude it
> for non x86. Honestly I don't know why the Aarch64 patch was done the way 
> it
> was - there must be some subtlety here that I'm not aware of.

 I think it was just the smallest patch that worked for the aarch64
 platform. I didn't spend time arguing about the fix, since it is supposed 
 to
 be short-lived anyway.

 /Magnus
>>
>>
>

Re: [NEW BUG]: Configure broken on MIPS

[Ao Qi]

>>
>> It might be some time still. I'm working on a complete overhaul of all
>> CFLAGS and LDFLAGS, where this is a part of that picture, but I was not
>> planning on addressing just this thing urgently.
>>
>> So, I think this patch will do for now. It solves the immediate problem
>> for MIPS, and I can come back and make a cleaner solution later on.
>
>
> Isn't the best quick fix one that only adds -m64 for x86? I recall  a report
> that arm32 is similarly broken.

I had a look at man gcc. It seems that at least -m64 is for S/390 and
zSeries, SPARC , RS/6000 and PowerPC, and x86.

>
> David
> -
>
>

Re: [NEW BUG]: Configure broken on MIPS

[Ao Qi]

So what should be the next? Is that another problem, or should the
MIPS broken configure be fixed together?

2018-03-23 5:04 GMT+08:00 David Holmes <david.hol...@oracle.com>:
> On 23/03/2018 12:13 AM, Erik Joelsson wrote:
>>
>> Hello,
>>
>> The fix looks correct, but I'm starting to think that maybe the
>> conditional should be inverted and instead list the architectures that
>> actually use -m64? It seems a whole lot of them don't.
>
>
> Magnus indicated he was working on a better solution when he put in the
> quick-fix check for Aarch64. Yes this should only add -m64 on compilers and
> platforms that support it.
>
> David
> -
>
>
>> /Erik
>>
>>
>> On 2018-03-21 23:24, Ao Qi wrote:
>>>
>>> Hi,
>>>
>>> I found configure of http://hg.openjdk.java.net/jdk/jdk was broken on
>>> MIPS.
>>>
>>> the output of configure:
>>> ...
>>> configure: Using default toolchain gcc (GNU Compiler Collection)
>>> checking for gcc... /usr/bin/gcc
>>> checking resolved symbolic links for CC...
>>> /usr/bin/mips64el-linux-gnuabi64-gcc-6
>>> configure: Using gcc C compiler version 6.3.0 [gcc (Debian 6.3.0-18)
>>> 6.3.0 20170516]
>>> checking whether the C compiler works... no
>>> configure: error: in `/home/loongson/aoqi/jdk':
>>> configure: error: C compiler cannot create executables
>>> See `config.log' for more details
>>> configure exiting with result code 77
>>> ...
>>>
>>> the related content of config.log:
>>> ...
>>> configure:35256: checking whether the C compiler works
>>> configure:35278: /usr/bin/gcc -m64-m64   conftest.c  >&5
>>> gcc: error: unrecognized command line option '-m64'
>>> gcc: error: unrecognized command line option '-m64'
>>> configure:35282: $? = 1
>>> configure:35320: result: no
>>> configure: failed program was:
>>> | /* confdefs.h */
>>> | #define PACKAGE_NAME "OpenJDK"
>>> | #define PACKAGE_TARNAME "openjdk"
>>> | #define PACKAGE_VERSION "jdk9"
>>> | #define PACKAGE_STRING "OpenJDK jdk9"
>>> | #define PACKAGE_BUGREPORT "build-dev@openjdk.java.net"
>>> | #define PACKAGE_URL "http://openjdk.java.net;
>>> | /* end confdefs.h.  */
>>> |
>>> | int
>>> | main ()
>>> | {
>>> |
>>> |   ;
>>> |   return 0;
>>> | }
>>> configure:35325: error: in `/home/loongson/aoqi/jdk':
>>> configure:35327: error: C compiler cannot create executables
>>> See `config.log' for more details
>>> ...
>>>
>>>
>>> I made a small patch to pass the configure:
>>>
>>> $ hg diff make/autoconf/flags.m4
>>> diff -r 3acb379b8672 make/autoconf/flags.m4
>>> --- a/make/autoconf/flags.m4 Thu Mar 22 08:09:51 2018 +0800
>>> +++ b/make/autoconf/flags.m4 Thu Mar 22 12:55:00 2018 +0800
>>> @@ -237,7 +237,11 @@
>>>   MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}"
>>> elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then
>>>   if test "x$OPENJDK_TARGET_CPU" != xaarch64 &&
>>> -test "x$OPENJDK_TARGET_CPU" != xarm; then
>>> +test "x$OPENJDK_TARGET_CPU" != xarm &&
>>> +test "x$OPENJDK_TARGET_CPU" != xmips &&
>>> +test "x$OPENJDK_TARGET_CPU" != xmipsel &&
>>> +test "x$OPENJDK_TARGET_CPU" != xmips64 &&
>>> +test "x$OPENJDK_TARGET_CPU" != xmips64el; then
>>> MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}"
>>>   fi
>>> fi
>>>
>>>
>>> I think this is the same problem with bug 8199052 and 8199152. Could
>>> someone help to review the change?
>>>
>>> Thanks,
>>> Ao Qi
>>
>>
>

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Ao Qi]

2018-03-22 6:41 GMT+08:00 John Paul Adrian Glaubitz
:
> On 03/22/2018 07:07 AM, Martin Buchholz wrote:
>> But for users, being able to bootstrap with an ancient jdk is definitely
>> convenient.
>
> Convenient is an understatement. Always enforcing the N-1 version to be
> used can be quite painful for downstream distributions. Rust upstream
> does the same thing and it becomes very frustrating when bootstrapping
> the compiler.
>
> When, for example, an architecture has fallen back a couple of releases
> of OpenJDK, I would have to go through the whole chain of 8->9->10->11
> to get the latest OpenJDK. I know that cross-compiling is possible, but
> it's not always the easiest option.
>

Indeed. I was trying to build OpenJDK 11 zero on MIPS. Because I only had
OpenJDK 8 binary as boot JDK, I have to build OpenJDK 9 first.
It is even more painful when I build OpenJDK 11 32 bits zero. Because I only
have 32-bit OpenJDK 6 as boot JDK, I have to build 7, 8, 9 and then 11.

> So, from a downstream perspective, allowing the oldest possible version
> is always a desirable feature to have. I do understand it though when
> OpenJDK 11 requires features from OpenJDK 10 which would rule out older
> versions completely.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[NEW BUG]: Configure broken on MIPS

[Ao Qi]

Hi,

I found configure of http://hg.openjdk.java.net/jdk/jdk was broken on MIPS.

the output of configure:
...
configure: Using default toolchain gcc (GNU Compiler Collection)
checking for gcc... /usr/bin/gcc
checking resolved symbolic links for CC...
/usr/bin/mips64el-linux-gnuabi64-gcc-6
configure: Using gcc C compiler version 6.3.0 [gcc (Debian 6.3.0-18)
6.3.0 20170516]
checking whether the C compiler works... no
configure: error: in `/home/loongson/aoqi/jdk':
configure: error: C compiler cannot create executables
See `config.log' for more details
configure exiting with result code 77
...

the related content of config.log:
...
configure:35256: checking whether the C compiler works
configure:35278: /usr/bin/gcc -m64-m64   conftest.c  >&5
gcc: error: unrecognized command line option '-m64'
gcc: error: unrecognized command line option '-m64'
configure:35282: $? = 1
configure:35320: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "OpenJDK"
| #define PACKAGE_TARNAME "openjdk"
| #define PACKAGE_VERSION "jdk9"
| #define PACKAGE_STRING "OpenJDK jdk9"
| #define PACKAGE_BUGREPORT "build-dev@openjdk.java.net"
| #define PACKAGE_URL "http://openjdk.java.net;
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:35325: error: in `/home/loongson/aoqi/jdk':
configure:35327: error: C compiler cannot create executables
See `config.log' for more details
...


I made a small patch to pass the configure:

$ hg diff make/autoconf/flags.m4
diff -r 3acb379b8672 make/autoconf/flags.m4
--- a/make/autoconf/flags.m4 Thu Mar 22 08:09:51 2018 +0800
+++ b/make/autoconf/flags.m4 Thu Mar 22 12:55:00 2018 +0800
@@ -237,7 +237,11 @@
 MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}"
   elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then
 if test "x$OPENJDK_TARGET_CPU" != xaarch64 &&
-test "x$OPENJDK_TARGET_CPU" != xarm; then
+test "x$OPENJDK_TARGET_CPU" != xarm &&
+test "x$OPENJDK_TARGET_CPU" != xmips &&
+test "x$OPENJDK_TARGET_CPU" != xmipsel &&
+test "x$OPENJDK_TARGET_CPU" != xmips64 &&
+test "x$OPENJDK_TARGET_CPU" != xmips64el; then
   MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}"
 fi
   fi


I think this is the same problem with bug 8199052 and 8199152. Could
someone help to review the change?

Thanks,
Ao Qi

Re: [PATCH] Fail to build zero on x86

[Ao Qi]

Hi John,

Thanks!
PS: It seems that the build begins to fail after this changeset:
http://hg.openjdk.java.net/jdk/jdk/rev/fb290fd1f9d4

Ao Qi

2018-01-10 7:58 GMT+08:00 John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de>:

> On 01/10/2018 12:27 AM, John Paul Adrian Glaubitz wrote:> which is the
> same configure line that the openjdk-7/8/9/10 packages in Debian> use.
> Sounds like a good
> idea to fix this warning though.
> PS: I'm happy to review and sponsor your change. But tomorrow :).
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

Re: [PATCH] Fail to build zero on x86

[Ao Qi]

Hi John,


> I assume that you eventually want to build OpenJDK for MIPS, correct (from
> your
> email address)? If yes, there are actually two additional patches
> necessary to
> get Zero to build on MIPS. In particular, jvmsigs cannot encode all signals
> found on MIPS. I should finally get around to work on this.
>
>
Thanks for your information. We have a Jenkins server to build OpenJDK
8/9/10 on x86 and MIPS (loongson3a), and I have already used those
patches:) Hope those patches can be submitted to upstream.

Ao Qi