Re: RFR(XS): 8200469: Update link to license in Docs.gmk

Iris: Bug: 8200469: Update link to license in Docs.gmk https://bugs.openjdk.java.net/browse/JDK-8200469 webrev: http://cr.openjdk.java.net/~iris/8200469/webrev/ Looks good. Tim

Re: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests

While testing I discovered build errors on Mac and Solaris. The following statement " BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exesigtest := -ljvm" was added to a Linux-only block. I have updated the make file to add this for any platform w/o conditions; the " exesigtest.c" is excluded from

RFR(XS): 8200469: Update link to license in Docs.gmk

Please review this small change to update the link to the Specification license referenced by the JavaDoc API. To avoid the need for future updates based on the version number, we should use $(VERSION_NUMBER) instead of a specific version number. Bug: 8200469: Update link to license in

Re: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests

I have addressed feedback from Christian, David and Magnus. Here is the updated webrev: http://cr.openjdk.java.net/~mseledtsov/8200126.01.open/index.html I have also confirmed that output from exesigtest.c printf() is logged into .jtr files.   Grepped for "signal", I can see the output

Re: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests

Magnus, Thank you for advice. I have updated the makefile accordingly. Will post updated webrev shortly. Misha On 03/28/2018 03:26 PM, Magnus Ihse Bursie wrote: Yes, you seem to have based this off an old version of JtregNativeHotspot.gmk. If you update the file I think you see how you

Re: RFR: 8199619: Building HotSpot on Windows should define NOMINMAX

Thanks Erik! Best regards, Robin > On 28 Mar 2018, at 17:47, Erik Joelsson wrote: > > I will sponsor the change. > > /Erik > > > On 2018-03-28 06:43, Robin Westberg wrote: >> Hi Kim, >> >>> On 26 Mar 2018, at 18:34, Kim Barrett wrote: >>>

Re: (urgent) RFR: JDK-8200409: jdk11 nightly solaris sparc build failure

If I understand the fix correctly, it will resolve the build issue. However, libjsig will not work, since we will not export any symbols at all. For this to work, we also need to filter out the fvisibility/xldscope flags from CFLAGS. I apologize for the mess I created. :-( /Magnus > 29

Re: (urgent) RFR: JDK-8200409: jdk11 nightly solaris sparc build failure

Looks good to me as well. I am submitting the patch for testing now. If builds work on all platforms, I will push it for Erik. Tim On 03/29/18 07:23, Alan Bateman wrote: This revert looks okay to me. I see Tim is going to push it for you. -Alan On 29/03/2018 15:18, Erik Joelsson wrote:

Re: (urgent) RFR: JDK-8200409: jdk11 nightly solaris sparc build failure

This revert looks okay to me. I see Tim is going to push it for you. -Alan On 29/03/2018 15:18, Erik Joelsson wrote: The removal of mapfiles didn't completely work out. On Solaris we now get the following build error: "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c",

(urgent) RFR: JDK-8200409: jdk11 nightly solaris sparc build failure

The removal of mapfiles didn't completely work out. On Solaris we now get the following build error: "/localhome/erik/jdk/open/src/java.base/solaris/native/libjsig/jsig.c", line 181: error: redeclaration must have the same or more restrictive linker scoping: signal

Re: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c

Hi Magnus, On Thu, Mar 29, 2018 at 8:47 AM, Thomas Stüfe wrote: > > > On Thu, Mar 29, 2018 at 12:37 AM, Magnus Ihse Bursie < > magnus.ihse.bur...@oracle.com> wrote: > >> On 2018-03-28 21:21, Thomas Stüfe wrote: >> >> Hi Magnus, >> >> I had a closer look at the changes,

Re: Problem building openjdk using cygwin

Hi Alireza, it seems you don’t have short file names enabled for the “Program Files” directory. Notice that you have short file names enabled for “c:\” (i.e. you have “progra~2”). You have to first enable short file names for the “Program Files” directory (see for example

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

On 28/03/2018 22:48, Magnus Ihse Bursie wrote: 2) The exported symbols from executables are a public API and the change therefore require a CSR. I don't think there are any supported/documented interfaces here. It would be nice if the launchers were linked without any exported symbols, that

Re: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c

On Thu, Mar 29, 2018 at 12:37 AM, Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > On 2018-03-28 21:21, Thomas Stüfe wrote: > > Hi Magnus, > > I had a closer look at the changes, especially at jsig.c. It all comes > slowly back. The AIX version has been almost comically wrong. > >

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

On Wed, Mar 28, 2018 at 3:14 PM, Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > On 2018-03-28 23:53, Martin Buchholz wrote: > > I can't find any documentation for what JNIEXPORT and friends actually do. > People including myself have been cargo-culting JNIEXPORT and JNICALL for >

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

>From https://gcc.gnu.org/wiki/Visibility Why is the new C++ visibility support so useful? Put simply, it hides most of the ELF symbols which would have previously (and unnecessarily) been public. This means: - *It very substantially improves load times of your DSO (Dynamic Shared