Re: OpenJDK 10 zero For Mips32el java -version IncompatilveClassChangeError

On 2020-06-05 08:06, William Larson wrote: Hello David, When running configure --with-buildjdk=./jdk/build/linux-x86_64-normal-server-release/jdk I get the following error configure: Potential Build JDK found at /opt/FaceClockJava/jdk10l/build/linux-x86_64-normal-server-release/jdk is incorrec

RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Changes are only to the build system, but since the changes have jdk-wide effect I’ve cc’d what I think are the relevant dev lists.] This change is part of JEP 347; the intent is to target JDK 16. Please review this change to the building of C++ code in the JDK to enable the use of C++14 languag

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

I know there was a discussion about this elsewhere but I would like to take the opportunity to correct this now make//autoconf/flags-cflags.m4:241 elif test "x$TOOLCHAIN_TYPE" = xclang; then if test "x$OPENJDK_TARGET_OS" = xmacosx; then # On MacOSX we optimize for size, something

Re: RFR: JDK-8246478 Remove src/utils/reorder

Looks good. /Erik On 2020-06-03 08:20, Magnus Ihse Bursie wrote: The tools in src/utils/reorder was used to produce the "reorder" map files, which were used as an early optimization technique for native libraries. We have not used reorder files for a long time; they have all been gone, but

Re: RFR: JDK-8246435 Replace Javascript implementation of pandoc filters with Java

Looks good. At some point we should figure out a better way to create fine granular dependencies on build tools without having to run "find" on the build tools source dir. Since this is not being done on Windows, I'm ok with it for now. /Erik On 2020-06-03 03:54, Magnus Ihse Bursie wrote: D

Re: Sponsor request: Always pass java.library.path when running micro benchmarks

Looks good. /Erik On 2020-06-03 13:01, Jorn Vernee wrote: Hi, Please sponsor the following patch that correctly passes java.library.path when running micro benchmarks [1]. As a little bit of background; previously the java.library.path was appended to $1_MICRO_JAVA_OPTIONS and this was pas

Re: RFR: JDK-8246484 Verify patch at start of COMPARE_BUILD=PATCH run

Nice one, looks good! /Erik On 2020-06-03 11:09, Magnus Ihse Bursie wrote: I have supplied an incorrect patch to COMPARE_BUILD=PATCH one time too many. This patch adds an early verification that the patch can be applied, before starting the full comparison build. Bug: https://bugs.openjdk.ja

RE: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

Hi Kim, builds out of the box on AIX with IBM XL C/C++ for AIX, V16.1.0 (We already use clang frontend by default.) Very cool! Best regards, Martin > -Original Message- > From: build-dev On Behalf Of Kim > Barrett > Sent: Freitag, 5. Juni 2020 09:53 > To: build-dev > Cc: 2d-...@openj

Build broken on ARM32 since "8242088: Replace mutually exclusive lists with concurrent alternatives"

Dear JDK Build Team, it looks after "8242088: Replace mutually exclusive lists with concurrent alternatives” (http://hg.openjdk.java.net/jdk/jdk/rev/e51cdea8457e ) the build on arm32 is broken. The compiler error is: /workspace/build/linux-a

Re: OpenJDK 10 zero For Mips32el java -version IncompatilveClassChangeError

Hello Magnus I got the source code from the openjdk mercurial repository following the building.html exactly. Here is the version numbers DEFAULT_VERSION_MAJOR=10 DEFAULT_VERSION_MINOR=0 DEFAULT_VERSION_SECURITY=0 DEFAULT_VERSION_PATCH=0 LAUNCHER_NAME=openjdk PRODUCT_NAME=OpenJDK PRODUCT_SUFFIX=

Re: OpenJDK 10 zero For Mips32el java -version IncompatilveClassChangeError

> On Jun 5, 2020, at 10:27 AM, William Larson wrote: > > Hello Magnus > > I got the source code from the openjdk mercurial repository following the > building.html exactly. Can you give some more details here please - exactly how do you get the sources? > Here is the version numbers > DEFAU

Re: OpenJDK 10 zero For Mips32el java -version IncompatilveClassChangeError

> On Jun 5, 2020, at 1:16 PM, Mikael Vidstedt > wrote: > > > >> On Jun 5, 2020, at 10:27 AM, William Larson > > wrote: >> >> Hello Magnus >> >> I got the source code from the openjdk mercurial repository following the >> buildin

Re: OpenJDK 10 zero For Mips32el java -version IncompatilveClassChangeError

Hello Mikael, This is how I get the sources hg clone http://hg.openjdk.java.net/jdk10/jdk10 cd jdk10 bash get_source.sh I checked my current build and this is what I see (note the 9 AC_DEFUN([BOOTJDK_CHECK_BUILD_JDK], [ # Extra M4 quote needed to protect [] in grep expression.

Re: OpenJDK 10 zero For Mips32el java -version IncompatilveClassChangeError

Glad you got it working! Still curious though: any particular reason for building jdk10 specifically? :) Cheers, Mikael > On Jun 5, 2020, at 3:30 PM, William Larson wrote: > > Hello Mikael, > This is how I get the sources > > hg clone http://hg.openjdk.java.net/jdk10/jdk10 >

Re: OpenJDK 10 zero For Mips32el java -version IncompatilveClassChangeError

Hello Mikael, I need at least OpenJDK 8 for TLS 1.2 support out of the box. I am also working with an embedded system that has proprietary code for biometrics compiled against a glibc version 2.18. I didn't want to stray too far from glibc 2.18 ( which is 2013-2014 time range) as other things in c

Re: Build broken on ARM32 since "8242088: Replace mutually exclusive lists with concurrent alternatives"

On 2020-06-05 17:21, Marc Hoffmann wrote: Dear JDK Build Team, it looks after "8242088: Replace mutually exclusive lists with concurrent alternatives” (http://hg.openjdk.java.net/jdk/jdk/rev/e51cdea8457e ) the build on arm32 is broken. The

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

On 2020-06-05 13:59, Jim Laskey wrote: I know there was a discussion about this elsewhere but I would like to take the opportunity to correct this now make//autoconf/flags-cflags.m4:241 elif test "x$TOOLCHAIN_TYPE" = xclang; then if test "x$OPENJDK_TARGET_OS" = xmacosx; then # O

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

On 2020-06-05 09:52, Kim Barrett wrote: [Changes are only to the build system, but since the changes have jdk-wide effect I’ve cc’d what I think are the relevant dev lists.] This change is part of JEP 347; the intent is to target JDK 16. Please review this change to the building of C++ code in

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

> On Jun 5, 2020, at 9:34 AM, Doerr, Martin wrote: > > Hi Kim, > > builds out of the box on AIX with IBM XL C/C++ for AIX, V16.1.0 (We already > use clang frontend by default.) > Very cool! Thanks for taking it for a spin.

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

> On Jun 5, 2020, at 7:57 PM, Magnus Ihse Bursie > wrote: > > On 2020-06-05 13:59, Jim Laskey wrote: >> I know there was a discussion about this elsewhere but I would like to take >> the opportunity to correct this now >> >> make//autoconf/flags-cflags.m4:241 >> >> […] >> MacOSX has been payi

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

> On Jun 5, 2020, at 7:57 PM, Magnus Ihse Bursie > wrote: > > On 2020-06-05 09:52, Kim Barrett wrote: >> [Changes are only to the build system, but since the changes have jdk-wide >> effect I’ve cc’d what I think are the relevant dev lists.] >> >> This change is part of JEP 347; the intent is t