RFR: JDK-8210941 Stop filtering out -xregs=no%appl for libsunec

We have been filtering out the -xregs=no%appl when compiling libsunec for sparc. This is just an remnant of the old build system, where this were not properly set. (The recommendation is to use it for dlls.) To mimic the old behavior, we chose to filter it out when converting the old build syst

Re: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two

Hi Bob, On 18/09/2018 11:17 PM, Bob Vandette wrote: I only did some basic testing of the hard-float abi. Bell SW has offered to do more extensive testing as part of this JEP. I have no way of knowing if any of the other profiles are being used but I would think it’s worth keeping them in the

Re: RFR: JDK-8210920 Native C++ tests are not using CXXFLAGS

Looks ok. /Erik On 2018-09-19 13:55, Magnus Ihse Bursie wrote: Native C++ tests are not using CXXFLAGS. This is mostly apparent on solaris, where CC and cc are quite different. Fixing this made some new warnings appear on C++ tests for solstudio/gcc. Also, when fixing this, it became appare

Re: RFR: JDK-8210924 Remove PACKAGE_PATH

Magnus: The variable PACKAGE_PATH crept into the build when the macosx port was integrated. It is not used, however, and should be removed. (This is a BSD construct, and the macosx port was based on the BSD port.) If/when the BSD port ever gets integrated upstream, we'll know better then how to

RFR: JDK-8210924 Remove PACKAGE_PATH

The variable PACKAGE_PATH crept into the build when the macosx port was integrated. It is not used, however, and should be removed. (This is a BSD construct, and the macosx port was based on the BSD port.) If/when the BSD port ever gets integrated upstream, we'll know better then how to restor

Re: RFR: JDK-8210920 Native C++ tests are not using CXXFLAGS

Magnus: Native C++ tests are not using CXXFLAGS. This is mostly apparent on solaris, where CC and cc are quite different. Fixing this made some new warnings appear on C++ tests for solstudio/gcc. Also, when fixing this, it became apparent that the *FLAGS_TESTLIB/TESTEXE is just clumsy. In the l

RFR: JDK-8210920 Native C++ tests are not using CXXFLAGS

Native C++ tests are not using CXXFLAGS. This is mostly apparent on solaris, where CC and cc are quite different. Fixing this made some new warnings appear on C++ tests for solstudio/gcc. Also, when fixing this, it became apparent that the *FLAGS_TESTLIB/TESTEXE is just clumsy. In the long ter

Re: RFR: JDK-8210919 Remove statically linked libjli on Windows

Looks good. /Erik On 2018-09-19 12:51, Magnus Ihse Bursie wrote: For historic reasons, we've produced both a dynamic and a static library of JLI on Windows. It's been recently determined (see http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023234.html) that this is no longer

RFR: JDK-8210919 Remove statically linked libjli on Windows

For historic reasons, we've produced both a dynamic and a static library of JLI on Windows. It's been recently determined (see http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023234.html) that this is no longer needed, and we should simplify the code. Bug: https://bugs.openjdk.

Re: RFR: 8210459: Add support for generating compile_commands.json

On 2018-09-19 04:02, Magnus Ihse Bursie wrote: 19 sep. 2018 kl. 09:51 skrev Magnus Ihse Bursie mailto:[email protected]>>: On 2018-09-19 09:25, Robin Westberg wrote: Hi Erik, On 14 Sep 2018, at 19:21, Erik Joelsson > wrote: Main.gmk:888:

Re: RFR: 8210459: Add support for generating compile_commands.json

> 19 sep. 2018 kl. 09:51 skrev Magnus Ihse Bursie > : > > > >> On 2018-09-19 09:25, Robin Westberg wrote: >> Hi Erik, >> >>> On 14 Sep 2018, at 19:21, Erik Joelsson wrote: >>> > Main.gmk:888: I think you meant to add test-compile-commands here, which > also requires you to define

Re: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two

Hi Bob, Thank you for this job! I have started testing. Will come back with results next week :) The changes is Ok for me. Please see some minor comments below. regards, Boris On 17.09.2018 20:49, Aleksey Shipilev wrote: On 09/17/2018 07:00 PM, Vladimir Kozlov wrote: On 9/17/18 9:20 AM, Bob V

Re: Syntax error with set-vs-env.sh: - building jdk8u on Windows (cygwin)

Hi Magnus, Not sure if this helps but we had a `\M` char in our PATH setting via ansible (to indicate that we wanted the PATH set as a system env). We came to the conclusion that we actually want the path set in user space on our hosts and so we happily removed that `\M`. Cheers, Martijn On We

Re: [12] RFR: 8209880: tzdb.dat is not reproducibly built

On 2018-09-18 19:41, Naoto Sato wrote: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8209880 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8209880/webrev.00/ Looks good. Thank you for fixing this! /Magnus The fix

Re: Syntax error with set-vs-env.sh: - building jdk8u on Windows (cygwin)

On 2018-09-17 14:13, Martijn Verburg wrote: Hi Erik, Thanks for the info, inside that shell script we noticed the concatenation of PATH with whatever the host already had got corrupted (because of the way we set it). We've fixed our ansible scripts locally and the build is now going through aga

Re: Linux + Clang + execstack

On 2018-09-19 02:01, Martin Buchholz wrote: Unfortunately, my gmail marked Arthur's emails to this thread as spam, with ensuing confusion. I retargeted this fix to the new bug 8209817: stack is executable when building with Clang on Linux http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecsta

Re: RFR: 8210459: Add support for generating compile_commands.json

On 2018-09-19 09:25, Robin Westberg wrote: Hi Erik, On 14 Sep 2018, at 19:21, Erik Joelsson wrote: Main.gmk:888: I think you meant to add test-compile-commands here, which also requires you to define that target. Fixed, the tests are now invoked from a top-level target. I also added a s

Re: RFR: 8210459: Add support for generating compile_commands.json

Hi Erik, > On 14 Sep 2018, at 19:21, Erik Joelsson wrote: > >>> Main.gmk:888: I think you meant to add test-compile-commands here, which >>> also requires you to define that target. >> Fixed, the tests are now invoked from a top-level target. I also added a >> second test to ensure that the no