jdk9/hs repo build issues for s390x

Fri Nov 25 18:12:26 UTC 2016

On Fri, Nov 25, 2016 at 3:51 PM, Shahid Shaikh <shahid at us.ibm.com> wrote:
>
> Hi Volker,
>
> It looks like the issue here may be related to single processor VM. We tried building OpenJDK9 on multi processor VM Ubuntu 16.04 x86 VM today and build was successful.
>
> We can see following difference in 'configure' logs:
> Older VM configure log:
> Build performance summary:
> * Cores to use: 1
> * Memory limit: 1898 MB
>
> New VM configure log:
> Build performance summary:
> * Cores to use: 2
> * Memory limit: 3951 MB
>
> Could you please verify that you get the same build failure for single processor machine?
>
Hi Shahid,

I don't believe this is an issue with single processor machines. In
the end you can always build with "JOBS=1" which should give you the
same results like on a single core machine. I actually don't have a
single core machine but I've just retried the build with "JOBS=1" and
it still succeeded. Also, as far as I remember, you could finally
build on a Linux/s390 single core machine after we had fixed the
corresponding s390 related bug. Anyway, I'm happy that you can finally
build on x86 :)

Regards,
Volker

>
> Thanks & Regards,
> Shahid
>
> Volker Simonis ---11/23/2016 06:54:15 PM---Hi Shahid, the first thing I see in configure log is:
>
> From: Volker Simonis <volker.simonis at gmail.com>
> To: Shahid Shaikh/Austin/Contr/IBM at IBMUS
> Cc: Amod Borkar/Austin/Contr/IBM at IBMUS, Cindy Lee <cinderel at ca.ibm.com>, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, "Schmidt, Lutz" <lutz.schmidt at sap.com>, "Doerr, Martin" <martin.doerr at sap.com>, "s390x-port-dev at openjdk.java.net" <s390x-port-dev at openjdk.java.net>
> Date: 11/23/2016 06:54 PM
>
>
> Subject: Re: jdk9/hs repo build issues for s390x
> ________________________________
>
>
>
> Hi Shahid,
>
> the first thing I see in configure log is:
>
> WARNING: The result of this configuration has overridden an older
> configuration. You *should* run 'make clean' to make sure you get a
> proper build. Failure to do so might result in strange build problems.
>
> So you should do "make clean" before building. But maybe this is only there because you've re-executed configure after the build.
>
> If you have build problems, I always recommend to use  LOG=debug JOBS=1 (i.e. 'make all LOG=debug JOBS=1'). This will give you a much more detailed trace of what's going on.
>
> From your build log file I can see that linking FPRegs fails in your case:
>
> Creating FPRegs from 1 file(s)
> /SSWorkspace/OpenJDK9/build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: In function `closeHandle':
> /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:48: undefined reference to `dlclose'
> /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:49: undefined reference to `dlerror'
> /SSWorkspace/OpenJDK9/build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: In function `loadJVM':
> /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:69: undefined reference to `dlopen'
> /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:77: undefined reference to `dlsym'
> /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:88: undefined reference to `dlerror'
> collect2: error: ld returned 1 exit status
>
> On my machine the corresponding commands look as follows (if building with LOG=debug):
>
> Compiling exeFPRegs.c (for FPRegs)
> ( /usr/bin/gcc -Wall -Wextra -Wno-unused -Wno-unused-parameter -Wformat=2 -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LITTLE_ENDIAN -DLINUX -D_LP64=1 -DARCH='"amd64"' -Damd64 -DDEBUG -I/priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/modules_include/java.base -I/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/share/native/include -I/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/linux/native/include -I/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/unix/native/include -I/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/share/native/libjava -I/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/unix/native/libjava -fno-strict-aliasing -g -fstack-protector-all --param ssp-buffer-size=1 -Werror -g -Werror -O0 -DTHIS_FILE='"exeFPRegs.c"' -c -MMD -MF /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.d -o /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o /usr/work/d046063/OpenJDK/jdk9-hs/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c > >(/usr/bin/tee /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o.log) 2> >(/usr/bin/tee /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o.log >&2) || ( exitcode=$? && /bin/cp /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o.log /priv/d046063/OpenJDK/output-jdk9-hs-dbg/make-support/failure-logs/support_test_hotspot_jtreg_native_support_exeFPRegs_exeFPRegs.o.log && exit $exitcode ) )
>
> Linking executable FPRegs
> ( /usr/bin/gcc -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,now -Wl,-z,relro -Wl,--allow-shlib-undefined -L/priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/modules_libs/java.base/amd64 -L/priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/modules_libs/java.base/amd64/server -o /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/bin/FPRegs /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o -ldl > >(/usr/bin/tee /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/BUILD_TEST_FPRegs_link.log) 2> >(/usr/bin/tee /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/BUILD_TEST_FPRegs_link.log >&2) || ( exitcode=$? && /bin/cp /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/BUILD_TEST_FPRegs_link.log /priv/d046063/OpenJDK/output-jdk9-hs-dbg/make-support/failure-logs/support_test_hotspot_jtreg_native_support_exeFPRegs_BUILD_TEST_FPRegs_link.log && exit $exitcode ) )
>
> Linking exeFPRegs.o into FPRegs seems actually quite trivial. It uses -ldl which contains the various dl* you are missing.
>
> Can you please do a new, clean build with LOG=debug. If you still get the same problem can you please try the two two command lines (i.e. compiling exeFPRegs.c and linking exeFPRegs.o) manually on the command line.
>
> Regards,
> Volker
>
>
> On Tue, Nov 22, 2016 at 2:49 PM, Shahid Shaikh <shahid at us.ibm.com> wrote:
>
> Hi Martin,
>
> Please find attached files for the 'configure' and 'make all' command logs (for OpenJDK9 build on Ubuntu 16.04 x86).
>
> Following are the build steps we are executing:
> apt-get install mercurial -y
> hg clone http://hg.openjdk.java.net/jdk9/hs OpenJDK9
> cd OpenJDK9/
> bash ./get_source.sh
> apt-get install libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev libasound2-dev libfreetype6-dev libcups2-dev -y
> apt-get install openjdk-8-jdk -y
> apt-get install zip unzip -y
> apt-get install libffi-dev -y
> unset JAVA_HOME
> export LANG=C
> export PATH="/usr/lib/jvm/java-8-openjdk-amd64/bin:${PATH}"
> bash ./configure --with-jvm-variants=server --disable-warnings-as-errors
> make all
>
> Please let us know if we're missing anything.
>
> Thanks & Regards,
> Shahid
>
> (See attached file: Ubuntu16.04_x86_OpenJDK9_configure.log)(See attached file: Ubuntu16.04_x86_OpenJDK9_make all.log)
>
> Volker Simonis ---11/21/2016 07:31:36 PM---On Fri, Nov 18, 2016 at 2:38 PM, Shahid Shaikh <shahid at us.ibm.com> wrote: > Hi Martin,
>
> From: Volker Simonis <volker.simonis at gmail.com>
> To: Shahid Shaikh/Austin/Contr/IBM at IBMUS
> Cc: "Doerr, Martin" <martin.doerr at sap.com>, Amod Borkar/Austin/Contr/IBM at IBMUS, Cindy Lee <cinderel at ca.ibm.com>, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, "Schmidt, Lutz" <lutz.schmidt at sap.com>, "s390x-port-dev at openjdk.java.net" <s390x-port-dev at openjdk.java.net>
> Date: 11/21/2016 07:31 PM
>
>
> Subject: Re: jdk9/hs repo build issues for s390x
> ________________________________
>
>
>
>
>
> On Fri, Nov 18, 2016 at 2:38 PM, Shahid Shaikh <shahid at us.ibm.com> wrote:
>
> Hi Martin,
>
> Apologies for late reply. We were working on testing the new 'jdk9/hs' repository where the patch has been pushed. We tested the build on RHEL7.2 and SLES12SP1 s390x VMs and the build is successful.
>
> >> Do you know if it is the same on single-processor x86 systems?
> The x86 VM which we used for testing is multi-processor.
>
> @Volker/Martin: Could you please give us some insight into 'jdk9/hs' repository? Because when we build OpenJDK9 from 'jdk9/jdk9' (JDK9 master) repository on Ubuntu x86 VM, the build is successful. However when we build 'jdk9/hs' on Ubuntu x86 VM, the build is failing.
>
>
>
> I don't understand this. I've just build a fresh version of jdk9/hs without any problems on my Ubuntu 16.04/x86_64 machine (bot 'images' and 'all' targets worked).
>
> Can you please describe you problem a little bit more detailed?
>
>
> So it looks like 'jdk9/hs' repository may not be in sync with JDK9 master repository. So we are not able to build OpenJDK9 for s390x for z system.
>
> Please check and let us know if you have any queries/comments.
>
> Thanks & Regards,
> Shahid
>
> "Doerr, Martin" ---11/15/2016 04:56:31 PM---Hi Shahid, the patch is part of the following change:
>
> From: "Doerr, Martin" <martin.doerr at sap.com>
> To: Shahid Shaikh/Austin/Contr/IBM at IBMUS
> Cc: Amod Borkar/Austin/Contr/IBM at IBMUS, Cindy Lee <cinderel at ca.ibm.com>, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, "Schmidt, Lutz" <lutz.schmidt at sap.com>, "s390x-port-dev at openjdk.java.net" <s390x-port-dev at openjdk.java.net>, Volker Simonis <volker.simonis at gmail.com>
> Date: 11/15/2016 04:56 PM
>
>
> Subject: RE: jdk9/hs repo build issues for s390x
>
> ________________________________
>
>
>
> Hi Shahid,
>
> the patch is part of the following change:
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/17a959a33da5
>
> It was pushed a couple of days ago.
>
> I was also wondering about the following part of the hs_err file you had sent:
> Threads with active compile tasks:
> C1 CompilerThread1 5 1 java.lang.StringLatin1::charAt (28 bytes)
> C1 CompilerThread0 4 1 java.lang.String::charAt (25 bytes)
>
> We should have 1 C1 and 1 C2 compiler thread on single-processor systems. Maybe the message is wrong.
> Do you know if it is the same on single-processor x86 systems?
>
> Best regards,
> Martin
>
> From: Shahid Shaikh [mailto:shahid at us.ibm.com]
> Sent: Dienstag, 15. November 2016 11:52
> To: Doerr, Martin <martin.doerr at sap.com>
> Cc: Amod Borkar <aborkar at us.ibm.com>; Cindy Lee <cinderel at ca.ibm.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Schmidt, Lutz <lutz.schmidt at sap.com>; s390x-port-dev at openjdk.java.net; Volker Simonis <volker.simonis at gmail.com>
> Subject: RE: jdk9/hs repo build issues for s390x
>
> Hi Martin,
>
> With the given patch, our build is successful for single-processor z system. We tried the build on RHEL7.2 and SLES12SP1 distributions.
>
> Please let us know when this patch will get merged to the jdk9/hs repository.
>
> Regards,
> Shahid
>
> "Doerr, Martin" ---11/09/2016 08:57:25 PM---Hi Shahid, if the issue on Ubuntu is still the single-processor LPAR, you can try the following patc
>
> From: "Doerr, Martin" <martin.doerr at sap.com>
> To: Shahid Shaikh/Austin/Contr/IBM at IBMUS, Volker Simonis <volker.simonis at gmail.com>
> Cc: Amod Borkar/Austin/Contr/IBM at IBMUS, Cindy Lee <cinderel at ca.ibm.com>, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, "Schmidt, Lutz" <lutz.schmidt at sap.com>, "s390x-port-dev at openjdk.java.net" <s390x-port-dev at openjdk.java.net>
> Date: 11/09/2016 08:57 PM
> Subject: RE: jdk9/hs repo build issues for s390x
>
> ________________________________
>
>
>
>
> Hi Shahid,
>
> if the issue on Ubuntu is still the single-processor LPAR, you can try the following patch:
> http://cr.openjdk.java.net/~mdoerr/s390_singleprocessor.patch
>
> @Goetz: Please add this to the z fixes change if it resolves the issue. (Need feedback from Shahid.)
>
> Best regards,
> Martin
>
>
> From: Shahid Shaikh [mailto:shahid at us.ibm.com]
> Sent: Mittwoch, 9. November 2016 15:49
> To: Volker Simonis <volker.simonis at gmail.com>
> Cc: Amod Borkar <aborkar at us.ibm.com>; Cindy Lee <cinderel at ca.ibm.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Schmidt, Lutz <lutz.schmidt at sap.com>; Doerr, Martin <martin.doerr at sap.com>; s390x-port-dev at openjdk.java.net
> Subject: Re: jdk9/hs repo build issues for s390x
>
> Hi Volker,
>
> As per the suggestion from Martin, we tried building OpenJDK9 on multi-processor z systems and the build is successful on RHEL7.2 and SLES12SP1. However the build is still failing for Ubuntu 16.04 distribution.
>
> Please let us know what else we can try for Ubuntu.
>
> Thanks & Regards,
> Shahid
>
> Volker Simonis ---11/08/2016 07:07:11 PM---On Tue, Nov 8, 2016 at 9:53 AM, Shahid Shaikh <shahid at us.ibm.com> wrote: > Hi Volker,
>
> From: Volker Simonis <volker.simonis at gmail.com>
> To: Shahid Shaikh/Austin/Contr/IBM at IBMUS
> Cc: Amod Borkar/Austin/Contr/IBM at IBMUS, Cindy Lee <cinderel at ca.ibm.com>, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, "Schmidt, Lutz" <lutz.schmidt at sap.com>, "Doerr, Martin" <martin.doerr at sap.com>, "s390x-port-dev at openjdk.java.net" <s390x-port-dev at openjdk.java.net>
> Date: 11/08/2016 07:07 PM
> Subject: Re: jdk9/hs repo build issues for s390x
>
> ________________________________
>
>
>
>
>
>
>
> On Tue, Nov 8, 2016 at 9:53 AM, Shahid Shaikh <shahid at us.ibm.com> wrote:
>
> Hi Volker,
>
> Good observation :)
>
> This difference is because we are using Docker containers to test OpenJDK build. The hs_err file which we sent is extracted from a RHEL7.2 docker container running on Ubuntu 16.04 host. As you said correctly, the issue is not related. We can confirm that we are able to reproduce the same on RHEL7.2 host VM.
>
>
> Thanks for the explanation!
> We never saw something similar before but it's good to know where it stems from. One never stops learning :)
>
> Regards,
> Volker
>
> As per suggestion from Martin Doerr, we are trying to build OpenJDK9 on a multi-processor z system. We will update you once we have the results.
>
> Thanks & Regards,
> Shahid
>
> Volker Simonis ---11/08/2016 01:53:57 PM---Hi Shahid, it is surely not related to this issue but it would be highly
>
> From: Volker Simonis <volker.simonis at gmail.com>
> To: Shahid Shaikh/Austin/Contr/IBM at IBMUS
> Cc: "Schmidt, Lutz" <lutz.schmidt at sap.com>, Amod Borkar/Austin/Contr/IBM at IBMUS, Cindy Lee <cinderel at ca.ibm.com>, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, "Doerr, Martin" <martin.doerr at sap.com>, "s390x-port-dev at openjdk.java.net" <s390x-port-dev at openjdk.java.net>
> Date: 11/08/2016 01:53 PM
>
>
> Subject: Re: jdk9/hs repo build issues for s390x
>
> ________________________________
>
>
>
>
>
> Hi Shahid,
>
> it is surely not related to this issue but it would be highly
> interesting to know what exact system you are running on. The system
> detection in the hs_err file looks reads really weird:
>
> OS:Red Hat Enterprise Linux Server release 7.2 (Maipo)
> uname:Linux 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:47:15 UTC 2016 s390x
>
> So you really have a RHEL 7.2 installation with a Ubuntu kernel?
>
> Thanks,
> Volker
>
>
> On Mon, Nov 7, 2016 at 5:26 PM, Shahid Shaikh <shahid at us.ibm.com> wrote:
> > Hi Volker/Lutz,
> >
> > Thanks for your help. Please find attached hs_err_pid48608.log and
> > replay_pid48608.log files. Also, the configure and build logs.
> >
> > Please find my comments inline.
> >
> > Thanks & Regards,
> > Shahid
> >
> > (See attached file: OpenJDK9_rhel7.2_build.log)(See attached file:
> > OpenJDK9_rhel7.2_configure.log)(See attached file: hs_err_pid30816.log)(See
> > attached file: replay_pid30816.log)
> >
> > "Schmidt, Lutz" ---11/07/2016 07:42:40 PM---Hi, the below error points to an
> > instruction pattern detection issue (what a
> >
> > From: "Schmidt, Lutz" <lutz.schmidt at sap.com>
> > To: Volker Simonis <volker.simonis at gmail.com>, Shahid
> > Shaikh/Austin/Contr/IBM at IBMUS, "Lindenmaier, Goetz"
> > <goetz.lindenmaier at sap.com>, "Doerr, Martin" <martin.doerr at sap.com>
> > Cc: "s390x-port-dev at openjdk.java.net" <s390x-port-dev at openjdk.java.net>,
> > Cindy Lee <cinderel at ca.ibm.com>, Amod Borkar/Austin/Contr/IBM at IBMUS
> > Date: 11/07/2016 07:42 PM
> > Subject: Re: jdk9/hs repo build issues for s390x
> >
> > ________________________________
> >
> >
> >
> > Hi,
> >
> >
> > the below error points to an instruction pattern detection issue (what a
> > complicated name :-)). There is a ³Call Far Patchable² at the examined
> > address, because
> > c0e5fffdd3c0 translates into BRASL R14,0xfffdd3c0
> > The detection code expects the BRASL to be prepended with a nop (0x0700).
> > Either, the nop isn¹t there or the examined address is incorrect (two
> > bytes too high).
> >
> > Im not sure if the hs_err_pid48608.log could help here. What we would need
> > is a storage dump/disassembly around the examined address.
> >
> > Regards, Lutz
> >
> >
> > On 04.11.16, 20:12, "s390x-port-dev on behalf of Volker Simonis"
> > <s390x-port-dev-bounces at openjdk.java.net on behalf of
> > volker.simonis at gmail.com> wrote:
> >
> >>On Fri, Nov 4, 2016 at 4:38 PM, Shahid Shaikh <shahid at us.ibm.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> We are trying to build OpenJDK9 for s390x from 'jdk9/hs' repository
> >>>(where
> >>> the s390x code changes has been merged). However build is failing with
> >>> following error:
> >>>
> >>> On RHEL7.2 / SLES12SP1:
> >>> Compiling 1 files for java.se.ee
> >>> Compiling 235 files for jdk.xml.ws
> >>> Note: Some input files use or override a deprecated API.
> >>> Note: Recompile with -Xlint:deprecation for details.
> >>> Note: Some input files use unchecked or unsafe operations.
> >>> Note: Recompile with -Xlint:unchecked for details.
> >>> Compiling 4 files for BUILD_JIGSAW_TOOLS
> >>> MacroAssembler::get_dest_of_call_far_patchable_at has a problem at
> >>> 0x2003009c900:
> >>> not a call_far_patchable: c0e5fffdd3c0e320 f0500004c0f40000, len = 8
> >>> Could not load hsdis-s390x.so; library not loadable; PrintAssembly is
> >>> disabled
> >>> #
> >>> # A fatal error has been detected by the Java Runtime Environment:
> >>> #
> >>> # Internal Error (macroAssembler_s390.cpp:2532), pid=48608, tid=48614
> >>> # Error: ShouldNotReachHere()
> >>> #
> >>> # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal
> >>> +0-2016-11-03-151506..OpenJDK9)
> >>> # Java VM: OpenJDK 64-Bit Server VM (9-internal
> >>> +0-2016-11-03-151506..OpenJDK9, mixed mode, tiered, compressed oops,
> >>>serial
> >>> gc, linux-s390x)
> >>> # Core dump will be written. Default location: Core dumps may be
> >>>processed
> >>> with "/usr/share/apport/apport %p %s %c %P" (or dumping
> >>> to /SSWorkspace/OpenJDK9/make/core.48608)
> >>> #
> >>> # An error report file with more information is saved as:
> >>> # /SSWorkspace/OpenJDK9/make/hs_err_pid48608.log
> >>> #
> >>> # Compiler replay data is saved as:
> >>> # /SSWorkspace/OpenJDK9/make/replay_pid48608.log
> >>> #
> >>
> >>Hi Shahid,
> >>
> >>sorry to hear you have problems with the port.
> >>
> >>Could you please send us the two /hs_err_pid48608.log and
> >>replay_pid48608.log files so we can further investigate the error.
> >>They will be stripped from the mailing list, but if you do a
> >>"reply-all" to this mail, my colleagues and I will get them.
> >>
> >>We've detected one problem with the port and currently do our nightly
> >>builds (see http://cr.openjdk.java.net/~simonis/ppc-aix-port/) with
> >>the attached patch. You could try it but it doesn't seems to be
> >>related to your problem.
> >>
> >>Could you please also send the output of configure along with the log
> >>files so we can see what tools you are using.
> >>
> >>> # If you would like to submit a bug report, please visit:
> >>> # http://bugreport.java.com/bugreport/crash.jsp
>
> >>> #
> >>> gmake[3]: ***
> >>>
> >>>[/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/jdk/_packa
> >>>ges_attribute.done]
> >>> Aborted (core dumped)
> >>> gmake[2]: *** [exploded-image-optimize] Error 1
> >>>
> >>> On Ubuntu 16.04:
> >>> Creating libTestJNI.so from 1 file(s)
> >>> Creating FPRegs from 1 file(s)
> >>> Creating invoke from 1 file(s)
> >>>
> >>>/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/tes
> >>>t/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o:
> >>> In function `closeHandle':
> >>>
> >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
> >>>Regs.c:48:
> >>> undefined reference to `dlclose'
> >>>
> >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
> >>>Regs.c:49:
> >>> undefined reference to `dlerror'
> >>>
> >>>/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/tes
> >>>t/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o:
> >>> In function `loadJVM':
> >>>
> >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
> >>>Regs.c:69:
> >>> undefined reference to `dlopen'
> >>>
> >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
> >>>Regs.c:77:
> >>> undefined reference to `dlsym'
> >>>
> >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
> >>>Regs.c:88:
> >>> undefined reference to `dlerror'
> >>> collect2: error: ld returned 1 exit status
> >>> JtregNative.gmk:111: recipe for target
> >>>
> >>>'/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/te
> >>>st/hotspot/jtreg/native/bin/FPRegs'
> >>> failed
> >>> make[3]: ***
> >>>
> >>>[/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/te
> >>>st/hotspot/jtreg/native/bin/FPRegs]
> >>> Error 1
> >>> make[2]: *** [build-test-hotspot-jtreg-native] Error 1
> >>> make[2]: *** Waiting for unfinished jobs....
> >>> make/Main.gmk:398: recipe for target 'build-test-hotspot-jtreg-native'
> >>> failed
> >>> Creating support/symbols/ct.sym
> >>>
> >>> ERROR: Build failed for target 'all' in configuration
> >>> 'linux-s390x-normal-server-release' (exit code 2)
> >>> Stopping sjavac server
> >>>
> >>
> &g t;>So this seems to be a different problem. It is a known bug that the
>
> >>tests are currently not completely working. Goetz still has a bug open
> >>for this (
> https://bugs.openjdk.java.net/browse/JDK-8166837) but you
>
> >>can already find a webrev which should fix the issue and which should
> >>hopefully be pushed soon here:
> >>
> >>
> http://cr.openjdk.java.net/~goetz/wr16/8166837-jtreg_fixes/jdk-wr.02
>
> >>
> >>Can you please try to just build the "images" target and report if
> >>that succeeds? If it does, you should find a complete image under
> >>images/jdk which you could use for testing.
> >>
> >
> > After applying the above code changes manually, the above error is gone for
> > Ubuntu 16.04 s390x build environment. However the 'make images' command is
> > still failing and now the error is similar to what we are getting for
> > RHEL7.2 and SLES12SP1 distributions.
> >
> >>If at least the "images" target succeeds on Ubuntu than the other
> >>build failure seems to be related to RHEL7.2 / SLES12SP1. Maybe they
> >>use another version of GCC which has some problems?
> >>
> >
> > Yes, the 'make' versions are different. Its '4.1' for Ubuntu 16.04 and
> > '3.82' for RHEL7.2.
> >
> >>Regards,
> >>Volker
> >>
> >>>
> >>> We are using following steps to build OpenJDK9:
> >>> hg clone http://hg.openjdk.java.net/jdk9/hs OpenJDK9
> >>> cd OpenJDK9
> >>> bash ./get_source.sh
> >>> unset JAVA_HOME
> >>> export LANG=C
> >>> export
> >>>
> >>>PATH="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b15.el7_2.s390x/bin:$
> >>> {PATH}"
> >>> bash ./configure --with-jvm-variants=server
> >>>--disable-warnings-as-errors
> >>> make all
> >>>
> >>
> >>That sounds reasonable.
> >>
> >>>
> >>> We tried same on x86 machine and got the same build failure.
> >>>
> >>
> >>That's strange. I just saw that we also use --with-jtreg on the
> >>configure command line which points to the latest version of JTreg
> >>we've built. Maybe that's the problem if you have build failures on
> >>x86? Again, try to build 'images' first and only if that succeeds try
> >>'test-images' or 'all'.
> >>
> >
> > We tried with '--with-jtreg' in the configure command (after installing
> > jtreg) and the 'make images' worked in our Ubuntu 16.04 x86 build
> > environment. However the 'make all' is still failing.
> >
> >>Regards,
> >>Volker
> >>
> >>PS: could you (and your colleagues) please subscribe to the list.
> >>Otherwise you mails will be on hold until I moderate them.
> >>
> >
> >>> Please let us know if we are missing anything here.
> >>>
> >>> Thanks & Regards,
> >>> Shahid
> >
> >
> >
>
>
>