From david.holmes at oracle.com Thu Feb 1 00:14:01 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Feb 2018 10:14:01 +1000 Subject: RFR: JDK-8196524: Align MaxRAMPercentage settings between open and closed In-Reply-To: References: Message-ID: <82bbc43d-af1d-d96f-235e-fbaf7375b07b@oracle.com> Looks good to me! Thanks for fixing Erik. One pre-existing query: ! # Make sure MaxRAMPercentage is high enough to not cause OOM or swapping since Surely "high" should be "low" ?? Thanks, David On 1/02/2018 9:52 AM, Erik Joelsson wrote: > An internal test at Oracle is failing because of a faulty shell > expression in a makefile for calculating the value for MaxRAMPercentage. > We already have such a calculation in TestCommon.gmk so we should just > use that, but it needs to be exported in a separate variable to be able > to do so. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196524 > > Webrev: http://cr.openjdk.java.net/~erikj/8196524/webrev.01/ > > /Erik > From tim.bell at oracle.com Thu Feb 1 00:15:10 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 31 Jan 2018 16:15:10 -0800 Subject: RFR: JDK-8196524: Align MaxRAMPercentage settings between open and closed In-Reply-To: References: Message-ID: <5A725C0E.3030807@oracle.com> Erik: > An internal test at Oracle is failing because of a faulty shell > expression in a makefile for calculating the value for MaxRAMPercentage. > We already have such a calculation in TestCommon.gmk so we should just > use that, but it needs to be exported in a separate variable to be able > to do so. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196524 > > Webrev: http://cr.openjdk.java.net/~erikj/8196524/webrev.01/ test/TestCommon.gmk You didn't change this line, however: 361 CONCURRENCY := $(shell awk \ Should it be $(AWK) instead of awk to be consistent with lines 254 ... 256? Thanks, Erik. Looks good otherwise. /Tim From erik.joelsson at oracle.com Thu Feb 1 00:26:34 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 31 Jan 2018 16:26:34 -0800 Subject: RFR: JDK-8196524: Align MaxRAMPercentage settings between open and closed In-Reply-To: <5A725C0E.3030807@oracle.com> References: <5A725C0E.3030807@oracle.com> Message-ID: <1ab271e8-5ee4-642f-77cb-e51f09a6f5c9@oracle.com> Good point, it really should. /Erik On 2018-01-31 16:15, Tim Bell wrote: > Erik: > >> An internal test at Oracle is failing because of a faulty shell >> expression in a makefile for calculating the value for MaxRAMPercentage. >> We already have such a calculation in TestCommon.gmk so we should just >> use that, but it needs to be exported in a separate variable to be able >> to do so. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196524 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8196524/webrev.01/ > > test/TestCommon.gmk > > You didn't change this line, however: > > 361 CONCURRENCY := $(shell awk \ > > Should it be $(AWK) instead of awk to be consistent with lines 254 ... > 256? > > Thanks, Erik.? Looks good otherwise. > > /Tim > > From erik.joelsson at oracle.com Thu Feb 1 00:26:55 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 31 Jan 2018 16:26:55 -0800 Subject: RFR: JDK-8196524: Align MaxRAMPercentage settings between open and closed In-Reply-To: <82bbc43d-af1d-d96f-235e-fbaf7375b07b@oracle.com> References: <82bbc43d-af1d-d96f-235e-fbaf7375b07b@oracle.com> Message-ID: <9dce6937-e11d-be4f-50a8-4257b42fdaa8@oracle.com> Yes, that would make more sense, will fix. /Erik On 2018-01-31 16:14, David Holmes wrote: > Looks good to me! Thanks for fixing Erik. > > One pre-existing query: > > ! # Make sure MaxRAMPercentage is high enough to not cause OOM or > swapping since > > Surely "high" should be "low"? ?? > > Thanks, > David > > On 1/02/2018 9:52 AM, Erik Joelsson wrote: >> An internal test at Oracle is failing because of a faulty shell >> expression in a makefile for calculating the value for >> MaxRAMPercentage. We already have such a calculation in >> TestCommon.gmk so we should just use that, but it needs to be >> exported in a separate variable to be able to do so. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196524 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8196524/webrev.01/ >> >> /Erik >> From erik.joelsson at oracle.com Thu Feb 1 00:29:24 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 31 Jan 2018 16:29:24 -0800 Subject: RFR: JDK-8196524: Align MaxRAMPercentage settings between open and closed In-Reply-To: References: Message-ID: <8b884450-73db-bdd9-7fa2-2bf4a3740f95@oracle.com> New webrev addressing concerns from both Tim and David. http://cr.openjdk.java.net/~erikj/8196524/webrev.02/ /Erik On 2018-01-31 15:52, Erik Joelsson wrote: > An internal test at Oracle is failing because of a faulty shell > expression in a makefile for calculating the value for > MaxRAMPercentage. We already have such a calculation in TestCommon.gmk > so we should just use that, but it needs to be exported in a separate > variable to be able to do so. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196524 > > Webrev: http://cr.openjdk.java.net/~erikj/8196524/webrev.01/ > > /Erik > From david.holmes at oracle.com Thu Feb 1 08:00:42 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Feb 2018 18:00:42 +1000 Subject: RFR: JDK-8196524: Align MaxRAMPercentage settings between open and closed In-Reply-To: <8b884450-73db-bdd9-7fa2-2bf4a3740f95@oracle.com> References: <8b884450-73db-bdd9-7fa2-2bf4a3740f95@oracle.com> Message-ID: Looks fine. Thanks, David On 1/02/2018 10:29 AM, Erik Joelsson wrote: > New webrev addressing concerns from both Tim and David. > > http://cr.openjdk.java.net/~erikj/8196524/webrev.02/ > > /Erik > > On 2018-01-31 15:52, Erik Joelsson wrote: >> An internal test at Oracle is failing because of a faulty shell >> expression in a makefile for calculating the value for >> MaxRAMPercentage. We already have such a calculation in TestCommon.gmk >> so we should just use that, but it needs to be exported in a separate >> variable to be able to do so. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196524 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8196524/webrev.01/ >> >> /Erik >> > From christoph.langer at sap.com Thu Feb 1 08:11:15 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 1 Feb 2018 08:11:15 +0000 Subject: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() In-Reply-To: <5A6A2611.4030003@oracle.com> References: <5A6A2611.4030003@oracle.com> Message-ID: Hi Gary, I was having a look at your changes. I'm wondering what the reason is behind uncommenting WSASendDisconnect in Java_sun_nio_ch_SocketDispatcher_preClose0 of file SocketDispatcher.c? And in dbgsysSocketClose? In socketTransport.c, line: 331 setLastError(0, "gethostbyname: unknown host"); you should change the description text of the error to getaddrinfo instead of gethostbyname. Best regards Christoph -----Original Message----- From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of Gary Adams Sent: Donnerstag, 25. Januar 2018 19:47 To: OpenJDK Serviceability ; OpenJDK Build ; OpenJDK Networking Subject: RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() Here's a first pass attempt to remove the -D_WINSOCK_DEPRECATED_NO_WARNINGS build flag and update the winsock deprecated functions. Issue: https://bugs.openjdk.java.net/browse/JDK-8080990 Webrev: http://cr.openjdk.java.net/~gadams/8080990/ These are the initial deprecated functions updated: gethostbyname -> getaddrinfo inet_addr -> inet_pton inet_ntoa -> inet_ntop I'm not sure how to replace the existing WSASendDisconnect calls. It's not clear that it actually provides a graceful disconnect. From gary.adams at oracle.com Thu Feb 1 11:16:49 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Thu, 1 Feb 2018 06:16:49 -0500 Subject: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() In-Reply-To: References: <5A6A2611.4030003@oracle.com> Message-ID: First pass over the code I disabled the compilation flag and then did quick substitution for the easier functions. I commented out the WSASendDisconnect calls so I could see what tests would fail if the function was just removed. I have a replacement now that uses "shutdown(fd,SD_SEND)", but I still have a few more test failures to investigate. I updated the error message text for "getaddrinfo". I'll post a revised webrev after the 4 jshell errors are corrected. On 2/1/18 3:11 AM, Langer, Christoph wrote: > Hi Gary, > > I was having a look at your changes. > > I'm wondering what the reason is behind uncommenting WSASendDisconnect in Java_sun_nio_ch_SocketDispatcher_preClose0 of file SocketDispatcher.c? And in dbgsysSocketClose? > > In socketTransport.c, line: > 331 setLastError(0, "gethostbyname: unknown host"); > you should change the description text of the error to getaddrinfo instead of gethostbyname. > > Best regards > Christoph > > > > -----Original Message----- > From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of Gary Adams > Sent: Donnerstag, 25. Januar 2018 19:47 > To: OpenJDK Serviceability ; OpenJDK Build ; OpenJDK Networking > Subject: RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() > > Here's a first pass attempt to remove the -D_WINSOCK_DEPRECATED_NO_WARNINGS > build flag and update the winsock deprecated functions. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8080990 > Webrev: http://cr.openjdk.java.net/~gadams/8080990/ > > These are the initial deprecated functions updated: > gethostbyname -> getaddrinfo > inet_addr -> inet_pton > inet_ntoa -> inet_ntop > > I'm not sure how to replace the existing WSASendDisconnect calls. > It's not clear that it actually provides a graceful disconnect. > > From adam.farley at uk.ibm.com Thu Feb 1 11:36:44 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 1 Feb 2018 11:36:44 +0000 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> Message-ID: Hi All, After doing some experimenting, I've discovered the problem isn't limited to SLES, or gcc 4.8.5, or zLinux. Platforms affected: zLinux, ppcle Linux Platforms not affected: x86 Linux gcc versions affected: 4.8.5, 5.4.0 gcc versions unaffected: 7.2.1 linux variations affected: Ubuntu, SLES E.g. when I told SLES 12 (zLinux) to install gcc, it installed 5.4.0. All this tells me that, if we intent to encourage SLES 12 users to build Java 11, we need this warning suppression hard coded. There are ways to do "greater than"s and "first character in"s in make, but they require either shell commands, or more dollar signs than you can shake a stick at. I propose we hard code "array-bounds" into javajpeg's DISABLED_WARNINGS_gcc for all java versions, and move on. On the basis that gcc 7.2.1 produces a different error message when an array-bounds problem occurs (e.g. frog[-1] produces the warning "error: ?frog[-7]? is used uninitialized in this function"), I don't see leaving array-bounds in DISABLED_WARNINGS_gcc as a problem. Thoughts? Best Regards Adam Farley > The claim on the wiki was made by Volker on July 13 2017. It was done on > SuSE linux while the reported problem is on zLinux. Maybe they have > different vendor specific patches in their respective gcc builds? Is SAP > still able to build without --disable-warnings-as-errors? This wiki is > supposed to be a community effort. > > /Erik > > >On 2018-01-24 16:37, David Holmes wrote: >> Hi Magnus, >> >> On 25/01/2018 9:55 AM, Magnus Ihse Bursie wrote: >>> I'm not sure I'm able to follow where this discussion is heading, but >>> at the very least I'd like to chime in on the patch below: >>> >>> I don't like how the entire DISABLED_WARNINGS_gcc line is lifted out. >>> A better solution is something like this: >>> >>> ifeq ($(CC_VERSION_NUMBER), 4.8.5) >>> #Turn off array-bounds warnings for libjava compilation because >>> jchuff.c >>> #fails to compile on gcc 4.8.5 with a warning that an array is >>> potentially >>> #out of bounds. This kills a warnings=errors build. >>> LIBJAVAJPEG_DISABLED_WARNINGS_gcc485 := array-bounds >>> endif >>> ... >>> DISABLED_WARNINGS_gcc := clobbered >>> $(LIBJAVAJPEG_DISABLED_WARNINGS_gcc485), \ >>> >>> I also can't see this going into anything else than the current >>> mainline, jdk/jdk i.e. JDK 11. Since the issue is trivially avoided >>> by using --disable-warnings-as-errors, I hardly see that it warrants >>> a backport. >> >> It's pointless in JDK 11 as we're not going to claim support for gcc >> 4.8.5. >> >> The issue is that out-of-the-box if you are building 8u or 9 and use >> gcc 4.8.5, which is supposed to be a valid compiler to use based on >> the wiki, then it fails because of this gcc bug, unless you disable >> warnings-as-errors. So either we put in a workaround for the bug or we >> update to the build docs (and/or the wiki) to make it very clear that >> you may need to disable warnings-as-errors (something there is no >> mention of in the build doc in 9). >> >> David >> ----- >> >>> /Magnus >>> >>> On 2018-01-23 14:44, Adam Farley8 wrote: >>>> Hi All, >>>> >>>> All: I think I responded to everyone below. Please could a committer or >>>> author raise a bug and, if people are happy with this change, line >>>> it up >>>> for contribution to JDKs 8-11 (assuming 4.8.5 is still the >>>> recommended gcc >>>> for JDK10 and 11 on SUSE sles)? >>>> >>>> Erik: One toolchain-specific change, as requested. This was tested >>>> on JDK9, >>>> so please apply an offset of -1 to the line numbers before applying >>>> to JDK10. >>>> >>>> ----------------------- Start of Diff ----------------------- >>>> >>>> diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk >>>> --- a/make/lib/Awt2dLibraries.gmk >>>> +++ b/make/lib/Awt2dLibraries.gmk >>>> @@ -482,6 +482,14 @@ >>>> BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC)) >>>> endif >>>> >>>> +LIBJAVAJPEG_DISABLED_WARNINGS_gcc := clobbered >>>> +ifeq ($(CC_VERSION_NUMBER), 4.8.5) >>>> + #Turn off array-bounds warnings for libjava compilation because >>>> jchuff.c >>>> + #fails to compile on gcc 4.8.5 with a warning that an array is >>>> potentially >>>> + #out of bounds. This kills a warnings=errors build. >>>> + LIBJAVAJPEG_DISABLED_WARNINGS_gcc := clobbered array-bounds >>>> +endif >>>> + >>>> $(eval $(call SetupNativeCompilation,BUILD_LIBJAVAJPEG, \ >>>> LIBRARY := javajpeg, \ >>>> OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ >>>> @@ -491,7 +499,7 @@ >>>> CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \ >>>> $(LIBJAVA_HEADER_FLAGS) \ >>>> -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \ >>>> - DISABLED_WARNINGS_gcc := clobbered, \ >>>> + DISABLED_WARNINGS_gcc := $(LIBJAVAJPEG_DISABLED_WARNINGS_gcc), \ >>>> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \ >>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>> >>>> ----------------------- End of Diff ----------------------- >>>> >>>> Phil: I've changed the title as asked and supplied the diff above. >>>> However, >>>> I can't upload files to cr.openjdk.java.net, nor can I create bugs >>>> myself. >>>> I understand that authors and committers can, but I don't have those >>>> privileges yet. Be nice if I did. :) >>>> >>>> John: I read your email, and I understand your position. I disagree >>>> with it, >>>> but I understand it. 4.8.5 is an old version of gcc, but right now >>>> it is the >>>> listed gcc version for SUSE sles on intel, ppc, ppcle, and zLinux. >>>> Even if >>>> this is not the case for JDK 10 or 11, we should ensure this fix is >>>> fully >>>> propagated to ensure consistent behaviour. >>>> >>>> That is my position. >>>> >>>> David: Thanks for the URL. I agree with your position on 4.8.5 gcc >>>> needing >>>> to compile OpenJDK without errors or special options. :) >>>> >>>> Best Regards >>>> >>>> Adam Farley >>>> >>>> >>>> >>>> From: Phil Race >>>> To: Adam Farley8 , 2d-dev at openjdk.java.net >>>> Cc: build-dev >>>> Date: 18/01/2018 19:16 >>>> Subject: Re: [OpenJDK 2D-Dev] [PATCH] Build fails to compile jchuff.c >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> >>>> Try again with build-dev cc'd .. >>>> >>>> -phil. >>>> >>>> On 01/18/2018 11:14 AM, Phil Race wrote: >>>> I agree with what Erik said on build-dev that being specific about >>>> the tool chain >>>> and the reason are worthwhile and important. We've done that in >>>> similar cases. >>>> >>>> Also these review threads usually should have a subject like >>>> RFR: : >>>> >>>> which means you first need a bug id .. the patch can't be pushed >>>> without one anyway. >>>> >>>> Then the patch should be an in-line diff or a webrev hosted on >>>> cr.openjdk.java.net. >>>> >>>> I think in-line would be OK for this small change. >>>> >>>> -phil. >>>> >>>> On 01/17/2018 09:30 AM, Adam Farley8 wrote: >>>> Hi All, >>>> >>>> Under these circumstances, jchuff.c will not compile: >>>> >>>> Platform: zLinux (s390x) >>>> Release: JDK9 (may affect other JDKs). >>>> GCC Version: 4.8.5 >>>> Notes: --disable-warnings-as-errors suppresses this error. >>>> >>>> The error is: >>>> >>>> /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c: >>>> >>>> In function 'jGenOptTbl': >>>> /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c:808:18: >>>> >>>> error: array subscript is below array bounds [-Werror=array-bounds] >>>> while (bits[j] == 0) >>>> ^ >>>> >>>> This is a continuation of a conversation in the build-dev mailing >>>> list, if anyone wants to >>>> check the history. >>>> >>>> The short version is that, while you *can* suppress the problem by >>>> adding >>>> --disable-warnings-as-errors to your configure step, I posit that a >>>> builder shouldn't >>>> have to. >>>> >>>> Various solutions were debated. One involves changing >>>> Awt2dLibraries.gmk. >>>> >>>> Basically you change line 494 to this: >>>> >>>> DISABLED_WARNINGS_gcc := clobbered array-bounds, \ >>>> >>>> I'm running a build now to check that works, but basically we should >>>> end up with a >>>> -Wno-array-bounds on the gcc compile command for jchuff.c, thereby >>>> ignoring the warning. >>>> >>>> A smarter variant involves checking for that specific version of the >>>> gcc, but that seems >>>> wordy to me for this problem. Keeping it simple. :) >>>> >>>> Thoughts? >>>> >>>> Best Regards >>>> >>>> Adam Farley >>>> >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with >>>> number 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>>> PO6 3AU >>>> >>>> >>>> >>>> >>>> >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with >>>> number 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>>> PO6 3AU >>> > > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From glaubitz at physik.fu-berlin.de Thu Feb 1 11:45:19 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 1 Feb 2018 12:45:19 +0100 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> Message-ID: On 02/01/2018 12:36 PM, Adam Farley8 wrote: > After doing some experimenting, I've discovered the problem isn't limited to > SLES, or gcc 4.8.5, or zLinux. > > (...) > Thoughts? I think the problem is more that if you are trying to silence warnings, you will end up being busy for a very long time since there are simply too many possible configurations out there [1]. For this reason, both Debian and openSUSE/SLE [2] build OpenJDK with the configure parameter "--disable-warnings-as-errors". Adrian > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-January/029754.html > [2] https://build.opensuse.org/package/view_file/openSUSE:Factory/java-10-openjdk/java-10-openjdk.spec?expand=1 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From christoph.langer at sap.com Thu Feb 1 11:59:58 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 1 Feb 2018 11:59:58 +0000 Subject: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() In-Reply-To: References: <5A6A2611.4030003@oracle.com> Message-ID: But WSASendDisconnect isn't deprecated, right? So you wanted to get rid of it? I still don't see the reason... -----Original Message----- From: gary.adams at oracle.com [mailto:gary.adams at oracle.com] Sent: Donnerstag, 1. Februar 2018 12:17 To: Langer, Christoph ; OpenJDK Serviceability ; OpenJDK Build ; OpenJDK Networking Subject: Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() First pass over the code I disabled the compilation flag and then did quick substitution for the easier functions. I commented out the WSASendDisconnect calls so I could see what tests would fail if the function was just removed. I have a replacement now that uses "shutdown(fd,SD_SEND)", but I still have a few more test failures to investigate. I updated the error message text for "getaddrinfo". I'll post a revised webrev after the 4 jshell errors are corrected. On 2/1/18 3:11 AM, Langer, Christoph wrote: > Hi Gary, > > I was having a look at your changes. > > I'm wondering what the reason is behind uncommenting WSASendDisconnect in Java_sun_nio_ch_SocketDispatcher_preClose0 of file SocketDispatcher.c? And in dbgsysSocketClose? > > In socketTransport.c, line: > 331 setLastError(0, "gethostbyname: unknown host"); > you should change the description text of the error to getaddrinfo instead of gethostbyname. > > Best regards > Christoph > > > > -----Original Message----- > From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of Gary Adams > Sent: Donnerstag, 25. Januar 2018 19:47 > To: OpenJDK Serviceability ; OpenJDK Build ; OpenJDK Networking > Subject: RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() > > Here's a first pass attempt to remove the -D_WINSOCK_DEPRECATED_NO_WARNINGS > build flag and update the winsock deprecated functions. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8080990 > Webrev: http://cr.openjdk.java.net/~gadams/8080990/ > > These are the initial deprecated functions updated: > gethostbyname -> getaddrinfo > inet_addr -> inet_pton > inet_ntoa -> inet_ntop > > I'm not sure how to replace the existing WSASendDisconnect calls. > It's not clear that it actually provides a graceful disconnect. > > From adam.farley at uk.ibm.com Thu Feb 1 12:00:45 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 1 Feb 2018 12:00:45 +0000 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> Message-ID: > On 02/01/2018 12:36 PM, Adam Farley8 wrote: >> After doing some experimenting, I've discovered the problem isn't limited to >> SLES, or gcc 4.8.5, or zLinux. >> >> (...) >> Thoughts? > I think the problem is more that if you are trying to silence warnings, > you will end up being busy for a very long time since there are simply > too many possible configurations out there [1]. Unfortunately it's not just a warning, it's a build-killer. Across those platforms, in those configurations, this is the only warning which causes the build to fail. Adding array-bounds to DISABLED_WARNINGS_gcc suppresses this warning-turned-error, and the builds then run and pass. > > For this reason, both Debian and openSUSE/SLE [2] build OpenJDK with the > configure parameter "--disable-warnings-as-errors". --disable-warnings-as-errors (in the configure step) can work around this problem, but then we need to add it to the relevant documentation, and it complicates the build process a little bit more from the user's POV. In my world, "bash ./configure" should be enough. I like to keep things simple. :) - Adam > > Adrian > >> [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_hotspot-2Ddev_2018-2DJanuary_029754.html&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=DL2no3G3wg34U0Tl9cbhAcWOQVVU4mv-0EiiF2QNh5U&s=0uzfk9CUqR2GtWgwtbQFBs7zFHnAs6hwM-LGYDMdeHs&e= >> [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__build.opensuse.org_package_view-5Ffile_openSUSE-3AFactory_java-2D10-2Dopenjdk_java-2D10-2Dopenjdk.spec-3Fexpand-3D1&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=DL2no3G3wg34U0Tl9cbhAcWOQVVU4mv-0EiiF2QNh5U&s=9NoPxdwrV4dfjgB4SpDpLgLApTLCTURy6xwVUU5LS6k&e= > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From gary.adams at oracle.com Thu Feb 1 13:21:27 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 01 Feb 2018 08:21:27 -0500 Subject: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() In-Reply-To: References: <5A6A2611.4030003@oracle.com> Message-ID: <5A731457.1040502@oracle.com> On 2/1/18, 6:59 AM, Langer, Christoph wrote: > But WSASendDisconnect isn't deprecated, right? So you wanted to get rid of it? I still don't see the reason... vs2013 include/um/winsock2.h has WSASendDisconnect deprecated. .../src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c(230) : error C2220: warning treated as error - no 'object' file generated .../src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c(230) : warning C4996: 'WSASendDisconnect': Use WSASend() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings From tim.bell at oracle.com Thu Feb 1 15:07:42 2018 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 01 Feb 2018 07:07:42 -0800 Subject: RFR: JDK-8196524: Align MaxRAMPercentage settings between open and closed In-Reply-To: References: <8b884450-73db-bdd9-7fa2-2bf4a3740f95@oracle.com> Message-ID: <5A732D3E.5030702@oracle.com> Erik: Looks good to me as well. Thanks. /Tim > Looks fine. > > Thanks, > David > > On 1/02/2018 10:29 AM, Erik Joelsson wrote: >> New webrev addressing concerns from both Tim and David. >> >> http://cr.openjdk.java.net/~erikj/8196524/webrev.02/ >> >> /Erik >> >> On 2018-01-31 15:52, Erik Joelsson wrote: >>> An internal test at Oracle is failing because of a faulty shell >>> expression in a makefile for calculating the value for >>> MaxRAMPercentage. We already have such a calculation in >>> TestCommon.gmk so we should just use that, but it needs to be >>> exported in a separate variable to be able to do so. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196524 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8196524/webrev.01/ >>> >>> /Erik >>> >> From gary.adams at oracle.com Thu Feb 1 15:27:21 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 01 Feb 2018 10:27:21 -0500 Subject: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() In-Reply-To: References: <5A6A2611.4030003@oracle.com> Message-ID: <5A7331D9.9000800@oracle.com> Here's a revised webrev http://cr.openjdk.java.net/~gadams/8080990/webrev.01/index.html Still testing ... Using shutdown() fixed problems reported by the java/nio/channelSocketChannel tests. I also noticed prior use of getaddrinfo for "localhost" was not calling freeaddrinfo. ... On 2/1/18, 6:16 AM, gary.adams at oracle.com wrote: > First pass over the code I disabled the compilation flag and then > did quick substitution for the easier functions. I commented out the > WSASendDisconnect calls so I could see what tests would fail if > the function was just removed. I have a replacement now that uses > "shutdown(fd,SD_SEND)", but I still have a few more test failures to > investigate. > > I updated the error message text for "getaddrinfo". > > I'll post a revised webrev after the 4 jshell errors are corrected. > > > On 2/1/18 3:11 AM, Langer, Christoph wrote: >> Hi Gary, >> >> I was having a look at your changes. >> >> I'm wondering what the reason is behind uncommenting >> WSASendDisconnect in Java_sun_nio_ch_SocketDispatcher_preClose0 of >> file SocketDispatcher.c? And in dbgsysSocketClose? >> >> In socketTransport.c, line: >> 331 setLastError(0, "gethostbyname: unknown host"); >> you should change the description text of the error to getaddrinfo >> instead of gethostbyname. >> >> Best regards >> Christoph >> >> >> >> -----Original Message----- >> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf >> Of Gary Adams >> Sent: Donnerstag, 25. Januar 2018 19:47 >> To: OpenJDK Serviceability ; >> OpenJDK Build ; OpenJDK Networking >> >> Subject: RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning >> C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() >> >> Here's a first pass attempt to remove the >> -D_WINSOCK_DEPRECATED_NO_WARNINGS >> build flag and update the winsock deprecated functions. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8080990 >> Webrev: http://cr.openjdk.java.net/~gadams/8080990/ >> >> These are the initial deprecated functions updated: >> gethostbyname -> getaddrinfo >> inet_addr -> inet_pton >> inet_ntoa -> inet_ntop >> >> I'm not sure how to replace the existing WSASendDisconnect calls. >> It's not clear that it actually provides a graceful disconnect. >> >> > From erik.joelsson at oracle.com Thu Feb 1 16:38:30 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Feb 2018 08:38:30 -0800 Subject: RFR: JDK-8195689 Remove generated-configure.sh and instead use autoconf In-Reply-To: References: <222fd001-0765-bb72-5edc-53b968041a42@oracle.com> Message-ID: <399fc4d2-b419-5e48-134d-c687f93eea78@oracle.com> This version looks good to me. /Erik On 2018-01-25 13:33, Magnus Ihse Bursie wrote: > On 2018-01-18 19:37, Erik Joelsson wrote: >> Hello Magnus, >> >> Nice to see this finally happening! > Thanks! > >> >> In building.md, when getting autoconf for Cygwin, I believe you also >> need the autoconf wrapper scripts package. > Hm, well, no, it's the other way around. "autoconf" is the name of the > cygwin "autoconf wrapper scripts" package. It depends on "m4", > "autoconf2.69" (or whatever), etc. I have verified that just > installing "autoconf" will be enough, and will pull in all needed > dependencies. > >> Perhaps it's also worth mentioning that you can download the autoconf >> src and build/install from there? > Well, I'm already giving a link to > http://www.gnu.org/software/autoconf in the build readme. I'm not sure > if it's helpful for anyone to download the autoconf source by > themselves. Most users will have it available prebuilt. And if not, > you'll also most likely need to pull down and build m4, and that's > trickier. The reason why we used to download autoconf and build it > from source was to make sure that we got the exactly right version, > but that only made sense when we checked in the > generated-configure.sh. (And this worked fine for us, since we had m4...) > >> In jib-profiles.js, you need to use build_platform instead of >> target_platform when creating the module name for the dependency. > Good point. Fixed. > >> I would also like if you added the dependency on the other main >> profiles as well. At least linux-x86, linux-arm64 and windows-x86 are >> still possible to build and should work fine with this. For >> solaris-x64 you would need to generate the package for it to work. > Sure. >> >> The TMPDIR logic looks weird. Are you unconditionally setting it to >> /cygdrive/t/...? That's a valid dir in our build farm, but not on my >> local windows box: >> >> mkdir: cannot create directory ?/cygdrive/t?: No such file or directory >> autom4te: cannot create >> /cygdrive/t/workspace/.build/tmpdir/am4t7009.7040: No such file or >> directory >> ?at >> /cygdrive/c/cygwin64/var/tmp/jib-erik/install/jpg/infra/builddeps/autoconf-windows_x64/2.69+1.0.1/autoconf-windows_x64-2.69+1.0.1.tar.gz/usr/bin/autom4te >> line 954. >> Error: Failed to generate runnable configure script > Yeah, that was broken by design. :-( > > Some offline discussion later, it turned out that the reason for the > trouble was mismatch between cygwin-32 and cygwin-64. I've solved this > by generating two different packages, for cygwin-32 and cygwin-64. > I've also made some other minor fixes to the build script, e.g. using > perl instead of sed due to the braindead sed being available on > solaris. :( > > Updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8195689-remove-generated-configure/webrev.02/ > > > /Magnus > > >> >> /Erik >> >> >> On 2018-01-18 05:28, Magnus Ihse Bursie wrote: >>> Currently, we require all developers who modify the configure script >>> to run autoconf locally, to update the generated-configure.sh >>> script, which is then checked in. This is the only instance of >>> checked in "compiled" code in OpenJDK, and this has brought along >>> several problems: >>> >>> * Only a specific version of autoconf, 2.69, can be used, to avoid >>> large code changes in the generated file. Unfortunately, Ubuntu >>> ships a version of autoconf that claims to be 2.69 but is actually >>> heavily patched. This requires all Ubuntu users to compiler their >>> own autoconf from source. >>> >>> * The Oracle JDK closed sources has a closed version that needs to >>> be updated. In practice, this has meant that all non-Oracle >>> developers, need an Oracle sponsor for patches modifying the >>> configure script. >>> >>> * If the configure script is not properly updated, the build will >>> fail. The same happens on the Oracle side if the closed version is >>> not in sync with the open version. It is easy to miss re-generating >>> the script after the last fix of a typo in the comments in an .m4 >>> file... >>> >>> * Merging between two changes containing configure modifications is >>> almost impossible. In practice, the entire generated-configure.sh >>> needs to be thrown away and regenerated. >>> >>> The entire benefit of having the file in the repo is to save >>> first-time developers the hassle of installing autoconf. On most >>> platforms, this is a no-brainer (like "apt install autoconf"), and >>> the requirement is similar to other open source projects using >>> autoconf and "./configure". It's just not worth it. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8195689 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8195689-remove-generated-configure/webrev.01 >>> >>> /Magnus >> > From andrew_m_leonard at uk.ibm.com Thu Feb 1 16:52:08 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 1 Feb 2018 16:52:08 +0000 Subject: Proposal: Make custom extension point additions In-Reply-To: <88a5bae4-252f-b084-0d7e-ec4e6c690441@oracle.com> References: <88a5bae4-252f-b084-0d7e-ec4e6c690441@oracle.com> Message-ID: Thanks Erik, I have moved the "post" hooks after the ###'s as you mentioned and similarly to the end for GensrcVarHandles.gmk. Here is the new hg diff -g patch, I have built it with the latest jdk head and run the jtreg tests successfully. Cheers Andrew diff --git a/make/common/SetupJavaCompilers.gmk b/make/common/SetupJavaCompilers.gmk --- a/make/common/SetupJavaCompilers.gmk +++ b/make/common/SetupJavaCompilers.gmk @@ -26,13 +26,16 @@ ifndef _SETUP_GMK _SETUP_GMK := 1 +# Include custom extension hook +$(eval $(call IncludeCustomExtension, common/SetupJavaCompilers.gmk)) + include JavaCompilation.gmk -DISABLE_WARNINGS := -Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally +DISABLE_WARNINGS ?= -Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally # If warnings needs to be non-fatal for testing purposes use a command like: # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" -JAVAC_WARNINGS := -Xlint:all -Werror +JAVAC_WARNINGS ?= -Xlint:all -Werror # The BOOT_JAVAC setup uses the boot jdk compiler to compile the tools # and the interim javac, to be run by the boot jdk. diff --git a/make/gensrc/GensrcVarHandles.gmk b/make/gensrc/GensrcVarHandles.gmk --- a/make/gensrc/GensrcVarHandles.gmk +++ b/make/gensrc/GensrcVarHandles.gmk @@ -168,3 +168,7 @@ $(eval $(call GenerateVarHandleByteArray,VAR_HANDLE_BYTE_ARRAY_$t,$t))) GENSRC_JAVA_BASE += $(GENSRC_VARHANDLES) + +# Include custom extension post hook +$(eval $(call IncludeCustomExtension, gensrc/GensrcVarHandles-post.gmk)) + diff --git a/make/lib/Lib-java.management.gmk b/make/lib/Lib-java.management.gmk --- a/make/lib/Lib-java.management.gmk +++ b/make/lib/Lib-java.management.gmk @@ -70,3 +70,7 @@ TARGETS += $(BUILD_LIBMANAGEMENT) ################################################################################ + +# Include custom extension post hook +$(eval $(call IncludeCustomExtension, lib/Lib-java.management-post.gmk)) + diff --git a/make/lib/Lib-jdk.management.gmk b/make/lib/Lib-jdk.management.gmk --- a/make/lib/Lib-jdk.management.gmk +++ b/make/lib/Lib-jdk.management.gmk @@ -80,3 +80,7 @@ TARGETS += $(BUILD_LIBMANAGEMENT_EXT) ################################################################################ + +# Include custom extension post hook +$(eval $(call IncludeCustomExtension, lib/Lib-jdk.management-post.gmk)) + Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Erik Joelsson To: Andrew Leonard , build-dev at openjdk.java.net Date: 31/01/2018 17:40 Subject: Re: Proposal: Make custom extension point additions Hello Andrew, This suggestion looks reasonable to me. Just a minor note on the placement of the post hooks. Especially in the Lib-* files, each individual library, or link entity, is put within ### separator lines. In the two files you modified, since there is only one library declared, this isn't as apparent. I would prefer if the post hook came after all the declared library sections instead of inside one of them. The Gensrc file is more of a snowflake so the placement is reasonable there. /Erik On 2018-01-31 03:21, Andrew Leonard wrote: > Hi, > I would like to find a sponsor for this change please? > To support certain extension capabilities I would like to propose the > following patch to the following make files, summary of changes: > M make/common/SetupJavaCompilers.gmk > ==> Add IncludeCustomExtension hook and allow custom override of > DISABLE_WARNINGS and JAVAC_WARNINGS > M make/gensrc/GensrcVarHandles.gmk > ==> Add IncludeCustomExtension "post" hook > M make/lib/Lib-java.management.gmk > ==> Add IncludeCustomExtension "post" hook > M make/lib/Lib-jdk.management.gmk > ==> Add IncludeCustomExtension "post" hook > > Many thanks, > Andrew > > hg diff -g output: > diff --git a/make/common/SetupJavaCompilers.gmk > b/make/common/SetupJavaCompilers.gmk > --- a/make/common/SetupJavaCompilers.gmk > +++ b/make/common/SetupJavaCompilers.gmk > @@ -26,13 +26,16 @@ > ifndef _SETUP_GMK > _SETUP_GMK := 1 > > +# Include custom extension hook > +$(eval $(call IncludeCustomExtension, common/SetupJavaCompilers.gmk)) > + > include JavaCompilation.gmk > > -DISABLE_WARNINGS := > -Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally > +DISABLE_WARNINGS ?= > -Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally > > # If warnings needs to be non-fatal for testing purposes use a command > like: > # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" > -JAVAC_WARNINGS := -Xlint:all -Werror > +JAVAC_WARNINGS ?= -Xlint:all -Werror > > # The BOOT_JAVAC setup uses the boot jdk compiler to compile the tools > # and the interim javac, to be run by the boot jdk. > diff --git a/make/gensrc/GensrcVarHandles.gmk > b/make/gensrc/GensrcVarHandles.gmk > --- a/make/gensrc/GensrcVarHandles.gmk > +++ b/make/gensrc/GensrcVarHandles.gmk > @@ -167,4 +167,7 @@ > $(foreach t, $(VARHANDLES_BYTE_ARRAY_TYPES), \ > $(eval $(call GenerateVarHandleByteArray,VAR_HANDLE_BYTE_ARRAY_$t,$t))) > > +# Include custom extension post hook > +$(eval $(call IncludeCustomExtension, gensrc/GensrcVarHandles-post.gmk)) > + > GENSRC_JAVA_BASE += $(GENSRC_VARHANDLES) > diff --git a/make/lib/Lib-java.management.gmk > b/make/lib/Lib-java.management.gmk > --- a/make/lib/Lib-java.management.gmk > +++ b/make/lib/Lib-java.management.gmk > @@ -67,6 +67,9 @@ > > $(BUILD_LIBMANAGEMENT): $(call FindLib, java.base, java) > > +# Include custom extension post hook > +$(eval $(call IncludeCustomExtension, lib/Lib-java.management-post.gmk)) > + > TARGETS += $(BUILD_LIBMANAGEMENT) > > > ################################################################################ > diff --git a/make/lib/Lib-jdk.management.gmk > b/make/lib/Lib-jdk.management.gmk > --- a/make/lib/Lib-jdk.management.gmk > +++ b/make/lib/Lib-jdk.management.gmk > @@ -77,6 +77,9 @@ > > $(BUILD_LIBMANAGEMENT_EXT): $(call FindLib, java.base, java) > > +# Include custom extension post hook > +$(eval $(call IncludeCustomExtension, lib/Lib-jdk.management-post.gmk)) > + > TARGETS += $(BUILD_LIBMANAGEMENT_EXT) > > > ################################################################################ > > > > > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From erik.joelsson at oracle.com Thu Feb 1 17:05:43 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Feb 2018 09:05:43 -0800 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> Message-ID: Am I understanding this correctly that it's really not tied to a gcc version but a cpu architecture, so it's only really affecting s390x? Are you also saying that gcc 7.2.1 is also affected but with a different message? I'm fine with disabling this warning conditional on s390x, no need for specific gcc versions. This discussion has already taken more time than it really warrants. :) Regarding warning chasing. I agree that we it's not feasible to chase down every warning in every version of GCC, or any other toolchain, but I also think that for platforms/configurations where people are actively developing changes for OpenJDK, it makes sense to try to keep it clean. This helps prevent new code from introducing warnings. For the configurations Oracle use, we keep a strict -Werror policy because we want the code to be clean. I'm fine with other users trying to keep the same standards on their configurations, but knowing that it will be their responsibility to keep up to date. I also think we need to be reasonably fine grained in when we disable warnings. Specifying every affected version of a toolchain is too much, but if there are specific well defined limits to where the disabling relevant, then I think we should use them, within reason. This also helps with keeping track of why a particular warning is disabled in a future attempt to fix them. On the other hand, if you are just building OpenJDK to produce binaries, without producing and up streaming new code changes, there really isn't much need for making the effort of trying to keep things clean, and trying to do so will likely just end up being more work than it's worth. /Erik On 2018-02-01 03:36, Adam Farley8 wrote: > Hi All, > > After doing some experimenting, I've discovered the problem isn't > limited to > SLES, or gcc 4.8.5, or zLinux. > > Platforms affected: zLinux, ppcle Linux > Platforms not affected: x86 Linux > > gcc versions affected: 4.8.5, 5.4.0 > gcc versions unaffected: 7.2.1 > > linux variations affected: Ubuntu, SLES > E.g. when I told SLES 12 (zLinux) to install gcc, it installed 5.4.0. > > All this tells me that, if we intent to encourage SLES 12 users to build > Java 11, we need this warning suppression hard coded. There are ways to > do "greater than"s and "first character in"s in make, but they require > either shell commands, or more dollar signs than you can shake a stick > at. > > I propose we hard code "array-bounds" into javajpeg's > DISABLED_WARNINGS_gcc > for all java versions, and move on. > > On the basis that gcc 7.2.1 produces a different error message when an > array-bounds problem occurs (e.g. frog[-1] produces the warning > "error: ?frog[-7]? is used uninitialized in this function"), I don't see > leaving array-bounds in DISABLED_WARNINGS_gcc as a problem. > > Thoughts? > > Best Regards > > Adam Farley > > > The claim on the wiki was made by Volker on July 13 2017. It was done on > > SuSE linux while the reported problem is on zLinux. Maybe they have > > different vendor specific patches in their respective gcc builds? Is SAP > > still able to build without --disable-warnings-as-errors? This wiki is > > supposed to be a community effort. > > > > /Erik > > > > > >On 2018-01-24 16:37, David Holmes wrote: > >> Hi Magnus, > >> > >> On 25/01/2018 9:55 AM, Magnus Ihse Bursie wrote: > >>> I'm not sure I'm able to follow where this discussion is heading, but > >>> at the very least I'd like to chime in on the patch below: > >>> > >>> I don't like how the entire DISABLED_WARNINGS_gcc line is lifted out. > >>> A better solution is something like this: > >>> > >>> ifeq ($(CC_VERSION_NUMBER), 4.8.5) > >>> ??#Turn off array-bounds warnings for libjava compilation because > >>> jchuff.c > >>> ??#fails to compile on gcc 4.8.5 with a warning that an array is > >>> potentially > >>> ??#out of bounds. This kills a warnings=errors build. > >>> ??LIBJAVAJPEG_DISABLED_WARNINGS_gcc485 := array-bounds > >>> endif > >>> ... > >>> DISABLED_WARNINGS_gcc := clobbered > >>> $(LIBJAVAJPEG_DISABLED_WARNINGS_gcc485), \ > >>> > >>> I also can't see this going into anything else than the current > >>> mainline, jdk/jdk i.e. JDK 11. Since the issue is trivially avoided > >>> by using --disable-warnings-as-errors, I hardly see that it warrants > >>> a backport. > >> > >> It's pointless in JDK 11 as we're not going to claim support for gcc > >> 4.8.5. > >> > >> The issue is that out-of-the-box if you are building 8u or 9 and use > >> gcc 4.8.5, which is supposed to be a valid compiler to use based on > >> the wiki, then it fails because of this gcc bug, unless you disable > >> warnings-as-errors. So either we put in a workaround for the bug or we > >> update to the build docs (and/or the wiki) to make it very clear that > >> you may need to disable warnings-as-errors (something there is no > >> mention of in the build doc in 9). > >> > >> David > >> ----- > >> > >>> /Magnus > >>> > >>> On 2018-01-23 14:44, Adam Farley8 wrote: > >>>> Hi All, > >>>> > >>>> All: I think I responded to everyone below. Please could a committer or > >>>> author raise a bug and, if people are happy with this change, line > >>>> it up > >>>> for contribution to JDKs 8-11 (assuming 4.8.5 is still the > >>>> recommended gcc > >>>> for JDK10 and 11 on SUSE sles)? > >>>> > >>>> Erik: One toolchain-specific change, as requested. This was tested > >>>> on JDK9, > >>>> so please apply an offset of -1 to the line numbers before applying > >>>> to JDK10. > >>>> > >>>> ----------------------- Start of Diff ----------------------- > >>>> > >>>> diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > >>>> --- a/make/lib/Awt2dLibraries.gmk > >>>> +++ b/make/lib/Awt2dLibraries.gmk > >>>> @@ -482,6 +482,14 @@ > >>>> ?BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC)) > >>>> ?endif > >>>> > >>>> +LIBJAVAJPEG_DISABLED_WARNINGS_gcc := clobbered > >>>> +ifeq ($(CC_VERSION_NUMBER), 4.8.5) > >>>> + ?#Turn off array-bounds warnings for libjava compilation because > >>>> jchuff.c > >>>> + ?#fails to compile on gcc 4.8.5 with a warning that an array is > >>>> potentially > >>>> + ?#out of bounds. This kills a warnings=errors build. > >>>> + ?LIBJAVAJPEG_DISABLED_WARNINGS_gcc := clobbered array-bounds > >>>> +endif > >>>> + > >>>> ?$(eval $(call SetupNativeCompilation,BUILD_LIBJAVAJPEG, \ > >>>> ? ? ?LIBRARY := javajpeg, \ > >>>> ? ? ?OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ > >>>> @@ -491,7 +499,7 @@ > >>>> ? ? ?CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \ > >>>> ? ?$(LIBJAVA_HEADER_FLAGS) \ > >>>> ?-I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \ > >>>> - ?DISABLED_WARNINGS_gcc := clobbered, \ > >>>> + ?DISABLED_WARNINGS_gcc := $(LIBJAVAJPEG_DISABLED_WARNINGS_gcc), \ > >>>> ? ? ?MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \ > >>>> ? ? ?LDFLAGS := $(LDFLAGS_JDKLIB) \ > >>>> ? ?$(call SET_SHARED_LIBRARY_ORIGIN), \ > >>>> > >>>> ----------------------- End of Diff ----------------------- > >>>> > >>>> Phil: I've changed the title as asked and supplied the diff above. > >>>> However, > >>>> I can't upload files to cr.openjdk.java.net, nor can I create bugs > >>>> myself. > >>>> I understand that authors and committers can, but I don't have those > >>>> privileges yet. Be nice if I did. :) > >>>> > >>>> John: I read your email, and I understand your position. I disagree > >>>> with it, > >>>> but I understand it. 4.8.5 is an old version of gcc, but right now > >>>> it is the > >>>> listed gcc version for SUSE sles on intel, ppc, ppcle, and zLinux. > >>>> Even if > >>>> this is not the case for JDK 10 or 11, we should ensure this fix is > >>>> fully > >>>> propagated to ensure consistent behaviour. > >>>> > >>>> That is my position. > >>>> > >>>> David: Thanks for the URL. I agree with your position on 4.8.5 gcc > >>>> needing > >>>> to compile OpenJDK without errors or special options. :) > >>>> > >>>> Best Regards > >>>> > >>>> Adam Farley > >>>> > >>>> > >>>> > >>>> From: Phil Race > >>>> To: Adam Farley8 , 2d-dev at openjdk.java.net > >>>> Cc: build-dev > >>>> Date: 18/01/2018 19:16 > >>>> Subject: Re: [OpenJDK 2D-Dev] [PATCH] Build fails to compile jchuff.c > >>>> ------------------------------------------------------------------------ > >>>> > >>>> > >>>> > >>>> > >>>> Try again with build-dev cc'd .. > >>>> > >>>> -phil. > >>>> > >>>> On 01/18/2018 11:14 AM, Phil Race wrote: > >>>> I agree with what Erik said on build-dev that being specific about > >>>> the tool chain > >>>> and the reason are worthwhile and important. We've done that in > >>>> similar cases. > >>>> > >>>> Also these review threads usually should have a subject like > >>>> RFR: : > >>>> > >>>> which means you first need a bug id .. the patch can't be pushed > >>>> without one anyway. > >>>> > >>>> Then the patch should be an in-line diff or a webrev hosted on > >>>> cr.openjdk.java.net. > >>>> > >>>> I think in-line would be OK for this small change. > >>>> > >>>> -phil. > >>>> > >>>> On 01/17/2018 09:30 AM, Adam Farley8 wrote: > >>>> Hi All, > >>>> > >>>> Under these circumstances, jchuff.c will not compile: > >>>> > >>>> Platform: zLinux (s390x) > >>>> Release: JDK9 (may affect other JDKs). > >>>> GCC Version: 4.8.5 > >>>> Notes: --disable-warnings-as-errors suppresses this error. > >>>> > >>>> The error is: > >>>> > >>>> /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c: > >>>> > >>>> In function 'jGenOptTbl': > >>>> /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c:808:18: > >>>> > >>>> error: array subscript is below array bounds [-Werror=array-bounds] > >>>> while (bits[j] == 0) > >>>> ? ? ? ? ? ?^ > >>>> > >>>> This is a continuation of a conversation in the build-dev mailing > >>>> list, if anyone wants to > >>>> check the history. > >>>> > >>>> The short version is that, while you *can* suppress the problem by > >>>> adding > >>>> --disable-warnings-as-errors to your configure step, I posit that a > >>>> builder shouldn't > >>>> have to. > >>>> > >>>> Various solutions were debated. One involves changing > >>>> Awt2dLibraries.gmk. > >>>> > >>>> Basically you change line 494 to this: > >>>> > >>>> DISABLED_WARNINGS_gcc := clobbered array-bounds, \ > >>>> > >>>> I'm running a build now to check that works, but basically we should > >>>> end up with a > >>>> -Wno-array-bounds on the gcc compile command for jchuff.c, thereby > >>>> ignoring the warning. > >>>> > >>>> A smarter variant involves checking for that specific version of the > >>>> gcc, but that seems > >>>> wordy to me for this problem. Keeping it simple. :) > >>>> > >>>> Thoughts? > >>>> > >>>> Best Regards > >>>> > >>>> Adam Farley > >>>> > >>>> Unless stated otherwise above: > >>>> IBM United Kingdom Limited - Registered in England and Wales with > >>>> number 741598. > >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > >>>> PO6 3AU > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Unless stated otherwise above: > >>>> IBM United Kingdom Limited - Registered in England and Wales with > >>>> number 741598. > >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > >>>> PO6 3AU > >>> > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From erik.joelsson at oracle.com Thu Feb 1 17:18:05 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Feb 2018 09:18:05 -0800 Subject: Proposal: Make custom extension point additions In-Reply-To: References: <88a5bae4-252f-b084-0d7e-ec4e6c690441@oracle.com> Message-ID: <8e129bef-5fb9-f924-09f7-6dde69e16d48@oracle.com> Hello Andrew, This looks good to me. I've created https://bugs.openjdk.java.net/browse/JDK-8196585 and will push it for you. /Erik On 2018-02-01 08:52, Andrew Leonard wrote: > Thanks Erik, > I have moved the "post" hooks after the ###'s as you mentioned and > similarly to the end for GensrcVarHandles.gmk. Here is the new hg diff > -g patch, I have built it with the latest jdk head and run the jtreg > tests successfully. > Cheers > Andrew > > diff --git a/make/common/SetupJavaCompilers.gmk > b/make/common/SetupJavaCompilers.gmk > --- a/make/common/SetupJavaCompilers.gmk > +++ b/make/common/SetupJavaCompilers.gmk > @@ -26,13 +26,16 @@ > ?ifndef _SETUP_GMK > ?_SETUP_GMK := 1 > > +# Include custom extension hook > +$(eval $(call IncludeCustomExtension, common/SetupJavaCompilers.gmk)) > + > ?include JavaCompilation.gmk > > -DISABLE_WARNINGS := > -Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally > +DISABLE_WARNINGS ?= > -Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally > > ?# If warnings needs to be non-fatal for testing purposes use a > command like: > ?# make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" > -JAVAC_WARNINGS := -Xlint:all -Werror > +JAVAC_WARNINGS ?= -Xlint:all -Werror > > ?# The BOOT_JAVAC setup uses the boot jdk compiler to compile the tools > ?# and the interim javac, to be run by the boot jdk. > diff --git a/make/gensrc/GensrcVarHandles.gmk > b/make/gensrc/GensrcVarHandles.gmk > --- a/make/gensrc/GensrcVarHandles.gmk > +++ b/make/gensrc/GensrcVarHandles.gmk > @@ -168,3 +168,7 @@ > ? ?$(eval $(call > GenerateVarHandleByteArray,VAR_HANDLE_BYTE_ARRAY_$t,$t))) > > ?GENSRC_JAVA_BASE += $(GENSRC_VARHANDLES) > + > +# Include custom extension post hook > +$(eval $(call IncludeCustomExtension, gensrc/GensrcVarHandles-post.gmk)) > + > diff --git a/make/lib/Lib-java.management.gmk > b/make/lib/Lib-java.management.gmk > --- a/make/lib/Lib-java.management.gmk > +++ b/make/lib/Lib-java.management.gmk > @@ -70,3 +70,7 @@ > ?TARGETS += $(BUILD_LIBMANAGEMENT) > > ?################################################################################ > > + > +# Include custom extension post hook > +$(eval $(call IncludeCustomExtension, lib/Lib-java.management-post.gmk)) > + > diff --git a/make/lib/Lib-jdk.management.gmk > b/make/lib/Lib-jdk.management.gmk > --- a/make/lib/Lib-jdk.management.gmk > +++ b/make/lib/Lib-jdk.management.gmk > @@ -80,3 +80,7 @@ > ?TARGETS += $(BUILD_LIBMANAGEMENT_EXT) > > ?################################################################################ > > + > +# Include custom extension post hook > +$(eval $(call IncludeCustomExtension, lib/Lib-jdk.management-post.gmk)) > + > > > > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Erik Joelsson > To: Andrew Leonard , > build-dev at openjdk.java.net > Date: 31/01/2018 17:40 > Subject: Re: Proposal: Make custom extension point additions > ------------------------------------------------------------------------ > > > > Hello Andrew, > > This suggestion looks reasonable to me. Just a minor note on the > placement of the post hooks. Especially in the Lib-* files, each > individual library, or link entity, is put within ### separator lines. > In the two files you modified, since there is only one library declared, > this isn't as apparent. I would prefer if the post hook came after all > the declared library sections instead of inside one of them. The Gensrc > file is more of a snowflake so the placement is reasonable there. > > /Erik > > > On 2018-01-31 03:21, Andrew Leonard wrote: > > Hi, > > I would like to find a sponsor for this change please? > > To support certain extension capabilities I would like to propose the > > following patch to the following make files, summary of changes: > > ? ? ?M make/common/SetupJavaCompilers.gmk > > ? ? ? ? ?==> Add IncludeCustomExtension hook and allow custom > override of > > DISABLE_WARNINGS and JAVAC_WARNINGS > > ? ? ?M make/gensrc/GensrcVarHandles.gmk > > ? ? ? ? ?==> Add IncludeCustomExtension "post" hook > > ? ? ?M make/lib/Lib-java.management.gmk > > ? ? ? ? ?==> Add IncludeCustomExtension "post" hook > > ? ? ?M make/lib/Lib-jdk.management.gmk > > ? ? ? ? ?==> Add IncludeCustomExtension "post" hook > > > > Many thanks, > > Andrew > > > > hg diff -g output: > > diff --git a/make/common/SetupJavaCompilers.gmk > > b/make/common/SetupJavaCompilers.gmk > > --- a/make/common/SetupJavaCompilers.gmk > > +++ b/make/common/SetupJavaCompilers.gmk > > @@ -26,13 +26,16 @@ > > ? ifndef _SETUP_GMK > > ? _SETUP_GMK := 1 > > > > +# Include custom extension hook > > +$(eval $(call IncludeCustomExtension, common/SetupJavaCompilers.gmk)) > > + > > ? include JavaCompilation.gmk > > > > -DISABLE_WARNINGS := > > > -Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally > > +DISABLE_WARNINGS ?= > > > -Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally > > > > ? # If warnings needs to be non-fatal for testing purposes use a command > > like: > > ? # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" > > -JAVAC_WARNINGS := -Xlint:all -Werror > > +JAVAC_WARNINGS ?= -Xlint:all -Werror > > > > ? # The BOOT_JAVAC setup uses the boot jdk compiler to compile the tools > > ? # and the interim javac, to be run by the boot jdk. > > diff --git a/make/gensrc/GensrcVarHandles.gmk > > b/make/gensrc/GensrcVarHandles.gmk > > --- a/make/gensrc/GensrcVarHandles.gmk > > +++ b/make/gensrc/GensrcVarHandles.gmk > > @@ -167,4 +167,7 @@ > > ? $(foreach t, $(VARHANDLES_BYTE_ARRAY_TYPES), \ > > ? ? $(eval $(call > GenerateVarHandleByteArray,VAR_HANDLE_BYTE_ARRAY_$t,$t))) > > > > +# Include custom extension post hook > > +$(eval $(call IncludeCustomExtension, > gensrc/GensrcVarHandles-post.gmk)) > > + > > ? GENSRC_JAVA_BASE += $(GENSRC_VARHANDLES) > > diff --git a/make/lib/Lib-java.management.gmk > > b/make/lib/Lib-java.management.gmk > > --- a/make/lib/Lib-java.management.gmk > > +++ b/make/lib/Lib-java.management.gmk > > @@ -67,6 +67,9 @@ > > > > ? $(BUILD_LIBMANAGEMENT): $(call FindLib, java.base, java) > > > > +# Include custom extension post hook > > +$(eval $(call IncludeCustomExtension, > lib/Lib-java.management-post.gmk)) > > + > > ? TARGETS += $(BUILD_LIBMANAGEMENT) > > > > > > > ################################################################################ > > diff --git a/make/lib/Lib-jdk.management.gmk > > b/make/lib/Lib-jdk.management.gmk > > --- a/make/lib/Lib-jdk.management.gmk > > +++ b/make/lib/Lib-jdk.management.gmk > > @@ -77,6 +77,9 @@ > > > > ? $(BUILD_LIBMANAGEMENT_EXT): $(call FindLib, java.base, java) > > > > +# Include custom extension post hook > > +$(eval $(call IncludeCustomExtension, lib/Lib-jdk.management-post.gmk)) > > + > > ? TARGETS += $(BUILD_LIBMANAGEMENT_EXT) > > > > > > > ################################################################################ > > > > > > > > > > > > > > Andrew Leonard > > Java Runtimes Development > > IBM Hursley > > IBM United Kingdom Ltd > > Phone internal: 245913, external: 01962 815913 > > internet email: andrew_m_leonard at uk.ibm.com > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From javalists at cbfiddle.com Thu Feb 1 17:57:39 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 1 Feb 2018 09:57:39 -0800 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> Message-ID: <6FE85EAB-8B0E-46B6-B347-2982A4C0371F@cbfiddle.com> > On Feb 1, 2018, at 9:05 AM, Erik Joelsson wrote: > > Regarding warning chasing. I agree that we it's not feasible to chase down every warning in every version of GCC, or any other toolchain, but I also think that for platforms/configurations where people are actively developing changes for OpenJDK, it makes sense to try to keep it clean. This helps prevent new code from introducing warnings. For the configurations Oracle use, we keep a strict -Werror policy because we want the code to be clean Is it not the case that building on macOS requires -disable-warnings-as-errors? Or is that only the case on more recent macOS releases that used by Oracle? Alan From erik.joelsson at oracle.com Thu Feb 1 18:04:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Feb 2018 10:04:32 -0800 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: <6FE85EAB-8B0E-46B6-B347-2982A4C0371F@cbfiddle.com> References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> <6FE85EAB-8B0E-46B6-B347-2982A4C0371F@cbfiddle.com> Message-ID: <74614e6d-a4d4-1aae-6f6a-bd5f9771b549@oracle.com> Hello, Oracle still builds JDK 10 and 11 using Xcode 6.3 using the Macosx10.9 sdk. We are warning free there. Using newer versions of Xcode is known to produce warnings. I'm currently in the process of updating the toolchain versions and platforms we use at Oracle so this should get fixed in the near future for JDK 11. Note though that it will deteriorate again with even newer versions of Xcode unless someone else provides fixes for it before we switch toolchain versions again. /Erik On 2018-02-01 09:57, Alan Snyder wrote: > >> On Feb 1, 2018, at 9:05 AM, Erik Joelsson > > wrote: >> >> Regarding warning chasing. I agree that we it's not feasible to chase >> down every warning in every version of GCC, or any other toolchain, >> but I also think that for platforms/configurations where people are >> actively developing changes for OpenJDK, it makes sense to try to >> keep it clean. This helps prevent new code from introducing warnings. >> For the configurations Oracle use, we keep a strict -Werror policy >> because we want the code to be clean > > Is it not the case that building on macOS requires > -disable-warnings-as-errors? Or is that only the case on more recent > macOS releases that used by Oracle? > > ? Alan > From christoph.langer at sap.com Fri Feb 2 09:21:17 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 2 Feb 2018 09:21:17 +0000 Subject: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() In-Reply-To: <5A7331D9.9000800@oracle.com> References: <5A6A2611.4030003@oracle.com> <5A7331D9.9000800@oracle.com> Message-ID: <9c23cba20f7649459f6a3059f80cb834@sap.com> Hi Gary, > Here's a revised webrev > > http://cr.openjdk.java.net/~gadams/8080990/webrev.01/index.html > > Still testing ... > > Using shutdown() fixed problems reported by the > java/nio/channelSocketChannel tests. The fix looks good. I would think we should rename dbgsysInetAddr to dbgsysPToN and use inet_pton also for the Unix/Linux platforms. It would be the better choice there as well, though we still only support IPv4 in libdt_socket. > > I also noticed prior use of getaddrinfo for "localhost" was not calling > freeaddrinfo. Thanks for spotting/fixing that. Best regards Christoph From archana.nogriya at uk.ibm.com Fri Feb 2 14:18:06 2018 From: archana.nogriya at uk.ibm.com (Archana Nogriya) Date: Fri, 2 Feb 2018 14:18:06 +0000 Subject: Contribute towards native code which override to OpenJDK In-Reply-To: References: Message-ID: Hi Erik, Sorry for delay, I took sometime to investigate what you had mentioned earlier and verified the build for native code overriding without having our fix with all possible scenarios. And I can confirm that it is working as you mentioned. Which means, this fix must have done after we made our internal fix. I will remove our fix then. :) Many Thanks Thanks and Regards Archana Nogriya IBM Java Runtime, Open Java Developer IBM Hursley Tel: Internal - 247073, External - +44 (0) 1962 81 7073 Office Mobile: 07500095480 Email: archana.nogriya at uk.ibm.com From: Erik Joelsson To: Archana Nogriya , build-dev at openjdk.java.net Date: 22/01/2018 17:14 Subject: Re: Contribute towards native code which override to OpenJDK Hello Archana, Before attempting this change, did you actually try overriding native source files? The support for this has been in NativeCompilation.gmk since a very long time (well before the support for overriding java source files was added) using this piece of logic further up the file: # Generate the .o (.obj) file name and place it in the bin dir. $1_$2_OBJ := $3/$$(call replace_with_obj_extension, $$(notdir $2)) # Only continue if this object file hasn't been processed already. This lets the first found # source file override any other with the same name. ifeq (,$$(findstring $$($1_$2_OBJ),$$($1_OBJS_SO_FAR))) $1_OBJS_SO_FAR+=$$($1_$2_OBJ) This also relies on the line from your patch below: # Find all files in the source trees. Preserve order. $1_SRCS := $$(foreach s, $$($1_SRC), $$(call CacheFind,$$(s))) By preserving order of source dirs, we let the first listed source location override any later location. We use this both for overriding shared code with platform specific as well as closed overriding open. If this is not working for you, I would be interested to know how your use case differs from ours. /Erik On 2018-01-19 05:07, Archana Nogriya wrote: > Hi, > > Why this contribution is required > > These changes are to support the override of native C/C++ source by the > SetupNativeCompilation macro in a similar way to how java classes can be > overridden in SetupJavaCompilation. This will enable extension/closed > source providers to easily override native implementations. > > Changes were made in: > > make/common/NativeCompilation.gmk > diff -r 3a52333a5e57 make/common/NativeCompilation.gmk > --- a/make/common/NativeCompilation.gmk Tue Jan 02 16:35:04 2018 -0500 > +++ b/make/common/NativeCompilation.gmk Tue Jan 16 13:42:54 2018 +0000 > @@ -511,8 +511,14 @@ > $$(error SRC specified to SetupNativeCompilation $1 contains > missing directory $$d))) > > # Find all files in the source trees. Preserve order. > - $1_SRCS := $$(foreach s, $$($1_SRC), $$(call CacheFind,$$(s))) > + $1_SRCS := $$(call uniq, $$(foreach s, $$($1_SRC), $$(call > CacheFind,$$(s)))) > $1_SRCS := $$(filter $$(NATIVE_SOURCE_EXTENSIONS), $$($1_SRCS)) > + $1_SRCS := $$(strip $$(foreach s, $$($1_SRCS), \ > + $$(eval relative_src := $$(call remove-prefixes, $$($1_SRC), > $$(s))) \ > + $$(if $$($1_$$(relative_src)), \ > + $$(eval $1_NATIVE_EXCLUDE_FILES += $$(s)), \ > + $$(eval $1_$$(relative_src) := 1) $$(s)))) > + $1_SRCS := $$(filter-out $$($1_NATIVE_EXCLUDE_FILES), $$($1_SRCS)) > # Extract the C/C++ files. > ifneq ($$($1_EXCLUDE_PATTERNS), ) > # We must not match the exclude pattern against the src root(s). > > > > This new code has been tested by building with latest JDK11. Build has > been successful. > Please let me know what is your view on these changes and if we can > contribute to openJDK. > > > Thanks and Regards > Archana Nogriya > IBM Java Runtime, Open Java Developer > IBM Hursley > Tel: Internal - 247073, External - +44 (0) 1962 81 7073 > Office Mobile: 07500095480 > Email: archana.nogriya at uk.ibm.com > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From jonathan.gibbons at oracle.com Fri Feb 2 21:42:50 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 02 Feb 2018 13:42:50 -0800 Subject: RFR: 8195795: Organize javadoc output files by module/package, not just package Message-ID: <5A74DB5A.4030802@oracle.com> Please review changes, including a couple of small build changes, to reorganize the generated documentation into per-module directories. Build folk: the changes are just to move the generated module graph images into the new hierarchy. Javadoc folk: the changes are mostly simple, with most of the "magic" happening in the DocPaths factory class, creating old-style or new-style paths as appropriate. Care is taken in DocFilesHandlerImpl, where DocPath objects are used for input, and have to work in conjunction with the module Locations. Other than than, some factory methods moved from DocPath to DocPaths, and most factory methods were changed from static to instance methods, to be able to take the interim backwards-compatibility option into account. This work leverages JDK-8195796, to reduce the size of relative URLs in generated docs. JBS: https://bugs.openjdk.java.net/browse/JDK-8195795 CSR: https://bugs.openjdk.java.net/browse/JDK-8196112 Webrev: http://cr.openjdk.java.net/~jjg/8195795/webrev.00/ -- Jon From erik.joelsson at oracle.com Fri Feb 2 21:56:40 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 2 Feb 2018 13:56:40 -0800 Subject: RFR: 8195795: Organize javadoc output files by module/package, not just package In-Reply-To: <5A74DB5A.4030802@oracle.com> References: <5A74DB5A.4030802@oracle.com> Message-ID: <0095177d-48c8-d8ad-f002-25ae740c9413@oracle.com> Build change looks good to me. /Erik On 2018-02-02 13:42, Jonathan Gibbons wrote: > Please review changes, including a couple of small build changes, to > reorganize the generated > documentation into per-module directories. > > Build folk: the changes are just to move the generated module graph > images into the new hierarchy. > > Javadoc folk: the changes are mostly simple, with most of the "magic" > happening in the DocPaths factory class, creating old-style or > new-style paths as appropriate. Care is taken in DocFilesHandlerImpl, > where DocPath objects are used for input, and have to work in > conjunction with the module Locations.? Other than than, some factory > methods moved from DocPath to DocPaths, and most factory methods were > changed from static to instance methods, to be able to take the > interim backwards-compatibility option into account. > > This work leverages JDK-8195796, to reduce the size of relative URLs > in generated docs. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8195795 > CSR: https://bugs.openjdk.java.net/browse/JDK-8196112 > Webrev: http://cr.openjdk.java.net/~jjg/8195795/webrev.00/ > > -- Jon From mandy.chung at oracle.com Fri Feb 2 22:02:11 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 2 Feb 2018 14:02:11 -0800 Subject: RFR: 8195795: Organize javadoc output files by module/package, not just package In-Reply-To: <5A74DB5A.4030802@oracle.com> References: <5A74DB5A.4030802@oracle.com> Message-ID: <7be2e3f1-d8da-64ce-a75f-a99d7dabb07c@oracle.com> $MODULE-graph.png to $MODULE/module-graph.png change looks fine. Mandy On 2/2/18 1:42 PM, Jonathan Gibbons wrote: > Please review changes, including a couple of small build changes, to > reorganize the generated > documentation into per-module directories. > > Build folk: the changes are just to move the generated module graph > images into the new hierarchy. > > Javadoc folk: the changes are mostly simple, with most of the "magic" > happening in the DocPaths factory class, creating old-style or > new-style paths as appropriate. Care is taken in DocFilesHandlerImpl, > where DocPath objects are used for input, and have to work in > conjunction with the module Locations.? Other than than, some factory > methods moved from DocPath to DocPaths, and most factory methods were > changed from static to instance methods, to be able to take the > interim backwards-compatibility option into account. > > This work leverages JDK-8195796, to reduce the size of relative URLs > in generated docs. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8195795 > CSR: https://bugs.openjdk.java.net/browse/JDK-8196112 > Webrev: http://cr.openjdk.java.net/~jjg/8195795/webrev.00/ > > -- Jon From martinrb at google.com Mon Feb 5 18:39:49 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 5 Feb 2018 10:39:49 -0800 Subject: "no tests selected" running tests in the test/jdk directory Message-ID: if I cd test/jdk && make all ... I get Test results: no tests selected ... Summary: jdk_default TEST STATS: name=jdk_default run=0 pass=0 fail=0 --- Also I find I have to define PRODUCT_HOME and JT_HOME as environment variables - make variables are insufficient From gary.adams at oracle.com Mon Feb 5 19:15:10 2018 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 05 Feb 2018 14:15:10 -0500 Subject: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() In-Reply-To: <5A731457.1040502@oracle.com> References: <5A6A2611.4030003@oracle.com> <5A731457.1040502@oracle.com> Message-ID: <5A78AD3E.9090503@oracle.com> One more to fix to cover the remaining test failures I was seeing. Previously, using inet_addr, there was a single -1 return that needed to be checked. Now that we're using inet_pton, there is a -1 and a 0 error return to be considered. My preference would be to leave the dbgSysInetAddr name unchanged and have the low level check for inet_pton errors to simply return the -1 that was previously checked. This specific issue is about the deprecation of library functions on windows. I'd recommend not upgrading the other platforms at this time until a complete update is done for ipv6 support. I'll post a new webrev when I've retested using the updated inet_pton error checking. ... > Hi Gary, > > > >/ Here's a revised webrev > />/ > />/ http://cr.openjdk.java.net/~gadams/8080990/webrev.01/index.html > />/ > />/ Still testing ... > />/ > />/ Using shutdown() fixed problems reported by the > />/ java/nio/channelSocketChannel tests. > / > The fix looks good. I would think we should rename dbgsysInetAddr to dbgsysPToN and use inet_pton also for the Unix/Linux platforms. It would be the better choice there as well, though we still only support IPv4 in libdt_socket. > > >/ > />/ I also noticed prior use of getaddrinfo for "localhost" was not calling > />/ freeaddrinfo. > / > Thanks for spotting/fixing that. > > Best regards > Christoph > From magnus.ihse.bursie at oracle.com Mon Feb 5 19:22:28 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 5 Feb 2018 20:22:28 +0100 Subject: "no tests selected" running tests in the test/jdk directory In-Reply-To: References: Message-ID: <177798CA-0A6F-47CB-9D95-C1EB0610C93D@oracle.com> Use make run-test TEST="test/jdk" instead. /Magnus > 5 feb. 2018 kl. 19:39 skrev Martin Buchholz : > > if I > cd test/jdk && make all ... > I get > > Test results: no tests selected > ... > Summary: jdk_default > TEST STATS: name=jdk_default run=0 pass=0 fail=0 > > --- > > Also I find I have to define PRODUCT_HOME and JT_HOME as environment > variables - make variables are insufficient From magnus.ihse.bursie at oracle.com Mon Feb 5 20:05:06 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 5 Feb 2018 21:05:06 +0100 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> Message-ID: <75fb3672-25dc-87bd-49c6-817221eaa191@oracle.com> Let's move this discussion to build-dev instead of jdk-dev. On 2018-02-05 17:30, Thomas St?fe wrote: > Hi Magnus, > > On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie > > > wrote: > > With the new solution, the exact version of autoconf does > not matter. > > > It seems to matter. I now get: > > Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.63] > stdin:33: error: Autoconf version 2.69 or higher is required > stdin:33: the top level > autom4te: /usr/bin/m4 failed with exit status: 63 > > Do we actually need this strict check for the autoconf version? Is > there a way to disable the check and retry with my old version? The check is enforced by AC_PREREQ([2.69]) in the top of make/autoconf/configure.ac. You could try removing it and see what happens. In the "best" case you'll get an error message when autoconf tries to generate the file, then we know for certain that it does not work. :-) Otherwise, you'll have to test the generated configure file more thoroughly to ensure that it really works. I'm quite certain that older versions (and believe me, everything prior to 2.69 is *ancient*) did not work at all, and that was the reason we added that requirement. /Magnus > > I would dislike for this to be a frequent error now - unfortunately, > we have some build environments where getting the latest GNU tools is > more work than just running an installer. > > Thanks, Thomas > > > The build documentation has been updated to reflect this change. > > /Magnus > > From magnus.ihse.bursie at oracle.com Mon Feb 5 20:14:10 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 5 Feb 2018 21:14:10 +0100 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: <75fb3672-25dc-87bd-49c6-817221eaa191@oracle.com> References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> <75fb3672-25dc-87bd-49c6-817221eaa191@oracle.com> Message-ID: <74c81f6c-e0f8-55c6-61fb-c1888a06f7b2@oracle.com> On 2018-02-05 21:05, Magnus Ihse Bursie wrote: > Let's move this discussion to build-dev instead of jdk-dev. > > On 2018-02-05 17:30, Thomas St?fe wrote: >> Hi Magnus, >> >> On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie >> > > wrote: >> >> ??? With the new solution, the exact version of autoconf does >> ??? not matter. >> >> >> It seems to matter. I now get: >> >> Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.63] >> stdin:33: error: Autoconf version 2.69 or higher is required >> stdin:33: the top level >> autom4te: /usr/bin/m4 failed with exit status: 63 >> >> Do we actually need this strict check for the autoconf version? Is >> there a way to disable the check and retry with my old version? > > The check is enforced by > AC_PREREQ([2.69]) > > in the top of make/autoconf/configure.ac. > > You could try removing it and see what happens. In the "best" case > you'll get an error message when autoconf tries to generate the file, > then we know for certain that it does not work. :-) Otherwise, you'll > have to test the generated configure file more thoroughly to ensure > that it really works. > > I'm quite certain that older versions (and believe me, everything > prior to 2.69 is *ancient*) did not work at all, and that was the > reason we added that requirement. Some code archeology gave me this: https://bugs.openjdk.java.net/browse/JDK-8023957 It seems that we at least supported 2.67 at the time, but we executable was not commonly (?) named "autoconf" so we couldn't autodetect it. Still can't say about 2.63 though. > > /Magnus > >> >> I would dislike for this to be a frequent error now - unfortunately, >> we have some build environments where getting the latest GNU tools is >> more work than just running an installer. >> >> Thanks, Thomas >> >> >> ??? The build documentation has been updated to reflect this change. >> >> ??? /Magnus >> >> > From martinrb at google.com Mon Feb 5 20:22:00 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 5 Feb 2018 12:22:00 -0800 Subject: "no tests selected" running tests in the test/jdk directory In-Reply-To: <177798CA-0A6F-47CB-9D95-C1EB0610C93D@oracle.com> References: <177798CA-0A6F-47CB-9D95-C1EB0610C93D@oracle.com> Message-ID: Ahh, I had forgotten we are in the middle of a transition to "run-test". I need to read doc/testing.md. On Mon, Feb 5, 2018 at 11:22 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > Use make run-test TEST="test/jdk" instead. > > /Magnus > > > 5 feb. 2018 kl. 19:39 skrev Martin Buchholz : > > > > if I > > cd test/jdk && make all ... > > I get > > > > Test results: no tests selected > > ... > > Summary: jdk_default > > TEST STATS: name=jdk_default run=0 pass=0 fail=0 > > > > --- > > > > Also I find I have to define PRODUCT_HOME and JT_HOME as environment > > variables - make variables are insufficient > From erik.joelsson at oracle.com Mon Feb 5 22:14:49 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Feb 2018 14:14:49 -0800 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: <74c81f6c-e0f8-55c6-61fb-c1888a06f7b2@oracle.com> References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> <75fb3672-25dc-87bd-49c6-817221eaa191@oracle.com> <74c81f6c-e0f8-55c6-61fb-c1888a06f7b2@oracle.com> Message-ID: Hello, In that change I bumped the number from 2.61 to 2.67. The original 2.61 was put there by Fredrik very early in the build-infra conversion and I don't know where that came from. The main reason for us to pick just one version was because we wanted to avoid large differences in the committed generated file. Since we are no longer committing the file, I don't see a good reason to enforce a particular version, but we also should not change this number until someone has verified that a particular version works reasonably well. It should also be noted that installing autoconf from src is trivially simple. The build has very few prerequisites and takes seconds to complete. I've never failed on any of the platforms I've tried it on over the years. /Erik On 2018-02-05 12:14, Magnus Ihse Bursie wrote: > On 2018-02-05 21:05, Magnus Ihse Bursie wrote: >> Let's move this discussion to build-dev instead of jdk-dev. >> >> On 2018-02-05 17:30, Thomas St?fe wrote: >>> Hi Magnus, >>> >>> On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie >>> >> > wrote: >>> >>> ??? With the new solution, the exact version of autoconf does >>> ??? not matter. >>> >>> >>> It seems to matter. I now get: >>> >>> Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.63] >>> stdin:33: error: Autoconf version 2.69 or higher is required >>> stdin:33: the top level >>> autom4te: /usr/bin/m4 failed with exit status: 63 >>> >>> Do we actually need this strict check for the autoconf version? Is >>> there a way to disable the check and retry with my old version? >> >> The check is enforced by >> AC_PREREQ([2.69]) >> >> in the top of make/autoconf/configure.ac. >> >> You could try removing it and see what happens. In the "best" case >> you'll get an error message when autoconf tries to generate the file, >> then we know for certain that it does not work. :-) Otherwise, you'll >> have to test the generated configure file more thoroughly to ensure >> that it really works. >> >> I'm quite certain that older versions (and believe me, everything >> prior to 2.69 is *ancient*) did not work at all, and that was the >> reason we added that requirement. > Some code archeology gave me this: > https://bugs.openjdk.java.net/browse/JDK-8023957 > > It seems that we at least supported 2.67 at the time, but we > executable was not commonly (?) named "autoconf" so we couldn't > autodetect it. Still can't say about 2.63 though. > >> >> /Magnus >> >>> >>> I would dislike for this to be a frequent error now - unfortunately, >>> we have some build environments where getting the latest GNU tools >>> is more work than just running an installer. >>> >>> Thanks, Thomas >>> >>> >>> ??? The build documentation has been updated to reflect this change. >>> >>> ??? /Magnus >>> >>> >> > From erik.joelsson at oracle.com Mon Feb 5 22:54:11 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Feb 2018 14:54:11 -0800 Subject: RFR: JDK-8196803: Fix build warnings in jdk libraries with Xcode 9 Message-ID: When building with Xcode 9, we get some warnings triggered in jdk libraries. This patch tries to fix them. See bug description for more details on each of them. In short the following things are addressed: In src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m, remove the check on MAC_OS_X_VERSION_MAX_ALLOWED. I don't think that's relevant. The source needs to compile against the headers that are present. This was touched on earlier in this thread: http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019486.html and when going back, it's quite clear to me that the fix done there was incorrect. In src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c, we can't modify the source file itself, so here I've added a wrapper for zlib.h that rewrites the ZLIB_VERNUM macro to a version that matches what's available on the Macosx version we are building for. This type of override can be brittle but seems to work OK in this case. While doing this, I also refactored the handling of libz cflags and libs. They are better set and exported from configure to be globally available in the build. We also get warnings when linking static libraries. These are easily fixed by adding the -mmacosx-version-min= arguments on these command lines just like we do for linking shared libraries and executables. I solved this by setting ARFLAGS and actually use that variable. Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html Bug: https://bugs.openjdk.java.net/browse/JDK-8196803 /Erik From tim.bell at oracle.com Tue Feb 6 00:00:36 2018 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 05 Feb 2018 16:00:36 -0800 Subject: RFR: JDK-8196803: Fix build warnings in jdk libraries with Xcode 9 In-Reply-To: References: Message-ID: <5A78F024.7040102@oracle.com> Erik: > Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196803 Looks good. /Tim From david.holmes at oracle.com Tue Feb 6 01:25:28 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Feb 2018 11:25:28 +1000 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 Message-ID: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> It's time to increment the actual version to 11 for JDK 11. Joe Darcy and I have worked through numerous test issues that delayed the update and I've been addressing a number of issues in hotspot related to obsolete/expired flag warnings. I have tested the update with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI failures for either JDK or HS pipelines. Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 Change: --- a/make/autoconf/version-numbers +++ b/make/autoconf/version-numbers @@ -25,7 +25,7 @@ # Default version numbers to use unless overridden by configure -DEFAULT_VERSION_FEATURE=10 +DEFAULT_VERSION_FEATURE=11 DEFAULT_VERSION_INTERIM=0 DEFAULT_VERSION_UPDATE=0 DEFAULT_VERSION_PATCH=0 Thanks, David From joe.darcy at oracle.com Tue Feb 6 01:32:40 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 05 Feb 2018 17:32:40 -0800 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 In-Reply-To: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> References: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> Message-ID: <5A7905B8.7080203@oracle.com> Ship it :-) -Joe On 2/5/2018 5:25 PM, David Holmes wrote: > It's time to increment the actual version to 11 for JDK 11. > > Joe Darcy and I have worked through numerous test issues that delayed > the update and I've been addressing a number of issues in hotspot > related to obsolete/expired flag warnings. I have tested the update > with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI > failures for either JDK or HS pipelines. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 > > Change: > > --- a/make/autoconf/version-numbers > +++ b/make/autoconf/version-numbers > @@ -25,7 +25,7 @@ > > # Default version numbers to use unless overridden by configure > > -DEFAULT_VERSION_FEATURE=10 > +DEFAULT_VERSION_FEATURE=11 > DEFAULT_VERSION_INTERIM=0 > DEFAULT_VERSION_UPDATE=0 > DEFAULT_VERSION_PATCH=0 > > Thanks, > David From martinrb at google.com Tue Feb 6 01:39:30 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 5 Feb 2018 17:39:30 -0800 Subject: "no tests selected" running tests in the test/jdk directory In-Reply-To: References: <177798CA-0A6F-47CB-9D95-C1EB0610C93D@oracle.com> Message-ID: OK, I did some reading up in doc/testing.md. I noticed #### TEST_MODE The test mode (`-agentvm`, `-samevm` or `-othervm`). but TEST_MODE=-agentvm is rejected - it must be TEST_MODE=agentvm. I suggest removing the dashes in the doc and perhaps changing the code to accept and ignore initial dashes. On Mon, Feb 5, 2018 at 12:22 PM, Martin Buchholz wrote: > Ahh, I had forgotten we are in the middle of a transition to "run-test". > I need to read doc/testing.md. > > On Mon, Feb 5, 2018 at 11:22 AM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> Use make run-test TEST="test/jdk" instead. >> >> /Magnus >> >> > 5 feb. 2018 kl. 19:39 skrev Martin Buchholz : >> > >> > if I >> > cd test/jdk && make all ... >> > I get >> > >> > Test results: no tests selected >> > ... >> > Summary: jdk_default >> > TEST STATS: name=jdk_default run=0 pass=0 fail=0 >> > >> > --- >> > >> > Also I find I have to define PRODUCT_HOME and JT_HOME as environment >> > variables - make variables are insufficient >> > > From mandy.chung at oracle.com Tue Feb 6 01:46:50 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 5 Feb 2018 17:46:50 -0800 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 In-Reply-To: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> References: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> Message-ID: <03f6ae5a-b56f-2efb-575b-7a7c11df357a@oracle.com> +1 Mandy On 2/5/18 5:25 PM, David Holmes wrote: > It's time to increment the actual version to 11 for JDK 11. > > Joe Darcy and I have worked through numerous test issues that delayed > the update and I've been addressing a number of issues in hotspot > related to obsolete/expired flag warnings. I have tested the update > with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI > failures for either JDK or HS pipelines. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 > > Change: > > --- a/make/autoconf/version-numbers > +++ b/make/autoconf/version-numbers > @@ -25,7 +25,7 @@ > > ?# Default version numbers to use unless overridden by configure > > -DEFAULT_VERSION_FEATURE=10 > +DEFAULT_VERSION_FEATURE=11 > ?DEFAULT_VERSION_INTERIM=0 > ?DEFAULT_VERSION_UPDATE=0 > ?DEFAULT_VERSION_PATCH=0 > > Thanks, > David From david.holmes at oracle.com Tue Feb 6 02:25:45 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Feb 2018 12:25:45 +1000 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 In-Reply-To: <5A7905B8.7080203@oracle.com> References: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> <5A7905B8.7080203@oracle.com> Message-ID: Thanks Joe! David On 6/02/2018 11:32 AM, Joseph D. Darcy wrote: > Ship it :-) > > -Joe > > On 2/5/2018 5:25 PM, David Holmes wrote: >> It's time to increment the actual version to 11 for JDK 11. >> >> Joe Darcy and I have worked through numerous test issues that delayed >> the update and I've been addressing a number of issues in hotspot >> related to obsolete/expired flag warnings. I have tested the update >> with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI >> failures for either JDK or HS pipelines. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 >> >> Change: >> >> --- a/make/autoconf/version-numbers >> +++ b/make/autoconf/version-numbers >> @@ -25,7 +25,7 @@ >> >> ?# Default version numbers to use unless overridden by configure >> >> -DEFAULT_VERSION_FEATURE=10 >> +DEFAULT_VERSION_FEATURE=11 >> ?DEFAULT_VERSION_INTERIM=0 >> ?DEFAULT_VERSION_UPDATE=0 >> ?DEFAULT_VERSION_PATCH=0 >> >> Thanks, >> David > From david.holmes at oracle.com Tue Feb 6 02:26:01 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Feb 2018 12:26:01 +1000 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 In-Reply-To: <03f6ae5a-b56f-2efb-575b-7a7c11df357a@oracle.com> References: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> <03f6ae5a-b56f-2efb-575b-7a7c11df357a@oracle.com> Message-ID: <31f51327-ff4e-a46b-f6e0-0cb7271baa98@oracle.com> Thanks Mandy! David On 6/02/2018 11:46 AM, mandy chung wrote: > +1 Mandy > > > On 2/5/18 5:25 PM, David Holmes wrote: >> It's time to increment the actual version to 11 for JDK 11. >> >> Joe Darcy and I have worked through numerous test issues that delayed >> the update and I've been addressing a number of issues in hotspot >> related to obsolete/expired flag warnings. I have tested the update >> with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI >> failures for either JDK or HS pipelines. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 >> >> Change: >> >> --- a/make/autoconf/version-numbers >> +++ b/make/autoconf/version-numbers >> @@ -25,7 +25,7 @@ >> >> ?# Default version numbers to use unless overridden by configure >> >> -DEFAULT_VERSION_FEATURE=10 >> +DEFAULT_VERSION_FEATURE=11 >> ?DEFAULT_VERSION_INTERIM=0 >> ?DEFAULT_VERSION_UPDATE=0 >> ?DEFAULT_VERSION_PATCH=0 >> >> Thanks, >> David > From christoph.langer at sap.com Tue Feb 6 07:50:21 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 6 Feb 2018 07:50:21 +0000 Subject: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() In-Reply-To: <5A78AD3E.9090503@oracle.com> References: <5A6A2611.4030003@oracle.com> <5A731457.1040502@oracle.com> <5A78AD3E.9090503@oracle.com> Message-ID: Hi Gary, ok, I would agree that a change like globally moving from dbgSysInetAddr to something like dbgsysPToN should at least be handled by a different change. Best regards Christoph From: Gary Adams [mailto:gary.adams at oracle.com] Sent: Montag, 5. Februar 2018 20:15 To: gary.adams at oracle.com Cc: Langer, Christoph ; OpenJDK Serviceability ; OpenJDK Build ; OpenJDK Networking Subject: Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() One more to fix to cover the remaining test failures I was seeing. Previously, using inet_addr, there was a single -1 return that needed to be checked. Now that we're using inet_pton, there is a -1 and a 0 error return to be considered. My preference would be to leave the dbgSysInetAddr name unchanged and have the low level check for inet_pton errors to simply return the -1 that was previously checked. This specific issue is about the deprecation of library functions on windows. I'd recommend not upgrading the other platforms at this time until a complete update is done for ipv6 support. I'll post a new webrev when I've retested using the updated inet_pton error checking. ... Hi Gary, > Here's a revised webrev > > http://cr.openjdk.java.net/~gadams/8080990/webrev.01/index.html > > Still testing ... > > Using shutdown() fixed problems reported by the > java/nio/channelSocketChannel tests. The fix looks good. I would think we should rename dbgsysInetAddr to dbgsysPToN and use inet_pton also for the Unix/Linux platforms. It would be the better choice there as well, though we still only support IPv4 in libdt_socket. > > I also noticed prior use of getaddrinfo for "localhost" was not calling > freeaddrinfo. Thanks for spotting/fixing that. Best regards Christoph From thomas.stuefe at gmail.com Tue Feb 6 08:51:15 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 6 Feb 2018 09:51:15 +0100 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> <75fb3672-25dc-87bd-49c6-817221eaa191@oracle.com> <74c81f6c-e0f8-55c6-61fb-c1888a06f7b2@oracle.com> Message-ID: Hi, On Mon, Feb 5, 2018 at 11:14 PM, Erik Joelsson wrote: > Hello, > > In that change I bumped the number from 2.61 to 2.67. The original 2.61 > was put there by Fredrik very early in the build-infra conversion and I > don't know where that came from. The main reason for us to pick just one > version was because we wanted to avoid large differences in the committed > generated file. Since we are no longer committing the file, I don't see a > good reason to enforce a particular version, but we also should not change > this number until someone has verified that a particular version works > reasonably well. > > It should also be noted that installing autoconf from src is trivially > simple. The build has very few prerequisites and takes seconds to complete. > I've never failed on any of the platforms I've tried it on over the years. > > You are right, maybe adapting to autoconf 2.69 is the cleaner way to go instead of trying to make the builds run with an older autoconf. As Volker wrote, this is a step in the right direction; we just have to go through our platforms and build a more modern autoconf. Kind Regards, Thomas > /Erik > > > > On 2018-02-05 12:14, Magnus Ihse Bursie wrote: > >> On 2018-02-05 21:05, Magnus Ihse Bursie wrote: >> >>> Let's move this discussion to build-dev instead of jdk-dev. >>> >>> On 2018-02-05 17:30, Thomas St?fe wrote: >>> >>>> Hi Magnus, >>>> >>>> On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie < >>>> magnus.ihse.bursie at oracle.com > >>>> wrote: >>>> >>>> With the new solution, the exact version of autoconf does >>>> not matter. >>>> >>>> >>>> It seems to matter. I now get: >>>> >>>> Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.63] >>>> stdin:33: error: Autoconf version 2.69 or higher is required >>>> stdin:33: the top level >>>> autom4te: /usr/bin/m4 failed with exit status: 63 >>>> >>>> Do we actually need this strict check for the autoconf version? Is >>>> there a way to disable the check and retry with my old version? >>>> >>> >>> The check is enforced by >>> AC_PREREQ([2.69]) >>> >>> in the top of make/autoconf/configure.ac. >>> >>> You could try removing it and see what happens. In the "best" case >>> you'll get an error message when autoconf tries to generate the file, then >>> we know for certain that it does not work. :-) Otherwise, you'll have to >>> test the generated configure file more thoroughly to ensure that it really >>> works. >>> >>> I'm quite certain that older versions (and believe me, everything prior >>> to 2.69 is *ancient*) did not work at all, and that was the reason we added >>> that requirement. >>> >> Some code archeology gave me this: https://bugs.openjdk.java.net/ >> browse/JDK-8023957 >> >> It seems that we at least supported 2.67 at the time, but we executable >> was not commonly (?) named "autoconf" so we couldn't autodetect it. Still >> can't say about 2.63 though. >> >> >>> /Magnus >>> >>> >>>> I would dislike for this to be a frequent error now - unfortunately, we >>>> have some build environments where getting the latest GNU tools is more >>>> work than just running an installer. >>>> >>>> Thanks, Thomas >>>> >>>> >>>> The build documentation has been updated to reflect this change. >>>> >>>> /Magnus >>>> >>>> >>>> >>> >> > From dalibor.topic at oracle.com Tue Feb 6 09:36:41 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 6 Feb 2018 10:36:41 +0100 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> <75fb3672-25dc-87bd-49c6-817221eaa191@oracle.com> <74c81f6c-e0f8-55c6-61fb-c1888a06f7b2@oracle.com> Message-ID: On 06.02.2018 09:51, Thomas St?fe wrote: > You are right, maybe adapting to autoconf 2.69 is the cleaner way to go > instead of trying to make the builds run with an older autoconf. It most likely is. The older the autoconf is that one requires, the more problematic using the OS provided one becomes, as due to the murky past of autotools, OS vendors used to patch them quite extensively to try to work around the effects of incompatibilities in transitions between 2.13 and 2.50. The autoconf civil wars took many years to settle down. See https://cygwin.com/ml/cygwin-announce/2001/msg00177.html for an example of the accidental complexity that the whole thing triggered. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From matthias.baesken at sap.com Tue Feb 6 13:27:45 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 6 Feb 2018 13:27:45 +0000 Subject: The generated-configure.sh script is dead - autoconf seems to write into the sources in the build process Message-ID: <1cd93f365ad94cd8a2058a14fc6016c0@sap.com> Hello I noticed that after replacing generated-configure.sh and using autoconf , the build process writes into the sources . Error looks like this : Runnable configure script is not present Generating runnable configure script mkdir: cannot create directory `/openjdk/linuxppc64/jdk/.build': Permission denied ( I run configure from a separate generation directory ) Is there a way around this currently (e.g. placing the .build folder where configure is started and not into the sources ?) ? Thanks ,Matthias From volker.simonis at gmail.com Tue Feb 6 14:53:32 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 6 Feb 2018 15:53:32 +0100 Subject: The generated-configure.sh script is dead - autoconf seems to write into the sources in the build process In-Reply-To: <1cd93f365ad94cd8a2058a14fc6016c0@sap.com> References: <1cd93f365ad94cd8a2058a14fc6016c0@sap.com> Message-ID: Hi, as Matthias wrote, we're usually running configure from a newly created build directory which is outside the source tree. Also, the build user who calls configure may differ from the user owning the source tree. I'd therefor like to propose the following small change which checks from where 'configure' was called. If configure was called from within the source tree, nothing changes, otherwise we will create the '.build' helper directory which contains 'generated-configure.sh' right in the current build directory: diff -r fd40b0b3d849 make/autoconf/configure --- a/make/autoconf/configure Tue Feb 06 23:49:10 2018 +0530 +++ b/make/autoconf/configure Tue Feb 06 15:46:48 2018 +0100 @@ -52,7 +52,16 @@ fi build_support_dir="$CUSTOM_ROOT/.build" else - build_support_dir="$TOPDIR/.build" + # Test from where we are running configure, in or outside of src root. + if test "x$TOPDIR" = `pwd`; then + # We are running configure from the src root. + # Create 'build_support_dir' under $TOPDIR + build_support_dir="$TOPDIR/.build" + else + # We are running configure from outside of the src dir. + # Create 'build_support_dir' in the current directory. + build_support_dir=".build" + fi fi conf_script_dir="$TOPDIR/make/autoconf" Would you be OK with this change? If nobody complains, I will open a JBS issue and submit a webrev for formal review. Regards, Volker On Tue, Feb 6, 2018 at 2:27 PM, Baesken, Matthias wrote: > Hello I noticed that after replacing generated-configure.sh and using autoconf , the build process writes into the sources . > Error looks like this : > > Runnable configure script is not present > Generating runnable configure script > mkdir: cannot create directory `/openjdk/linuxppc64/jdk/.build': Permission denied > > > ( I run configure from a separate generation directory ) > > Is there a way around this currently (e.g. placing the .build folder where configure is started and not into the sources ?) ? > > > Thanks ,Matthias From jonathan.gibbons at oracle.com Tue Feb 6 16:11:04 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 6 Feb 2018 08:11:04 -0800 Subject: "no tests selected" running tests in the test/jdk directory In-Reply-To: References: <177798CA-0A6F-47CB-9D95-C1EB0610C93D@oracle.com> Message-ID: .. and samevm mode no longer exists. -- Jon On 2/5/18 5:39 PM, Martin Buchholz wrote: > OK, I did some reading up in doc/testing.md. I noticed > > #### TEST_MODE > The test mode (`-agentvm`, `-samevm` or `-othervm`). > > but TEST_MODE=-agentvm is rejected - it must be TEST_MODE=agentvm. > > I suggest removing the dashes in the doc and perhaps changing the code to > accept and ignore initial dashes. > > On Mon, Feb 5, 2018 at 12:22 PM, Martin Buchholz > wrote: > >> Ahh, I had forgotten we are in the middle of a transition to "run-test". >> I need to read doc/testing.md. >> >> On Mon, Feb 5, 2018 at 11:22 AM, Magnus Ihse Bursie < >> magnus.ihse.bursie at oracle.com> wrote: >> >>> Use make run-test TEST="test/jdk" instead. >>> >>> /Magnus >>> >>>> 5 feb. 2018 kl. 19:39 skrev Martin Buchholz : >>>> >>>> if I >>>> cd test/jdk && make all ... >>>> I get >>>> >>>> Test results: no tests selected >>>> ... >>>> Summary: jdk_default >>>> TEST STATS: name=jdk_default run=0 pass=0 fail=0 >>>> >>>> --- >>>> >>>> Also I find I have to define PRODUCT_HOME and JT_HOME as environment >>>> variables - make variables are insufficient >> From thomas.stuefe at gmail.com Tue Feb 6 16:40:56 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 6 Feb 2018 17:40:56 +0100 Subject: The generated-configure.sh script is dead, long live autoconf! In-Reply-To: References: <244f1436-2a10-3ad8-93e0-e523c4e74104@oracle.com> <75fb3672-25dc-87bd-49c6-817221eaa191@oracle.com> <74c81f6c-e0f8-55c6-61fb-c1888a06f7b2@oracle.com> Message-ID: On Tue, Feb 6, 2018 at 10:36 AM, dalibor topic wrote: > On 06.02.2018 09:51, Thomas St?fe wrote: > >> You are right, maybe adapting to autoconf 2.69 is the cleaner way to go >> instead of trying to make the builds run with an older autoconf. >> > It most likely is. > > The older the autoconf is that one requires, the more problematic using > the OS provided one becomes, as due to the murky past of autotools, OS > vendors used to patch them quite extensively to try to work around the > effects of incompatibilities in transitions between 2.13 and 2.50. > > The autoconf civil wars took many years to settle down. See > https://cygwin.com/ml/cygwin-announce/2001/msg00177.html for an example > of the accidental complexity that the whole thing triggered. > Reading through this is quite painful :) Yes, I am convinced now. ..Thomas > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Ham > > burg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-8 > 0992 > M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From erik.joelsson at oracle.com Tue Feb 6 17:24:15 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 6 Feb 2018 09:24:15 -0800 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 In-Reply-To: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> References: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> Message-ID: <8fadd660-fa9e-80bb-ee5b-efbc4945bf2a@oracle.com> Looks good! /Erik On 2018-02-05 17:25, David Holmes wrote: > It's time to increment the actual version to 11 for JDK 11. > > Joe Darcy and I have worked through numerous test issues that delayed > the update and I've been addressing a number of issues in hotspot > related to obsolete/expired flag warnings. I have tested the update > with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI > failures for either JDK or HS pipelines. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 > > Change: > > --- a/make/autoconf/version-numbers > +++ b/make/autoconf/version-numbers > @@ -25,7 +25,7 @@ > > ?# Default version numbers to use unless overridden by configure > > -DEFAULT_VERSION_FEATURE=10 > +DEFAULT_VERSION_FEATURE=11 > ?DEFAULT_VERSION_INTERIM=0 > ?DEFAULT_VERSION_UPDATE=0 > ?DEFAULT_VERSION_PATCH=0 > > Thanks, > David From erik.joelsson at oracle.com Tue Feb 6 17:22:07 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 6 Feb 2018 09:22:07 -0800 Subject: The generated-configure.sh script is dead - autoconf seems to write into the sources in the build process In-Reply-To: References: <1cd93f365ad94cd8a2058a14fc6016c0@sap.com> Message-ID: <25e6db3c-1e3c-e203-f3b2-f3520139faa2@oracle.com> Hello Volker, I think this is a reasonable idea, but have opinions on the implementation. I think this should apply even if you have a CUSTOM_ROOT defined. Thinking some more on this, isn't it always true that you want it in $PWD/.build? Or if we want to get really strict about it, if PWD is a subdir of TOPDIR (or CUSTOM_ROOT), then use TOPDIR (or CUSTOM_ROOT), otherwise use PWD. /Erik On 2018-02-06 06:53, Volker Simonis wrote: > Hi, > > as Matthias wrote, we're usually running configure from a newly > created build directory which is outside the source tree. Also, the > build user who calls configure may differ from the user owning the > source tree. I'd therefor like to propose the following small change > which checks from where 'configure' was called. If configure was > called from within the source tree, nothing changes, otherwise we will > create the '.build' helper directory which contains > 'generated-configure.sh' right in the current build directory: > > diff -r fd40b0b3d849 make/autoconf/configure > --- a/make/autoconf/configure Tue Feb 06 23:49:10 2018 +0530 > +++ b/make/autoconf/configure Tue Feb 06 15:46:48 2018 +0100 > @@ -52,7 +52,16 @@ > fi > build_support_dir="$CUSTOM_ROOT/.build" > else > - build_support_dir="$TOPDIR/.build" > + # Test from where we are running configure, in or outside of src root. > + if test "x$TOPDIR" = `pwd`; then > + # We are running configure from the src root. > + # Create 'build_support_dir' under $TOPDIR > + build_support_dir="$TOPDIR/.build" > + else > + # We are running configure from outside of the src dir. > + # Create 'build_support_dir' in the current directory. > + build_support_dir=".build" > + fi > fi > > conf_script_dir="$TOPDIR/make/autoconf" > > Would you be OK with this change? If nobody complains, I will open a > JBS issue and submit a webrev for formal review. > > Regards, > Volker > > > On Tue, Feb 6, 2018 at 2:27 PM, Baesken, Matthias > wrote: >> Hello I noticed that after replacing generated-configure.sh and using autoconf , the build process writes into the sources . >> Error looks like this : >> >> Runnable configure script is not present >> Generating runnable configure script >> mkdir: cannot create directory `/openjdk/linuxppc64/jdk/.build': Permission denied >> >> >> ( I run configure from a separate generation directory ) >> >> Is there a way around this currently (e.g. placing the .build folder where configure is started and not into the sources ?) ? >> >> >> Thanks ,Matthias From magnus.ihse.bursie at oracle.com Tue Feb 6 17:28:26 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Feb 2018 18:28:26 +0100 Subject: The generated-configure.sh script is dead - autoconf seems to write into the sources in the build process In-Reply-To: References: <1cd93f365ad94cd8a2058a14fc6016c0@sap.com> Message-ID: <106c24d4-e36b-c37f-990b-f8e61302b879@oracle.com> On 2018-02-06 15:53, Volker Simonis wrote: > Hi, > > as Matthias wrote, we're usually running configure from a newly > created build directory which is outside the source tree. Also, the > build user who calls configure may differ from the user owning the > source tree. I'd therefor like to propose the following small change > which checks from where 'configure' was called. If configure was > called from within the source tree, nothing changes, otherwise we will > create the '.build' helper directory which contains > 'generated-configure.sh' right in the current build directory: > > diff -r fd40b0b3d849 make/autoconf/configure > --- a/make/autoconf/configure Tue Feb 06 23:49:10 2018 +0530 > +++ b/make/autoconf/configure Tue Feb 06 15:46:48 2018 +0100 > @@ -52,7 +52,16 @@ > fi > build_support_dir="$CUSTOM_ROOT/.build" > else > - build_support_dir="$TOPDIR/.build" > + # Test from where we are running configure, in or outside of src root. > + if test "x$TOPDIR" = `pwd`; then > + # We are running configure from the src root. > + # Create 'build_support_dir' under $TOPDIR > + build_support_dir="$TOPDIR/.build" > + else > + # We are running configure from outside of the src dir. > + # Create 'build_support_dir' in the current directory. > + build_support_dir=".build" > + fi > fi > > conf_script_dir="$TOPDIR/make/autoconf" > > Would you be OK with this change? If nobody complains, I will open a > JBS issue and submit a webrev for formal review. Hi Volker and Matthias, I'm sorry I missed this usecase. :-( I think the patch is OK. I'm just thinking about the "make reconfigure" case. I guess it works as long as you call "make reconfigure" from the same directory, but then again, that's probably the likely way to work in this case. It will *not* work in the case that you do e.g.: mkdir -p build/mybuild && cd build/mybuild bash ../../configure cd ../.. make CONF=mybuild but then again, mixing "methods" like that is perhaps not so common, and the only penalty is that we get two .build directories. Maybe we should even use "configure-support" instead of ".build" as build_support_dir for the "outside of src dir" case? It would certainly fit in better with already existing structure in the build output directory. /Magnus > > Regards, > Volker > > > On Tue, Feb 6, 2018 at 2:27 PM, Baesken, Matthias > wrote: >> Hello I noticed that after replacing generated-configure.sh and using autoconf , the build process writes into the sources . >> Error looks like this : >> >> Runnable configure script is not present >> Generating runnable configure script >> mkdir: cannot create directory `/openjdk/linuxppc64/jdk/.build': Permission denied >> >> >> ( I run configure from a separate generation directory ) >> >> Is there a way around this currently (e.g. placing the .build folder where configure is started and not into the sources ?) ? >> >> >> Thanks ,Matthias From magnus.ihse.bursie at oracle.com Tue Feb 6 17:30:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Feb 2018 18:30:52 +0100 Subject: The generated-configure.sh script is dead - autoconf seems to write into the sources in the build process In-Reply-To: <25e6db3c-1e3c-e203-f3b2-f3520139faa2@oracle.com> References: <1cd93f365ad94cd8a2058a14fc6016c0@sap.com> <25e6db3c-1e3c-e203-f3b2-f3520139faa2@oracle.com> Message-ID: <506ae1da-da33-cbfb-772f-2a3b6bc83b48@oracle.com> On 2018-02-06 18:22, Erik Joelsson wrote: > Hello Volker, > > I think this is a reasonable idea, but have opinions on the > implementation. I think this should apply even if you have a > CUSTOM_ROOT defined. Thinking some more on this, isn't it always true > that you want it in $PWD/.build? Or if we want to get really strict > about it, if PWD is a subdir of TOPDIR (or CUSTOM_ROOT), then use > TOPDIR (or CUSTOM_ROOT), otherwise use PWD. I don't think we allow running configure in anything else than the TOPDIR (or CUSTOM_ROOT), or an empty directory. Once upon a time, TOPDIR/make or TOPDIR/common/autoconf was also supported, but I removed that some time ago. But I agree with your analysis that this should be used even if CUSTOM_ROOT is defined. /Magnus > > /Erik > > > On 2018-02-06 06:53, Volker Simonis wrote: >> Hi, >> >> as Matthias wrote, we're usually running configure from a newly >> created build directory which is outside the source tree. Also, the >> build user who calls configure may differ from the user owning the >> source tree. I'd therefor like to propose the following small change >> which checks from where 'configure' was called. If configure was >> called from within the source tree, nothing changes, otherwise we will >> create the '.build' helper directory which contains >> 'generated-configure.sh' right in the current build directory: >> >> diff -r fd40b0b3d849 make/autoconf/configure >> --- a/make/autoconf/configure?? Tue Feb 06 23:49:10 2018 +0530 >> +++ b/make/autoconf/configure?? Tue Feb 06 15:46:48 2018 +0100 >> @@ -52,7 +52,16 @@ >> ??? fi >> ??? build_support_dir="$CUSTOM_ROOT/.build" >> ? else >> -? build_support_dir="$TOPDIR/.build" >> +? # Test from where we are running configure, in or outside of src >> root. >> +? if test "x$TOPDIR" = `pwd`; then >> +??? # We are running configure from the src root. >> +??? # Create 'build_support_dir' under $TOPDIR >> +??? build_support_dir="$TOPDIR/.build" >> +? else >> +??? # We are running configure from outside of the src dir. >> +??? # Create 'build_support_dir' in the current directory. >> +??? build_support_dir=".build" >> +? fi >> ? fi >> >> ? conf_script_dir="$TOPDIR/make/autoconf" >> >> Would you be OK with this change? If nobody complains, I will open a >> JBS issue and submit a webrev for formal review. >> >> Regards, >> Volker >> >> >> On Tue, Feb 6, 2018 at 2:27 PM, Baesken, Matthias >> wrote: >>> Hello I noticed? that?? after replacing?? generated-configure.sh?? >>> and? using autoconf , the? build process? writes into the sources . >>> Error? looks like this?? : >>> >>> Runnable configure script is not present >>> Generating runnable configure script >>> mkdir: cannot create directory `/openjdk/linuxppc64/jdk/.build': >>> Permission denied >>> >>> >>> ( I run? configure? from? a separate? generation directory? ) >>> >>> Is there a way around this? currently? (e.g.?? placing the .build >>> folder? where configure is started and not into the sources ?) ? >>> >>> >>> Thanks ,Matthias > From magnus.ihse.bursie at oracle.com Tue Feb 6 17:35:36 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Feb 2018 18:35:36 +0100 Subject: RFR: JDK-8196803: Fix build warnings in jdk libraries with Xcode 9 In-Reply-To: References: Message-ID: On 2018-02-05 23:54, Erik Joelsson wrote: > When building with Xcode 9, we get some warnings triggered in jdk > libraries. This patch tries to fix them. See bug description for more > details on each of them. In short the following things are addressed: > > In src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m, remove > the check on MAC_OS_X_VERSION_MAX_ALLOWED. I don't think that's > relevant. The source needs to compile against the headers that are > present. This was touched on earlier in this thread: > http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019486.html > and when going back, it's quite clear to me that the fix done there > was incorrect. > > In src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c, we > can't modify the source file itself, so here I've added a wrapper for > zlib.h that rewrites the ZLIB_VERNUM macro to a version that matches > what's available on the Macosx version we are building for. This type > of override can be brittle but seems to work OK in this case. While > doing this, I also refactored the handling of libz cflags and libs. > They are better set and exported from configure to be globally > available in the build. > > We also get warnings when linking static libraries. These are easily > fixed by adding the -mmacosx-version-min= arguments on these command > lines just like we do for linking shared libraries and executables. I > solved this by setting ARFLAGS and actually use that variable. > > Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html Looks good to me. Thanks for the ZLIB cleanup. The naming and usage there has really been off. /Magnus > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196803 > > /Erik > From magnus.ihse.bursie at oracle.com Tue Feb 6 17:38:13 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Feb 2018 18:38:13 +0100 Subject: "no tests selected" running tests in the test/jdk directory In-Reply-To: References: <177798CA-0A6F-47CB-9D95-C1EB0610C93D@oracle.com> Message-ID: <2ec84d5b-267b-fbf8-ca43-2c0e4ef449ca@oracle.com> On 2018-02-06 02:39, Martin Buchholz wrote: > OK, I did some reading up in doc/testing.md . I > noticed > > #### TEST_MODE > The test mode (`-agentvm`, `-samevm` or `-othervm`). > > but?TEST_MODE=-agentvm is rejected - it must be TEST_MODE=agentvm. > > I suggest removing the dashes in the doc and perhaps changing the code > to accept and ignore initial dashes. Thanks! I opened https://bugs.openjdk.java.net/browse/JDK-8196875. /Magnus > > On Mon, Feb 5, 2018 at 12:22 PM, Martin Buchholz > wrote: > > Ahh, I had forgotten we are in the middle of a transition to > "run-test". > I need to read doc/testing.md . > > On Mon, Feb 5, 2018 at 11:22 AM, Magnus Ihse Bursie > > wrote: > > Use make run-test TEST="test/jdk" instead. > > /Magnus > > > 5 feb. 2018 kl. 19:39 skrev Martin Buchholz > >: > > > > if I > > cd test/jdk && make all ... > > I get > > > > Test results: no tests selected > > ... > > Summary: jdk_default > > TEST STATS: name=jdk_default? run=0 pass=0? fail=0 > > > > --- > > > > Also I find I have to define PRODUCT_HOME and JT_HOME as > environment > > variables - make variables are insufficient > > > From volker.simonis at gmail.com Tue Feb 6 18:01:59 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 6 Feb 2018 19:01:59 +0100 Subject: The generated-configure.sh script is dead - autoconf seems to write into the sources in the build process In-Reply-To: <106c24d4-e36b-c37f-990b-f8e61302b879@oracle.com> References: <1cd93f365ad94cd8a2058a14fc6016c0@sap.com> <106c24d4-e36b-c37f-990b-f8e61302b879@oracle.com> Message-ID: On Tue, Feb 6, 2018 at 6:28 PM, Magnus Ihse Bursie wrote: > > > On 2018-02-06 15:53, Volker Simonis wrote: >> >> Hi, >> >> as Matthias wrote, we're usually running configure from a newly >> created build directory which is outside the source tree. Also, the >> build user who calls configure may differ from the user owning the >> source tree. I'd therefor like to propose the following small change >> which checks from where 'configure' was called. If configure was >> called from within the source tree, nothing changes, otherwise we will >> create the '.build' helper directory which contains >> 'generated-configure.sh' right in the current build directory: >> >> diff -r fd40b0b3d849 make/autoconf/configure >> --- a/make/autoconf/configure Tue Feb 06 23:49:10 2018 +0530 >> +++ b/make/autoconf/configure Tue Feb 06 15:46:48 2018 +0100 >> @@ -52,7 +52,16 @@ >> fi >> build_support_dir="$CUSTOM_ROOT/.build" >> else >> - build_support_dir="$TOPDIR/.build" >> + # Test from where we are running configure, in or outside of src root. >> + if test "x$TOPDIR" = `pwd`; then >> + # We are running configure from the src root. >> + # Create 'build_support_dir' under $TOPDIR >> + build_support_dir="$TOPDIR/.build" >> + else >> + # We are running configure from outside of the src dir. >> + # Create 'build_support_dir' in the current directory. >> + build_support_dir=".build" >> + fi >> fi >> >> conf_script_dir="$TOPDIR/make/autoconf" >> >> Would you be OK with this change? If nobody complains, I will open a >> JBS issue and submit a webrev for formal review. > > Hi Volker and Matthias, > > I'm sorry I missed this usecase. :-( No problem - we're here to fix it :) > > I think the patch is OK. I'm just thinking about the "make reconfigure" > case. I guess it works as long as you call "make reconfigure" from the same > directory, but then again, that's probably the likely way to work in this > case. It will *not* work in the case that you do e.g.: > mkdir -p build/mybuild && cd build/mybuild > bash ../../configure > cd ../.. > make CONF=mybuild > > but then again, mixing "methods" like that is perhaps not so common, and the > only penalty is that we get two .build directories. > > Maybe we should even use "configure-support" instead of ".build" as > build_support_dir for the "outside of src dir" case? It would certainly fit > in better with already existing structure in the build output directory. > This was my first idea as well. Unfortunately, "$OUTPUTDIR/configure-support" is only created from generated-configure.sh (from basics.m4) so we have a chicken/egg problem here. Do you propose to already create "$OUTPUTDIR/configure-support" in the configure script before creating generated-configure.sh ? > /Magnus > > > >> >> Regards, >> Volker >> >> >> On Tue, Feb 6, 2018 at 2:27 PM, Baesken, Matthias >> wrote: >>> >>> Hello I noticed that after replacing generated-configure.sh and >>> using autoconf , the build process writes into the sources . >>> Error looks like this : >>> >>> Runnable configure script is not present >>> Generating runnable configure script >>> mkdir: cannot create directory `/openjdk/linuxppc64/jdk/.build': >>> Permission denied >>> >>> >>> ( I run configure from a separate generation directory ) >>> >>> Is there a way around this currently (e.g. placing the .build folder >>> where configure is started and not into the sources ?) ? >>> >>> >>> Thanks ,Matthias > > From erik.joelsson at oracle.com Tue Feb 6 18:16:16 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 6 Feb 2018 10:16:16 -0800 Subject: RFR: JDK-8196879: Forgot to add file in JDK-8196803 Message-ID: <505b2e08-85f8-2184-ad1a-e4ad13272842@oracle.com> When pushing JDK-8196803 just now, I forgot to add the zlib.h file. Please review this correction. Bug: https://bugs.openjdk.java.net/browse/JDK-8196879 Webrev: http://cr.openjdk.java.net/~erikj/8196879/webrev.01/ /Erik From tim.bell at oracle.com Tue Feb 6 18:18:08 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 06 Feb 2018 10:18:08 -0800 Subject: RFR: JDK-8196879: Forgot to add file in JDK-8196803 In-Reply-To: <505b2e08-85f8-2184-ad1a-e4ad13272842@oracle.com> References: <505b2e08-85f8-2184-ad1a-e4ad13272842@oracle.com> Message-ID: <5A79F160.8080104@oracle.com> On 02/06/18 10:16, Erik Joelsson wrote: > When pushing JDK-8196803 just now, I forgot to add the zlib.h file. > Please review this correction. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196879 > > Webrev: http://cr.openjdk.java.net/~erikj/8196879/webrev.01/ Looks good. /Tim From magnus.ihse.bursie at oracle.com Tue Feb 6 18:34:44 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Feb 2018 19:34:44 +0100 Subject: The generated-configure.sh script is dead - autoconf seems to write into the sources in the build process In-Reply-To: References: <1cd93f365ad94cd8a2058a14fc6016c0@sap.com> <106c24d4-e36b-c37f-990b-f8e61302b879@oracle.com> Message-ID: <27ca4832-17d2-b9a7-fa23-db31e54a4ebe@oracle.com> On 2018-02-06 19:01, Volker Simonis wrote: > On Tue, Feb 6, 2018 at 6:28 PM, Magnus Ihse Bursie > wrote: >> >> On 2018-02-06 15:53, Volker Simonis wrote: >>> Hi, >>> >>> as Matthias wrote, we're usually running configure from a newly >>> created build directory which is outside the source tree. Also, the >>> build user who calls configure may differ from the user owning the >>> source tree. I'd therefor like to propose the following small change >>> which checks from where 'configure' was called. If configure was >>> called from within the source tree, nothing changes, otherwise we will >>> create the '.build' helper directory which contains >>> 'generated-configure.sh' right in the current build directory: >>> >>> diff -r fd40b0b3d849 make/autoconf/configure >>> --- a/make/autoconf/configure Tue Feb 06 23:49:10 2018 +0530 >>> +++ b/make/autoconf/configure Tue Feb 06 15:46:48 2018 +0100 >>> @@ -52,7 +52,16 @@ >>> fi >>> build_support_dir="$CUSTOM_ROOT/.build" >>> else >>> - build_support_dir="$TOPDIR/.build" >>> + # Test from where we are running configure, in or outside of src root. >>> + if test "x$TOPDIR" = `pwd`; then >>> + # We are running configure from the src root. >>> + # Create 'build_support_dir' under $TOPDIR >>> + build_support_dir="$TOPDIR/.build" >>> + else >>> + # We are running configure from outside of the src dir. >>> + # Create 'build_support_dir' in the current directory. >>> + build_support_dir=".build" >>> + fi >>> fi >>> >>> conf_script_dir="$TOPDIR/make/autoconf" >>> >>> Would you be OK with this change? If nobody complains, I will open a >>> JBS issue and submit a webrev for formal review. >> Hi Volker and Matthias, >> >> I'm sorry I missed this usecase. :-( > No problem - we're here to fix it :) > >> I think the patch is OK. I'm just thinking about the "make reconfigure" >> case. I guess it works as long as you call "make reconfigure" from the same >> directory, but then again, that's probably the likely way to work in this >> case. It will *not* work in the case that you do e.g.: >> mkdir -p build/mybuild && cd build/mybuild >> bash ../../configure >> cd ../.. >> make CONF=mybuild >> >> but then again, mixing "methods" like that is perhaps not so common, and the >> only penalty is that we get two .build directories. >> >> Maybe we should even use "configure-support" instead of ".build" as >> build_support_dir for the "outside of src dir" case? It would certainly fit >> in better with already existing structure in the build output directory. >> > This was my first idea as well. Unfortunately, > "$OUTPUTDIR/configure-support" is only created from > generated-configure.sh (from basics.m4) so we have a chicken/egg > problem here. > > Do you propose to already create "$OUTPUTDIR/configure-support" in the > configure script before creating generated-configure.sh ? Yes. If we run configure from TOPDIR then we to not know the name of $OUTPUTDIR until a bit into the configure script. But if we start configure from a non-TOPDIR directory, then it will be used as $OUTPUTDIR so we can (and should!) use that fact. Just as .build is created if it does not exist, so configure-support should be created if it does not exist. Something like this: diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4 --- a/make/autoconf/basics.m4 +++ b/make/autoconf/basics.m4 @@ -814,6 +814,7 @@ ?????????? | $SED -e 's/config.log//g' \ ?????????????? -e 's/configure.log//g' \ ?????????????? -e 's/confdefs.h//g' \ +????????????? -e 's/configure-support//g' \ ?????????????? -e 's/ //g' \ ?????????? | $TR -d '\n'` ?????? if test "x$filtered_files" != x; then diff --git a/make/autoconf/configure b/make/autoconf/configure --- a/make/autoconf/configure +++ b/make/autoconf/configure @@ -52,7 +52,16 @@ ?? fi ?? build_support_dir="$CUSTOM_ROOT/.build" ?else -? build_support_dir="$TOPDIR/.build" +? # Test from where we are running configure, in or outside of src root. +? if test "x$TOPDIR" = `pwd`; then +??? # We are running configure from the src root. +??? # Create 'build_support_dir' under $TOPDIR +??? build_support_dir="$TOPDIR/.build" +? else +??? # We are running configure from outside of the src dir. +??? # Create 'build_support_dir' in the current directory. +??? build_support_dir="configure-support" +? fi ?fi ?conf_script_dir="$TOPDIR/make/autoconf" (It turned out we also need to accept that "configure-support" exists in the "empty" directory) /Magnus > >> /Magnus >> >> >> >>> Regards, >>> Volker >>> >>> >>> On Tue, Feb 6, 2018 at 2:27 PM, Baesken, Matthias >>> wrote: >>>> Hello I noticed that after replacing generated-configure.sh and >>>> using autoconf , the build process writes into the sources . >>>> Error looks like this : >>>> >>>> Runnable configure script is not present >>>> Generating runnable configure script >>>> mkdir: cannot create directory `/openjdk/linuxppc64/jdk/.build': >>>> Permission denied >>>> >>>> >>>> ( I run configure from a separate generation directory ) >>>> >>>> Is there a way around this currently (e.g. placing the .build folder >>>> where configure is started and not into the sources ?) ? >>>> >>>> >>>> Thanks ,Matthias >> From erik.joelsson at oracle.com Tue Feb 6 19:30:33 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 6 Feb 2018 11:30:33 -0800 Subject: RFR: JDK-8196895: Create devkit for Macosx with Xcode 9.2 Message-ID: <04e7e778-1f76-c38e-dc9d-07e26257edec@oracle.com> This script documents how we at Oracle intends to create the new devkit for building on Macosx, once we change the toolchains used for JDK 11. Since we haven't bumped the toolchains yet, I'm adding a new script instead of replacing the existing one. I'm also renaming the old one to match the new naming scheme. Bug: https://bugs.openjdk.java.net/browse/JDK-8196895 Webrev: http://cr.openjdk.java.net/~erikj/8196895/webrev.01/ /Erik From magnus.ihse.bursie at oracle.com Tue Feb 6 19:42:36 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Feb 2018 20:42:36 +0100 Subject: RFR: JDK-8196895: Create devkit for Macosx with Xcode 9.2 In-Reply-To: <04e7e778-1f76-c38e-dc9d-07e26257edec@oracle.com> References: <04e7e778-1f76-c38e-dc9d-07e26257edec@oracle.com> Message-ID: <2534c2ee-aeb3-13c4-a051-4c9c9288111e@oracle.com> On 2018-02-06 20:30, Erik Joelsson wrote: > This script documents how we at Oracle intends to create the new > devkit for building on Macosx, once we change the toolchains used for > JDK 11. Since we haven't bumped the toolchains yet, I'm adding a new > script instead of replacing the existing one. I'm also renaming the > old one to match the new naming scheme. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196895 > > Webrev: http://cr.openjdk.java.net/~erikj/8196895/webrev.01/ You gave up on trying to extract .xip files using command-line tools? :-) Looks good to me. /Magnus > > /Erik > From erik.joelsson at oracle.com Tue Feb 6 20:37:08 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 6 Feb 2018 12:37:08 -0800 Subject: RFR: JDK-8196895: Create devkit for Macosx with Xcode 9.2 In-Reply-To: <2534c2ee-aeb3-13c4-a051-4c9c9288111e@oracle.com> References: <04e7e778-1f76-c38e-dc9d-07e26257edec@oracle.com> <2534c2ee-aeb3-13c4-a051-4c9c9288111e@oracle.com> Message-ID: <3e9f2f4c-aa7e-357d-dd02-a7c44b0a8d67@oracle.com> On 2018-02-06 11:42, Magnus Ihse Bursie wrote: > On 2018-02-06 20:30, Erik Joelsson wrote: >> This script documents how we at Oracle intends to create the new >> devkit for building on Macosx, once we change the toolchains used for >> JDK 11. Since we haven't bumped the toolchains yet, I'm adding a new >> script instead of replacing the existing one. I'm also renaming the >> old one to match the new naming scheme. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196895 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8196895/webrev.01/ > > You gave up on trying to extract .xip files using command-line tools? :-) > Yeah, there are no standard tools for handling that. There are some tools written for it, but I didn't want to complicate things by using any such thirdparty tool. /Erik > Looks good to me. > > /Magnus > >> >> /Erik >> > From Sergey.Bylokhov at oracle.com Tue Feb 6 20:54:05 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 6 Feb 2018 12:54:05 -0800 Subject: RFR: JDK-8196803: Fix build warnings in jdk libraries with Xcode 9 In-Reply-To: References: Message-ID: <42c4a88f-0a22-b9b8-5549-964411c26df3@oracle.com> Hi, Erik. Why XCode 9 was selected? It seems that 9.2 is the latest one. 9.2 produces some additional warnings even after this fix. On 05/02/2018 14:54, Erik Joelsson wrote: > When building with Xcode 9, we get some warnings triggered in jdk > libraries. This patch tries to fix them. See bug description for more > details on each of them. In short the following things are addressed: > > In src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m, remove > the check on MAC_OS_X_VERSION_MAX_ALLOWED. I don't think that's > relevant. The source needs to compile against the headers that are > present. This was touched on earlier in this thread: > http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019486.html > and when going back, it's quite clear to me that the fix done there was > incorrect. > > In src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c, we > can't modify the source file itself, so here I've added a wrapper for > zlib.h that rewrites the ZLIB_VERNUM macro to a version that matches > what's available on the Macosx version we are building for. This type of > override can be brittle but seems to work OK in this case. While doing > this, I also refactored the handling of libz cflags and libs. They are > better set and exported from configure to be globally available in the > build. > > We also get warnings when linking static libraries. These are easily > fixed by adding the -mmacosx-version-min= arguments on these command > lines just like we do for linking shared libraries and executables. I > solved this by setting ARFLAGS and actually use that variable. > > Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196803 > > /Erik > -- Best regards, Sergey. From erik.joelsson at oracle.com Tue Feb 6 21:03:58 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 6 Feb 2018 13:03:58 -0800 Subject: RFR: JDK-8196803: Fix build warnings in jdk libraries with Xcode 9 In-Reply-To: <42c4a88f-0a22-b9b8-5549-964411c26df3@oracle.com> References: <42c4a88f-0a22-b9b8-5549-964411c26df3@oracle.com> Message-ID: Hello, The 9 was just me being sloppy and thinking 9.x, I'm actually using 9.2. These are all the warnings I found in JDK libraries. There are additional ones in other parts of the build which have been dealt with in separate issues. /Erik On 2018-02-06 12:54, Sergey Bylokhov wrote: > Hi, Erik. > Why XCode 9 was selected? It seems that 9.2 is the latest one. > 9.2 produces some additional warnings even after this fix. > > On 05/02/2018 14:54, Erik Joelsson wrote: >> When building with Xcode 9, we get some warnings triggered in jdk >> libraries. This patch tries to fix them. See bug description for more >> details on each of them. In short the following things are addressed: >> >> In src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m, >> remove the check on MAC_OS_X_VERSION_MAX_ALLOWED. I don't think >> that's relevant. The source needs to compile against the headers that >> are present. This was touched on earlier in this thread: >> http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019486.html >> and when going back, it's quite clear to me that the fix done there >> was incorrect. >> >> In src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c, >> we can't modify the source file itself, so here I've added a wrapper >> for zlib.h that rewrites the ZLIB_VERNUM macro to a version that >> matches what's available on the Macosx version we are building for. >> This type of override can be brittle but seems to work OK in this >> case. While doing this, I also refactored the handling of libz cflags >> and libs. They are better set and exported from configure to be >> globally available in the build. >> >> We also get warnings when linking static libraries. These are easily >> fixed by adding the -mmacosx-version-min= arguments on these command >> lines just like we do for linking shared libraries and executables. I >> solved this by setting ARFLAGS and actually use that variable. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196803 >> >> /Erik >> > > From erik.joelsson at oracle.com Tue Feb 6 21:35:39 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 6 Feb 2018 13:35:39 -0800 Subject: RFR: JDK-8196911: Windows build fails with not finding zlib.h Message-ID: <354b7602-8a61-594d-ab3e-47f36465207c@oracle.com> A small typo managed to sneak itself into my previous patch, causing the build to fail on Windows. Bug: https://bugs.openjdk.java.net/browse/JDK-8196911 Patch inline: diff -r 0b1138ce244f make/autoconf/lib-bundled.m4 --- a/make/autoconf/lib-bundled.m4????? Tue Feb 06 10:17:31 2018 -0800 +++ b/make/autoconf/lib-bundled.m4????? Tue Feb 06 22:34:12 2018 +0100 @@ -209,7 +209,7 @@ ???? AC_MSG_ERROR([Invalid value for --with-zlib: ${with_zlib}, use 'system' or 'bundled']) ?? fi -? if test "x$USER_EXTERNAL_LIBZ" = "xfalse"; then +? if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then ???? LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib" ?? else ???? LIBZ_LIBS="-lz" /Erik From tim.bell at oracle.com Tue Feb 6 21:47:32 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 06 Feb 2018 13:47:32 -0800 Subject: RFR: JDK-8196911: Windows build fails with not finding zlib.h In-Reply-To: <354b7602-8a61-594d-ab3e-47f36465207c@oracle.com> References: <354b7602-8a61-594d-ab3e-47f36465207c@oracle.com> Message-ID: <5A7A2274.1000808@oracle.com> Erik: > A small typo managed to sneak itself into my previous patch, causing the > build to fail on Windows. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196911 [...snip...] > - if test "x$USER_EXTERNAL_LIBZ" = "xfalse"; then > + if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then Looks good. I missed that one myself as a reviewer. /Tim From david.holmes at oracle.com Tue Feb 6 21:49:46 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Feb 2018 07:49:46 +1000 Subject: RFR: 8173401: Update VERSION_FEATURE for JDK 11 In-Reply-To: <8fadd660-fa9e-80bb-ee5b-efbc4945bf2a@oracle.com> References: <8dc3714c-6a71-21de-8d96-a2d7801102e7@oracle.com> <8fadd660-fa9e-80bb-ee5b-efbc4945bf2a@oracle.com> Message-ID: <72b40012-9914-6972-e5dd-fdc79f1b45cd@oracle.com> Thanks Erik. Pushing now. David On 7/02/2018 3:24 AM, Erik Joelsson wrote: > Looks good! > > /Erik > > > On 2018-02-05 17:25, David Holmes wrote: >> It's time to increment the actual version to 11 for JDK 11. >> >> Joe Darcy and I have worked through numerous test issues that delayed >> the update and I've been addressing a number of issues in hotspot >> related to obsolete/expired flag warnings. I have tested the update >> with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI >> failures for either JDK or HS pipelines. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8173401 >> >> Change: >> >> --- a/make/autoconf/version-numbers >> +++ b/make/autoconf/version-numbers >> @@ -25,7 +25,7 @@ >> >> ?# Default version numbers to use unless overridden by configure >> >> -DEFAULT_VERSION_FEATURE=10 >> +DEFAULT_VERSION_FEATURE=11 >> ?DEFAULT_VERSION_INTERIM=0 >> ?DEFAULT_VERSION_UPDATE=0 >> ?DEFAULT_VERSION_PATCH=0 >> >> Thanks, >> David > From tim.bell at oracle.com Tue Feb 6 22:18:34 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 06 Feb 2018 14:18:34 -0800 Subject: RFR: JDK-8196895: Create devkit for Macosx with Xcode 9.2 In-Reply-To: <3e9f2f4c-aa7e-357d-dd02-a7c44b0a8d67@oracle.com> References: <04e7e778-1f76-c38e-dc9d-07e26257edec@oracle.com> <2534c2ee-aeb3-13c4-a051-4c9c9288111e@oracle.com> <3e9f2f4c-aa7e-357d-dd02-a7c44b0a8d67@oracle.com> Message-ID: <5A7A29BA.8020208@oracle.com> Erik: > On 2018-02-06 11:42, Magnus Ihse Bursie wrote: >> On 2018-02-06 20:30, Erik Joelsson wrote: >>> This script documents how we at Oracle intends to create the new >>> devkit for building on Macosx, once we change the toolchains used for >>> JDK 11. Since we haven't bumped the toolchains yet, I'm adding a new >>> script instead of replacing the existing one. I'm also renaming the >>> old one to match the new naming scheme. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196895 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8196895/webrev.01/ >> >> You gave up on trying to extract .xip files using command-line tools? :-) >> > Yeah, there are no standard tools for handling that. There are some > tools written for it, but I didn't want to complicate things by using > any such thirdparty tool. > > /Erik >> Looks good to me. >> >> /Magnus Looks good to me as well. /Tim From thomas.stuefe at gmail.com Wed Feb 7 14:13:05 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 7 Feb 2018 15:13:05 +0100 Subject: RFR: JDK-8196911: Windows build fails with not finding zlib.h In-Reply-To: <5A7A2274.1000808@oracle.com> References: <354b7602-8a61-594d-ab3e-47f36465207c@oracle.com> <5A7A2274.1000808@oracle.com> Message-ID: Could this also explain what we see in some of our nightlies? The builds broke on some platforms for us (e.g. linux ppcle). It seems that "@LIBZ_CFLAGS@" does not get expanded correctly and finds its way into the makefile, confusing the compiler: ( /sapmnt/appl_sw/gcc-4.8/bin/gcc ... -g1 -fPIC @LIBZ_CFLAGS@ ... -o /net/ usr.work/openjdk/nb/linuxppc64le/nightly/output-jdk-fastdebug/support/native/java.base/libzip/Adler32.o /net/ usr.work/openjdk/nb/linuxppc64le/nightly/jdk/src/java.base/share/native/libzip/Adler32.c gcc: error: @LIBZ_CFLAGS@: No such file or directory ? On Tue, Feb 6, 2018 at 10:47 PM, Tim Bell wrote: > Erik: > > A small typo managed to sneak itself into my previous patch, causing the >> build to fail on Windows. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196911 >> > [...snip...] > >> - if test "x$USER_EXTERNAL_LIBZ" = "xfalse"; then >> + if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then >> > > Looks good. I missed that one myself as a reviewer. > > /Tim > > From Alan.Bateman at oracle.com Wed Feb 7 14:20:57 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Feb 2018 14:20:57 +0000 Subject: RFR: JDK-8196911: Windows build fails with not finding zlib.h In-Reply-To: References: <354b7602-8a61-594d-ab3e-47f36465207c@oracle.com> <5A7A2274.1000808@oracle.com> Message-ID: <76308fab-0412-2420-0a15-a2a53e6db743@oracle.com> On 07/02/2018 14:13, Thomas St?fe wrote: > Could this also explain what we see in some of our nightlies? The builds > broke on some platforms for us (e.g. linux ppcle). It seems that > "@LIBZ_CFLAGS@" does not get expanded correctly and finds its way into the > makefile, confusing the compiler: > > ( /sapmnt/appl_sw/gcc-4.8/bin/gcc ... -g1 -fPIC @LIBZ_CFLAGS@ ... -o /net/ > usr.work/openjdk/nb/linuxppc64le/nightly/output-jdk-fastdebug/support/native/java.base/libzip/Adler32.o > /net/ > usr.work/openjdk/nb/linuxppc64le/nightly/jdk/src/java.base/share/native/libzip/Adler32.c > > gcc: error: @LIBZ_CFLAGS@: No such file or directory > > ? > Several of us have been running into an issue like this on macOS too, it's tracked as JDK-8196951 [1]. Locally I'm using the following to workaround it: diff -r ce02b30d382b make/autoconf/lib-bundled.m4 --- a/make/autoconf/lib-bundled.m4??? Wed Feb 07 11:57:51 2018 +0000 +++ b/make/autoconf/lib-bundled.m4??? Wed Feb 07 14:18:47 2018 +0000 @@ -212,6 +212,7 @@ ?? if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then ???? LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib" ?? else +??? LIBZ_CFLAGS="" ???? LIBZ_LIBS="-lz" ?? fi -Alan. [1] https://bugs.openjdk.java.net/browse/JDK-8196951 From thomas.stuefe at gmail.com Wed Feb 7 14:53:34 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 7 Feb 2018 15:53:34 +0100 Subject: RFR: JDK-8196911: Windows build fails with not finding zlib.h In-Reply-To: <76308fab-0412-2420-0a15-a2a53e6db743@oracle.com> References: <354b7602-8a61-594d-ab3e-47f36465207c@oracle.com> <5A7A2274.1000808@oracle.com> <76308fab-0412-2420-0a15-a2a53e6db743@oracle.com> Message-ID: On Wed, Feb 7, 2018 at 3:20 PM, Alan Bateman wrote: > > > On 07/02/2018 14:13, Thomas St?fe wrote: > >> Could this also explain what we see in some of our nightlies? The builds >> broke on some platforms for us (e.g. linux ppcle). It seems that >> "@LIBZ_CFLAGS@" does not get expanded correctly and finds its way into >> the >> makefile, confusing the compiler: >> >> ( /sapmnt/appl_sw/gcc-4.8/bin/gcc ... -g1 -fPIC @LIBZ_CFLAGS@ ... -o >> /net/ >> usr.work/openjdk/nb/linuxppc64le/nightly/output-jdk- >> fastdebug/support/native/java.base/libzip/Adler32.o >> /net/ >> usr.work/openjdk/nb/linuxppc64le/nightly/jdk/src/java.base/ >> share/native/libzip/Adler32.c >> >> gcc: error: @LIBZ_CFLAGS@: No such file or directory >> >> ? >> >> Several of us have been running into an issue like this on macOS too, > it's tracked as JDK-8196951 [1]. > > Locally I'm using the following to workaround it: > > diff -r ce02b30d382b make/autoconf/lib-bundled.m4 > --- a/make/autoconf/lib-bundled.m4 Wed Feb 07 11:57:51 2018 +0000 > +++ b/make/autoconf/lib-bundled.m4 Wed Feb 07 14:18:47 2018 +0000 > @@ -212,6 +212,7 @@ > if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then > LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/ > native/libzip/zlib" > else > + LIBZ_CFLAGS="" > LIBZ_LIBS="-lz" > fi > > -Alan. > > [1] https://bugs.openjdk.java.net/browse/JDK-8196951 > Thanks for the pointer! ..Thomas From adam.farley at uk.ibm.com Wed Feb 7 16:38:29 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 7 Feb 2018 16:38:29 +0000 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> Message-ID: Re: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.cErik Joelsson to: Adam Farley8 01/02/2018 17:06 Cc: build-dev, David Holmes, John Paul Adrian Glaubitz, Magnus Ihse Bursie From: Erik Joelsson To: Adam Farley8 Cc: build-dev , David Holmes , John Paul Adrian Glaubitz , Magnus Ihse Bursie > Am I understanding this correctly that it's really not tied to a gcc version > but a cpu architecture, so it's only really affecting s390x? I'm saying it is tied to a combination of CPU architecture and gcc version. Any combination of the affected gcc versions (4.8.5, 5.4.0) and affected platforms (zLinux, ppcle Linux) see this error. x86 Linux is not affected, not are gcc versions equal to (or, I assume, later than) 7.2.1. > Are you also saying that gcc 7.2.1 is also affected but with a different > message? I'm fine with disabling this warning conditional on s390x, no need > for specific gcc versions. I was unclear. 7.2.1 fails my unit test with a different warning, but a build I ran proves that this warning doesn't fail the build. That being said, the addition of this option to a 7.2.1 test didn't seem to break anything, so we should be fine to just stick "DISABLED_WARNINGS_gcc := clobbered array-bounds" into Awt2dLibraries.gmk. > This discussion has already taken more time than it really warrants. :) Agreed. :) > Regarding warning chasing. I agree that we it's not feasible to chase down every > warning in every version of GCC, or any other toolchain, but I also think that > for platforms/configurations where people are actively developing changes for > OpenJDK, it makes sense to try to keep it clean. This helps prevent new code from > introducing warnings. For the configurations Oracle use, we keep a strict -Werror > policy because we want the code to be clean. I'm fine with other users trying to > keep the same standards on their configurations, but knowing that it will be their > responsibility to keep up to date. I also think we need to be reasonably fine grained > in when we disable warnings. Specifying every affected version of a toolchain is too > much, but if there are specific well defined limits to where the disabling relevant, > then I think we should use them, within reason. This also helps with keeping track > of why a particular warning is disabled in a future attempt to fix them. I agree with all of this. Well put. :) > On the other hand, if you are just building OpenJDK to produce binaries, without > producing and up streaming new code changes, there really isn't much need for > making the effort of trying to keep things clean, and trying to do so will likely > just end up being more work than it's worth. > /Erik I'm building OpenJDK to test fixes and new features, which I will eventually contribute to OpenJDK. I consider this to be one of those fixes. One fix at a time. :) Given all of this, I ask for a volunteer to raise a bug so we can integrate this change into JDK8 (as it's still very popular), and JDK. 10 would be great too, though I understand it's locked against all but the worst bugs. 9 is optional, as it's soon to be replaced by 10. Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From erik.joelsson at oracle.com Wed Feb 7 16:42:00 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 7 Feb 2018 08:42:00 -0800 Subject: RFR: JDK-8196951: jdk build fails with clang: error: no such file or directory: '@LIBZ_CFLAGS@' Message-ID: <781681e4-2959-b3c0-c239-03859688e6f2@oracle.com> It seems my recent changes has caused yet another build failure. I'm puzzled over why this worked in our internal CI builds but fails in other situations. Some toolchains must simply be accepting @LIBZ_CFLAGS@ on the command line. Anyway, the fix is to make sure the variables are always defined in configure: Bug: https://bugs.openjdk.java.net/browse/JDK-8196951 Patch: diff -r 8cc67294ec56 make/autoconf/lib-bundled.m4 --- a/make/autoconf/lib-bundled.m4 +++ b/make/autoconf/lib-bundled.m4 @@ -209,6 +209,8 @@ ???? AC_MSG_ERROR([Invalid value for --with-zlib: ${with_zlib}, use 'system' or 'bundled']) ?? fi +? LIBZ_CFLAGS="" +? LIBZ_LIBS="" ?? if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then ???? LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib" ?? else /Erik From lance.andersen at oracle.com Wed Feb 7 16:57:22 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 7 Feb 2018 11:57:22 -0500 Subject: RFR 8190378: Java EE and CORBA modules removal Message-ID: Hi all, I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. The CSR for removing the modules has been approved: https://bugs.openjdk.java.net/browse/JDK-8193757 The open webrev can be found at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/ To make the open review easier, I have broken the changes into 5 webrevs: build changes are: http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/ miscellaneous changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/ module changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/ rmic changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/ test changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/ As part of the removal, the following issues have also been logged: Removal of the Java EE and CORBA tools from the documentation: https://bugs.openjdk.java.net/browse/JDK-8193906 Updating the RMIC man pages for the removal of the -iiop and -idl options: https://bugs.openjdk.java.net/browse/JDK-8196510 Hotspot tests may require further updating or just removed: https://bugs.openjdk.java.net/browse/JDK-8194310 jdeprescan will need updates due to the removal of the Java EE and CORBA modules: https://bugs.openjdk.java.net/browse/JDK-8194308 Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From erik.joelsson at oracle.com Wed Feb 7 17:11:24 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 7 Feb 2018 09:11:24 -0800 Subject: RFR 8190378: Java EE and CORBA modules removal In-Reply-To: References: Message-ID: Build changes look good. /Erik On 2018-02-07 08:57, Lance Andersen wrote: > Hi all, > > I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. > The CSR for removing the modules has been approved: https://bugs.openjdk.java.net/browse/JDK-8193757 > > The open webrev can be found at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/ > > To make the open review easier, I have broken the changes into 5 webrevs: > build changes are: http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/ > miscellaneous changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/ > module changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/ > rmic changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/ > test changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/ > > As part of the removal, the following issues have also been logged: > Removal of the Java EE and CORBA tools from the documentation: https://bugs.openjdk.java.net/browse/JDK-8193906 > Updating the RMIC man pages for the removal of the -iiop and -idl options: https://bugs.openjdk.java.net/browse/JDK-8196510 > Hotspot tests may require further updating or just removed: https://bugs.openjdk.java.net/browse/JDK-8194310 > jdeprescan will need updates due to the removal of the Java EE and CORBA modules: https://bugs.openjdk.java.net/browse/JDK-8194308 > > > > Best, > Lance > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From tim.bell at oracle.com Wed Feb 7 17:19:13 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 07 Feb 2018 09:19:13 -0800 Subject: RFR: JDK-8196951: jdk build fails with clang: error: no such file or directory: '@LIBZ_CFLAGS@' In-Reply-To: <781681e4-2959-b3c0-c239-03859688e6f2@oracle.com> References: <781681e4-2959-b3c0-c239-03859688e6f2@oracle.com> Message-ID: <5A7B3511.70704@oracle.com> Erik: > It seems my recent changes has caused yet another build failure. I'm > puzzled over why this worked in our internal CI builds but fails in > other situations. Some toolchains must simply be accepting @LIBZ_CFLAGS@ > on the command line. Anyway, the fix is to make sure the variables are > always defined in configure: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196951 > > Patch: > > diff -r 8cc67294ec56 make/autoconf/lib-bundled.m4 > --- a/make/autoconf/lib-bundled.m4 > +++ b/make/autoconf/lib-bundled.m4 > @@ -209,6 +209,8 @@ > AC_MSG_ERROR([Invalid value for --with-zlib: ${with_zlib}, use > 'system' or 'bundled']) > fi > > + LIBZ_CFLAGS="" > + LIBZ_LIBS="" > if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then > LIBZ_CFLAGS="$LIBZ_CFLAGS > -I$TOPDIR/src/java.base/share/native/libzip/zlib" > else Looks good. /Tim From Alan.Bateman at oracle.com Wed Feb 7 17:24:31 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Feb 2018 17:24:31 +0000 Subject: RFR: JDK-8196951: jdk build fails with clang: error: no such file or directory: '@LIBZ_CFLAGS@' In-Reply-To: <781681e4-2959-b3c0-c239-03859688e6f2@oracle.com> References: <781681e4-2959-b3c0-c239-03859688e6f2@oracle.com> Message-ID: <353ce4bd-5a92-7d3b-67ee-0ebcb22b91a3@oracle.com> On 07/02/2018 16:42, Erik Joelsson wrote: > It seems my recent changes has caused yet another build failure. I'm > puzzled over why this worked in our internal CI builds but fails in > other situations. Some toolchains must simply be accepting > @LIBZ_CFLAGS@ on the command line. Anyway, the fix is to make sure the > variables are always defined in configure: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196951 > > Patch: > > diff -r 8cc67294ec56 make/autoconf/lib-bundled.m4 > --- a/make/autoconf/lib-bundled.m4 > +++ b/make/autoconf/lib-bundled.m4 > @@ -209,6 +209,8 @@ > ???? AC_MSG_ERROR([Invalid value for --with-zlib: ${with_zlib}, use > 'system' or 'bundled']) > ?? fi > > +? LIBZ_CFLAGS="" > +? LIBZ_LIBS="" > ?? if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then > ???? LIBZ_CFLAGS="$LIBZ_CFLAGS > -I$TOPDIR/src/java.base/share/native/libzip/zlib" > ?? else Looks good. From goetz.lindenmaier at sap.com Wed Feb 7 20:20:53 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Feb 2018 20:20:53 +0000 Subject: RFR 8190378: Java EE and CORBA modules removal In-Reply-To: References: Message-ID: <7811bd0dc275498a8cc3417af961bdfc@sap.com> Hi Lance, Would you mind to add similar change as for test/jdk/tools/launcher/VersionCheck.java also for test/jdk/tools/launcher/HelpFlagsTest.java That test is pretty recent which is why you may have missed it. It will not fail though, there will just be left over stuff in it. Best regards, Goetz. -----Original Message----- From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Lance Andersen Sent: Wednesday, February 7, 2018 5:57 PM To: core-libs-dev ; build-dev Subject: RFR 8190378: Java EE and CORBA modules removal Hi all, I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. The CSR for removing the modules has been approved: https://bugs.openjdk.java.net/browse/JDK-8193757 The open webrev can be found at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/ To make the open review easier, I have broken the changes into 5 webrevs: build changes are: http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/ miscellaneous changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/ module changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/ rmic changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/ test changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/ As part of the removal, the following issues have also been logged: Removal of the Java EE and CORBA tools from the documentation: https://bugs.openjdk.java.net/browse/JDK-8193906 Updating the RMIC man pages for the removal of the -iiop and -idl options: https://bugs.openjdk.java.net/browse/JDK-8196510 Hotspot tests may require further updating or just removed: https://bugs.openjdk.java.net/browse/JDK-8194310 jdeprescan will need updates due to the removal of the Java EE and CORBA modules: https://bugs.openjdk.java.net/browse/JDK-8194308 Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Wed Feb 7 21:07:37 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 7 Feb 2018 16:07:37 -0500 Subject: RFR 8190378: Java EE and CORBA modules removal In-Reply-To: <7811bd0dc275498a8cc3417af961bdfc@sap.com> References: <7811bd0dc275498a8cc3417af961bdfc@sap.com> Message-ID: Hi Goetz, I updated the webrev with the suggested update http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/test/jdk/tools/launcher/HelpFlagsTest.java.sdiff.html Best Lance > On Feb 7, 2018, at 3:20 PM, Lindenmaier, Goetz wrote: > > Hi Lance, > > Would you mind to add similar change as for > test/jdk/tools/launcher/VersionCheck.java > also for > test/jdk/tools/launcher/HelpFlagsTest.java > > That test is pretty recent which is why you may have missed it. > It will not fail though, there will just be left over stuff in it. > > Best regards, > Goetz. > > > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Lance Andersen > Sent: Wednesday, February 7, 2018 5:57 PM > To: core-libs-dev ; build-dev > Subject: RFR 8190378: Java EE and CORBA modules removal > > Hi all, > > I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. > The CSR for removing the modules has been approved: https://bugs.openjdk.java.net/browse/JDK-8193757 > > The open webrev can be found at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/ > > To make the open review easier, I have broken the changes into 5 webrevs: > build changes are: http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/ > miscellaneous changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/ > module changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/ > rmic changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/ > test changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/ > > As part of the removal, the following issues have also been logged: > Removal of the Java EE and CORBA tools from the documentation: https://bugs.openjdk.java.net/browse/JDK-8193906 > Updating the RMIC man pages for the removal of the -iiop and -idl options: https://bugs.openjdk.java.net/browse/JDK-8196510 > Hotspot tests may require further updating or just removed: https://bugs.openjdk.java.net/browse/JDK-8194310 > jdeprescan will need updates due to the removal of the Java EE and CORBA modules: https://bugs.openjdk.java.net/browse/JDK-8194308 > > > > Best, > Lance > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Wed Feb 7 22:00:54 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 7 Feb 2018 14:00:54 -0800 Subject: RFR 8190378: Java EE and CORBA modules removal In-Reply-To: References: Message-ID: <640e4b80-9083-809a-2a90-798f9d848d2d@oracle.com> Hi Lance, Great to see this JEP moving along. I reviewed all changes except test/langtools/tools/javac tests. Looks fine overall. Minor comments: src/java.base/share/lib/security/default.policy - no change in this file. test/jdk/tools/jmod/hashes/HashesTest.java test/jdk/tools/launcher/modules/addexports/AddExportsTest.java - I think we should replace this test case with a different upgradeable module. It's okay to remove this case in this patch and follow up separately with a new JBS issue. test/langtools/tools/jdeps/modules/patches/java/sql/NonNull.java - copyright start year needs update. Mandy On 2/7/18 8:57 AM, Lance Andersen wrote: > Hi all, > > I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. > The CSR for removing the modules has been approved: https://bugs.openjdk.java.net/browse/JDK-8193757 > > The open webrev can be found at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/ > > To make the open review easier, I have broken the changes into 5 webrevs: > build changes are: http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/ > miscellaneous changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/ > module changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/ > rmic changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/ > test changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/ > > As part of the removal, the following issues have also been logged: > Removal of the Java EE and CORBA tools from the documentation: https://bugs.openjdk.java.net/browse/JDK-8193906 > Updating the RMIC man pages for the removal of the -iiop and -idl options: https://bugs.openjdk.java.net/browse/JDK-8196510 > Hotspot tests may require further updating or just removed: https://bugs.openjdk.java.net/browse/JDK-8194310 > jdeprescan will need updates due to the removal of the Java EE and CORBA modules: https://bugs.openjdk.java.net/browse/JDK-8194308 > > > > Best, > Lance > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From lance.andersen at oracle.com Wed Feb 7 22:33:13 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 7 Feb 2018 17:33:13 -0500 Subject: RFR 8190378: Java EE and CORBA modules removal In-Reply-To: <640e4b80-9083-809a-2a90-798f9d848d2d@oracle.com> References: <640e4b80-9083-809a-2a90-798f9d848d2d@oracle.com> Message-ID: <93C1985C-9E4B-4DCE-A306-E4A733007C11@oracle.com> Hi Mandy > On Feb 7, 2018, at 5:00 PM, mandy chung wrote: > > Hi Lance, > > Great to see this JEP moving along. I reviewed all changes except > test/langtools/tools/javac tests. > > Looks fine overall. Thank you for the review. > Minor comments: > > src/java.base/share/lib/security/default.policy > - no change in this file. Weird, not sure what happened, but it is now fixed. > > test/jdk/tools/jmod/hashes/HashesTest.java > test/jdk/tools/launcher/modules/addexports/AddExportsTest.java > - I think we should replace this test case with a different upgradeable module. > It's okay to remove this case in this patch and follow up separately with > a new JBS issue. I can do that. > > test/langtools/tools/jdeps/modules/patches/java/sql/NonNull.java > - copyright start year needs update. Updated. Best Lance > > Mandy > > On 2/7/18 8:57 AM, Lance Andersen wrote: >> Hi all, >> >> I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. >> The CSR for removing the modules has been approved: https://bugs.openjdk.java.net/browse/JDK-8193757 >> >> The open webrev can be found at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/ >> >> To make the open review easier, I have broken the changes into 5 webrevs: >> build changes are: http://cr.openjdk.java.net/~lancea/8190378/open_changes/build_webrev/ >> miscellaneous changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/misc_webrev/ >> module changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/modules_webrev/ >> rmic changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/rmic_webrev/ >> test changes are at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/ >> >> As part of the removal, the following issues have also been logged: >> Removal of the Java EE and CORBA tools from the documentation: https://bugs.openjdk.java.net/browse/JDK-8193906 >> Updating the RMIC man pages for the removal of the -iiop and -idl options: https://bugs.openjdk.java.net/browse/JDK-8196510 >> Hotspot tests may require further updating or just removed: https://bugs.openjdk.java.net/browse/JDK-8194310 >> jdeprescan will need updates due to the removal of the Java EE and CORBA modules: https://bugs.openjdk.java.net/browse/JDK-8194308 >> >> >> >> Best, >> Lance >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From erik.joelsson at oracle.com Wed Feb 7 22:33:36 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 7 Feb 2018 14:33:36 -0800 Subject: RFR: JDK-8196985: Disable new warnings from GCC 7.3 in jdk libraries Message-ID: When building the jdk with GCC 7.3, a bunch of new warnings are triggered. These include: * implicit-fallthrough * shift-negative-value * misleading-indentation * maybe-uninitialized I won't attempt to fix any of these at this point, but rather just disable the warnings. I have created followup issues (or added to existing ones where applicable) for each library/executable where warnings need to be evaluated. Bug: https://bugs.openjdk.java.net/browse/JDK-8196985 Webrev: http://cr.openjdk.java.net/~erikj/8196985/webrev.01/ /Erik From tim.bell at oracle.com Wed Feb 7 22:46:28 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 07 Feb 2018 14:46:28 -0800 Subject: RFR: JDK-8196985: Disable new warnings from GCC 7.3 in jdk libraries In-Reply-To: References: Message-ID: <5A7B81C4.4030209@oracle.com> Erik: > When building the jdk with GCC 7.3, a bunch of new warnings are > triggered. These include: > > * implicit-fallthrough > * shift-negative-value > * misleading-indentation > * maybe-uninitialized > > I won't attempt to fix any of these at this point, but rather just > disable the warnings. I have created followup issues (or added to > existing ones where applicable) for each library/executable where > warnings need to be evaluated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196985 > > Webrev: http://cr.openjdk.java.net/~erikj/8196985/webrev.01/ Looks good. Thanks for creating the followup bug reports. /Tim From erik.joelsson at oracle.com Wed Feb 7 22:57:27 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 7 Feb 2018 14:57:27 -0800 Subject: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3 Message-ID: For oracle internal builds, we need to construct a portable devkit based on GCC 7.3. This change contains the updated makefile logic used to create this. The changes adds gdb and the gold linker. It also adds dynamic downloading of the sysroot rpms. Several long standing bugs were also fixed. Bug: https://bugs.openjdk.java.net/browse/JDK-8196998 Webrev: http://cr.openjdk.java.net/~erikj/8196998/webrev.01/ /Erik From gary.adams at oracle.com Wed Feb 7 23:39:46 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Wed, 7 Feb 2018 18:39:46 -0500 Subject: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() In-Reply-To: <5A78AD3E.9090503@oracle.com> References: <5A6A2611.4030003@oracle.com> <5A731457.1040502@oracle.com> <5A78AD3E.9090503@oracle.com> Message-ID: <0d39f31d-9e09-80f6-d6fd-98346edc9f06@oracle.com> A fresh webrev rebased with latest jdk/jdk repos: ?http://cr.openjdk.java.net/~gadams/8080990/webrev.03/index.html If there are no more comments, I'll check in locally with these reviewers ? clanger,chegar,erikj and cut patches on Thurs AM. On 2/5/18 2:15 PM, Gary Adams wrote: > One more to fix to cover the remaining test failures I was seeing. > > Previously, using inet_addr, there was a single -1 return that needed > to be checked. > Now that we're using inet_pton, there is a -1 and a 0 error return to > be considered. > > My preference would be to leave the dbgSysInetAddr name unchanged and > have the low level > check for inet_pton errors to simply return the -1 that was previously > checked. > > This specific issue is about the deprecation of library functions on > windows. I'd recommend not > upgrading the other platforms at this time until a complete update is > done for ipv6 support. > > I'll post a new webrev when I've retested using the updated inet_pton > error checking. > > ... >> Hi Gary, >> >> >> >/Here's a revised webrev />//>/http://cr.openjdk.java.net/~gadams/8080990/webrev.01/index.html >> />//>/Still testing ... />//>/Using shutdown() fixed problems reported by the />/java/nio/channelSocketChannel tests. / >> The fix looks good. I would think we should rename dbgsysInetAddr to dbgsysPToN and use inet_pton also for the Unix/Linux platforms. It would be the better choice there as well, though we still only support IPv4 in libdt_socket. >> >> >//>/I also noticed prior use of getaddrinfo for "localhost" was not calling />/freeaddrinfo. / >> Thanks for spotting/fixing that. >> >> Best regards >> Christoph >> From tim.bell at oracle.com Thu Feb 8 01:49:44 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 07 Feb 2018 17:49:44 -0800 Subject: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3 In-Reply-To: References: Message-ID: <5A7BACB8.2080309@oracle.com> Erik: > For oracle internal builds, we need to construct a portable devkit based > on GCC 7.3. This change contains the updated makefile logic used to > create this. The changes adds gdb and the gold linker. It also adds > dynamic downloading of the sysroot rpms. Several long standing bugs were > also fixed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196998 > > Webrev: http://cr.openjdk.java.net/~erikj/8196998/webrev.01/ Looks good. /Tim From Alan.Bateman at oracle.com Thu Feb 8 08:04:02 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Feb 2018 08:04:02 +0000 Subject: RFR 8190378: Java EE and CORBA modules removal In-Reply-To: References: Message-ID: On 07/02/2018 16:57, Lance Andersen wrote: > Hi all, > > I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. > The CSR for removing the modules has been approved: https://bugs.openjdk.java.net/browse/JDK-8193757 > > The open webrev can be found at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/ > 800 KLOC deleted, wonderful! The update to technology-summary.html page means its html title no longer matches the contents. We should probably change it to "JCP Technologies in JDK 11" for now. The removal of test cases from the tests in tools/launcher/modules removes most of the test coverage for the upgrade module path. We'll need to replace these sub-tests. Can you create an issue to track that? Everything else looks good and it's okay to track residual issues with other JIRA issues. I think the important thing is to get this monster patch into JDK builds soon so that libraries and the eco system can start to adjust. -Alan From magnus.ihse.bursie at oracle.com Thu Feb 8 10:37:31 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 8 Feb 2018 11:37:31 +0100 Subject: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3 In-Reply-To: <5A7BACB8.2080309@oracle.com> References: <5A7BACB8.2080309@oracle.com> Message-ID: Erik, Is it possible that you could address https://bugs.openjdk.java.net/browse/JDK-8193016 at this time as well? Apart from that, it looks good to me. /Magnus > 8 feb. 2018 kl. 02:49 skrev Tim Bell : > > Erik: > >> For oracle internal builds, we need to construct a portable devkit based >> on GCC 7.3. This change contains the updated makefile logic used to >> create this. The changes adds gdb and the gold linker. It also adds >> dynamic downloading of the sysroot rpms. Several long standing bugs were >> also fixed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196998 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8196998/webrev.01/ > > > Looks good. > > /Tim > From magnus.ihse.bursie at oracle.com Thu Feb 8 11:06:30 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 8 Feb 2018 12:06:30 +0100 Subject: RFR: JDK-8196985: Disable new warnings from GCC 7.3 in jdk libraries In-Reply-To: References: Message-ID: <791BBCA2-5E6C-43AC-B1DD-900457B39DCA@oracle.com> Looks good to me. /Magnus > 7 feb. 2018 kl. 23:33 skrev Erik Joelsson : > > When building the jdk with GCC 7.3, a bunch of new warnings are triggered. These include: > > * implicit-fallthrough > * shift-negative-value > * misleading-indentation > * maybe-uninitialized > > I won't attempt to fix any of these at this point, but rather just disable the warnings. I have created followup issues (or added to existing ones where applicable) for each library/executable where warnings need to be evaluated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196985 > > Webrev: http://cr.openjdk.java.net/~erikj/8196985/webrev.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Thu Feb 8 13:19:34 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 8 Feb 2018 14:19:34 +0100 Subject: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux In-Reply-To: References: <8d4cdbde-cf35-648d-9010-1ec692334b0b@physik.fu-berlin.de> Message-ID: <6efa438a-ee76-ba51-8cd7-88d49ee84ce8@oracle.com> On 2018-01-17 15:07, Adam Farley8 wrote: >>> If this is the consensus, then perhaps we should consider setting >>> --disable-warnings-as-errors by default (in the code), rather than >>> depending on the user using an option which is not part of the formal >>> build instructions. >> I'm not sure why. > Because the default build instructions don't work in this scenario, and > if all the effort to impliment a clone-config-make model was intended to > encourage more users to attempt a local build (in order to try their hand > at a fixing a bug themselves or something) it makes sense to me to try > to maintain a scenario where OpenJDK can build to completion across a wide > variety of toolchains. I'm not sure what you mean by that the "default build instrictions don't work". When the build fails due to a warning and you have not disabled warnings as error, the build output looks like this: ERROR: Build failed for target 'jdk' in configuration 'linux-x64' (exit code 2) === Output from failing command(s) repeated here === * For target support_native_jdk.management_libmanagement_ext_Flag.o: /localhome/hg/jdk-ALT/open/src/jdk.management/share/native/libmanagement_ext/Flag.c: In function 'heh': /localhome/hg/jdk-ALT/open/src/jdk.management/share/native/libmanagement_ext/Flag.c:37:10: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] ?if (hest < 0) { ????????? ^ cc1: all warnings being treated as errors * All command lines available in /localhome/hg/jdk-ALT/build/linux-x64/make-support/failure-logs. === End of repeated output === === Make failed targets repeated here === Lib-jdk.management.gmk:56: recipe for target '/localhome/hg/jdk-ALT/build/linux-x64/support/native/jdk.management/libmanagement_ext/Flag.o' failed make/Main.gmk:226: recipe for target 'jdk.management-libs' 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. I don't think it requires much of an effort or capacity as a programmer to figure out that this is a warning, which was turned into an error. At the very last line before your prompt, you are also given a very good suggestion. And very much so, the troubleshooting chapter does indeed have a section on "Fixing Unexpected Build Failures" where --disable-warnings-as-errors are suggested. If by "default" you mean that you only read like the top part of the document: "TL;DR (Instructions for the Impatient) If you are eager to try out building OpenJDK, these simple steps works most of the time." but missed out the "most of the time" or the "If any of these steps failed, or if you want to know more about build requirements or build functionality, please continue reading this document." following after the just 5 numbered items, then I don't know what will help you. We try really hard to make the build experience easy, pleasant and simple, but there is no way that everything is ever going to work perfectly straight out of the box for anyone. Especially not if they are using exotic or unusal hardware or software. In those cases, reading the documentation is necessary, as for all software projects. /Magnus > >> Building OpenJDK from source isn't exactly something >> that is done by normal users. If someone is willing to hack on the > OpenJDK >> code base, I would assume they know about -Werror and similar options and >> how to control them. > I don't agree. Someone should not have to be familiar with gcc options in > order to fix a typo, or change some Java code. And besides, we have a > clear > and simple four-step build process (clone, get source, configure, make). > Why would we want people to have to fail their build and experiment with > different options, when we can fix the problem right here and now. > >> I mean, yes, you can change that to have -Werror turned off by default, >> but having the compiler complain less is usually a bad idea. > In general, yes. In this one compile it's breaking the build. > > David suggested disabling this warning. The simplest way I see to do this > is to change Awt2dLibraries.gmk. > > The code is here: > > $(eval $(call SetupNativeCompilation,BUILD_LIBJAVAJPEG, \ > LIBRARY := javajpeg, \ > OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ > SRC := $(LIBJAVAJPEG_SRC), \ > INCLUDE_FILES := $(BUILD_LIBJAVAJPEG_INCLUDE_FILES), \ > OPTIMIZATION := HIGHEST, \ > > Switching the OPTIMIZATION to LOW will solve this at a stroke. > > Best Regards > > Adam farley > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From lance.andersen at oracle.com Thu Feb 8 13:37:51 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 8 Feb 2018 08:37:51 -0500 Subject: RFR 8190378: Java EE and CORBA modules removal In-Reply-To: References: Message-ID: <360C5181-3B9E-4339-B460-04A8385F2461@oracle.com> > On Feb 8, 2018, at 3:04 AM, Alan Bateman wrote: > > On 07/02/2018 16:57, Lance Andersen wrote: >> Hi all, >> >> I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. >> The CSR for removing the modules has been approved: https://bugs.openjdk.java.net/browse/JDK-8193757 >> >> The open webrev can be found at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/ >> > 800 KLOC deleted, wonderful! > > The update to technology-summary.html page means its html title no longer matches the contents. We should probably change it to "JCP Technologies in JDK 11" for now. I updated the webrev. Thanks for catching that (btw we missed this for JDK 10) > > The removal of test cases from the tests in tools/launcher/modules removes most of the test coverage for the upgrade module path. We'll need to replace these sub-tests. Can you create an issue to track that? I can do that > > Everything else looks good and it's okay to track residual issues with other JIRA issues. I think the important thing is to get this monster patch into JDK builds soon so that libraries and the eco system can start to adjust. Thank you Alan for the review Best Lance > > -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From thomas.stuefe at gmail.com Thu Feb 8 14:42:04 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 8 Feb 2018 15:42:04 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build Message-ID: Hi, may I please have reviews for this tiny fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ Thanks and Kind Regards, Thomas From goetz.lindenmaier at sap.com Thu Feb 8 14:49:13 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 8 Feb 2018 14:49:13 +0000 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: <70b84988307847d888f514b5ef3ad776@sap.com> HI Thomas, looks good, thanks! Best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Thomas St?fe > Sent: Donnerstag, 8. Februar 2018 15:42 > To: ppc-aix-port-dev at openjdk.java.net; build-dev dev at openjdk.java.net> > Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in > fastdebug build > > Hi, > > may I please have reviews for this tiny fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc- > overflow-in-fastdebug/webrev.00/webrev/ > > Thanks and Kind Regards, Thomas From matthias.baesken at sap.com Thu Feb 8 14:58:50 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 8 Feb 2018 14:58:50 +0000 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: <42c7d1d9fddc4136a4238daadc5a357f@sap.com> Hi Thomas , looks good to me ( not a Reviever however). Best Regards, Matthias From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe Sent: Donnerstag, 8. Februar 2018 15:42 To: ppc-aix-port-dev at openjdk.java.net; build-dev Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build Hi, may I please have reviews for this tiny fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ Thanks and Kind Regards, Thomas From erik.joelsson at oracle.com Thu Feb 8 17:09:03 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Feb 2018 09:09:03 -0800 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: Looks good, happy pushing without a sponsor! /Erik On 2018-02-08 06:42, Thomas St?fe wrote: > Hi, > > may I please have reviews for this tiny fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ > > Thanks and Kind Regards, Thomas From thomas.stuefe at gmail.com Thu Feb 8 17:11:28 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 8 Feb 2018 18:11:28 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: Hi Eric, On Thu, Feb 8, 2018 at 6:09 PM, Erik Joelsson wrote: > Looks good, happy pushing without a sponsor! > > /Erik > > Yes please, that would be nice! ..Thomas > > > On 2018-02-08 06:42, Thomas St?fe wrote: > >> Hi, >> >> may I please have reviews for this tiny fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc- >> overflow-in-fastdebug/webrev.00/webrev/ >> >> Thanks and Kind Regards, Thomas >> > > From thomas.stuefe at gmail.com Thu Feb 8 17:19:55 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 8 Feb 2018 18:19:55 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: <42c7d1d9fddc4136a4238daadc5a357f@sap.com> References: <42c7d1d9fddc4136a4238daadc5a357f@sap.com> Message-ID: Thanks Matthias! On Thu, Feb 8, 2018 at 3:58 PM, Baesken, Matthias wrote: > Hi Thomas , looks good to me ( not a Reviever however). > > > > Best Regards, Matthias > > > > *From:* ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] > *On Behalf Of *Thomas St?fe > *Sent:* Donnerstag, 8. Februar 2018 15:42 > *To:* ppc-aix-port-dev at openjdk.java.net; build-dev < > build-dev at openjdk.java.net> > *Subject:* RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so > in fastdebug build > > > > Hi, > > > > may I please have reviews for this tiny fix: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 > > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ > 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ > > > > Thanks and Kind Regards, Thomas > From thomas.stuefe at gmail.com Thu Feb 8 17:20:02 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 8 Feb 2018 18:20:02 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: <70b84988307847d888f514b5ef3ad776@sap.com> References: <70b84988307847d888f514b5ef3ad776@sap.com> Message-ID: Thanks! On Thu, Feb 8, 2018 at 3:49 PM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > HI Thomas, > > looks good, thanks! > > Best regards, > Goetz. > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > bounces at openjdk.java.net] On Behalf Of Thomas St?fe > > Sent: Donnerstag, 8. Februar 2018 15:42 > > To: ppc-aix-port-dev at openjdk.java.net; build-dev > dev at openjdk.java.net> > > Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in > > fastdebug build > > > > Hi, > > > > may I please have reviews for this tiny fix: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 > > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc- > > overflow-in-fastdebug/webrev.00/webrev/ > > > > Thanks and Kind Regards, Thomas > From erik.joelsson at oracle.com Thu Feb 8 17:49:51 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Feb 2018 09:49:51 -0800 Subject: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time Message-ID: The check for when to generate the generated configure script is not working quite as expected. It currently only compares timestamps if the local repository has any local changes in the make/autoconf directory. This used to make sense when we had a committed generated script, but now we actually do need to regenerate any time an input file is newer than the generated script. Bug: https://bugs.openjdk.java.net/browse/JDK-8196356 Webrev: http://cr.openjdk.java.net/~erikj/8196356/webrev.01/ /Erik From erik.joelsson at oracle.com Thu Feb 8 17:50:16 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Feb 2018 09:50:16 -0800 Subject: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3 In-Reply-To: References: <5A7BACB8.2080309@oracle.com> Message-ID: Good point, I will look into it. /Erik On 2018-02-08 02:37, Magnus Ihse Bursie wrote: > Erik, > > Is it possible that you could address > https://bugs.openjdk.java.net/browse/JDK-8193016?at this time as well? > > Apart from that, it looks good to me. > > /Magnus > > 8 feb. 2018 kl. 02:49 skrev Tim Bell >: > >> Erik: >> >>> For oracle internal builds, we need to construct a portable devkit based >>> on GCC 7.3. This change contains the updated makefile logic used to >>> create this. The changes adds gdb and the gold linker. It also adds >>> dynamic downloading of the sysroot rpms. Several long standing bugs were >>> also fixed. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196998 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8196998/webrev.01/ >>> >> >> >> Looks good. >> >> /Tim >> From tim.bell at oracle.com Thu Feb 8 17:54:46 2018 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 08 Feb 2018 09:54:46 -0800 Subject: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time In-Reply-To: References: Message-ID: <5A7C8EE6.6000500@oracle.com> Erik: > The check for when to generate the generated configure script is not > working quite as expected. It currently only compares timestamps if the > local repository has any local changes in the make/autoconf directory. > This used to make sense when we had a committed generated script, but > now we actually do need to regenerate any time an input file is newer > than the generated script. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196356 > > Webrev: http://cr.openjdk.java.net/~erikj/8196356/webrev.01/ Yes, that makes sense. Looks good to me. /Tim From erik.joelsson at oracle.com Thu Feb 8 19:42:18 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Feb 2018 11:42:18 -0800 Subject: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3 In-Reply-To: References: <5A7BACB8.2080309@oracle.com> Message-ID: <02a3f756-170d-21ba-a6bb-ae5a7bd76d90@oracle.com> Here is a new webrev with dtrace included. I have verified that it builds open linux-x64 successfully with dtrace enabled both on my Ubuntu without any dtrace installed as well as in mach5. http://cr.openjdk.java.net/~erikj/8196998/webrev.02/ /Erik On 2018-02-08 02:37, Magnus Ihse Bursie wrote: > Erik, > > Is it possible that you could address > https://bugs.openjdk.java.net/browse/JDK-8193016?at this time as well? > > Apart from that, it looks good to me. > > /Magnus > > 8 feb. 2018 kl. 02:49 skrev Tim Bell >: > >> Erik: >> >>> For oracle internal builds, we need to construct a portable devkit based >>> on GCC 7.3. This change contains the updated makefile logic used to >>> create this. The changes adds gdb and the gold linker. It also adds >>> dynamic downloading of the sysroot rpms. Several long standing bugs were >>> also fixed. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196998 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8196998/webrev.01/ >>> >> >> >> Looks good. >> >> /Tim >> From tim.bell at oracle.com Thu Feb 8 19:55:55 2018 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 08 Feb 2018 11:55:55 -0800 Subject: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3 In-Reply-To: <02a3f756-170d-21ba-a6bb-ae5a7bd76d90@oracle.com> References: <5A7BACB8.2080309@oracle.com> <02a3f756-170d-21ba-a6bb-ae5a7bd76d90@oracle.com> Message-ID: <5A7CAB4B.7070001@oracle.com> Erik: make/devkit/Tools.gmk line 553: one typo - 'too the' should be 'to the' Looks good otherwise. Tim On 02/08/18 11:42, Erik Joelsson wrote: > Here is a new webrev with dtrace included. I have verified that it > builds open linux-x64 successfully with dtrace enabled both on my Ubuntu > without any dtrace installed as well as in mach5. > > http://cr.openjdk.java.net/~erikj/8196998/webrev.02/ > > /Erik > > > On 2018-02-08 02:37, Magnus Ihse Bursie wrote: >> Erik, >> >> Is it possible that you could address >> https://bugs.openjdk.java.net/browse/JDK-8193016 at this time as well? >> >> Apart from that, it looks good to me. >> >> /Magnus >> >> 8 feb. 2018 kl. 02:49 skrev Tim Bell > >: >> >>> Erik: >>> >>>> For oracle internal builds, we need to construct a portable devkit based >>>> on GCC 7.3. This change contains the updated makefile logic used to >>>> create this. The changes adds gdb and the gold linker. It also adds >>>> dynamic downloading of the sysroot rpms. Several long standing bugs were >>>> also fixed. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196998 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8196998/webrev.01/ >>>> >>> >>> >>> Looks good. >>> >>> /Tim >>> > From erik.joelsson at oracle.com Thu Feb 8 19:59:31 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Feb 2018 11:59:31 -0800 Subject: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3 In-Reply-To: <5A7CAB4B.7070001@oracle.com> References: <5A7BACB8.2080309@oracle.com> <02a3f756-170d-21ba-a6bb-ae5a7bd76d90@oracle.com> <5A7CAB4B.7070001@oracle.com> Message-ID: <410eb0fa-64e9-bf71-0856-3e183cc06f59@oracle.com> Thanks, updated in place. /Erik On 2018-02-08 11:55, Tim Bell wrote: > Erik: > > make/devkit/Tools.gmk > > line 553: one typo - 'too the' should be 'to the' > > Looks good otherwise. > > Tim > > On 02/08/18 11:42, Erik Joelsson wrote: >> Here is a new webrev with dtrace included. I have verified that it >> builds open linux-x64 successfully with dtrace enabled both on my Ubuntu >> without any dtrace installed as well as in mach5. >> >> http://cr.openjdk.java.net/~erikj/8196998/webrev.02/ >> >> /Erik >> >> >> On 2018-02-08 02:37, Magnus Ihse Bursie wrote: >>> Erik, >>> >>> Is it possible that you could address >>> https://bugs.openjdk.java.net/browse/JDK-8193016 at this time as well? >>> >>> Apart from that, it looks good to me. >>> >>> /Magnus >>> >>> 8 feb. 2018 kl. 02:49 skrev Tim Bell >> >: >>> >>>> Erik: >>>> >>>>> For oracle internal builds, we need to construct a portable devkit >>>>> based >>>>> on GCC 7.3. This change contains the updated makefile logic used to >>>>> create this. The changes adds gdb and the gold linker. It also adds >>>>> dynamic downloading of the sysroot rpms. Several long standing >>>>> bugs were >>>>> also fixed. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196998 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8196998/webrev.01/ >>>>> >>>> >>>> >>>> Looks good. >>>> >>>> /Tim >>>> >> > From magnus.ihse.bursie at oracle.com Thu Feb 8 21:53:40 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 8 Feb 2018 22:53:40 +0100 Subject: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3 In-Reply-To: <410eb0fa-64e9-bf71-0856-3e183cc06f59@oracle.com> References: <5A7BACB8.2080309@oracle.com> <02a3f756-170d-21ba-a6bb-ae5a7bd76d90@oracle.com> <5A7CAB4B.7070001@oracle.com> <410eb0fa-64e9-bf71-0856-3e183cc06f59@oracle.com> Message-ID: <984EF126-86F8-40CC-A774-A13669FEDBC9@oracle.com> Looks good to me. /Magnus > 8 feb. 2018 kl. 20:59 skrev Erik Joelsson : > > Thanks, updated in place. > > /Erik > > >> On 2018-02-08 11:55, Tim Bell wrote: >> Erik: >> >> make/devkit/Tools.gmk >> >> line 553: one typo - 'too the' should be 'to the' >> >> Looks good otherwise. >> >> Tim >> >>> On 02/08/18 11:42, Erik Joelsson wrote: >>> Here is a new webrev with dtrace included. I have verified that it >>> builds open linux-x64 successfully with dtrace enabled both on my Ubuntu >>> without any dtrace installed as well as in mach5. >>> >>> http://cr.openjdk.java.net/~erikj/8196998/webrev.02/ >>> >>> /Erik >>> >>> >>>> On 2018-02-08 02:37, Magnus Ihse Bursie wrote: >>>> Erik, >>>> >>>> Is it possible that you could address >>>> https://bugs.openjdk.java.net/browse/JDK-8193016 at this time as well? >>>> >>>> Apart from that, it looks good to me. >>>> >>>> /Magnus >>>> >>>> 8 feb. 2018 kl. 02:49 skrev Tim Bell >>> >: >>>> >>>>> Erik: >>>>> >>>>>> For oracle internal builds, we need to construct a portable devkit based >>>>>> on GCC 7.3. This change contains the updated makefile logic used to >>>>>> create this. The changes adds gdb and the gold linker. It also adds >>>>>> dynamic downloading of the sysroot rpms. Several long standing bugs were >>>>>> also fixed. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196998 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8196998/webrev.01/ >>>>>> >>>>> >>>>> >>>>> Looks good. >>>>> >>>>> /Tim >>>>> >>> >> > From erik.joelsson at oracle.com Fri Feb 9 16:37:50 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Feb 2018 08:37:50 -0800 Subject: RFR: JDK-8187676: Disable uninitialized warnings for two files until proper fix available Message-ID: Hello, In preparation for upgrading the toolchains used at Oracle, we need the build to be clean with the new compiler versions. On Linux, we are currently aiming at GCC 7.3. In hotspot, two files generate warnings when using this compiler. I found this issue already filed with a patch for disabling the warnings and the related issue JDK-8160404 which will deal with actually fixing the problem. I would like to push the disabling of the warnings ASAP so that the compiler upgrade project can continue unhindered. Bug: https://bugs.openjdk.java.net/browse/JDK-8187676 Webrev: http://cr.openjdk.java.net/~ehelin/8187676/00/ /Erik From tim.bell at oracle.com Fri Feb 9 17:13:43 2018 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 09 Feb 2018 09:13:43 -0800 Subject: RFR: JDK-8187676: Disable uninitialized warnings for two files until proper fix available In-Reply-To: References: Message-ID: <5A7DD6C7.2000103@oracle.com> Erik: > In preparation for upgrading the toolchains used at Oracle, we need the > build to be clean with the new compiler versions. On Linux, we are > currently aiming at GCC 7.3. In hotspot, two files generate warnings > when using this compiler. I found this issue already filed with a patch > for disabling the warnings and the related issue JDK-8160404 which will > deal with actually fixing the problem. I would like to push the > disabling of the warnings ASAP so that the compiler upgrade project can > continue unhindered. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187676 > > Webrev: http://cr.openjdk.java.net/~ehelin/8187676/00/ Looks good. /Tim From vladimir.kozlov at oracle.com Fri Feb 9 17:31:36 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Feb 2018 09:31:36 -0800 Subject: RFR: JDK-8187676: Disable uninitialized warnings for two files until proper fix available In-Reply-To: References: Message-ID: <3f07db43-90be-dac5-466e-8a035c85c37d@oracle.com> Good. Thanks, Vladimir K On 2/9/18 8:37 AM, Erik Joelsson wrote: > Hello, > > In preparation for upgrading the toolchains used at Oracle, we need the build to be clean with the new compiler > versions. On Linux, we are currently aiming at GCC 7.3. In hotspot, two files generate warnings when using this > compiler. I found this issue already filed with a patch for disabling the warnings and the related issue JDK-8160404 > which will deal with actually fixing the problem. I would like to push the disabling of the warnings ASAP so that the > compiler upgrade project can continue unhindered. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187676 > > Webrev: http://cr.openjdk.java.net/~ehelin/8187676/00/ > > /Erik > From magnus.ihse.bursie at oracle.com Fri Feb 9 20:19:18 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 9 Feb 2018 21:19:18 +0100 Subject: RFR: JDK-8187676: Disable uninitialized warnings for two files until proper fix available In-Reply-To: References: Message-ID: Looks good to me. (But ~ehelin..?) /Magnus > 9 feb. 2018 kl. 17:37 skrev Erik Joelsson : > > Hello, > > In preparation for upgrading the toolchains used at Oracle, we need the build to be clean with the new compiler versions. On Linux, we are currently aiming at GCC 7.3. In hotspot, two files generate warnings when using this compiler. I found this issue already filed with a patch for disabling the warnings and the related issue JDK-8160404 which will deal with actually fixing the problem. I would like to push the disabling of the warnings ASAP so that the compiler upgrade project can continue unhindered. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187676 > > Webrev: http://cr.openjdk.java.net/~ehelin/8187676/00/ > > /Erik > From erik.joelsson at oracle.com Fri Feb 9 21:02:07 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Feb 2018 13:02:07 -0800 Subject: RFR: JDK-8187676: Disable uninitialized warnings for two files until proper fix available In-Reply-To: References: Message-ID: On 2018-02-09 12:19, Magnus Ihse Bursie wrote: > (But ~ehelin..?) > I found the issue filed and review posted already last year, but it was dropped in favor of fixing the underlying problem instead. I just reused his patch. See hotspot-compiler-dev archive if you are curious: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-November/027719.html /Erik From Alan.Bateman at oracle.com Sat Feb 10 08:12:32 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 10 Feb 2018 08:12:32 +0000 Subject: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time In-Reply-To: References: Message-ID: <5403cf9c-3db4-ade9-809e-d1fa536e2c23@oracle.com> On 08/02/2018 17:49, Erik Joelsson wrote: > The check for when to generate the generated configure script is not > working quite as expected. It currently only compares timestamps if > the local repository has any local changes in the make/autoconf > directory. This used to make sense when we had a committed generated > script, but now we actually do need to regenerate any time an input > file is newer than the generated script. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196356 In addition to `hg status` showing no changes, I think it will continue to confuse people to generate it into a hidden directory. Was there any consideration to generating into a regular directory? -Alan From thomas.stuefe at gmail.com Sat Feb 10 11:29:21 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 10 Feb 2018 12:29:21 +0100 Subject: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time In-Reply-To: <5403cf9c-3db4-ade9-809e-d1fa536e2c23@oracle.com> References: <5403cf9c-3db4-ade9-809e-d1fa536e2c23@oracle.com> Message-ID: On Sat, Feb 10, 2018 at 9:12 AM, Alan Bateman wrote: > On 08/02/2018 17:49, Erik Joelsson wrote: > >> The check for when to generate the generated configure script is not >> working quite as expected. It currently only compares timestamps if the >> local repository has any local changes in the make/autoconf directory. This >> used to make sense when we had a committed generated script, but now we >> actually do need to regenerate any time an input file is newer than the >> generated script. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196356 >> > In addition to `hg status` showing no changes, I think it will continue to > confuse people to generate it into a hidden directory. Was there any > consideration to generating into a regular directory? > > I agree. Also, we still generate the configure.sh into the source tree even if the output directory is somewhere else. I always keep my output directories separate from the source tree. Sometimes my source directory is even on a read-only share. I would prefer and also expect any temporary files to be placed in the output directory resp. the current directory, not in the source tree. Would that be possible? Thanks and Kind Regards, Thomas > -Alan > From martinrb at google.com Sat Feb 10 22:39:36 2018 From: martinrb at google.com (Martin Buchholz) Date: Sat, 10 Feb 2018 14:39:36 -0800 Subject: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time In-Reply-To: References: <5403cf9c-3db4-ade9-809e-d1fa536e2c23@oracle.com> Message-ID: I agree. Once you make something lazy-initted you have a concurrency problem. And there's no CAS or lock on the filesystem. What happens if two configure processes run at exactly the same time, perhaps even with different versions of autoconf? If you lazy-generate configure, it must be written outside the source tree. On Sat, Feb 10, 2018 at 3:29 AM, Thomas St?fe wrote: > On Sat, Feb 10, 2018 at 9:12 AM, Alan Bateman > wrote: > > > On 08/02/2018 17:49, Erik Joelsson wrote: > > > >> The check for when to generate the generated configure script is not > >> working quite as expected. It currently only compares timestamps if the > >> local repository has any local changes in the make/autoconf directory. > This > >> used to make sense when we had a committed generated script, but now we > >> actually do need to regenerate any time an input file is newer than the > >> generated script. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196356 > >> > > In addition to `hg status` showing no changes, I think it will continue > to > > confuse people to generate it into a hidden directory. Was there any > > consideration to generating into a regular directory? > > > > > I agree. Also, we still generate the configure.sh into the source tree even > if the output directory is somewhere else. I always keep my output > directories separate from the source tree. Sometimes my source directory is > even on a read-only share. I would prefer and also expect any temporary > files to be placed in the output directory resp. the current directory, not > in the source tree. Would that be possible? > > Thanks and Kind Regards, Thomas > > > > -Alan > > > From martijnverburg at gmail.com Mon Feb 12 10:06:11 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 12 Feb 2018 10:06:11 +0000 Subject: RFR 8190378: Java EE and CORBA modules removal In-Reply-To: <360C5181-3B9E-4339-B460-04A8385F2461@oracle.com> References: <360C5181-3B9E-4339-B460-04A8385F2461@oracle.com> Message-ID: One could almost shed a tear - of joy! This is exactly the use case for the module system that the developer community at large will understand. Thanks for this change and a leaner meaner JDK. Cheers, Martijn On 8 February 2018 at 13:37, Lance Andersen wrote: > > > On Feb 8, 2018, at 3:04 AM, Alan Bateman > wrote: > > > > On 07/02/2018 16:57, Lance Andersen wrote: > >> Hi all, > >> > >> I think we are at a point where we are ready to start reviewing the > changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, > has been targeted to JDK 11. > >> The CSR for removing the modules has been approved: > https://bugs.openjdk.java.net/browse/JDK-8193757 < > https://bugs.openjdk.java.net/browse/JDK-8193757> > >> > >> The open webrev can be found at: http://cr.openjdk.java.net/~ > lancea/8190378/open_changes/ lancea/8190378/open_changes/> > >> > > 800 KLOC deleted, wonderful! > > > > The update to technology-summary.html page means its html title no > longer matches the contents. We should probably change it to "JCP > Technologies in JDK 11" for now. > > I updated the webrev. Thanks for catching that (btw we missed this for JDK > 10) > > > > The removal of test cases from the tests in tools/launcher/modules > removes most of the test coverage for the upgrade module path. We'll need > to replace these sub-tests. Can you create an issue to track that? > > I can do that > > > > Everything else looks good and it's okay to track residual issues with > other JIRA issues. I think the important thing is to get this monster patch > into JDK builds soon so that libraries and the eco system can start to > adjust. > > Thank you Alan for the review > > Best > Lance > > > > -Alan > > > < > http://oracle.com/us/design/oracle-email-sig-198324.gif> > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From magnus.ihse.bursie at oracle.com Mon Feb 12 11:42:23 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Feb 2018 12:42:23 +0100 Subject: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time In-Reply-To: <5403cf9c-3db4-ade9-809e-d1fa536e2c23@oracle.com> References: <5403cf9c-3db4-ade9-809e-d1fa536e2c23@oracle.com> Message-ID: On 2018-02-10 09:12, Alan Bateman wrote: > On 08/02/2018 17:49, Erik Joelsson wrote: >> The check for when to generate the generated configure script is not >> working quite as expected. It currently only compares timestamps if >> the local repository has any local changes in the make/autoconf >> directory. This used to make sense when we had a committed generated >> script, but now we actually do need to regenerate any time an input >> file is newer than the generated script. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196356 > In addition to `hg status` showing no changes, I think it will > continue to confuse people to generate it into a hidden directory. Was > there any consideration to generating into a regular directory? Why would hidden files be confusing? Or, rephrased, how is this any more confusing than other hidden directories, such as .idea or .jib? I modelled the behaviour on jib. In fact, I was considering using the same directory (.jib), but since the name was so specialized, it felt like misusing it. That's why I gave it a more general name. (In fact, I believe, if .build had been present when jib was created, it would have used that instead of creating the specialized .jib directory). /Magnus From magnus.ihse.bursie at oracle.com Mon Feb 12 11:50:59 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Feb 2018 12:50:59 +0100 Subject: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time In-Reply-To: References: <5403cf9c-3db4-ade9-809e-d1fa536e2c23@oracle.com> Message-ID: On 2018-02-10 23:39, Martin Buchholz wrote: > I agree. Once you make something lazy-initted you have a concurrency > problem. And there's no CAS or lock on the filesystem. What happens if > two configure processes run at exactly the same time, perhaps even with > different versions of autoconf? If you lazy-generate configure, it must be > written outside the source tree. That is of course a problem with the entire build system, and is certainly not unique to this problem. What happens if you run "make" concurrently in the same directory? Catastrophe! Or if you run "configure" at the same time? Disaster! Creating the file outside the source tree will not help in the slightest regard; you can just as well create a race condition in any place you select. This does not sound like a real-world problem that one has to safe-guard against. /Magnus > > On Sat, Feb 10, 2018 at 3:29 AM, Thomas St?fe > wrote: > >> On Sat, Feb 10, 2018 at 9:12 AM, Alan Bateman >> wrote: >> >>> On 08/02/2018 17:49, Erik Joelsson wrote: >>> >>>> The check for when to generate the generated configure script is not >>>> working quite as expected. It currently only compares timestamps if the >>>> local repository has any local changes in the make/autoconf directory. >> This >>>> used to make sense when we had a committed generated script, but now we >>>> actually do need to regenerate any time an input file is newer than the >>>> generated script. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196356 >>>> >>> In addition to `hg status` showing no changes, I think it will continue >> to >>> confuse people to generate it into a hidden directory. Was there any >>> consideration to generating into a regular directory? >>> >>> >> I agree. Also, we still generate the configure.sh into the source tree even >> if the output directory is somewhere else. I always keep my output >> directories separate from the source tree. Sometimes my source directory is >> even on a read-only share. I would prefer and also expect any temporary >> files to be placed in the output directory resp. the current directory, not >> in the source tree. Would that be possible? >> >> Thanks and Kind Regards, Thomas >> >> >>> -Alan >>> From Alan.Bateman at oracle.com Mon Feb 12 12:01:11 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Feb 2018 12:01:11 +0000 Subject: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time In-Reply-To: References: <5403cf9c-3db4-ade9-809e-d1fa536e2c23@oracle.com> Message-ID: On 12/02/2018 11:42, Magnus Ihse Bursie wrote: > > Why would hidden files be confusing? Or, rephrased, how is this any > more confusing than other hidden directories, such as .idea or .jib? I > modelled the behaviour on jib. In fact, I was considering using the > same directory (.jib), but since the name was so specialized, it felt > like misusing it. That's why I gave it a more general name. (In fact, > I believe, if .build had been present when jib was created, it would > have used that instead of creating the specialized .jib directory). I'm aware of at least 10 people that ran into problems in the latter part of last week because they didn't know about the .build directory. I think most people are used to blowing away the build directory, the .build directory is new so we need to learn to blow away that too (irrespective of whether the build re-generated when it seems the time stamp is old). All I'm saying is that hidden directories have a tenancy to confuse. I can't comment on .jib as that is not in OpenJDK. -Alan From thomas.stuefe at gmail.com Mon Feb 12 12:03:16 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Feb 2018 13:03:16 +0100 Subject: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time In-Reply-To: References: <5403cf9c-3db4-ade9-809e-d1fa536e2c23@oracle.com> Message-ID: Hi Magnus, On Mon, Feb 12, 2018 at 12:50 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2018-02-10 23:39, Martin Buchholz wrote: > >> I agree. Once you make something lazy-initted you have a concurrency >> problem. And there's no CAS or lock on the filesystem. What happens if >> two configure processes run at exactly the same time, perhaps even with >> different versions of autoconf? If you lazy-generate configure, it must >> be >> written outside the source tree. >> > That is of course a problem with the entire build system, and is certainly > not unique to this problem. What happens if you run "make" concurrently in > the same directory? Catastrophe! Or if you run "configure" at the same > time? Disaster! Creating the file outside the source tree will not help in > the slightest regard; you can just as well create a race condition in any > place you select. This does not sound like a real-world problem that one > has to safe-guard against. > > Until now it was perfectly fine to run N makes in parallel from the same source tree. I do this all the time: I have a source directory and a number of output directories side by side for various build configurations (debug, fastdebug, release, 32bit, zero...); in the morning I pull all changes and start a number of scratch builds. We also do this nightly. We share source trees for multiple builds (among other reasons it makes comparing builds easier). But since now the configuration is written by the build into the source tree, parallel builds can overwrite each others generated-configure shell script. As for your other mail, this issue here (generating stuff into the source tree) is for me a far greater pain than the fact that the directory is hidden; the latter is just aesthetics, and as you say, we already do this in other cases. Best Regards, Thomas > /Magnus > > > >> On Sat, Feb 10, 2018 at 3:29 AM, Thomas St?fe >> wrote: >> >> On Sat, Feb 10, 2018 at 9:12 AM, Alan Bateman >>> wrote: >>> >>> On 08/02/2018 17:49, Erik Joelsson wrote: >>>> >>>> The check for when to generate the generated configure script is not >>>>> working quite as expected. It currently only compares timestamps if the >>>>> local repository has any local changes in the make/autoconf directory. >>>>> >>>> This >>> >>>> used to make sense when we had a committed generated script, but now we >>>>> actually do need to regenerate any time an input file is newer than the >>>>> generated script. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196356 >>>>> >>>>> In addition to `hg status` showing no changes, I think it will continue >>>> >>> to >>> >>>> confuse people to generate it into a hidden directory. Was there any >>>> consideration to generating into a regular directory? >>>> >>>> >>>> I agree. Also, we still generate the configure.sh into the source tree >>> even >>> if the output directory is somewhere else. I always keep my output >>> directories separate from the source tree. Sometimes my source directory >>> is >>> even on a read-only share. I would prefer and also expect any temporary >>> files to be placed in the output directory resp. the current directory, >>> not >>> in the source tree. Would that be possible? >>> >>> Thanks and Kind Regards, Thomas >>> >>> >>> -Alan >>>> >>>> > From magnus.ihse.bursie at oracle.com Mon Feb 12 13:09:15 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Feb 2018 14:09:15 +0100 Subject: RFR: JDK-8197571 Change storage location for generated-configure.sh Message-ID: In JDK-8195689, the generated-configure.sh was no longer checked in, but locally generated. The selected location for generation ($TOPDIR/.build) was not unproblematic for some use cases. This patch attempts remedy this. The new behaviour will be this: ?* If run from $TOPDIR, the storage directory will be $TOPDIR/build/.configure-support. ?* If run from $CUSTOM_ROOT, the storage directory will be $CUSTOM_ROOT/build/.configure-support. ?* If run from any other directory (about to become the build output directory for the configuration), the storage directory will be $PWD/configure-support. This will allow "rm -rf $TOPDIR/build" to function as before to remove all build artifacts. It will allow configuration created in out-of-tree directories to have the script generated locally. I could not put the output file in build/$BUILD/configure-support, since the $BUILD name is not yet determined. I did not want to put it in build/configure-support, since that would make it look like a configuration to the code that enumerates configurations in build. I hope this addresses all issues that has been raised. Bug: https://bugs.openjdk.java.net/browse/JDK-8197571 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage-location-for-generated-configure/webrev.01 /Magnus From thomas.stuefe at gmail.com Mon Feb 12 13:47:03 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Feb 2018 14:47:03 +0100 Subject: RFR: JDK-8197571 Change storage location for generated-configure.sh In-Reply-To: References: Message-ID: Hi Magnus, Thanks a lot for fixing this! I tried my configuration as described in earlier mails, and the configure scripts gets now created in the output directory as expected. Some notes: - would it be possible to write out the path name of the generated configure shell script? - No concern of mine, because I never do this, but just something I noted when looking at the change: it seems before the patch it was possible to start the make from any subdirectory within the source tree and still have the build configuration written to source tree root. That would not work anymore, now builds inside the source tree have to be started from the root of the source tree? Kind Regards, Thomas On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > In JDK-8195689, the generated-configure.sh was no longer checked in, but > locally generated. The selected location for generation ($TOPDIR/.build) > was not unproblematic for some use cases. This patch attempts remedy this. > > The new behaviour will be this: > * If run from $TOPDIR, the storage directory will be > $TOPDIR/build/.configure-support. > * If run from $CUSTOM_ROOT, the storage directory will be > $CUSTOM_ROOT/build/.configure-support. > * If run from any other directory (about to become the build output > directory for the configuration), the storage directory will be > $PWD/configure-support. > > This will allow "rm -rf $TOPDIR/build" to function as before to remove all > build artifacts. It will allow configuration created in out-of-tree > directories to have the script generated locally. > > I could not put the output file in build/$BUILD/configure-support, since > the $BUILD name is not yet determined. I did not want to put it in > build/configure-support, since that would make it look like a configuration > to the code that enumerates configurations in build. > > I hope this addresses all issues that has been raised. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8197571 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage- > location-for-generated-configure/webrev.01 > > /Magnus > > From magnus.ihse.bursie at oracle.com Mon Feb 12 13:53:10 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Feb 2018 14:53:10 +0100 Subject: RFR: JDK-8197571 Change storage location for generated-configure.sh In-Reply-To: References: Message-ID: <4eaa660b-f0dd-032b-f23d-c79de9cbe01a@oracle.com> On 2018-02-12 14:47, Thomas St?fe wrote: > Hi Magnus, > > Thanks a lot for fixing this! I tried my configuration as described in > earlier mails, and the configure scripts gets now created in the > output directory as expected. > > Some notes: > > - would it be possible to write out the path name of the generated > configure shell script? Sure, but why? What's the use case? Do you want it only when it is generated/updated, or always when running configure? > - No concern of mine, because I never do this, but just something I > noted when looking at the change: it seems before the patch it was > possible to start the make from any subdirectory within the source > tree and still have the build configuration written to source tree > root. That would not work anymore, now builds inside the source tree > have to be started from the root of the source tree? We have never supported running configure in anything but an empty director or the source tree root. You will end up with something like: configure: Current directory is /localhome/hg/jdk-ALT/open/src. configure: Since this is not the source root, configure will output the configuration here configure: (as opposed to creating a configuration in /build/). configure: However, this directory is not empty. This is not allowed, since it could configure: seriously mess up just about everything. /Magnus > > Kind Regards, Thomas > > > On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie > > > wrote: > > In JDK-8195689, the generated-configure.sh was no longer checked > in, but locally generated. The selected location for generation > ($TOPDIR/.build) was not unproblematic for some use cases. This > patch attempts remedy this. > > The new behaviour will be this: > ?* If run from $TOPDIR, the storage directory will be > $TOPDIR/build/.configure-support. > ?* If run from $CUSTOM_ROOT, the storage directory will be > $CUSTOM_ROOT/build/.configure-support. > ?* If run from any other directory (about to become the build > output directory for the configuration), the storage directory > will be $PWD/configure-support. > > This will allow "rm -rf $TOPDIR/build" to function as before to > remove all build artifacts. It will allow configuration created in > out-of-tree directories to have the script generated locally. > > I could not put the output file in build/$BUILD/configure-support, > since the $BUILD name is not yet determined. I did not want to put > it in build/configure-support, since that would make it look like > a configuration to the code that enumerates configurations in build. > > I hope this addresses all issues that has been raised. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8197571 > > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage-location-for-generated-configure/webrev.01 > > > /Magnus > > From thomas.stuefe at gmail.com Mon Feb 12 13:57:30 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Feb 2018 14:57:30 +0100 Subject: RFR: JDK-8197571 Change storage location for generated-configure.sh In-Reply-To: <4eaa660b-f0dd-032b-f23d-c79de9cbe01a@oracle.com> References: <4eaa660b-f0dd-032b-f23d-c79de9cbe01a@oracle.com> Message-ID: On Mon, Feb 12, 2018 at 2:53 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2018-02-12 14:47, Thomas St?fe wrote: > > Hi Magnus, > > Thanks a lot for fixing this! I tried my configuration as described in > earlier mails, and the configure scripts gets now created in the output > directory as expected. > > Some notes: > > - would it be possible to write out the path name of the generated > configure shell script? > > Sure, but why? What's the use case? Do you want it only when it is > generated/updated, or always when running configure? > > The former. Just as an information. > - No concern of mine, because I never do this, but just something I noted > when looking at the change: it seems before the patch it was possible to > start the make from any subdirectory within the source tree and still have > the build configuration written to source tree root. That would not work > anymore, now builds inside the source tree have to be started from the root > of the source tree? > > > We have never supported running configure in anything but an empty > director or the source tree root. You will end up with something like: > > configure: Current directory is /localhome/hg/jdk-ALT/open/src. > configure: Since this is not the source root, configure will output the > configuration here > configure: (as opposed to creating a configuration in > /build/). > configure: However, this directory is not empty. This is not allowed, > since it could > configure: seriously mess up just about everything. > > Okay. Change is reviewed from my end. Thanks, Thomas > /Magnus > > > > Kind Regards, Thomas > > > On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> In JDK-8195689, the generated-configure.sh was no longer checked in, but >> locally generated. The selected location for generation ($TOPDIR/.build) >> was not unproblematic for some use cases. This patch attempts remedy this. >> >> The new behaviour will be this: >> * If run from $TOPDIR, the storage directory will be >> $TOPDIR/build/.configure-support. >> * If run from $CUSTOM_ROOT, the storage directory will be >> $CUSTOM_ROOT/build/.configure-support. >> * If run from any other directory (about to become the build output >> directory for the configuration), the storage directory will be >> $PWD/configure-support. >> >> This will allow "rm -rf $TOPDIR/build" to function as before to remove >> all build artifacts. It will allow configuration created in out-of-tree >> directories to have the script generated locally. >> >> I could not put the output file in build/$BUILD/configure-support, since >> the $BUILD name is not yet determined. I did not want to put it in >> build/configure-support, since that would make it look like a configuration >> to the code that enumerates configurations in build. >> >> I hope this addresses all issues that has been raised. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8197571 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage- >> location-for-generated-configure/webrev.01 >> >> /Magnus >> >> > > From magnus.ihse.bursie at oracle.com Mon Feb 12 11:48:25 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Feb 2018 12:48:25 +0100 Subject: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time In-Reply-To: References: <5403cf9c-3db4-ade9-809e-d1fa536e2c23@oracle.com> Message-ID: On 2018-02-10 12:29, Thomas St?fe wrote: > On Sat, Feb 10, 2018 at 9:12 AM, Alan Bateman > wrote: > >> On 08/02/2018 17:49, Erik Joelsson wrote: >> >>> The check for when to generate the generated configure script is not >>> working quite as expected. It currently only compares timestamps if the >>> local repository has any local changes in the make/autoconf directory. This >>> used to make sense when we had a committed generated script, but now we >>> actually do need to regenerate any time an input file is newer than the >>> generated script. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196356 >>> >> In addition to `hg status` showing no changes, I think it will continue to >> confuse people to generate it into a hidden directory. Was there any >> consideration to generating into a regular directory? >> >> > I agree. Also, we still generate the configure.sh into the source tree even > if the output directory is somewhere else. I always keep my output > directories separate from the source tree. Sometimes my source directory is > even on a read-only share. I would prefer and also expect any temporary > files to be placed in the output directory resp. the current directory, not > in the source tree. Would that be possible? As discussed in another thread, the current behaviour is no good when running configure outside the source tree root. We should definitely fix that (I thought Volker were going to publish a RFR but that didn't happen; I'll pick up the ball and submit a RFR). With that in place, the behaviour will in principle be that the output is in the current directory. /Magnus > > Thanks and Kind Regards, Thomas > > >> -Alan >> From volker.simonis at gmail.com Mon Feb 12 14:31:52 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 12 Feb 2018 15:31:52 +0100 Subject: RFR: JDK-8197571 Change storage location for generated-configure.sh In-Reply-To: References: Message-ID: Hi Magnus, thanks for doing this change. It was actually on my TODO list but I somehow forgot about it :) The change looks good. Thumb up from me, Volker On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie wrote: > In JDK-8195689, the generated-configure.sh was no longer checked in, but > locally generated. The selected location for generation ($TOPDIR/.build) was > not unproblematic for some use cases. This patch attempts remedy this. > > The new behaviour will be this: > * If run from $TOPDIR, the storage directory will be > $TOPDIR/build/.configure-support. > * If run from $CUSTOM_ROOT, the storage directory will be > $CUSTOM_ROOT/build/.configure-support. > * If run from any other directory (about to become the build output > directory for the configuration), the storage directory will be > $PWD/configure-support. > > This will allow "rm -rf $TOPDIR/build" to function as before to remove all > build artifacts. It will allow configuration created in out-of-tree > directories to have the script generated locally. > > I could not put the output file in build/$BUILD/configure-support, since the > $BUILD name is not yet determined. I did not want to put it in > build/configure-support, since that would make it look like a configuration > to the code that enumerates configurations in build. > > I hope this addresses all issues that has been raised. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8197571 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage-location-for-generated-configure/webrev.01 > > /Magnus > From thomas.stuefe at gmail.com Mon Feb 12 14:32:41 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Feb 2018 15:32:41 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: Hi all, may I have a sponsor please? I am not sure whether I am allowed to push myself, and if yes, to which repository. I have three reviewers already. Thank you! Thomas On Thu, Feb 8, 2018 at 3:42 PM, Thomas St?fe wrote: > Hi, > > may I please have reviews for this tiny fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ > 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ > > Thanks and Kind Regards, Thomas > From thomas.stuefe at gmail.com Mon Feb 12 14:33:39 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Feb 2018 15:33:39 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: Please disregard my last mail, the change has just been pushed. Thanks, Thomas On Mon, Feb 12, 2018 at 3:32 PM, Thomas St?fe wrote: > Hi all, > > may I have a sponsor please? I am not sure whether I am allowed to push > myself, and if yes, to which repository. > > I have three reviewers already. > > Thank you! > > Thomas > > > On Thu, Feb 8, 2018 at 3:42 PM, Thomas St?fe > wrote: > >> Hi, >> >> may I please have reviews for this tiny fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 >> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488- >> aix-toc-overflow-in-fastdebug/webrev.00/webrev/ >> >> Thanks and Kind Regards, Thomas >> > > From tim.bell at oracle.com Mon Feb 12 15:08:39 2018 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 12 Feb 2018 07:08:39 -0800 Subject: RFR: JDK-8197571 Change storage location for generated-configure.sh In-Reply-To: References: Message-ID: <5A81ADF7.4050501@oracle.com> Magnus: Looks good to me as well. /Tim On 02/12/18 06:31, Volker Simonis wrote: > Hi Magnus, > > thanks for doing this change. It was actually on my TODO list but I > somehow forgot about it :) > > The change looks good. Thumb up from me, > Volker > > On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie > wrote: >> In JDK-8195689, the generated-configure.sh was no longer checked in, but >> locally generated. The selected location for generation ($TOPDIR/.build) was >> not unproblematic for some use cases. This patch attempts remedy this. >> >> The new behaviour will be this: >> * If run from $TOPDIR, the storage directory will be >> $TOPDIR/build/.configure-support. >> * If run from $CUSTOM_ROOT, the storage directory will be >> $CUSTOM_ROOT/build/.configure-support. >> * If run from any other directory (about to become the build output >> directory for the configuration), the storage directory will be >> $PWD/configure-support. >> >> This will allow "rm -rf $TOPDIR/build" to function as before to remove all >> build artifacts. It will allow configuration created in out-of-tree >> directories to have the script generated locally. >> >> I could not put the output file in build/$BUILD/configure-support, since the >> $BUILD name is not yet determined. I did not want to put it in >> build/configure-support, since that would make it look like a configuration >> to the code that enumerates configurations in build. >> >> I hope this addresses all issues that has been raised. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8197571 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage-location-for-generated-configure/webrev.01 >> >> /Magnus >> From magnus.ihse.bursie at oracle.com Mon Feb 12 15:41:37 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Feb 2018 16:41:37 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: On 2018-02-12 15:32, Thomas St?fe wrote: > Hi all, > > may I have a sponsor please? I am not sure whether I am allowed to push > myself, and if yes, to which repository. Since the removal of generated-configure.sh you don't need a sponsor just because you touch autoconf files. So for jdk/jdk, you're free to just push it. As far as I understand, you're also free to just push it to jdk/hs nowadays, if that were you want it to go, but someone from hotspot should probably confirm this. /Magnus > > I have three reviewers already. > > Thank you! > > Thomas > > > On Thu, Feb 8, 2018 at 3:42 PM, Thomas St?fe > wrote: > >> Hi, >> >> may I please have reviews for this tiny fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 >> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ >> 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ >> >> Thanks and Kind Regards, Thomas >> From magnus.ihse.bursie at oracle.com Mon Feb 12 15:38:35 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Feb 2018 16:38:35 +0100 Subject: RFR: JDK-8197571 Change storage location for generated-configure.sh In-Reply-To: References: <4eaa660b-f0dd-032b-f23d-c79de9cbe01a@oracle.com> Message-ID: On 2018-02-12 14:57, Thomas St?fe wrote: > > > On Mon, Feb 12, 2018 at 2:53 PM, Magnus Ihse Bursie > > > wrote: > > On 2018-02-12 14:47, Thomas St?fe wrote: >> Hi Magnus, >> >> Thanks a lot for fixing this! I tried my configuration as >> described in earlier mails, and the configure scripts gets now >> created in the output directory as expected. >> >> Some notes: >> >> - would it be possible to write out the path name of the >> generated configure shell script? > Sure, but why? What's the use case? Do you want it only when it is > generated/updated, or always when running configure? > > > The former. Just as an information. Ok, I updated the printout to look like this: Runnable configure script is not present Generating runnable configure script at /localhome/hg/jdk-ALT/open/build/.configure-support/generated-configure.sh Using autoconf at /usr/local/bin/autoconf [autoconf (GNU Autoconf) 2.69] ... I didn't think this warranted a re-review. /Magnus >> - No concern of mine, because I never do this, but just something >> I noted when looking at the change: it seems before the patch it >> was possible to start the make from any subdirectory within the >> source tree and still have the build configuration written to >> source tree root. That would not work anymore, now builds inside >> the source tree have to be started from the root of the source tree? > > We have never supported running configure in anything but an empty > director or the source tree root. You will end up with something like: > > configure: Current directory is /localhome/hg/jdk-ALT/open/src. > configure: Since this is not the source root, configure will > output the configuration here > configure: (as opposed to creating a configuration in > /build/). > configure: However, this directory is not empty. This is not > allowed, since it could > configure: seriously mess up just about everything. > > > Okay. Change is reviewed from my end. > > Thanks, Thomas > > /Magnus > > >> >> Kind Regards, Thomas >> >> >> On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie >> > > wrote: >> >> In JDK-8195689, the generated-configure.sh was no longer >> checked in, but locally generated. The selected location for >> generation ($TOPDIR/.build) was not unproblematic for some >> use cases. This patch attempts remedy this. >> >> The new behaviour will be this: >> ?* If run from $TOPDIR, the storage directory will be >> $TOPDIR/build/.configure-support. >> ?* If run from $CUSTOM_ROOT, the storage directory will be >> $CUSTOM_ROOT/build/.configure-support. >> ?* If run from any other directory (about to become the build >> output directory for the configuration), the storage >> directory will be $PWD/configure-support. >> >> This will allow "rm -rf $TOPDIR/build" to function as before >> to remove all build artifacts. It will allow configuration >> created in out-of-tree directories to have the script >> generated locally. >> >> I could not put the output file in >> build/$BUILD/configure-support, since the $BUILD name is not >> yet determined. I did not want to put it in >> build/configure-support, since that would make it look like a >> configuration to the code that enumerates configurations in >> build. >> >> I hope this addresses all issues that has been raised. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8197571 >> >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage-location-for-generated-configure/webrev.01 >> >> >> /Magnus >> >> > > From thomas.stuefe at gmail.com Mon Feb 12 15:51:50 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Feb 2018 16:51:50 +0100 Subject: RFR: JDK-8197571 Change storage location for generated-configure.sh In-Reply-To: References: <4eaa660b-f0dd-032b-f23d-c79de9cbe01a@oracle.com> Message-ID: On Mon, Feb 12, 2018 at 4:38 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > > On 2018-02-12 14:57, Thomas St?fe wrote: > > > > On Mon, Feb 12, 2018 at 2:53 PM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> On 2018-02-12 14:47, Thomas St?fe wrote: >> >> Hi Magnus, >> >> Thanks a lot for fixing this! I tried my configuration as described in >> earlier mails, and the configure scripts gets now created in the output >> directory as expected. >> >> Some notes: >> >> - would it be possible to write out the path name of the generated >> configure shell script? >> >> Sure, but why? What's the use case? Do you want it only when it is >> generated/updated, or always when running configure? >> >> > The former. Just as an information. > > Ok, I updated the printout to look like this: > Runnable configure script is not present > Generating runnable configure script at /localhome/hg/jdk-ALT/open/ > build/.configure-support/generated-configure.sh > Using autoconf at /usr/local/bin/autoconf [autoconf (GNU Autoconf) 2.69] > ... > > I didn't think this warranted a re-review. > > Sure. Thank you. ..Thomas > /Magnus > > > >> - No concern of mine, because I never do this, but just something I noted >> when looking at the change: it seems before the patch it was possible to >> start the make from any subdirectory within the source tree and still have >> the build configuration written to source tree root. That would not work >> anymore, now builds inside the source tree have to be started from the root >> of the source tree? >> >> >> We have never supported running configure in anything but an empty >> director or the source tree root. You will end up with something like: >> >> configure: Current directory is /localhome/hg/jdk-ALT/open/src. >> configure: Since this is not the source root, configure will output the >> configuration here >> configure: (as opposed to creating a configuration in >> /build/). >> configure: However, this directory is not empty. This is not allowed, >> since it could >> configure: seriously mess up just about everything. >> >> > Okay. Change is reviewed from my end. > > Thanks, Thomas > > >> /Magnus >> >> >> >> Kind Regards, Thomas >> >> >> On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie < >> magnus.ihse.bursie at oracle.com> wrote: >> >>> In JDK-8195689, the generated-configure.sh was no longer checked in, but >>> locally generated. The selected location for generation ($TOPDIR/.build) >>> was not unproblematic for some use cases. This patch attempts remedy this. >>> >>> The new behaviour will be this: >>> * If run from $TOPDIR, the storage directory will be >>> $TOPDIR/build/.configure-support. >>> * If run from $CUSTOM_ROOT, the storage directory will be >>> $CUSTOM_ROOT/build/.configure-support. >>> * If run from any other directory (about to become the build output >>> directory for the configuration), the storage directory will be >>> $PWD/configure-support. >>> >>> This will allow "rm -rf $TOPDIR/build" to function as before to remove >>> all build artifacts. It will allow configuration created in out-of-tree >>> directories to have the script generated locally. >>> >>> I could not put the output file in build/$BUILD/configure-support, >>> since the $BUILD name is not yet determined. I did not want to put it in >>> build/configure-support, since that would make it look like a configuration >>> to the code that enumerates configurations in build. >>> >>> I hope this addresses all issues that has been raised. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8197571 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage- >>> location-for-generated-configure/webrev.01 >>> >>> /Magnus >>> >>> >> >> > > From thomas.stuefe at gmail.com Mon Feb 12 15:52:34 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Feb 2018 16:52:34 +0100 Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build In-Reply-To: References: Message-ID: On Mon, Feb 12, 2018 at 4:41 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2018-02-12 15:32, Thomas St?fe wrote: > >> Hi all, >> >> may I have a sponsor please? I am not sure whether I am allowed to push >> myself, and if yes, to which repository. >> > > Since the removal of generated-configure.sh you don't need a sponsor just > because you touch autoconf files. So for jdk/jdk, you're free to just push > it. As far as I understand, you're also free to just push it to jdk/hs > nowadays, if that were you want it to go, but someone from hotspot should > probably confirm this. > > Ok. Nice to know. Thanks. ..Thomas > /Magnus > > > >> I have three reviewers already. >> >> Thank you! >> >> Thomas >> >> >> On Thu, Feb 8, 2018 at 3:42 PM, Thomas St?fe >> wrote: >> >> Hi, >>> >>> may I please have reviews for this tiny fix: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 >>> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ >>> 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ >>> >>> Thanks and Kind Regards, Thomas >>> >>> > From maobaolong at 139.com Mon Feb 12 06:51:53 2018 From: maobaolong at 139.com (mbl) Date: Mon, 12 Feb 2018 14:51:53 +0800 Subject: macOS High Sierra, version 10.13.2 configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype' Message-ID: OS: macOS High Sierra, version 10.13.2 Repo : https://github.com/dmlloyd/openjdk.git Branch : jdk/jdk mbldeMacBook-Pro:openjdk mbl$ bash ./configure --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk9.0.4.jdk/Home configure: Configuration created at Mon Feb 12 14:43:36 CST 2018. configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype'. /projects/jdpros/openjdk/.build/generated-configure.sh: line 82: 5: Bad file descriptor configure exiting with result code 1 mbldeMacBook-Pro:openjdk mbl$ sudo brew install freetype Password: Error: Running Homebrew as root is extremely dangerous and no longer supported. As Homebrew does not drop privileges on installation you would be giving all build scripts full access to your system. mbldeMacBook-Pro:openjdk mbl$ brew install freetype Updating Homebrew... Warning: freetype 2.9 is already installed What can I do? From erik.joelsson at oracle.com Mon Feb 12 18:47:05 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 Feb 2018 10:47:05 -0800 Subject: macOS High Sierra, version 10.13.2 configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype' In-Reply-To: References: Message-ID: <22b9f556-464f-db03-52b2-beb002f2a67b@oracle.com> Hello, I just tried this myself and configure is automatically picking up my freetype from brew in /usr/local/opt/freetype/. Looking at my log, this is done using pkg-config from brew. So you could try installing pkg-config (brew install pkg-config). You can also try adding --with-freetype=/usr/local/opt/freetype if that's where brew installed it for you. /Erik On 2018-02-11 22:51, mbl wrote: > OS: macOS High Sierra, version 10.13.2 > Repo : https://github.com/dmlloyd/openjdk.git > Branch : jdk/jdk > > mbldeMacBook-Pro:openjdk mbl$ bash ./configure --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk9.0.4.jdk/Home > configure: Configuration created at Mon Feb 12 14:43:36 CST 2018. > configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype'. > /projects/jdpros/openjdk/.build/generated-configure.sh: line 82: 5: Bad file descriptor > configure exiting with result code 1 > mbldeMacBook-Pro:openjdk mbl$ sudo brew install freetype > Password: > Error: Running Homebrew as root is extremely dangerous and no longer supported. > As Homebrew does not drop privileges on installation you would be giving all > build scripts full access to your system. > mbldeMacBook-Pro:openjdk mbl$ brew install freetype > Updating Homebrew... > Warning: freetype 2.9 is already installed > > > What can I do? From maobaolong at 139.com Tue Feb 13 09:41:08 2018 From: maobaolong at 139.com (mbl) Date: Tue, 13 Feb 2018 17:41:08 +0800 Subject: macOS High Sierra, version 10.13.2 configure: error: Could notfind freetype! You might be able to fix this by running 'brew installfreetype' In-Reply-To: <22b9f556-464f-db03-52b2-beb002f2a67b@oracle.com> References: <22b9f556-464f-db03-52b2-beb002f2a67b@oracle.com> Message-ID: <88249E80-DF5E-4C01-833D-920DBC44BBBA@139.com> Thank you for your kind help, I?ve jump out of the last pit. Now the new challenge is: I execute the following command: bash ../8dev/configure --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home --with-freetype=/usr/local/Cellar/freetype/2.9/ --enable-ccache --with-jvm-variants=server --with-boot-jdk-jvmargs="-Xlint:deprecation -Xlint:unchecked" --disable-zip-debug-info MAKE=/Applications/Xcode9.app/Contents/Developer/usr/bin/make But I see the following error dyld: Library not loaded: @rpath/DVTFoundation.framework/Versions/A/DVTFoundation Referenced from: /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild Reason: no suitable image found. Did find: /Applications/Xcode.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation: cannot load '/Applications/Xcode.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation' because Objective-C garbage collection is not supported xcrun: error: unable to locate xcodebuild, please make sure the path to the Xcode folder is set correctly! xcrun: error: You can set the path to the Xcode folder using /usr/bin/xcode-select -switch configure: error: Xcode 4 is required to build JDK 8, the version found was . Use --with-xcode-path to specify the location of Xcode 4 or make Xcode 4 active by using xcode-select. configure exiting with result code 1 Please help me more. Thank your advance! My Env is: OS: macOS High Sierra, version 10.13. Repo : http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ Tags: jdk8u162-b12 Other info: The configure error pick me to mv my default xcode (9.0.4) to a backup as `/Applications/Xcode9.app`. I install Xcode4.6.3 to `Applications/Xcode.app`, and execute `sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer` to active it. > On 13 Feb 2018, at 02:47, Erik Joelsson wrote: > > Hello, > > I just tried this myself and configure is automatically picking up my freetype from brew in /usr/local/opt/freetype/. Looking at my log, this is done using pkg-config from brew. So you could try installing pkg-config (brew install pkg-config). You can also try adding --with-freetype=/usr/local/opt/freetype if that's where brew installed it for you. > > /Erik > > > On 2018-02-11 22:51, mbl wrote: >> OS: macOS High Sierra, version 10.13.2 >> Repo : https://github.com/dmlloyd/openjdk.git >> Branch : jdk/jdk >> >> mbldeMacBook-Pro:openjdk mbl$ bash ./configure --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk9.0.4.jdk/Home >> configure: Configuration created at Mon Feb 12 14:43:36 CST 2018. >> configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype'. >> /projects/jdpros/openjdk/.build/generated-configure.sh: line 82: 5: Bad file descriptor >> configure exiting with result code 1 >> mbldeMacBook-Pro:openjdk mbl$ sudo brew install freetype >> Password: >> Error: Running Homebrew as root is extremely dangerous and no longer supported. >> As Homebrew does not drop privileges on installation you would be giving all >> build scripts full access to your system. >> mbldeMacBook-Pro:openjdk mbl$ brew install freetype >> Updating Homebrew... >> Warning: freetype 2.9 is already installed >> >> >> What can I do? > From adam.farley at uk.ibm.com Tue Feb 13 12:12:16 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 13 Feb 2018 12:12:16 +0000 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> Message-ID: -- Summary -- I ask for a committer to go into jdk/jdk and add one word to make/lib/Awt2dLibraries.gmk We need to go to line 495 and add array-bounds into the list of disabled warnings. So this: DISABLED_WARNINGS_gcc := clobbered implicit-fallthrough shift-negative-value, \ becomes this: DISABLED_WARNINGS_gcc := clobbered implicit-fallthrough shift-negative-value array-bounds, \ This fixes a build-breaking problem which occurs if you don't disable errors-as-warnings on zLinux or Linux for ppcle. P.S. Backporting this to jdk8 would be awesome, but the priority is jdk/jdk. -- Conversation -- > Am I understanding this correctly that it's really not tied to a gcc version > but a cpu architecture, so it's only really affecting s390x? I'm saying it is tied to a combination of CPU architecture and gcc version. Any combination of the affected gcc versions (4.8.5, 5.4.0) and affected platforms (zLinux, ppcle Linux) see this error. x86 Linux is not affected, not are gcc versions equal to (or, I assume, later than) 7.2.1. > Are you also saying that gcc 7.2.1 is also affected but with a different > message? I'm fine with disabling this warning conditional on s390x, no need > for specific gcc versions. I was unclear. 7.2.1 fails my unit test with a different warning, but a build I ran proves that this warning doesn't fail the build. That being said, the addition of this option to a 7.2.1 test didn't seem to break anything, so we should be fine to just stick "DISABLED_WARNINGS_gcc := clobbered array-bounds" into Awt2dLibraries.gmk. > This discussion has already taken more time than it really warrants. :) Agreed. :) > Regarding warning chasing. I agree that we it's not feasible to chase down every > warning in every version of GCC, or any other toolchain, but I also think that > for platforms/configurations where people are actively developing changes for > OpenJDK, it makes sense to try to keep it clean. This helps prevent new code from > introducing warnings. For the configurations Oracle use, we keep a strict -Werror > policy because we want the code to be clean. I'm fine with other users trying to > keep the same standards on their configurations, but knowing that it will be their > responsibility to keep up to date. I also think we need to be reasonably fine grained > in when we disable warnings. Specifying every affected version of a toolchain is too > much, but if there are specific well defined limits to where the disabling relevant, > then I think we should use them, within reason. This also helps with keeping track > of why a particular warning is disabled in a future attempt to fix them. I agree with all of this. Well put. :) > On the other hand, if you are just building OpenJDK to produce binaries, without > producing and up streaming new code changes, there really isn't much need for > making the effort of trying to keep things clean, and trying to do so will likely > just end up being more work than it's worth. > /Erik I'm building OpenJDK to test fixes and new features, which I will eventually contribute to OpenJDK. I consider this to be one of those fixes. One fix at a time. :) Given all of this, I ask for a volunteer to raise a bug so we can integrate this change into JDK8 (as it's still very popular), and JDK. 10 would be great too, though I understand it's locked against all but the worst bugs. 9 is optional, as it's soon to be replaced by 10. Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From david.holmes at oracle.com Tue Feb 13 13:05:35 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Feb 2018 23:05:35 +1000 Subject: RFR 8190378: Java EE and CORBA modules removal In-Reply-To: <360C5181-3B9E-4339-B460-04A8385F2461@oracle.com> References: <360C5181-3B9E-4339-B460-04A8385F2461@oracle.com> Message-ID: <6ae59d8a-578c-fe1e-b92c-deab72a109af@oracle.com> Lance, In Docs.gmk you seem to have missed this: 445 ################################################################################ 446 # Setup generation of the Java SE API documentation (javadoc + modulegraph) 447 448 # The Java SE module scope is just java.se.ee and its transitive indirect 449 # exports. 450 JAVASE_MODULES := java.se.ee 451 452 $(eval $(call SetupApiDocsGeneration, JAVASE_API, \ 453 MODULES := $(JAVASE_MODULES), \ 454 SHORT_NAME := $(JAVASE_SHORT_NAME), \ 455 LONG_NAME := $(JAVASE_LONG_NAME), \ 456 TARGET_DIR := $(IMAGES_OUTPUTDIR)/javase-docs/api, \ 457 )) which now results in a doc build hanging due to the non-existent java.se.ee module. It leads to execution of: grep -e @moduleGraph with no module-info.java argument, which causes grep to hang trying to read from stdin. At least that is what my analysis indicates. I simply set: JAVASE_MODULES := to work around it. David ----- On 8/02/2018 11:37 PM, Lance Andersen wrote: > >> On Feb 8, 2018, at 3:04 AM, Alan Bateman wrote: >> >> On 07/02/2018 16:57, Lance Andersen wrote: >>> Hi all, >>> >>> I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. >>> The CSR for removing the modules has been approved: https://bugs.openjdk.java.net/browse/JDK-8193757 >>> >>> The open webrev can be found at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/ >>> >> 800 KLOC deleted, wonderful! >> >> The update to technology-summary.html page means its html title no longer matches the contents. We should probably change it to "JCP Technologies in JDK 11" for now. > > I updated the webrev. Thanks for catching that (btw we missed this for JDK 10) >> >> The removal of test cases from the tests in tools/launcher/modules removes most of the test coverage for the upgrade module path. We'll need to replace these sub-tests. Can you create an issue to track that? > > I can do that >> >> Everything else looks good and it's okay to track residual issues with other JIRA issues. I think the important thing is to get this monster patch into JDK builds soon so that libraries and the eco system can start to adjust. > > Thank you Alan for the review > > Best > Lance >> >> -Alan > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From erik.joelsson at oracle.com Tue Feb 13 16:55:56 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 13 Feb 2018 08:55:56 -0800 Subject: macOS High Sierra, version 10.13.2 configure: error: Could notfind freetype! You might be able to fix this by running 'brew installfreetype' In-Reply-To: <88249E80-DF5E-4C01-833D-920DBC44BBBA@139.com> References: <22b9f556-464f-db03-52b2-beb002f2a67b@oracle.com> <88249E80-DF5E-4C01-833D-920DBC44BBBA@139.com> Message-ID: <42d80600-4322-a637-397f-ba8241069f64@oracle.com> Hello, My guess would be that Xcode 4 isn't working on Macos 10.13. Internally we build JDK 8 on 10.8. /Erik On 2018-02-13 01:41, mbl wrote: > Thank you for your kind help, I?ve jump out of the last pit. > > Now the new challenge is: > > I execute the following command: > > ?bash ../8dev/configure > ?--with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home > --with-freetype=/usr/local/Cellar/freetype/2.9/ --enable-ccache > --with-jvm-variants=server --with-boot-jdk-jvmargs="-Xlint:deprecation > -Xlint:unchecked" --disable-zip-debug-info > MAKE=/Applications/Xcode9.app/Contents/Developer/usr/bin/make > > But I see the following error > > dyld: Library not loaded: > @rpath/DVTFoundation.framework/Versions/A/DVTFoundation > ? Referenced from: > /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild > ? Reason: no suitable image found. ?Did find: > /Applications/Xcode.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation: > cannot load > '/Applications/Xcode.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation' > because Objective-C garbage collection is not supported > xcrun: error: unable to locate xcodebuild, please make sure the path > to the Xcode folder is set correctly! > xcrun: error: You can set the path to the Xcode folder using > /usr/bin/xcode-select -switch > configure: error: Xcode 4 is required to build JDK 8, the version > found was . Use --with-xcode-path to specify the location of Xcode 4 > or make Xcode 4 active by using xcode-select. > configure exiting with result code 1 > > > Please help me more. Thank your advance! > > > My Env is: > > * OS: macOS High Sierra, version 10.13. > * Repo : http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ > * Tags: jdk8u162-b12 > > > > Other info: > > * The configure error pick me to mv my default xcode (9.0.4) to a > backup as `/Applications/Xcode9.app`. I install Xcode4.6.3 to > `Applications/Xcode.app`, and execute `sudo xcode-select -switch > /Applications/Xcode.app/Contents/Developer` to active it. > > > > >> On 13 Feb 2018, at 02:47, Erik Joelsson > > wrote: >> >> Hello, >> >> I just tried this myself and configure is automatically picking up my >> freetype from brew in /usr/local/opt/freetype/. Looking at my log, >> this is done using pkg-config from brew. So you could try installing >> pkg-config (brew install pkg-config). You can also try adding >> --with-freetype=/usr/local/opt/freetype if that's where brew >> installed it for you. >> >> /Erik >> >> >> On 2018-02-11 22:51, mbl wrote: >>> OS: macOS High Sierra, version 10.13.2 >>> Repo : https://github.com/dmlloyd/openjdk.git >>> Branch : jdk/jdk >>> >>> mbldeMacBook-Pro:openjdk mbl$ bash ./configure >>> --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk9.0.4.jdk/Home >>> configure: Configuration created at Mon Feb 12 14:43:36 CST 2018. >>> configure: error: Could not find freetype! You might be able to fix >>> this by running 'brew install freetype'. >>> /projects/jdpros/openjdk/.build/generated-configure.sh: line 82: 5: >>> Bad file descriptor >>> configure exiting with result code 1 >>> mbldeMacBook-Pro:openjdk mbl$ sudo brew install freetype >>> Password: >>> Error: Running Homebrew as root is extremely dangerous and no longer >>> supported. >>> As Homebrew does not drop privileges on installation you would be >>> giving all >>> build scripts full access to your system. >>> mbldeMacBook-Pro:openjdk mbl$ brew install freetype >>> Updating Homebrew... >>> Warning: freetype 2.9 is already installed >>> >>> >>> What can I do? >> > From lance.andersen at oracle.com Tue Feb 13 17:54:03 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 13 Feb 2018 12:54:03 -0500 Subject: RFR 8190378: Java EE and CORBA modules removal In-Reply-To: <6ae59d8a-578c-fe1e-b92c-deab72a109af@oracle.com> References: <360C5181-3B9E-4339-B460-04A8385F2461@oracle.com> <6ae59d8a-578c-fe1e-b92c-deab72a109af@oracle.com> Message-ID: <60DB93E9-3DBC-4850-B42D-8177C2D1551E@oracle.com> Hi David, I thought I did make that change. Let me go back and double check and if not, will push. My build worked fine but maybe I missed this in a merge. Best Lance > On Feb 13, 2018, at 8:05 AM, David Holmes wrote: > > Lance, > > In Docs.gmk you seem to have missed this: > > 445 ################################################################################ > 446 # Setup generation of the Java SE API documentation (javadoc + modulegraph) > 447 > 448 # The Java SE module scope is just java.se.ee and its transitive indirect > 449 # exports. > 450 JAVASE_MODULES := java.se.ee > 451 > 452 $(eval $(call SetupApiDocsGeneration, JAVASE_API, \ > 453 MODULES := $(JAVASE_MODULES), \ > 454 SHORT_NAME := $(JAVASE_SHORT_NAME), \ > 455 LONG_NAME := $(JAVASE_LONG_NAME), \ > 456 TARGET_DIR := $(IMAGES_OUTPUTDIR)/javase-docs/api, \ > 457 )) > > which now results in a doc build hanging due to the non-existent java.se.ee module. It leads to execution of: > > grep -e @moduleGraph > > with no module-info.java argument, which causes grep to hang trying to read from stdin. > > At least that is what my analysis indicates. I simply set: > > JAVASE_MODULES := > > to work around it. > > David > ----- > > On 8/02/2018 11:37 PM, Lance Andersen wrote: >>> On Feb 8, 2018, at 3:04 AM, Alan Bateman wrote: >>> >>> On 07/02/2018 16:57, Lance Andersen wrote: >>>> Hi all, >>>> >>>> I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. >>>> The CSR for removing the modules has been approved: https://bugs.openjdk.java.net/browse/JDK-8193757 >>>> >>>> The open webrev can be found at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/ >>>> >>> 800 KLOC deleted, wonderful! >>> >>> The update to technology-summary.html page means its html title no longer matches the contents. We should probably change it to "JCP Technologies in JDK 11" for now. >> I updated the webrev. Thanks for catching that (btw we missed this for JDK 10) >>> >>> The removal of test cases from the tests in tools/launcher/modules removes most of the test coverage for the upgrade module path. We'll need to replace these sub-tests. Can you create an issue to track that? >> I can do that >>> >>> Everything else looks good and it's okay to track residual issues with other JIRA issues. I think the important thing is to get this monster patch into JDK builds soon so that libraries and the eco system can start to adjust. >> Thank you Alan for the review >> Best >> Lance >>> >>> -Alan >> > >> > > >> >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Tue Feb 13 19:29:58 2018 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 13 Feb 2018 11:29:58 -0800 Subject: [11] RFR JDK-8197865: @moduleGraph taglet generates incorrect link to module graph Message-ID: <5f7d7e98-9801-d658-c8a6-b22a76d6fe19@oracle.com> Jon, Kumar, This is a regression from JDK-8195795 that generates but module-summary.html is under ${MODULE} directory. The correct link should be a href="module-graph.png">... Lance - I include make/Docs.gmk fix here since the docs hangs. Are you going to push a fix for it? If not, I can create a separate issue and fix it. diff --git a/make/Docs.gmk b/make/Docs.gmk --- a/make/Docs.gmk +++ b/make/Docs.gmk @@ -445,9 +445,9 @@ ################################################################################ # Setup generation of the Java SE API documentation (javadoc + modulegraph) -# The Java SE module scope is just java.se.ee and its transitive indirect +# The Java SE module scope is just java.se and its transitive indirect # exports. -JAVASE_MODULES := java.se.ee +JAVASE_MODULES := java.se $(eval $(call SetupApiDocsGeneration, JAVASE_API, \ MODULES := $(JAVASE_MODULES), \ diff --git a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java --- a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java +++ b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java @@ -64,7 +64,7 @@ } String moduleName = ((ModuleElement) element).getQualifiedName().toString(); - String imageFile = moduleName + "/module-graph.png"; + String imageFile = "module-graph.png"; int thumbnailHeight = -1; String hoverImage = ""; if (!moduleName.equals("java.base")) { From lance.andersen at oracle.com Tue Feb 13 19:36:49 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 13 Feb 2018 14:36:49 -0500 Subject: RFR: 8197866 Docs.mk still had a reference to java.se.ee Message-ID: <4C8ECB60-DDA1-475B-B2A0-1F8639C87E98@oracle.com> Hi, Please review this change to address the missed reference to java.se.ee ?????????? hg diff make/Docs.gmk diff -r 345f41527dcc make/Docs.gmk --- a/make/Docs.gmk Thu Feb 08 15:35:49 2018 +0100 +++ b/make/Docs.gmk Tue Feb 13 14:31:36 2018 -0500 @@ -445,9 +445,9 @@ ################################################################################ # Setup generation of the Java SE API documentation (javadoc + modulegraph) -# The Java SE module scope is just java.se.ee and its transitive indirect +# The Java SE module scope is just java.se and its transitive indirect # exports. -JAVASE_MODULES := java.se.ee +JAVASE_MODULES := java.se $(eval $(call SetupApiDocsGeneration, JAVASE_API, \ MODULES := $(JAVASE_MODULES), \ ?????????????? make and make docs runs clean ?????? $ make docs Building target 'docs' in configuration 'macosx-x64' Generating JDK_API javadoc for 69 modules Finished building target 'docs' in configuration 'macosx-x64' ljanders-mac:Test-jdk10-Feb09 ljanders$ ????????? Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Tue Feb 13 19:38:58 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 13 Feb 2018 14:38:58 -0500 Subject: [11] RFR JDK-8197865: @moduleGraph taglet generates incorrect link to module graph In-Reply-To: <5f7d7e98-9801-d658-c8a6-b22a76d6fe19@oracle.com> References: <5f7d7e98-9801-d658-c8a6-b22a76d6fe19@oracle.com> Message-ID: Hi Mandy I just submitted an RFR to build-dev so our emails crossed > On Feb 13, 2018, at 2:29 PM, mandy chung wrote: > > Jon, Kumar, > > This is a regression from JDK-8195795 that generates > but module-summary.html > is under ${MODULE} directory. The correct link should be > a href="module-graph.png">... > > Lance - I include make/Docs.gmk fix here since the docs hangs. > Are you going to push a fix for it? If not, I can create > a separate issue and fix it. > > diff --git a/make/Docs.gmk b/make/Docs.gmk > --- a/make/Docs.gmk > +++ b/make/Docs.gmk > @@ -445,9 +445,9 @@ > ################################################################################ > # Setup generation of the Java SE API documentation (javadoc + modulegraph) > > -# The Java SE module scope is just java.se.ee and its transitive indirect > +# The Java SE module scope is just java.se and its transitive indirect > # exports. > -JAVASE_MODULES := java.se.ee > +JAVASE_MODULES := java.se > > $(eval $(call SetupApiDocsGeneration, JAVASE_API, \ > MODULES := $(JAVASE_MODULES), \ > diff --git a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java > --- a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java > +++ b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java > @@ -64,7 +64,7 @@ > } > > String moduleName = ((ModuleElement) element).getQualifiedName().toString(); > - String imageFile = moduleName + "/module-graph.png"; > + String imageFile = "module-graph.png"; > int thumbnailHeight = -1; > String hoverImage = ""; > if (!moduleName.equals("java.base")) { Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From tim.bell at oracle.com Tue Feb 13 19:39:14 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 13 Feb 2018 11:39:14 -0800 Subject: RFR: 8197866 Docs.mk still had a reference to java.se.ee In-Reply-To: <4C8ECB60-DDA1-475B-B2A0-1F8639C87E98@oracle.com> References: <4C8ECB60-DDA1-475B-B2A0-1F8639C87E98@oracle.com> Message-ID: <5A833EE2.4010107@oracle.com> Lance: > Please review this change to address the missed reference to java.se.ee > > ?????????? > hg diff make/Docs.gmk > diff -r 345f41527dcc make/Docs.gmk > --- a/make/Docs.gmk Thu Feb 08 15:35:49 2018 +0100 > +++ b/make/Docs.gmk Tue Feb 13 14:31:36 2018 -0500 > @@ -445,9 +445,9 @@ > ################################################################################ > # Setup generation of the Java SE API documentation (javadoc + modulegraph) > > -# The Java SE module scope is just java.se.ee and its transitive indirect > +# The Java SE module scope is just java.se and its transitive indirect > # exports. > -JAVASE_MODULES := java.se.ee > +JAVASE_MODULES := java.se > > $(eval $(call SetupApiDocsGeneration, JAVASE_API, \ > MODULES := $(JAVASE_MODULES), \ > ?????????????? Looks good. /Tim From lance.andersen at oracle.com Tue Feb 13 19:43:22 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 13 Feb 2018 14:43:22 -0500 Subject: [11] RFR JDK-8197865: @moduleGraph taglet generates incorrect link to module graph In-Reply-To: References: <5f7d7e98-9801-d658-c8a6-b22a76d6fe19@oracle.com> Message-ID: <0B229C8D-BE4B-4522-A97E-E5CB0B585AB0@oracle.com> Change is pushed. Thank you Tim for the review your change looks good Mandy... Best Lance > On Feb 13, 2018, at 2:38 PM, Lance Andersen wrote: > > Hi Mandy > > I just submitted an RFR to build-dev so our emails crossed > >> On Feb 13, 2018, at 2:29 PM, mandy chung wrote: >> >> Jon, Kumar, >> >> This is a regression from JDK-8195795 that generates >> but module-summary.html >> is under ${MODULE} directory. The correct link should be >> a href="module-graph.png">... >> >> Lance - I include make/Docs.gmk fix here since the docs hangs. >> Are you going to push a fix for it? If not, I can create >> a separate issue and fix it. >> >> diff --git a/make/Docs.gmk b/make/Docs.gmk >> --- a/make/Docs.gmk >> +++ b/make/Docs.gmk >> @@ -445,9 +445,9 @@ >> ################################################################################ >> # Setup generation of the Java SE API documentation (javadoc + modulegraph) >> >> -# The Java SE module scope is just java.se.ee and its transitive indirect >> +# The Java SE module scope is just java.se and its transitive indirect >> # exports. >> -JAVASE_MODULES := java.se.ee >> +JAVASE_MODULES := java.se >> >> $(eval $(call SetupApiDocsGeneration, JAVASE_API, \ >> MODULES := $(JAVASE_MODULES), \ >> diff --git a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java >> --- a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java >> +++ b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java >> @@ -64,7 +64,7 @@ >> } >> >> String moduleName = ((ModuleElement) element).getQualifiedName().toString(); >> - String imageFile = moduleName + "/module-graph.png"; >> + String imageFile = "module-graph.png"; >> int thumbnailHeight = -1; >> String hoverImage = ""; >> if (!moduleName.equals("java.base")) { > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Tue Feb 13 19:47:46 2018 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 13 Feb 2018 11:47:46 -0800 Subject: [11] RFR JDK-8197865: @moduleGraph taglet generates incorrect link to module graph In-Reply-To: References: <5f7d7e98-9801-d658-c8a6-b22a76d6fe19@oracle.com> Message-ID: <5a309ca7-d8c4-b471-d0dd-e628d406e54c@oracle.com> Good. I see you pushed the fix to Docs.gmk. Kumar, Jon - can you please review this patch? diff --git a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java --- a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java +++ b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java @@ -64,7 +64,7 @@ } String moduleName = ((ModuleElement) element).getQualifiedName().toString(); - String imageFile = moduleName + "/module-graph.png"; + String imageFile = "module-graph.png"; int thumbnailHeight = -1; String hoverImage = ""; if (!moduleName.equals("java.base")) { Mandy From david.holmes at oracle.com Tue Feb 13 21:40:34 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Feb 2018 07:40:34 +1000 Subject: RFR: 8197866 Docs.mk still had a reference to java.se.ee In-Reply-To: <4C8ECB60-DDA1-475B-B2A0-1F8639C87E98@oracle.com> References: <4C8ECB60-DDA1-475B-B2A0-1F8639C87E98@oracle.com> Message-ID: <7bda6887-b75f-6205-aca8-44e536247e7c@oracle.com> Thanks Lance. That fixes my builds. David On 14/02/2018 5:36 AM, Lance Andersen wrote: > Hi, > > Please review this change to address the missed reference to java.se.ee > > ?????????? > hg diff make/Docs.gmk > diff -r 345f41527dcc make/Docs.gmk > --- a/make/Docs.gmk Thu Feb 08 15:35:49 2018 +0100 > +++ b/make/Docs.gmk Tue Feb 13 14:31:36 2018 -0500 > @@ -445,9 +445,9 @@ > ################################################################################ > # Setup generation of the Java SE API documentation (javadoc + modulegraph) > > -# The Java SE module scope is just java.se.ee and its transitive indirect > +# The Java SE module scope is just java.se and its transitive indirect > # exports. > -JAVASE_MODULES := java.se.ee > +JAVASE_MODULES := java.se > > $(eval $(call SetupApiDocsGeneration, JAVASE_API, \ > MODULES := $(JAVASE_MODULES), \ > ?????????????? > > make and make docs runs clean > > ?????? > $ make docs > Building target 'docs' in configuration 'macosx-x64' > Generating JDK_API javadoc for 69 modules > Finished building target 'docs' in configuration 'macosx-x64' > ljanders-mac:Test-jdk10-Feb09 ljanders$ > ????????? > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From jonathan.gibbons at oracle.com Tue Feb 13 23:32:18 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 13 Feb 2018 15:32:18 -0800 Subject: [11] RFR JDK-8197865: @moduleGraph taglet generates incorrect link to module graph In-Reply-To: <5a309ca7-d8c4-b471-d0dd-e628d406e54c@oracle.com> References: <5f7d7e98-9801-d658-c8a6-b22a76d6fe19@oracle.com> <5a309ca7-d8c4-b471-d0dd-e628d406e54c@oracle.com> Message-ID: <5A837582.6040608@oracle.com> +1 -- Jon On 02/13/2018 11:47 AM, mandy chung wrote: > Good. I see you pushed the fix to Docs.gmk. > > Kumar, Jon - can you please review this patch? > diff --git a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java > --- a/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java > +++ b/make/jdk/src/classes/build/tools/taglet/ModuleGraph.java > @@ -64,7 +64,7 @@ > } > > String moduleName = ((ModuleElement) element).getQualifiedName().toString(); > - String imageFile = moduleName + "/module-graph.png"; > + String imageFile = "module-graph.png"; > int thumbnailHeight = -1; > String hoverImage = ""; > if (!moduleName.equals("java.base")) { > > Mandy From erik.joelsson at oracle.com Wed Feb 14 00:50:56 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 13 Feb 2018 16:50:56 -0800 Subject: RFR: JDK-8153294: Solaris devkit uses linker from system instead of in devkit Message-ID: The current devkit I created for Solaris has a flaw in that CC will still call the system linker instead of the one in the devkit. I have finally figured out a solution for this, while working on the next devkit with upgraded compiler versions, but this fix has value on its own so I decided to update the existing one for 11 immediately. The devkit is changed to include the relevant executables as well as the specific libs they need, arranged in such a way so that the existing runpaths in the executables match the relative paths of the libs. In configure, I added a check for ld in the devkit and add the necessary flag to SYSROOT_LDFLAGS if found. Bug: https://bugs.openjdk.java.net/browse/JDK-8153294 Webrev: http://cr.openjdk.java.net/~erikj/8153294/webrev.01/ /Erik From tim.bell at oracle.com Wed Feb 14 02:00:24 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 13 Feb 2018 18:00:24 -0800 Subject: RFR: JDK-8153294: Solaris devkit uses linker from system instead of in devkit In-Reply-To: References: Message-ID: <5A839838.8080606@oracle.com> Erik: > The current devkit I created for Solaris has a flaw in that CC will > still call the system linker instead of the one in the devkit. I have > finally figured out a solution for this, while working on the next > devkit with upgraded compiler versions, but this fix has value on its > own so I decided to update the existing one for 11 immediately. > > The devkit is changed to include the relevant executables as well as the > specific libs they need, arranged in such a way so that the existing > runpaths in the executables match the relative paths of the libs. In > configure, I added a check for ld in the devkit and add the necessary > flag to SYSROOT_LDFLAGS if found. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153294 > > Webrev: http://cr.openjdk.java.net/~erikj/8153294/webrev.01/ Looks good. /Tim From david.holmes at oracle.com Wed Feb 14 04:39:54 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Feb 2018 14:39:54 +1000 Subject: RFR(S): 8197906: Enable CDS mode execution of jtreg tests via make In-Reply-To: <5A83B872.6070904@oracle.com> References: <5A83B872.6070904@oracle.com> Message-ID: <62875c74-bbde-7c83-f25b-8b2db7d73ca3@oracle.com> cc'ing build-dev as this is a shared makefile change Thanks, David On 14/02/2018 2:17 PM, Mikhailo Seledtsov wrote: > Please review this small change that enables execution of any jtreg > test(s) in CDS mode > via make. Please see bug description for details. > > Thanks to Erik and Igor for their help with this change. > > ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8197906 > ??? WebRev: http://cr.openjdk.java.net/~mseledtsov/8197906.01/ > > ??? Testing: > ????? - ran hotspot_runtime in CDS mode with this change - Linux-x64 - > no new failures > ????? - running several test sets in CDS mode via distributed test > system - pass > ????? - running pre-integration sanity testing (HS tier1, tier2) - in > progress > > Thank you, > Misha > From thomas.stuefe at gmail.com Wed Feb 14 11:24:26 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 14 Feb 2018 12:24:26 +0100 Subject: Choosing which Visual Studio installation to use Message-ID: Hi all, On Windows, if one has multiple VS installations side by side, is it possible to choose which Visual Studio installation to use? Note that I start the configure script from within the cygwin shell. Thanks, Thomas From glaubitz at physik.fu-berlin.de Wed Feb 14 11:29:36 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 14 Feb 2018 12:29:36 +0100 Subject: Choosing which Visual Studio installation to use In-Reply-To: References: Message-ID: <48c454a8-2ab8-4d7b-1a9d-a948cce6aae3@physik.fu-berlin.de> Hi Thomas! On 02/14/2018 12:24 PM, Thomas St?fe wrote: > On Windows, if one has multiple VS installations side by side, is it > possible to choose which Visual Studio installation to use? From my slightly rusted memory regarding Visual Studio, isn't the regular way to choose a certain VS toolchain calling a batch script which sets the environment variables for the toolchain to be used. That is, when you open a command prompt and type "cl.exe" which usually end up with a "Bad command or filename" error as none of the command line utilities are normally set in $PATH. So, I would guess that you would use that method for OpenJDK as well? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Wed Feb 14 11:42:50 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 14 Feb 2018 12:42:50 +0100 Subject: Choosing which Visual Studio installation to use In-Reply-To: <48c454a8-2ab8-4d7b-1a9d-a948cce6aae3@physik.fu-berlin.de> References: <48c454a8-2ab8-4d7b-1a9d-a948cce6aae3@physik.fu-berlin.de> Message-ID: Hi Adrian, On Wed, Feb 14, 2018 at 12:29 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Hi Thomas! > > On 02/14/2018 12:24 PM, Thomas St?fe wrote: > >> On Windows, if one has multiple VS installations side by side, is it >> possible to choose which Visual Studio installation to use? >> > > From my slightly rusted memory regarding Visual Studio, isn't the regular > way to choose a certain VS toolchain calling a batch script which sets > the environment variables for the toolchain to be used. > > That is, when you open a command prompt and type "cl.exe" which usually > end up with a "Bad command or filename" error as none of the command > line utilities are normally set in $PATH. > > Yes, that is normally the way - that or just starting the corresponding "visual studio command prompt" shell. That is why I was specifying that I am running from cygwin shell - the openjdk build somehow chooses that batch script for you, and it would be nice to be able to choose with a configure option. ..Thomas > So, I would guess that you would use that method for OpenJDK as well? > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From glaubitz at physik.fu-berlin.de Wed Feb 14 11:45:27 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 14 Feb 2018 12:45:27 +0100 Subject: Choosing which Visual Studio installation to use In-Reply-To: References: <48c454a8-2ab8-4d7b-1a9d-a948cce6aae3@physik.fu-berlin.de> Message-ID: <187e98dc-3370-fcfa-4458-0776425c0d5e@physik.fu-berlin.de> On 02/14/2018 12:42 PM, Thomas St?fe wrote: > Yes, that is normally the way - that or just starting the corresponding "visual studio command prompt" shell. That is why I was specifying that I am running from cygwin shell - the openjdk build somehow chooses that batch script for you, and it would be nice to be able to choose with a configure option. Does it have to be Cygwin though? On Windows I usually install the "git bash for Windows" package or whatever it's called and it gives me a nice bash command prompt with a working git and bash environment. You can then call the environment scripts from there. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Wed Feb 14 13:07:47 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 14 Feb 2018 14:07:47 +0100 Subject: Choosing which Visual Studio installation to use In-Reply-To: <187e98dc-3370-fcfa-4458-0776425c0d5e@physik.fu-berlin.de> References: <48c454a8-2ab8-4d7b-1a9d-a948cce6aae3@physik.fu-berlin.de> <187e98dc-3370-fcfa-4458-0776425c0d5e@physik.fu-berlin.de> Message-ID: On Wed, Feb 14, 2018 at 12:45 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > On 02/14/2018 12:42 PM, Thomas St?fe wrote: > >> Yes, that is normally the way - that or just starting the corresponding >> "visual studio command prompt" shell. That is why I was specifying that I >> am running from cygwin shell - the openjdk build somehow chooses that batch >> script for you, and it would be nice to be able to choose with a configure >> option. >> > > Does it have to be Cygwin though? > > Yes. I love cygwin. You can put it into fullscreen and pretend you have a very slow Linux machine :) But seriously, it is very stable and mature, would not like at all to change my environment. On Windows I usually install the "git bash for Windows" package or whatever > it's called and it gives me a nice bash command prompt with a working git > and bash environment. You can then call the environment scripts from there. > > Can you do a full openjdk build with that? ..Thomas > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From glaubitz at physik.fu-berlin.de Wed Feb 14 13:16:37 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 14 Feb 2018 14:16:37 +0100 Subject: Choosing which Visual Studio installation to use In-Reply-To: References: <48c454a8-2ab8-4d7b-1a9d-a948cce6aae3@physik.fu-berlin.de> <187e98dc-3370-fcfa-4458-0776425c0d5e@physik.fu-berlin.de> Message-ID: <64988785-63d7-346e-a3fd-65cf06f3e17b@physik.fu-berlin.de> On 02/14/2018 02:07 PM, Thomas St?fe wrote: > Does it have to be Cygwin though? > > > Yes. I love cygwin. You can put it into fullscreen and pretend you have a very slow Linux machine :) But seriously, it is very stable and mature, would not like at all to change my environment. Yes, but, if I remember correctly, the problem is that anything built with Cygwin always requires Cygwin to be present to be able to run. You always have to carry the runtime around if I remember correctly. > On Windows I usually install the "git bash for Windows" package or whatever > it's called and it gives me a nice bash command prompt with a working git > and bash environment. You can then call the environment scripts from there. > > > Can you do a full openjdk build with that? I haven't tried OpenJDK. But in my previous company we did heavy Qt development with git bash for Windows and any additional external libraries that were required could usually be installed manually. It required some elbow grease, but at least the resulting binaries were regular Win32 applications which didn't require any particular runtime environment to be present except for the DLLs the binaries were linked against. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Wed Feb 14 13:23:02 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 14 Feb 2018 14:23:02 +0100 Subject: Choosing which Visual Studio installation to use In-Reply-To: <64988785-63d7-346e-a3fd-65cf06f3e17b@physik.fu-berlin.de> References: <48c454a8-2ab8-4d7b-1a9d-a948cce6aae3@physik.fu-berlin.de> <187e98dc-3370-fcfa-4458-0776425c0d5e@physik.fu-berlin.de> <64988785-63d7-346e-a3fd-65cf06f3e17b@physik.fu-berlin.de> Message-ID: On Wed, Feb 14, 2018 at 2:16 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > On 02/14/2018 02:07 PM, Thomas St?fe wrote: > >> Does it have to be Cygwin though? >> >> >> Yes. I love cygwin. You can put it into fullscreen and pretend you have a >> very slow Linux machine :) But seriously, it is very stable and mature, >> would not like at all to change my environment. >> > > Yes, but, if I remember correctly, the problem is that anything built > with Cygwin always requires Cygwin to be present to be able to run. > > We do not build with cygwin. We just use the cygwin tool chain (bash, make etc) to run the make. Compiler tool chain is still Visual Studio (hence the original question). > You always have to carry the runtime around if I remember correctly. > > Maybe if you use cygwin gcc, but the standard openjdk build on Windows does not. There was someone on the mailing list attempting to build with gcc, if I remember correctly. If you are right, this would be an argument against such a build. > On Windows I usually install the "git bash for Windows" package or >> whatever >> it's called and it gives me a nice bash command prompt with a working >> git >> and bash environment. You can then call the environment scripts from >> there. >> >> >> Can you do a full openjdk build with that? >> > I haven't tried OpenJDK. But in my previous company we did heavy Qt > development > with git bash for Windows and any additional external libraries that were > required > could usually be installed manually. It required some elbow grease, but at > least > the resulting binaries were regular Win32 applications which didn't > require any > particular runtime environment to be present except for the DLLs the > binaries > were linked against. Neither do ours, see above. cygwin basically gives you apt-get for windows. A very well maintained repository of any tool you potentially need. In addition to the pure build tool, I use ksh, diff tools, vim, mercurial, git, ... from cygwin. That completeness together with the stability is very useful. (So, if any Redhat people read this, thank you for cygwin :-) ..Thomas > > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From GROEGES at uk.ibm.com Wed Feb 14 15:01:31 2018 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 14 Feb 2018 15:01:31 +0000 Subject: Proposal: make/Main.gmk Add extra extension/override points to the make file Message-ID: Hi Erik, Sorry these updates have take a while to make but here is there latest diff for my proposed changes to make/Main.gmk to allow extension/override points in that make file to enable someone to provide an alternate JVM. Please could you take another look at these and let me know if they are OK. If so, would you be able to get these proposed and committed. diff -r b2f2bdba0472 make/Main.gmk --- a/make/Main.gmk Fri Jan 26 11:27:53 2018 -0800 +++ b/make/Main.gmk Wed Feb 14 14:37:15 2018 +0000 @@ -56,6 +56,9 @@ # All modules for the current target platform. ALL_MODULES := $(call FindAllModules) +# If not already set, set the JVM variant target so that the JVM will be built. +JVM_VARIANT_TARGETS ?= hotspot-$(JVM_VARIANT_MAIN)-libs + ################################################################################ ################################################################################ # @@ -645,7 +648,7 @@ generate-exported-symbols: java.base-libs jdk.jdwp.agent-libs # Building one JVM variant is enough to start building the other libs - $(LIBS_TARGETS): hotspot-$(JVM_VARIANT_MAIN)-libs + $(LIBS_TARGETS): $(JVM_VARIANT_TARGETS) $(LAUNCHER_TARGETS): java.base-libs @@ -722,8 +725,11 @@ java.base-jmod: jrtfs-jar $(filter-out java.base-jmod, $(JMOD_TARGETS)) endif - # Building java.base-jmod requires all of hotspot to be built. - java.base-jmod: hotspot + # If not already set, set the JVM target so that the JVM will be built. + JVM_MAIN_TARGETS ?= hotspot + + # Building java.base-jmod requires all of VM (ie hotspot) to be built. + java.base-jmod: $(JVM_MAIN_TARGETS) # Declare dependencies from -jmod to all other module targets # When creating a BUILDJDK, the java compilation has already been done by the @@ -749,7 +755,7 @@ # in java.base-copy) and tzdb.dat (done in java.base-gendata) to the # appropriate location otherwise jimage, jlink and jmod won't start. This # also applies when creating the buildjdk. - DEFAULT_JMOD_DEPS := java.base-libs java.base-copy java.base-gendata \ + DEFAULT_JMOD_DEPS += java.base-libs java.base-copy java.base-gendata \ jdk.jlink-launchers # When cross compiling and buildjdk is to be created, depend on creating the # buildjdk instead of the default dependencies. @@ -824,9 +830,11 @@ docs-javase-api-modulegraph: exploded-image buildtools-modules docs-reference-api-modulegraph: exploded-image buildtools-modules - + # If not already set, then set the JVM specific docs targets + JVM_DOCS_TARGETS ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc + # The gensrc steps for hotspot and jdk.jdi create html spec files. - docs-jdk-specs: hotspot-$(JVM_VARIANT_MAIN)-gensrc jdk.jdi-gensrc \ + docs-jdk-specs: $(JVM_DOCS_TARGETS) jdk.jdi-gensrc \ docs-jdk-index docs-jdk-index: exploded-image buildtools-modules @@ -893,8 +901,10 @@ ################################################################################ # Virtual targets without recipes +# If not already set, set the JVM specific tools targets +JVM_TOOLS_TARGETS ?= buildtools-hotspot buildtools: buildtools-langtools interim-langtools interim-rmic \ - buildtools-jdk buildtools-hotspot + buildtools-jdk $(JVM_TOOLS_TARGETS) hotspot: $(HOTSPOT_VARIANT_TARGETS) hotspot-jsig @@ -936,8 +946,11 @@ $(foreach m, $(LAUNCHER_MODULES), $(eval $m: $m-launchers)) $(foreach m, $(ALL_COPY_MODULES), $(eval $m: $m-copy)) +# If not already set, set the JVM specific build targets +JVM_BUILD_TARGETS ?= hotspot + # Building java.base includes building all of hotspot. -java.base: hotspot +java.base: $(JVM_BUILD_TARGETS) demos: demos-jdk @@ -1004,10 +1017,15 @@ # This target builds the documentation image docs-image: docs-jdk +# If not already set, set the JVM specific targets to built the test image +JVM_TEST_IMAGE_TARGETS ?= test-image-hotspot-jtreg-native test-image-hotspot-gtest + # This target builds the test image -test-image: prepare-test-image test-image-hotspot-jtreg-native \ - test-image-jdk-jtreg-native test-image-failure-handler test-image-hotspot-gtest \ - test-image-demos-jdk +test-image: prepare-test-image \ + test-image-jdk-jtreg-native test-image-failure-handler \ + test-image-demos-jdk $(JVM_TEST_IMAGE_TARGETS) + +################################################################################ # all-images builds all our deliverables as images. all-images: product-images test-image docs-image @@ -1146,7 +1164,10 @@ $(MAKESUPPORT_OUTPUTDIR)/main-targets.gmk ################################################################################ +# Hook to include the corresponding custom file, if present. +$(eval $(call IncludeCustomExtension, Main-post.gmk)) .PHONY: $(ALL_TARGETS) FRC: # Force target + Thanks Steve Groeger Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From mvala at redhat.com Wed Feb 14 15:20:23 2018 From: mvala at redhat.com (Michal Vala) Date: Wed, 14 Feb 2018 16:20:23 +0100 Subject: Choosing which Visual Studio installation to use In-Reply-To: References: Message-ID: <0aded0b8-ea01-d678-7aec-b5c6f4fc06e1@redhat.com> Hi, On 02/14/2018 12:24 PM, Thomas St?fe wrote: > Hi all, > > On Windows, if one has multiple VS installations side by side, is it > possible to choose which Visual Studio installation to use? > > Note that I start the configure script from within the cygwin shell. > OpenJDK configure is reading VS environment properties VS100COMNTOOLS/VS120COMNTOOLS/VS140COMNTOOLS etc. One option is to set just one of them. AFAIK configure takes latest supported VS (2013 for ojdk9). Another option is to use configure parameters, but I don't know how exactly use them. Try to look to configure help $ bash ./configure --help | grep toolchain --with-tools-dir alias for --with-toolchain-path for backwards --with-toolchain-path prepend these directories when searching for toolchain binaries (compilers etc) --with-toolchain-type the toolchain type (or family) to use, use '--help' --with-toolchain-version the version of the toolchain to look for, use --with-build-devkit Devkit to use for the build platform toolchain [toolchain dependent] The following toolchains are available as arguments to --with-toolchain-type. -- Michal Vala OpenJDK QE Red Hat Czech From mikhailo.seledtsov at oracle.com Wed Feb 14 15:26:22 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Wed, 14 Feb 2018 07:26:22 -0800 Subject: RFR(S): 8197906: Enable CDS mode execution of jtreg tests via make In-Reply-To: References: <5A83B872.6070904@oracle.com> Message-ID: <5A84551E.6020707@oracle.com> Hi Igor, Thank you for review. This is what I see from the test execution logs on Windows: // At archive creation time: > -XX:SharedArchiveFile=T:/testoutput/jtreg/cds_archive.jsa -Xshare:dump // At archive use time: > -vmoption:-XX:+UnlockDiagnosticVMOptions -vmoption:-XX:SharedArchiveFile=/cygdrive/t/testoutput/jtreg/cds_archive.jsa -javaoptions:-Xshare:auto -javaoptions:-Xlog:class+path=trace -javaoptions:-showversion I am not a Windows expert, and especially not a wiz in Cygwin. Do you know if these 2 paths are equivalent? [1] T:/testoutput/jtreg/cds_archive.jsa [2] /cygdrive/t/testoutput/jtreg/cds_archive.jsa If these are equivalent, then the code is OK as is. If not, I will change it and rerun the tests. Please let me know. Thank you, Misha On 2/13/18, 8:41 PM, Igor Ignatyev wrote: > Hi Misha, > > have you check that it works on windows w/ GENERATE_CDS_ARCHIVE=true? it seems that you should called GETMIXEDPATH in CDS_VM_ARGS: >> CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=$(CDS_ARCHIVE_FILE) > vs >> CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=$(shell $(GETMIXEDPATH) "$(CDS_ARCHIVE_FILE)") > otherwise, tests won't be able to find cds archive during test execution. > > -- Igor > >> On Feb 13, 2018, at 8:17 PM, Mikhailo Seledtsov wrote: >> >> Please review this small change that enables execution of any jtreg test(s) in CDS mode >> via make. Please see bug description for details. >> >> Thanks to Erik and Igor for their help with this change. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8197906 >> WebRev: http://cr.openjdk.java.net/~mseledtsov/8197906.01/ >> >> Testing: >> - ran hotspot_runtime in CDS mode with this change - Linux-x64 - no new failures >> - running several test sets in CDS mode via distributed test system - pass >> - running pre-integration sanity testing (HS tier1, tier2) - in progress >> >> Thank you, >> Misha >> From igor.ignatyev at oracle.com Wed Feb 14 17:00:21 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 14 Feb 2018 09:00:21 -0800 Subject: RFR(S): 8197906: Enable CDS mode execution of jtreg tests via make In-Reply-To: <5A84551E.6020707@oracle.com> References: <5A83B872.6070904@oracle.com> <5A84551E.6020707@oracle.com> Message-ID: [1] and [2] are equivalent for cygwin, but it doesn't mean they are equivalent JVM. I recall there were some problems when cygwin paths passed to JVM. so to be on the safe side, I'd use mixed or windows path to the archive in JVM flags. Thanks, -- Igor > On Feb 14, 2018, at 7:26 AM, Mikhailo Seledtsov wrote: > > Hi Igor, > > Thank you for review. This is what I see from the test execution logs on Windows: > > // At archive creation time: > > -XX:SharedArchiveFile=T:/testoutput/jtreg/cds_archive.jsa -Xshare:dump > > > // At archive use time: > > > -vmoption:-XX:+UnlockDiagnosticVMOptions -vmoption:-XX:SharedArchiveFile=/cygdrive/t/testoutput/jtreg/cds_archive.jsa -javaoptions:-Xshare:auto -javaoptions:-Xlog:class+path=trace -javaoptions:-showversion > > > I am not a Windows expert, and especially not a wiz in Cygwin. Do you know if these 2 paths are equivalent? > [1] T:/testoutput/jtreg/cds_archive.jsa > [2] /cygdrive/t/testoutput/jtreg/cds_archive.jsa > > If these are equivalent, then the code is OK as is. If not, I will change it and rerun the tests. Please let me know. > > > Thank you, > Misha > > > On 2/13/18, 8:41 PM, Igor Ignatyev wrote: >> Hi Misha, >> >> have you check that it works on windows w/ GENERATE_CDS_ARCHIVE=true? it seems that you should called GETMIXEDPATH in CDS_VM_ARGS: >>> CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=$(CDS_ARCHIVE_FILE) >> vs >>> CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=$(shell $(GETMIXEDPATH) "$(CDS_ARCHIVE_FILE)") >> otherwise, tests won't be able to find cds archive during test execution. >> >> -- Igor >> >>> On Feb 13, 2018, at 8:17 PM, Mikhailo Seledtsov wrote: >>> >>> Please review this small change that enables execution of any jtreg test(s) in CDS mode >>> via make. Please see bug description for details. >>> >>> Thanks to Erik and Igor for their help with this change. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8197906 >>> WebRev: http://cr.openjdk.java.net/~mseledtsov/8197906.01/ >>> >>> Testing: >>> - ran hotspot_runtime in CDS mode with this change - Linux-x64 - no new failures >>> - running several test sets in CDS mode via distributed test system - pass >>> - running pre-integration sanity testing (HS tier1, tier2) - in progress >>> >>> Thank you, >>> Misha >>> From magnus.ihse.bursie at oracle.com Wed Feb 14 19:59:18 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 14 Feb 2018 20:59:18 +0100 Subject: RFR: JDK-8153294: Solaris devkit uses linker from system instead of in devkit In-Reply-To: References: Message-ID: <8d085d65-7b24-8793-52b7-7099120a33c6@oracle.com> On 2018-02-14 01:50, Erik Joelsson wrote: > The current devkit I created for Solaris has a flaw in that CC will > still call the system linker instead of the one in the devkit. I have > finally figured out a solution for this, while working on the next > devkit with upgraded compiler versions, but this fix has value on its > own so I decided to update the existing one for 11 immediately. > > The devkit is changed to include the relevant executables as well as > the specific libs they need, arranged in such a way so that the > existing runpaths in the executables match the relative paths of the > libs. In configure, I added a check for ld in the devkit and add the > necessary flag to SYSROOT_LDFLAGS if found. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153294 > > Webrev: http://cr.openjdk.java.net/~erikj/8153294/webrev.01/ Looks good to me. Thanks for the care you're taking in making high quality devkits! /Magnus > > /Erik > From magnus.ihse.bursie at oracle.com Wed Feb 14 20:04:03 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 14 Feb 2018 21:04:03 +0100 Subject: RFR(S): 8197906: Enable CDS mode execution of jtreg tests via make In-Reply-To: <5A84551E.6020707@oracle.com> References: <5A83B872.6070904@oracle.com> <5A84551E.6020707@oracle.com> Message-ID: On 2018-02-14 16:26, Mikhailo Seledtsov wrote: > Hi Igor, > > ? Thank you for review. This is what I see from the test execution > logs on Windows: > > // At archive creation time: > ?> -XX:SharedArchiveFile=T:/testoutput/jtreg/cds_archive.jsa -Xshare:dump > > > // At archive use time: > > ?>??????? -vmoption:-XX:+UnlockDiagnosticVMOptions > -vmoption:-XX:SharedArchiveFile=/cygdrive/t/testoutput/jtreg/cds_archive.jsa > -javaoptions:-Xshare:auto -javaoptions:-Xlog:class+path=trace > -javaoptions:-showversion > > > I am not a Windows expert, and especially not a wiz in Cygwin. Do you > know if these 2 paths are equivalent? That's likely incorrect. Java will not be able to correctly interpred /cygdrive/t. I believe the fix should be to do: CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=$(shell $(GETMIXEDPATH) "$(CDS_ARCHIVE_FILE)") instead. Otherwise the patch looks OK to me. /Magnus > [1] T:/testoutput/jtreg/cds_archive.jsa > [2] /cygdrive/t/testoutput/jtreg/cds_archive.jsa > > If these are equivalent, then the code is OK as is. If not, I will > change it and rerun the tests. Please let me know. > > > Thank you, > Misha > > > On 2/13/18, 8:41 PM, Igor Ignatyev wrote: >> Hi Misha, >> >> have you check that it works on windows w/ GENERATE_CDS_ARCHIVE=true? >> it seems that you should called GETMIXEDPATH in CDS_VM_ARGS: >>> CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions >>> -XX:SharedArchiveFile=$(CDS_ARCHIVE_FILE) >> vs >>> CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions >>> -XX:SharedArchiveFile=$(shell $(GETMIXEDPATH) "$(CDS_ARCHIVE_FILE)") >> otherwise, tests won't be able to find cds archive during test >> execution. >> >> -- Igor >> >>> On Feb 13, 2018, at 8:17 PM, Mikhailo >>> Seledtsov? wrote: >>> >>> Please review this small change that enables execution of any jtreg >>> test(s) in CDS mode >>> via make. Please see bug description for details. >>> >>> Thanks to Erik and Igor for their help with this change. >>> >>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8197906 >>> ??? WebRev: http://cr.openjdk.java.net/~mseledtsov/8197906.01/ >>> >>> ??? Testing: >>> ????? - ran hotspot_runtime in CDS mode with this change - Linux-x64 >>> - no new failures >>> ????? - running several test sets in CDS mode via distributed test >>> system - pass >>> ????? - running pre-integration sanity testing (HS tier1, tier2) - >>> in progress >>> >>> Thank you, >>> Misha >>> From sangheon.kim at oracle.com Wed Feb 14 21:45:04 2018 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 14 Feb 2018 13:45:04 -0800 Subject: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM) Message-ID: <1554d7d4-df1f-5254-9014-f4f1d0c2aac6@oracle.com> Hi all, Could I have some reviews for CMM removal? This is closed CR but some public codes also need small modifications. This CR is for removing stuff related to an Oracle JDK module/package. Changes are just removing CMM from lists or in a test to skip the testing logic. CR: https://bugs.openjdk.java.net/browse/JDK-8193909 Webrev: http://cr.openjdk.java.net/~sangheki/8193909/webrev.0 Testing: hs-tier1~5, jdk1~3, open/test/jdk:jdk_core Thanks, Sangheon From david.holmes at oracle.com Wed Feb 14 22:40:02 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Feb 2018 08:40:02 +1000 Subject: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM) In-Reply-To: <1554d7d4-df1f-5254-9014-f4f1d0c2aac6@oracle.com> References: <1554d7d4-df1f-5254-9014-f4f1d0c2aac6@oracle.com> Message-ID: That all seems trivially fine. Thanks, David On 15/02/2018 7:45 AM, sangheon.kim wrote: > Hi all, > > Could I have some reviews for CMM removal? > This is closed CR but some public codes also need small modifications. > This CR is for removing stuff related to an Oracle JDK module/package. > Changes are just removing CMM from lists or in a test to skip the > testing logic. > > CR: https://bugs.openjdk.java.net/browse/JDK-8193909 > Webrev: http://cr.openjdk.java.net/~sangheki/8193909/webrev.0 > Testing: hs-tier1~5, jdk1~3, open/test/jdk:jdk_core > > Thanks, > Sangheon > From jesper.wilhelmsson at oracle.com Wed Feb 14 22:53:21 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 14 Feb 2018 23:53:21 +0100 Subject: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM) In-Reply-To: <1554d7d4-df1f-5254-9014-f4f1d0c2aac6@oracle.com> References: <1554d7d4-df1f-5254-9014-f4f1d0c2aac6@oracle.com> Message-ID: <71FFFDAB-B096-48F1-BC18-765F5D6EE734@oracle.com> Looks good! /Jesper > On 14 Feb 2018, at 22:45, sangheon.kim wrote: > > Hi all, > > Could I have some reviews for CMM removal? > This is closed CR but some public codes also need small modifications. This CR is for removing stuff related to an Oracle JDK module/package. > Changes are just removing CMM from lists or in a test to skip the testing logic. > > CR: https://bugs.openjdk.java.net/browse/JDK-8193909 > Webrev: http://cr.openjdk.java.net/~sangheki/8193909/webrev.0 > Testing: hs-tier1~5, jdk1~3, open/test/jdk:jdk_core > > Thanks, > Sangheon > From sangheon.kim at oracle.com Wed Feb 14 23:02:38 2018 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 14 Feb 2018 15:02:38 -0800 Subject: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM) In-Reply-To: <71FFFDAB-B096-48F1-BC18-765F5D6EE734@oracle.com> References: <1554d7d4-df1f-5254-9014-f4f1d0c2aac6@oracle.com> <71FFFDAB-B096-48F1-BC18-765F5D6EE734@oracle.com> Message-ID: <91fd2bf6-e4ac-e4fb-7c34-8332b78a3e27@oracle.com> Hi David and Jesper, Thank you for the review. Sangheon On 02/14/2018 02:53 PM, jesper.wilhelmsson at oracle.com wrote: > Looks good! > /Jesper > >> On 14 Feb 2018, at 22:45, sangheon.kim wrote: >> >> Hi all, >> >> Could I have some reviews for CMM removal? >> This is closed CR but some public codes also need small modifications. This CR is for removing stuff related to an Oracle JDK module/package. >> Changes are just removing CMM from lists or in a test to skip the testing logic. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8193909 >> Webrev: http://cr.openjdk.java.net/~sangheki/8193909/webrev.0 >> Testing: hs-tier1~5, jdk1~3, open/test/jdk:jdk_core >> >> Thanks, >> Sangheon >> From mandy.chung at oracle.com Wed Feb 14 23:45:50 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 14 Feb 2018 15:45:50 -0800 Subject: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM) In-Reply-To: <1554d7d4-df1f-5254-9014-f4f1d0c2aac6@oracle.com> References: <1554d7d4-df1f-5254-9014-f4f1d0c2aac6@oracle.com> Message-ID: <07c86a73-1695-9080-57df-80ef15261221@oracle.com> +1 Mandy On 2/14/18 1:45 PM, sangheon.kim wrote: > Hi all, > > Could I have some reviews for CMM removal? > This is closed CR but some public codes also need small modifications. > This CR is for removing stuff related to an Oracle JDK module/package. > Changes are just removing CMM from lists or in a test to skip the > testing logic. > > CR: https://bugs.openjdk.java.net/browse/JDK-8193909 > Webrev: http://cr.openjdk.java.net/~sangheki/8193909/webrev.0 > Testing: hs-tier1~5, jdk1~3, open/test/jdk:jdk_core > > Thanks, > Sangheon > From sangheon.kim at oracle.com Wed Feb 14 23:58:21 2018 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 14 Feb 2018 15:58:21 -0800 Subject: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM) In-Reply-To: <07c86a73-1695-9080-57df-80ef15261221@oracle.com> References: <1554d7d4-df1f-5254-9014-f4f1d0c2aac6@oracle.com> <07c86a73-1695-9080-57df-80ef15261221@oracle.com> Message-ID: Hi Mandy, Thank you for the review! Sangheon On 02/14/2018 03:45 PM, mandy chung wrote: > +1 > > Mandy > > On 2/14/18 1:45 PM, sangheon.kim wrote: >> Hi all, >> >> Could I have some reviews for CMM removal? >> This is closed CR but some public codes also need small >> modifications. This CR is for removing stuff related to an Oracle JDK >> module/package. >> Changes are just removing CMM from lists or in a test to skip the >> testing logic. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8193909 >> Webrev: http://cr.openjdk.java.net/~sangheki/8193909/webrev.0 >> Testing: hs-tier1~5, jdk1~3, open/test/jdk:jdk_core >> >> Thanks, >> Sangheon >> > From maobaolong at 139.com Thu Feb 15 00:35:06 2018 From: maobaolong at 139.com (mbl) Date: Thu, 15 Feb 2018 08:35:06 +0800 Subject: macOS High Sierra, version 10.13.2 configure: error: Couldnotfind freetype! You might be able to fix this by running 'brewinstallfreetype' In-Reply-To: <42d80600-4322-a637-397f-ba8241069f64@oracle.com> References: <22b9f556-464f-db03-52b2-beb002f2a67b@oracle.com> <88249E80-DF5E-4C01-833D-920DBC44BBBA@139.com> <42d80600-4322-a637-397f-ba8241069f64@oracle.com> Message-ID: <1761B1DF-C376-498C-AFBF-63E96CB6FE91@139.com> Thank you to let me know, You are right, i see my Xcode 4 is , so what can I do if I still want to build openjdk on my macos? I really don not want to downgrade my Mac OS. > On 14 Feb 2018, at 00:55, Erik Joelsson wrote: > > Hello, > > My guess would be that Xcode 4 isn't working on Macos 10.13. Internally we build JDK 8 on 10.8. > > /Erik > > On 2018-02-13 01:41, mbl wrote: >> Thank you for your kind help, I?ve jump out of the last pit. >> >> Now the new challenge is: >> >> I execute the following command: >> >> bash ../8dev/configure --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home --with-freetype=/usr/local/Cellar/freetype/2.9/ --enable-ccache --with-jvm-variants=server --with-boot-jdk-jvmargs="-Xlint:deprecation -Xlint:unchecked" --disable-zip-debug-info MAKE=/Applications/Xcode9.app/Contents/Developer/usr/bin/make >> >> But I see the following error >> >> dyld: Library not loaded: @rpath/DVTFoundation.framework/Versions/A/DVTFoundation >> Referenced from: /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild >> Reason: no suitable image found. Did find: >> /Applications/Xcode.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation: cannot load '/Applications/Xcode.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation' because Objective-C garbage collection is not supported >> xcrun: error: unable to locate xcodebuild, please make sure the path to the Xcode folder is set correctly! >> xcrun: error: You can set the path to the Xcode folder using /usr/bin/xcode-select -switch >> configure: error: Xcode 4 is required to build JDK 8, the version found was . Use --with-xcode-path to specify the location of Xcode 4 or make Xcode 4 active by using xcode-select. >> configure exiting with result code 1 >> >> >> Please help me more. Thank your advance! >> >> >> My Env is: >> >> OS: macOS High Sierra, version 10.13. >> Repo : http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ >> Tags: jdk8u162-b12 >> >> Other info: >> >> The configure error pick me to mv my default xcode (9.0.4) to a backup as `/Applications/Xcode9.app`. I install Xcode4.6.3 to `Applications/Xcode.app`, and execute `sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer` to active it. >> >> >> >>> On 13 Feb 2018, at 02:47, Erik Joelsson > wrote: >>> >>> Hello, >>> >>> I just tried this myself and configure is automatically picking up my freetype from brew in /usr/local/opt/freetype/. Looking at my log, this is done using pkg-config from brew. So you could try installing pkg-config (brew install pkg-config). You can also try adding --with-freetype=/usr/local/opt/freetype if that's where brew installed it for you. >>> >>> /Erik >>> >>> >>> On 2018-02-11 22:51, mbl wrote: >>>> OS: macOS High Sierra, version 10.13.2 >>>> Repo : https://github.com/dmlloyd/openjdk.git >>>> Branch : jdk/jdk >>>> >>>> mbldeMacBook-Pro:openjdk mbl$ bash ./configure --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk9.0.4.jdk/Home >>>> configure: Configuration created at Mon Feb 12 14:43:36 CST 2018. >>>> configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype'. >>>> /projects/jdpros/openjdk/.build/generated-configure.sh: line 82: 5: Bad file descriptor >>>> configure exiting with result code 1 >>>> mbldeMacBook-Pro:openjdk mbl$ sudo brew install freetype >>>> Password: >>>> Error: Running Homebrew as root is extremely dangerous and no longer supported. >>>> As Homebrew does not drop privileges on installation you would be giving all >>>> build scripts full access to your system. >>>> mbldeMacBook-Pro:openjdk mbl$ brew install freetype >>>> Updating Homebrew... >>>> Warning: freetype 2.9 is already installed >>>> >>>> >>>> What can I do? >>> >> > From ted at tedneward.com Thu Feb 15 00:38:31 2018 From: ted at tedneward.com (Ted Neward) Date: Wed, 14 Feb 2018 16:38:31 -0800 Subject: JDK10 build problem: "--module-path"? Message-ID: I?m getting a weird error in my OpenJDK 10 (tip) build, where after pulling source and configure, I get a build error about the Java compiler being executed with ?--module-path? as a parameter, which obviously isn?t a legitimate javac flag. Is this just me? Is anybody else able to repro this, and is there a fix coming that isn?t checked into the main trunk yet? I am in the process of finalizing some Docker images (both with the source inside the image and built, so people can just ?go?, as well as images with the prereqs and some shell scripts to do the build with the source and build artifacts on the host machine), and this is holding up the current ?tip? images from being really ready for public consumption. (JDK8u and JDK9 are up and ready to go.) Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 From david.holmes at oracle.com Thu Feb 15 02:17:25 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Feb 2018 12:17:25 +1000 Subject: JDK10 build problem: "--module-path"? In-Reply-To: References: Message-ID: <2a3400cc-bc21-e7be-aba7-60f0f85a7115@oracle.com> On 15/02/2018 10:38 AM, Ted Neward wrote: > I?m getting a weird error in my OpenJDK 10 (tip) build, where after pulling source and configure, I get a build error about the Java compiler being executed with ?--module-path? as a parameter, which obviously isn?t a legitimate javac flag. > > Is this just me? Is anybody else able to repro this, and is there a fix coming that isn?t checked into the main trunk yet? No issues with our internal builds. What platform are you building? Did the reconfigure work correctly? Does blowing away build directory and starting again fix it? David ----- > > > I am in the process of finalizing some Docker images (both with the source inside the image and built, so people can just ?go?, as well as images with the prereqs and some shell scripts to do the build with the source and build artifacts on the host machine), and this is holding up the current ?tip? images from being really ready for public consumption. (JDK8u and JDK9 are up and ready to go.) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > From jonathan.gibbons at oracle.com Thu Feb 15 02:53:31 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 14 Feb 2018 18:53:31 -0800 Subject: JDK10 build problem: "--module-path"? In-Reply-To: References: Message-ID: <50f4068f-6aa9-44bd-3858-5e5e2fa02737@oracle.com> On 2/14/18 4:38 PM, Ted Neward wrote: > I?m getting a weird error in my OpenJDK 10 (tip) build, where after pulling source and configure, I get a build error about the Java compiler being executed with ?--module-path? as a parameter, which obviously isn?t a legitimate javac flag. > > I can't speak to your specific build error, but --module-path is a legitimate javac option, as of JDK 9. -- Jon > > Is this just me? Is anybody else able to repro this, and is there a fix coming that isn?t checked into the main trunk yet? > > > > I am in the process of finalizing some Docker images (both with the source inside the image and built, so people can just ?go?, as well as images with the prereqs and some shell scripts to do the build with the source and build artifacts on the host machine), and this is holding up the current ?tip? images from being really ready for public consumption. (JDK8u and JDK9 are up and ready to go.) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > From ted at tedneward.com Thu Feb 15 06:32:35 2018 From: ted at tedneward.com (Ted Neward) Date: Wed, 14 Feb 2018 22:32:35 -0800 Subject: JDK10 build problem: "--module-path"? In-Reply-To: <50f4068f-6aa9-44bd-3858-5e5e2fa02737@oracle.com> References: <50f4068f-6aa9-44bd-3858-5e5e2fa02737@oracle.com> Message-ID: <85DE1A73-B78C-4E4F-A852-350B57256B75@tedneward.com> Really?!? I thought the javac -help only listed -modulepath. Not to disbelieve you *grin*, but are you sure? The reason I ask is (barring some really bizarre misconfiguration) I should be using the OpenJDK9 as the boot JDK for this, and I'm getting the error. Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 ?On 2/14/18, 6:53 PM, "build-dev on behalf of Jonathan Gibbons" wrote: On 2/14/18 4:38 PM, Ted Neward wrote: > I?m getting a weird error in my OpenJDK 10 (tip) build, where after pulling source and configure, I get a build error about the Java compiler being executed with ?--module-path? as a parameter, which obviously isn?t a legitimate javac flag. > > I can't speak to your specific build error, but --module-path is a legitimate javac option, as of JDK 9. -- Jon > > Is this just me? Is anybody else able to repro this, and is there a fix coming that isn?t checked into the main trunk yet? > > > > I am in the process of finalizing some Docker images (both with the source inside the image and built, so people can just ?go?, as well as images with the prereqs and some shell scripts to do the build with the source and build artifacts on the host machine), and this is holding up the current ?tip? images from being really ready for public consumption. (JDK8u and JDK9 are up and ready to go.) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > From thomas.stuefe at gmail.com Thu Feb 15 07:30:32 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 15 Feb 2018 08:30:32 +0100 Subject: Choosing which Visual Studio installation to use In-Reply-To: <0aded0b8-ea01-d678-7aec-b5c6f4fc06e1@redhat.com> References: <0aded0b8-ea01-d678-7aec-b5c6f4fc06e1@redhat.com> Message-ID: Hi Michael, On Wed, Feb 14, 2018 at 4:20 PM, Michal Vala wrote: > Hi, > > On 02/14/2018 12:24 PM, Thomas St?fe wrote: > >> Hi all, >> >> On Windows, if one has multiple VS installations side by side, is it >> possible to choose which Visual Studio installation to use? >> >> Note that I start the configure script from within the cygwin shell. >> >> > OpenJDK configure is reading VS environment properties > VS100COMNTOOLS/VS120COMNTOOLS/VS140COMNTOOLS etc. One option is to set > just one of them. AFAIK configure takes latest supported VS (2013 for > ojdk9). > > Another option is to use configure parameters, but I don't know how > exactly use them. Try to look to configure help > > $ bash ./configure --help | grep toolchain > --with-tools-dir alias for --with-toolchain-path for backwards > --with-toolchain-path prepend these directories when searching for > toolchain binaries (compilers etc) > --with-toolchain-type the toolchain type (or family) to use, use > '--help' > --with-toolchain-version > the version of the toolchain to look for, use > --with-build-devkit Devkit to use for the build platform toolchain > [toolchain dependent] > The following toolchains are available as arguments to > --with-toolchain-type. > > > -- > Michal Vala > OpenJDK QE > Red Hat Czech > Thank you for your pointers, I'll see how far I get. ..Thomas From Alan.Bateman at oracle.com Thu Feb 15 08:05:25 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Feb 2018 08:05:25 +0000 Subject: JDK10 build problem: "--module-path"? In-Reply-To: <85DE1A73-B78C-4E4F-A852-350B57256B75@tedneward.com> References: <50f4068f-6aa9-44bd-3858-5e5e2fa02737@oracle.com> <85DE1A73-B78C-4E4F-A852-350B57256B75@tedneward.com> Message-ID: <3cb9e208-1e7a-fdef-9142-04d5f77b82c0@oracle.com> On 15/02/2018 06:32, Ted Neward wrote: > Really?!? I thought the javac -help only listed -modulepath. Not to disbelieve you *grin*, but are you sure? The reason I ask is (barring some really bizarre misconfiguration) I should be using the OpenJDK9 as the boot JDK for this, and I'm getting the error. > What is your boot JDK? Any possibility that you have really old EA build of JDK 9? From ben_walsh at uk.ibm.com Thu Feb 15 11:32:45 2018 From: ben_walsh at uk.ibm.com (Ben Walsh) Date: Thu, 15 Feb 2018 11:32:45 +0000 Subject: [PATCH] Add post custom extension hooks to two launchers Message-ID: This patch simply adds a hook to two launchers to call a post custom extension if it is available. I would like to pair with a sponsor to contribute this patch ... ------------------------------------------------------------------------------------ diff -r 85c27aabf312 make/launcher/Launcher-jdk.jcmd.gmk --- a/make/launcher/Launcher-jdk.jcmd.gmk Thu Feb 08 10:06:57 2018 -0500 +++ b/make/launcher/Launcher-jdk.jcmd.gmk Thu Feb 15 11:16:28 2018 +0000 @@ -1,5 +1,5 @@ # -# Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it @@ -60,3 +60,6 @@ $(eval $(call SetupBuildLauncher, jcmd, \ MAIN_CLASS := sun.tools.jcmd.JCmd, \ )) + +# Hook to include the corresponding custom file, if present. +$(eval $(call IncludeCustomExtension, launcher/Launcher-jdk.jcmd-post.gmk)) diff -r 85c27aabf312 make/launcher/Launcher-jdk.jstatd.gmk --- a/make/launcher/Launcher-jdk.jstatd.gmk Thu Feb 08 10:06:57 2018 -0500 +++ b/make/launcher/Launcher-jdk.jstatd.gmk Thu Feb 15 11:16:28 2018 +0000 @@ -1,5 +1,5 @@ # -# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it @@ -28,3 +28,6 @@ $(eval $(call SetupBuildLauncher, jstatd, \ MAIN_CLASS := sun.tools.jstatd.Jstatd, \ )) + +# Hook to include the corresponding custom file, if present. +$(eval $(call IncludeCustomExtension, launcher/Launcher-jdk.jstatd-post.gmk)) ------------------------------------------------------------------------------------ Regards, Ben Walsh Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From thomas.schatzl at oracle.com Thu Feb 15 11:32:48 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 15 Feb 2018 12:32:48 +0100 Subject: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM) In-Reply-To: <1554d7d4-df1f-5254-9014-f4f1d0c2aac6@oracle.com> References: <1554d7d4-df1f-5254-9014-f4f1d0c2aac6@oracle.com> Message-ID: <1518694368.4282.26.camel@oracle.com> Hi, On Wed, 2018-02-14 at 13:45 -0800, sangheon.kim wrote: > Hi all, > > Could I have some reviews for CMM removal? > This is closed CR but some public codes also need small > modifications. > This CR is for removing stuff related to an Oracle JDK > module/package. > Changes are just removing CMM from lists or in a test to skip the > testing logic. > > CR: https://bugs.openjdk.java.net/browse/JDK-8193909 > Webrev: http://cr.openjdk.java.net/~sangheki/8193909/webrev.0 > Testing: hs-tier1~5, jdk1~3, open/test/jdk:jdk_core > looks good. Thomas From magnus.ihse.bursie at oracle.com Thu Feb 15 14:14:22 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Feb 2018 15:14:22 +0100 Subject: RFR: JDK-8198227 Fix COMPARE_BUILD after forest consolidation Message-ID: <5ed92142-8540-c0ef-acbe-bd73468eec23@oracle.com> The new repo structure with the forest consolidation broke the COMPARE_BUILD functionality when using a closed repo. Bug: https://bugs.openjdk.java.net/browse/JDK-8198227 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8198227-fix-COMPARE_BUILD-in-CLOSED_ROOT/webrev.01 From sangheon.kim at oracle.com Thu Feb 15 15:00:17 2018 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 15 Feb 2018 07:00:17 -0800 Subject: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM) In-Reply-To: <1518694368.4282.26.camel@oracle.com> References: <1554d7d4-df1f-5254-9014-f4f1d0c2aac6@oracle.com> <1518694368.4282.26.camel@oracle.com> Message-ID: <10e5b37c-fdcc-3666-5934-c301b4d18fa0@oracle.com> Hi Thomas, On 02/15/2018 03:32 AM, Thomas Schatzl wrote: > Hi, > > On Wed, 2018-02-14 at 13:45 -0800, sangheon.kim wrote: >> Hi all, >> >> Could I have some reviews for CMM removal? >> This is closed CR but some public codes also need small >> modifications. >> This CR is for removing stuff related to an Oracle JDK >> module/package. >> Changes are just removing CMM from lists or in a test to skip the >> testing logic. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8193909 >> Webrev: http://cr.openjdk.java.net/~sangheki/8193909/webrev.0 >> Testing: hs-tier1~5, jdk1~3, open/test/jdk:jdk_core >> > looks good. Thank you for your review! Sangheon > > Thomas From erik.joelsson at oracle.com Thu Feb 15 15:22:40 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 15 Feb 2018 07:22:40 -0800 Subject: Choosing which Visual Studio installation to use In-Reply-To: References: Message-ID: Hello Thomas, If you have multiple versions installed, configure will pick the one to use in order of most supported. To explicitly pick one, you can use --with-toolchain-version=2010 (or some other number) and configure will look for that specific version of Visual Studio. Just pointing to an install dir or bin dir does not work because configure needs to know which version it is dealing with and we haven't implemented smart enough discovery logic to automatically figure that out. Note that I recently added configure support for 2015 and 2017 in JDK 11. This does NOT mean the product actually builds with those and configure will print warnings accordingly. We are working on properly supporting 2017, but it's apparently non trivial. /Erik On 2018-02-14 03:24, Thomas St?fe wrote: > Hi all, > > On Windows, if one has multiple VS installations side by side, is it > possible to choose which Visual Studio installation to use? > > Note that I start the configure script from within the cygwin shell. > > Thanks, Thomas From jonathan.gibbons at oracle.com Thu Feb 15 15:27:41 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 15 Feb 2018 07:27:41 -0800 Subject: JDK10 build problem: "--module-path"? In-Reply-To: <85DE1A73-B78C-4E4F-A852-350B57256B75@tedneward.com> References: <50f4068f-6aa9-44bd-3858-5e5e2fa02737@oracle.com> <85DE1A73-B78C-4E4F-A852-350B57256B75@tedneward.com> Message-ID: <15a6e924-a114-c1d4-1de3-37ce123ec14e@oracle.com> Ted, Yes, I'm sure :-) This is the relevant line from the source code for JDK 9, listing --module-path and -p as alternatives for this option. MODULE_PATH("--module-path -p", "opt.arg.path", "opt.modulepath", STANDARD, FILEMANAGER), http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/65bfdabaab9c/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java#l183 -- Jon On 2/14/18 10:32 PM, Ted Neward wrote: > Really?!? I thought the javac -help only listed -modulepath. Not to disbelieve you *grin*, but are you sure? The reason I ask is (barring some really bizarre misconfiguration) I should be using the OpenJDK9 as the boot JDK for this, and I'm getting the error. > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > ?On 2/14/18, 6:53 PM, "build-dev on behalf of Jonathan Gibbons" wrote: > > > > On 2/14/18 4:38 PM, Ted Neward wrote: > > I?m getting a weird error in my OpenJDK 10 (tip) build, where after pulling source and configure, I get a build error about the Java compiler being executed with ?--module-path? as a parameter, which obviously isn?t a legitimate javac flag. > > > > > I can't speak to your specific build error, but --module-path is a > legitimate javac option, as of JDK 9. > > -- Jon > > > > > Is this just me? Is anybody else able to repro this, and is there a fix coming that isn?t checked into the main trunk yet? > > > > > > > > I am in the process of finalizing some Docker images (both with the source inside the image and built, so people can just ?go?, as well as images with the prereqs and some shell scripts to do the build with the source and build artifacts on the host machine), and this is holding up the current ?tip? images from being really ready for public consumption. (JDK8u and JDK9 are up and ready to go.) > > > > > > > > Ted Neward > > > > Author, Speaker, Mentor > > > > http://www.newardassociates.com > > > > t: @tedneward | m: (425) 647-4526 > > > > > > From erik.joelsson at oracle.com Thu Feb 15 15:27:45 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 15 Feb 2018 07:27:45 -0800 Subject: Choosing which Visual Studio installation to use In-Reply-To: <64988785-63d7-346e-a3fd-65cf06f3e17b@physik.fu-berlin.de> References: <48c454a8-2ab8-4d7b-1a9d-a948cce6aae3@physik.fu-berlin.de> <187e98dc-3370-fcfa-4458-0776425c0d5e@physik.fu-berlin.de> <64988785-63d7-346e-a3fd-65cf06f3e17b@physik.fu-berlin.de> Message-ID: <53d8f13b-4893-2bd7-7397-ab543215688e@oracle.com> Hello, Just want to clear some things up around this. We use Cygwin just as a unix emulation layer for running typical unix tools. OpenJDK can only be built on Windows using Visual Studio as the compiler toolchain. We currently don't support any other unix emulation layer. We have had support for msys and we may work with msys2, but it's not being actively maintained so I'm pretty sure that has bit rotted by now. It's correct that if we actually used the gcc from cygwin, we would build for cygwin and not windows. In the future I would like to support WSL, but it will require some work. I do believe the latest version is competent enough to get everything we need working though. /Erik On 2018-02-14 05:16, John Paul Adrian Glaubitz wrote: > On 02/14/2018 02:07 PM, Thomas St?fe wrote: >> ??? Does it have to be Cygwin though? >> >> >> Yes. I love cygwin. You can put it into fullscreen and pretend you >> have a very slow Linux machine :) But seriously, it is very stable >> and mature, would not like at all to change my environment. > > Yes, but, if I remember correctly, the problem is that anything built > with Cygwin always requires Cygwin to be present to be able to run. > > You always have to carry the runtime around if I remember correctly. > >> ??? On Windows I usually install the "git bash for Windows" package >> or whatever >> ??? it's called and it gives me a nice bash command prompt with a >> working git >> ??? and bash environment. You can then call the environment scripts >> from there. >> >> >> Can you do a full openjdk build with that? > I haven't tried OpenJDK. But in my previous company we did heavy Qt > development > with git bash for Windows and any additional external libraries that > were required > could usually be installed manually. It required some elbow grease, > but at least > the resulting binaries were regular Win32 applications which didn't > require any > particular runtime environment to be present except for the DLLs the > binaries > were linked against. > > Adrian > From erik.joelsson at oracle.com Thu Feb 15 15:31:16 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 15 Feb 2018 07:31:16 -0800 Subject: macOS High Sierra, version 10.13.2 configure: error: Couldnotfind freetype! You might be able to fix this by running 'brewinstallfreetype' In-Reply-To: <1761B1DF-C376-498C-AFBF-63E96CB6FE91@139.com> References: <22b9f556-464f-db03-52b2-beb002f2a67b@oracle.com> <88249E80-DF5E-4C01-833D-920DBC44BBBA@139.com> <42d80600-4322-a637-397f-ba8241069f64@oracle.com> <1761B1DF-C376-498C-AFBF-63E96CB6FE91@139.com> Message-ID: <51caf5e7-a4fa-2d8c-62eb-4d9b19f1bff5@oracle.com> You could hack configure to disable that check and try a slightly newer xcode. Maybe 5.x or 6.x works well enough. It's likely that you then also need to add --disable-warnings-as-errors to configure. You could also try installing an older Macos as a virtual machine on your current mac. Note though that the licensing around that is unclear. /Erik On 2018-02-14 16:35, mbl wrote: > Thank you to let me know, > > You are right, i see my Xcode 4 is , so what can I do if I still want > to build openjdk on my macos? I really don not want to downgrade my > Mac OS. > >> On 14 Feb 2018, at 00:55, Erik Joelsson > > wrote: >> >> Hello, >> >> My guess would be that Xcode 4 isn't working on Macos 10.13. >> Internally we build JDK 8 on 10.8. >> >> /Erik >> >> >> On 2018-02-13 01:41, mbl wrote: >>> Thank you for your kind help, I?ve jump out of the last pit. >>> >>> Now the new challenge is: >>> >>> I execute the following command: >>> >>> ?bash ../8dev/configure >>> ?--with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home >>> --with-freetype=/usr/local/Cellar/freetype/2.9/ --enable-ccache >>> --with-jvm-variants=server >>> --with-boot-jdk-jvmargs="-Xlint:deprecation -Xlint:unchecked" >>> --disable-zip-debug-info >>> MAKE=/Applications/Xcode9.app/Contents/Developer/usr/bin/make >>> >>> But I see the following error >>> >>> dyld: Library not loaded: >>> @rpath/DVTFoundation.framework/Versions/A/DVTFoundation >>> ? Referenced from: >>> /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild >>> ? Reason: no suitable image found. ?Did find: >>> /Applications/Xcode.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation: >>> cannot load >>> '/Applications/Xcode.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation' >>> because Objective-C garbage collection is not supported >>> xcrun: error: unable to locate xcodebuild, please make sure the path >>> to the Xcode folder is set correctly! >>> xcrun: error: You can set the path to the Xcode folder using >>> /usr/bin/xcode-select -switch >>> configure: error: Xcode 4 is required to build JDK 8, the version >>> found was . Use --with-xcode-path to specify the location of Xcode 4 >>> or make Xcode 4 active by using xcode-select. >>> configure exiting with result code 1 >>> >>> >>> Please help me more. Thank your advance! >>> >>> >>> My Env is: >>> >>> * OS: macOS High Sierra, version 10.13. >>> * Repo : http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ >>> * Tags: jdk8u162-b12 >>> >>> >>> >>> Other info: >>> >>> * The configure error pick me to mv my default xcode (9.0.4) to a >>> backup as `/Applications/Xcode9.app`. I install Xcode4.6.3 to >>> `Applications/Xcode.app`, and execute `sudo xcode-select -switch >>> /Applications/Xcode.app/Contents/Developer` to active it. >>> >>> >>> >>> >>>> On 13 Feb 2018, at 02:47, Erik Joelsson >>> > wrote: >>>> >>>> Hello, >>>> >>>> I just tried this myself and configure is automatically picking up >>>> my freetype from brew in /usr/local/opt/freetype/. Looking at my >>>> log, this is done using pkg-config from brew. So you could try >>>> installing pkg-config (brew install pkg-config). You can also try >>>> adding --with-freetype=/usr/local/opt/freetype if that's where brew >>>> installed it for you. >>>> >>>> /Erik >>>> >>>> >>>> On 2018-02-11 22:51, mbl wrote: >>>>> OS: macOS High Sierra, version 10.13.2 >>>>> Repo : https://github.com/dmlloyd/openjdk.git >>>>> Branch : jdk/jdk >>>>> >>>>> mbldeMacBook-Pro:openjdk mbl$ bash ./configure >>>>> --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk9.0.4.jdk/Home >>>>> configure: Configuration created at Mon Feb 12 14:43:36 CST 2018. >>>>> configure: error: Could not find freetype! You might be able to >>>>> fix this by running 'brew install freetype'. >>>>> /projects/jdpros/openjdk/.build/generated-configure.sh: line 82: >>>>> 5: Bad file descriptor >>>>> configure exiting with result code 1 >>>>> mbldeMacBook-Pro:openjdk mbl$ sudo brew install freetype >>>>> Password: >>>>> Error: Running Homebrew as root is extremely dangerous and no >>>>> longer supported. >>>>> As Homebrew does not drop privileges on installation you would be >>>>> giving all >>>>> build scripts full access to your system. >>>>> mbldeMacBook-Pro:openjdk mbl$ brew install freetype >>>>> Updating Homebrew... >>>>> Warning: freetype 2.9 is already installed >>>>> >>>>> >>>>> What can I do? >>>> >>> >> > From erik.joelsson at oracle.com Thu Feb 15 15:40:35 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 15 Feb 2018 07:40:35 -0800 Subject: RFR: JDK-8198227 Fix COMPARE_BUILD after forest consolidation In-Reply-To: <5ed92142-8540-c0ef-acbe-bd73468eec23@oracle.com> References: <5ed92142-8540-c0ef-acbe-bd73468eec23@oracle.com> Message-ID: <74059e0f-564a-6d70-c349-302d381a2b1d@oracle.com> Looks good. /Erik On 2018-02-15 06:14, Magnus Ihse Bursie wrote: > The new repo structure with the forest consolidation broke the > COMPARE_BUILD functionality when using a closed repo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198227 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198227-fix-COMPARE_BUILD-in-CLOSED_ROOT/webrev.01 > From erik.joelsson at oracle.com Thu Feb 15 15:42:57 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 15 Feb 2018 07:42:57 -0800 Subject: JDK10 build problem: "--module-path"? In-Reply-To: <3cb9e208-1e7a-fdef-9142-04d5f77b82c0@oracle.com> References: <50f4068f-6aa9-44bd-3858-5e5e2fa02737@oracle.com> <85DE1A73-B78C-4E4F-A852-350B57256B75@tedneward.com> <3cb9e208-1e7a-fdef-9142-04d5f77b82c0@oracle.com> Message-ID: <7109126a-158d-b3a9-5bb1-d4bc6568f8f7@oracle.com> I have hit this same problem once for the same reason Alan describes. Ubuntu provided me with a really old EA build of 9. /Erik On 2018-02-15 00:05, Alan Bateman wrote: > > > On 15/02/2018 06:32, Ted Neward wrote: >> Really?!? I thought the javac -help only listed -modulepath. Not to >> disbelieve you *grin*, but are you sure? The reason I ask is (barring >> some really bizarre misconfiguration) I should be using the OpenJDK9 >> as the boot JDK for this, and I'm getting the error. >> > What is your boot JDK? Any possibility that you have really old EA > build of JDK 9? From martinrb at google.com Thu Feb 15 16:50:05 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 15 Feb 2018 08:50:05 -0800 Subject: JDK10 build problem: "--module-path"? In-Reply-To: <7109126a-158d-b3a9-5bb1-d4bc6568f8f7@oracle.com> References: <50f4068f-6aa9-44bd-3858-5e5e2fa02737@oracle.com> <85DE1A73-B78C-4E4F-A852-350B57256B75@tedneward.com> <3cb9e208-1e7a-fdef-9142-04d5f77b82c0@oracle.com> <7109126a-158d-b3a9-5bb1-d4bc6568f8f7@oracle.com> Message-ID: Looking at https://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=openjdk-9-jdk&searchon=names it seems like Ubuntu ships whatever openjdk-9 is available at time of creation of a specific version, and doesn't update it afterwards, not even for the quarterly security patches. On Thu, Feb 15, 2018 at 7:42 AM, Erik Joelsson wrote: > I have hit this same problem once for the same reason Alan describes. > Ubuntu provided me with a really old EA build of 9. > > /Erik > > > > On 2018-02-15 00:05, Alan Bateman wrote: > >> >> >> On 15/02/2018 06:32, Ted Neward wrote: >> >>> Really?!? I thought the javac -help only listed -modulepath. Not to >>> disbelieve you *grin*, but are you sure? The reason I ask is (barring some >>> really bizarre misconfiguration) I should be using the OpenJDK9 as the boot >>> JDK for this, and I'm getting the error. >>> >>> What is your boot JDK? Any possibility that you have really old EA build >> of JDK 9? >> > > From thomas.stuefe at gmail.com Thu Feb 15 17:38:17 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 15 Feb 2018 18:38:17 +0100 Subject: Choosing which Visual Studio installation to use In-Reply-To: References: Message-ID: Hi Erik, On Thu, Feb 15, 2018 at 4:22 PM, Erik Joelsson wrote: > Hello Thomas, > > If you have multiple versions installed, configure will pick the one to > use in order of most supported. To explicitly pick one, you can use > --with-toolchain-version=2010 (or some other number) and configure will > look for that specific version of Visual Studio. Just pointing to an > install dir or bin dir does not work because configure needs to know which > version it is dealing with and we haven't implemented smart enough > discovery logic to automatically figure that out. > > Great, exactly what I was looking for! > Note that I recently added configure support for 2015 and 2017 in JDK 11. > This does NOT mean the product actually builds with those and configure > will print warnings accordingly. We are working on properly supporting > 2017, but it's apparently non trivial. > > Yes, I was playing around with getting VS2017 to build, and wanted to test changes with various VS versions. I see that Lois Foltan is quite active, maybe I just wait till he is done. ..Thomas > /Erik > > > > On 2018-02-14 03:24, Thomas St?fe wrote: > >> Hi all, >> >> On Windows, if one has multiple VS installations side by side, is it >> possible to choose which Visual Studio installation to use? >> >> Note that I start the configure script from within the cygwin shell. >> >> Thanks, Thomas >> > > From mikhailo.seledtsov at oracle.com Thu Feb 15 17:44:16 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Thu, 15 Feb 2018 09:44:16 -0800 Subject: RFR(S): 8197906: Enable CDS mode execution of jtreg tests via make In-Reply-To: References: <5A83B872.6070904@oracle.com> <5A84551E.6020707@oracle.com> Message-ID: <5A85C6F0.4080008@oracle.com> Hi Magnus, Thank you for review and feedback. I will update my change based on your recommendation, the retest. If tests pass, I am planning to push. Thank you, Misha On 2/14/18, 12:04 PM, Magnus Ihse Bursie wrote: > > > On 2018-02-14 16:26, Mikhailo Seledtsov wrote: >> Hi Igor, >> >> Thank you for review. This is what I see from the test execution >> logs on Windows: >> >> // At archive creation time: >> > -XX:SharedArchiveFile=T:/testoutput/jtreg/cds_archive.jsa -Xshare:dump >> >> >> // At archive use time: >> >> > -vmoption:-XX:+UnlockDiagnosticVMOptions >> -vmoption:-XX:SharedArchiveFile=/cygdrive/t/testoutput/jtreg/cds_archive.jsa >> -javaoptions:-Xshare:auto -javaoptions:-Xlog:class+path=trace >> -javaoptions:-showversion >> >> >> I am not a Windows expert, and especially not a wiz in Cygwin. Do you >> know if these 2 paths are equivalent? > That's likely incorrect. Java will not be able to correctly interpred > /cygdrive/t. I believe the fix should be to do: > CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions > -XX:SharedArchiveFile=$(shell $(GETMIXEDPATH) "$(CDS_ARCHIVE_FILE)") > instead. > > Otherwise the patch looks OK to me. > > /Magnus > > >> [1] T:/testoutput/jtreg/cds_archive.jsa >> [2] /cygdrive/t/testoutput/jtreg/cds_archive.jsa >> >> If these are equivalent, then the code is OK as is. If not, I will >> change it and rerun the tests. Please let me know. >> >> >> Thank you, >> Misha >> >> >> On 2/13/18, 8:41 PM, Igor Ignatyev wrote: >>> Hi Misha, >>> >>> have you check that it works on windows w/ >>> GENERATE_CDS_ARCHIVE=true? it seems that you should called >>> GETMIXEDPATH in CDS_VM_ARGS: >>>> CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions >>>> -XX:SharedArchiveFile=$(CDS_ARCHIVE_FILE) >>> vs >>>> CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions >>>> -XX:SharedArchiveFile=$(shell $(GETMIXEDPATH) "$(CDS_ARCHIVE_FILE)") >>> otherwise, tests won't be able to find cds archive during test >>> execution. >>> >>> -- Igor >>> >>>> On Feb 13, 2018, at 8:17 PM, Mikhailo >>>> Seledtsov wrote: >>>> >>>> Please review this small change that enables execution of any jtreg >>>> test(s) in CDS mode >>>> via make. Please see bug description for details. >>>> >>>> Thanks to Erik and Igor for their help with this change. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8197906 >>>> WebRev: http://cr.openjdk.java.net/~mseledtsov/8197906.01/ >>>> >>>> Testing: >>>> - ran hotspot_runtime in CDS mode with this change - >>>> Linux-x64 - no new failures >>>> - running several test sets in CDS mode via distributed test >>>> system - pass >>>> - running pre-integration sanity testing (HS tier1, tier2) - >>>> in progress >>>> >>>> Thank you, >>>> Misha >>>> > From mikhailo.seledtsov at oracle.com Thu Feb 15 17:42:42 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Thu, 15 Feb 2018 09:42:42 -0800 Subject: RFR(S): 8197906: Enable CDS mode execution of jtreg tests via make In-Reply-To: References: <5A83B872.6070904@oracle.com> <5A84551E.6020707@oracle.com> Message-ID: <5A85C692.8050401@oracle.com> Hi Igor, Thank you very much for catching this, and for the explanation. I have updated the patch and running tests now. I assume the recommended update is small/trivial enough that it does not need another webrev; let me know otherwise. Thank you, Misha On 2/14/18, 9:00 AM, Igor Ignatyev wrote: > [1] and [2] are equivalent for cygwin, but it doesn't mean they are equivalent JVM. I recall there were some problems when cygwin paths passed to JVM. so to be on the safe side, I'd use mixed or windows path to the archive in JVM flags. > > Thanks, > -- Igor > >> On Feb 14, 2018, at 7:26 AM, Mikhailo Seledtsov wrote: >> >> Hi Igor, >> >> Thank you for review. This is what I see from the test execution logs on Windows: >> >> // At archive creation time: >>> -XX:SharedArchiveFile=T:/testoutput/jtreg/cds_archive.jsa -Xshare:dump >> >> // At archive use time: >> >>> -vmoption:-XX:+UnlockDiagnosticVMOptions -vmoption:-XX:SharedArchiveFile=/cygdrive/t/testoutput/jtreg/cds_archive.jsa -javaoptions:-Xshare:auto -javaoptions:-Xlog:class+path=trace -javaoptions:-showversion >> >> I am not a Windows expert, and especially not a wiz in Cygwin. Do you know if these 2 paths are equivalent? >> [1] T:/testoutput/jtreg/cds_archive.jsa >> [2] /cygdrive/t/testoutput/jtreg/cds_archive.jsa >> >> If these are equivalent, then the code is OK as is. If not, I will change it and rerun the tests. Please let me know. >> >> >> Thank you, >> Misha >> >> >> On 2/13/18, 8:41 PM, Igor Ignatyev wrote: >>> Hi Misha, >>> >>> have you check that it works on windows w/ GENERATE_CDS_ARCHIVE=true? it seems that you should called GETMIXEDPATH in CDS_VM_ARGS: >>>> CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=$(CDS_ARCHIVE_FILE) >>> vs >>>> CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=$(shell $(GETMIXEDPATH) "$(CDS_ARCHIVE_FILE)") >>> otherwise, tests won't be able to find cds archive during test execution. >>> >>> -- Igor >>> >>>> On Feb 13, 2018, at 8:17 PM, Mikhailo Seledtsov wrote: >>>> >>>> Please review this small change that enables execution of any jtreg test(s) in CDS mode >>>> via make. Please see bug description for details. >>>> >>>> Thanks to Erik and Igor for their help with this change. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8197906 >>>> WebRev: http://cr.openjdk.java.net/~mseledtsov/8197906.01/ >>>> >>>> Testing: >>>> - ran hotspot_runtime in CDS mode with this change - Linux-x64 - no new failures >>>> - running several test sets in CDS mode via distributed test system - pass >>>> - running pre-integration sanity testing (HS tier1, tier2) - in progress >>>> >>>> Thank you, >>>> Misha >>>> From tim.bell at oracle.com Thu Feb 15 17:55:38 2018 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 15 Feb 2018 09:55:38 -0800 Subject: RFR: JDK-8198227 Fix COMPARE_BUILD after forest consolidation In-Reply-To: <74059e0f-564a-6d70-c349-302d381a2b1d@oracle.com> References: <5ed92142-8540-c0ef-acbe-bd73468eec23@oracle.com> <74059e0f-564a-6d70-c349-302d381a2b1d@oracle.com> Message-ID: <5A85C99A.6040004@oracle.com> Magnus: Looks good to me as well. Tim On 02/15/18 07:40, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2018-02-15 06:14, Magnus Ihse Bursie wrote: >> The new repo structure with the forest consolidation broke the >> COMPARE_BUILD functionality when using a closed repo. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198227 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8198227-fix-COMPARE_BUILD-in-CLOSED_ROOT/webrev.01 >> >> > From ted at tedneward.com Thu Feb 15 19:20:21 2018 From: ted at tedneward.com (Ted Neward) Date: Thu, 15 Feb 2018 11:20:21 -0800 Subject: JDK10 build problem: "--module-path"? In-Reply-To: References: <50f4068f-6aa9-44bd-3858-5e5e2fa02737@oracle.com> <85DE1A73-B78C-4E4F-A852-350B57256B75@tedneward.com> <3cb9e208-1e7a-fdef-9142-04d5f77b82c0@oracle.com> <7109126a-158d-b3a9-5bb1-d4bc6568f8f7@oracle.com> Message-ID: So? Hmm. Anybody here know what the blessed way to get OpenJDK9 into a Docker image would be, then? Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 From: Martin Buchholz Date: Thursday, February 15, 2018 at 8:50 AM To: Erik Joelsson Cc: Alan Bateman , Ted Neward , Jonathan Gibbons , "build-dev at openjdk.java.net" Subject: Re: JDK10 build problem: "--module-path"? Looking at https://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=openjdk-9-jdk&searchon=names it seems like Ubuntu ships whatever openjdk-9 is available at time of creation of a specific version, and doesn't update it afterwards, not even for the quarterly security patches. On Thu, Feb 15, 2018 at 7:42 AM, Erik Joelsson wrote: I have hit this same problem once for the same reason Alan describes. Ubuntu provided me with a really old EA build of 9. /Erik On 2018-02-15 00:05, Alan Bateman wrote: On 15/02/2018 06:32, Ted Neward wrote: Really?!? I thought the javac -help only listed -modulepath. Not to disbelieve you *grin*, but are you sure? The reason I ask is (barring some really bizarre misconfiguration) I should be using the OpenJDK9 as the boot JDK for this, and I'm getting the error. What is your boot JDK? Any possibility that you have really old EA build of JDK 9? From ted at tedneward.com Thu Feb 15 20:30:36 2018 From: ted at tedneward.com (Ted Neward) Date: Thu, 15 Feb 2018 12:30:36 -0800 Subject: JDK10 build problem: "--module-path"? In-Reply-To: <15a6e924-a114-c1d4-1de3-37ce123ec14e@oracle.com> References: <50f4068f-6aa9-44bd-3858-5e5e2fa02737@oracle.com> <85DE1A73-B78C-4E4F-A852-350B57256B75@tedneward.com> <15a6e924-a114-c1d4-1de3-37ce123ec14e@oracle.com> Message-ID: <629FEC49-A438-48D3-831E-992A32152334@tedneward.com> The temptation to do a ?Well, actually?? here is strong. ;-) Seriously, thanks for taking my incredulity in the spirit it was intended. :-) Is it becoming more common for Java tools to accept different ?styles? of arguments, or did this become a complete switch/rename? (You can tell how much I?ve used modules recently, right?) Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 From: Jonathan Gibbons Date: Thursday, February 15, 2018 at 7:27 AM To: Ted Neward , Subject: Re: JDK10 build problem: "--module-path"? Ted, Yes, I'm sure :-) This is the relevant line from the source code for JDK 9, listing --module-path and -p as alternatives for this option. ??? MODULE_PATH("--module-path -p", "opt.arg.path", "opt.modulepath", STANDARD, FILEMANAGER), http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/65bfdabaab9c/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java#l183 -- Jon On 2/14/18 10:32 PM, Ted Neward wrote: Really?!? I thought the javac -help only listed -modulepath. Not to disbelieve you *grin*, but are you sure? The reason I ask is (barring some really bizarre misconfiguration) I should be using the OpenJDK9 as the boot JDK for this, and I'm getting the error. Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 ?On 2/14/18, 6:53 PM, "build-dev on behalf of Jonathan Gibbons" wrote: ??? ???? ????On 2/14/18 4:38 PM, Ted Neward wrote: ??? > I?m getting a weird error in my OpenJDK 10 (tip) build, where after pulling source and configure, I get a build error about the Java compiler being executed with ?--module-path? as a parameter, which obviously isn?t a legitimate javac flag. ???> ??? >?? ????I can't speak to your specific build error, but --module-path is a ????legitimate javac option, as of JDK 9. ??? ????-- Jon ??? ????> ??? > Is this just me? Is anybody else able to repro this, and is there a fix coming that isn?t checked into the main trunk yet? ??? > ??? >?? ????> ??? > I am in the process of finalizing some Docker images (both with the source inside the image and built, so people can just ?go?, as well as images with the prereqs and some shell scripts to do the build with the source and build artifacts on the host machine), and this is holding up the current ?tip? images from being really ready for public consumption. (JDK8u and JDK9 are up and ready to go.) ??? > ??? >?? ????> ??? > Ted Neward ??? > ??? > Author, Speaker, Mentor ??? > ??? > http://www.newardassociates.com ??? > ??? > t: @tedneward | m: (425) 647-4526 ??? > ?? ? ???? From erik.joelsson at oracle.com Fri Feb 16 19:19:06 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 16 Feb 2018 11:19:06 -0800 Subject: Proposal: make/Main.gmk Add extra extension/override points to the make file In-Reply-To: References: Message-ID: <5080819e-7066-2e50-0743-3ae26a022585@oracle.com> Hello, I would rename the JVM_VARIANT_TARGETS to JVM_MAIN_LIB_TARGETS. The purpose of this target is to be the minimal amount of prerequisites before we can start linking to -ljvm. I would also move the definition of that variable down to its first use, like the other variables. I'm not clear on the difference between JVM_BUILD_TARGETS and JVM_MAIN_TARGETS. They should probably be merged. The docs targets comment needs a newline before it. Otherwise this looks ok. /Erik On 2018-02-14 07:01, Steve Groeger wrote: > diff -r b2f2bdba0472 make/Main.gmk > --- a/make/Main.gmkFri Jan 26 11:27:53 2018 -0800 > +++ b/make/Main.gmkWed Feb 14 14:37:15 2018 +0000 > @@ -56,6 +56,9 @@ > ?# All modules for the current target platform. > ?ALL_MODULES := $(call FindAllModules) > +# If not already set, set the JVM variant target so that the JVM will > be built. > +JVM_VARIANT_TARGETS ?= hotspot-$(JVM_VARIANT_MAIN)-libs > + > ?################################################################################ > ?################################################################################ > ?# > @@ -645,7 +648,7 @@ > ? ?generate-exported-symbols: java.base-libs jdk.jdwp.agent-libs > ? ?# Building one JVM variant is enough to start building the other libs > - ?$(LIBS_TARGETS): hotspot-$(JVM_VARIANT_MAIN)-libs > + ?$(LIBS_TARGETS): $(JVM_VARIANT_TARGETS) > ? ?$(LAUNCHER_TARGETS): java.base-libs > @@ -722,8 +725,11 @@ > ? ? ?java.base-jmod: jrtfs-jar $(filter-out java.base-jmod, > $(JMOD_TARGETS)) > ? ?endif > - ?# Building java.base-jmod requires all of hotspot to be built. > - ?java.base-jmod: hotspot > + ?# If not already set, set the JVM target so that the JVM will be built. > + ?JVM_MAIN_TARGETS ?= hotspot > + > + ?# Building java.base-jmod requires all of VM (ie hotspot) to be built. > + ?java.base-jmod: $(JVM_MAIN_TARGETS) > ? ?# Declare dependencies from -jmod to all other module targets > ? ?# When creating a BUILDJDK, the java compilation has already been > done by the > @@ -749,7 +755,7 @@ > ? ?# in java.base-copy) and tzdb.dat (done in java.base-gendata) to the > ? ?# appropriate location otherwise jimage, jlink and jmod won't > start. This > ? ?# also applies when creating the buildjdk. > - ?DEFAULT_JMOD_DEPS := java.base-libs java.base-copy java.base-gendata \ > + ?DEFAULT_JMOD_DEPS += java.base-libs java.base-copy java.base-gendata \ > ? ? ? ?jdk.jlink-launchers > ? ?# When cross compiling and buildjdk is to be created, depend on > creating the > ? ?# buildjdk instead of the default dependencies. > @@ -824,9 +830,11 @@ > ? ?docs-javase-api-modulegraph: exploded-image buildtools-modules > ? ?docs-reference-api-modulegraph: exploded-image buildtools-modules > - > + ?# If not already set, then set the JVM specific docs targets > + ?JVM_DOCS_TARGETS ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc > + > ? ?# The gensrc steps for hotspot and jdk.jdi create html spec files. > - ?docs-jdk-specs: hotspot-$(JVM_VARIANT_MAIN)-gensrc jdk.jdi-gensrc \ > + ?docs-jdk-specs: $(JVM_DOCS_TARGETS) jdk.jdi-gensrc \ > ? ? ? ?docs-jdk-index > ? ?docs-jdk-index: exploded-image buildtools-modules > @@ -893,8 +901,10 @@ > ?################################################################################ > ?# Virtual targets without recipes > +# If not already set, set the JVM specific tools targets > +JVM_TOOLS_TARGETS ?= buildtools-hotspot > ?buildtools: buildtools-langtools interim-langtools interim-rmic \ > - ? ?buildtools-jdk buildtools-hotspot > + ? ?buildtools-jdk $(JVM_TOOLS_TARGETS) > ?hotspot: $(HOTSPOT_VARIANT_TARGETS) hotspot-jsig > @@ -936,8 +946,11 @@ > ?$(foreach m, $(LAUNCHER_MODULES), $(eval $m: $m-launchers)) > ?$(foreach m, $(ALL_COPY_MODULES), $(eval $m: $m-copy)) > +# If not already set, set the JVM specific build targets > +JVM_BUILD_TARGETS ?= hotspot > + > ?# Building java.base includes building all of hotspot. > -java.base: hotspot > +java.base: $(JVM_BUILD_TARGETS) > ?demos: demos-jdk > @@ -1004,10 +1017,15 @@ > ?# This target builds the documentation image > ?docs-image: docs-jdk > +# If not already set, set the JVM specific targets to built the test > image > +JVM_TEST_IMAGE_TARGETS ?= test-image-hotspot-jtreg-native > test-image-hotspot-gtest > + > ?# This target builds the test image > -test-image: prepare-test-image test-image-hotspot-jtreg-native \ > - ? ?test-image-jdk-jtreg-native test-image-failure-handler > test-image-hotspot-gtest \ > - ? ?test-image-demos-jdk > +test-image: prepare-test-image \ > + ? ?test-image-jdk-jtreg-native test-image-failure-handler \ > + ? ?test-image-demos-jdk $(JVM_TEST_IMAGE_TARGETS) > + > +################################################################################ > ?# all-images builds all our deliverables as images. > ?all-images: product-images test-image docs-image > @@ -1146,7 +1164,10 @@ > ? ? ?$(MAKESUPPORT_OUTPUTDIR)/main-targets.gmk > ?################################################################################ > +# Hook to include the corresponding custom file, if present. > +$(eval $(call IncludeCustomExtension, Main-post.gmk)) > ?.PHONY: $(ALL_TARGETS) > ?FRC: # Force target > + From erik.joelsson at oracle.com Fri Feb 16 19:22:35 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 16 Feb 2018 11:22:35 -0800 Subject: [PATCH] Add post custom extension hooks to two launchers In-Reply-To: References: Message-ID: <32a4fb1a-1fcf-e122-7326-eb0aeae58b07@oracle.com> This looks ok. I can sponsor it. /Erik On 2018-02-15 03:32, Ben Walsh wrote: > This patch simply adds a hook to two launchers to call a post custom > extension > if it is available. > > I would like to pair with a sponsor to contribute this patch ... > > ------------------------------------------------------------------------------------ > > diff -r 85c27aabf312 make/launcher/Launcher-jdk.jcmd.gmk > --- a/make/launcher/Launcher-jdk.jcmd.gmk Thu Feb 08 10:06:57 2018 > -0500 > +++ b/make/launcher/Launcher-jdk.jcmd.gmk Thu Feb 15 11:16:28 2018 > +0000 > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights > reserved. > +# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > @@ -60,3 +60,6 @@ > $(eval $(call SetupBuildLauncher, jcmd, \ > MAIN_CLASS := sun.tools.jcmd.JCmd, \ > )) > + > +# Hook to include the corresponding custom file, if present. > +$(eval $(call IncludeCustomExtension, > launcher/Launcher-jdk.jcmd-post.gmk)) > diff -r 85c27aabf312 make/launcher/Launcher-jdk.jstatd.gmk > --- a/make/launcher/Launcher-jdk.jstatd.gmk Thu Feb 08 10:06:57 2018 > -0500 > +++ b/make/launcher/Launcher-jdk.jstatd.gmk Thu Feb 15 11:16:28 2018 > +0000 > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights > reserved. > +# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > @@ -28,3 +28,6 @@ > $(eval $(call SetupBuildLauncher, jstatd, \ > MAIN_CLASS := sun.tools.jstatd.Jstatd, \ > )) > + > +# Hook to include the corresponding custom file, if present. > +$(eval $(call IncludeCustomExtension, > launcher/Launcher-jdk.jstatd-post.gmk)) > > ------------------------------------------------------------------------------------ > > Regards, > Ben Walsh > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From philip.race at oracle.com Fri Feb 16 23:04:45 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 16 Feb 2018 15:04:45 -0800 Subject: RFR: 8194870: Some regression tests throw NPE exception on a specific Solaris 11.2 sun4v sparc machine Message-ID: <5d0a8a1c-2ba0-becf-49c0-3e5532073a0e@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8194870 diff inline below : It seems to be sufficient to make this change. If there is some Sun Studio / linker args needed to ensure the undefined symbols are allowed they are apparently already present .. Details in the bug report. And as noted there I have left the AIX line alone. diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -691,7 +691,7 @@ LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \ LIBS_linux := -lc, \ - LIBS_solaris := -lawt_headless -lc, \ + LIBS_solaris := -lc, \ LIBS_aix := -lawt_headless,\ LIBS_windows := $(WIN_JAVA_LIB) advapi32.lib user32.lib gdi32.lib \ $(WIN_AWT_LIB), \ -phil. From magnus.ihse.bursie at oracle.com Fri Feb 16 23:19:57 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 17 Feb 2018 00:19:57 +0100 Subject: RFR: 8194870: Some regression tests throw NPE exception on a specific Solaris 11.2 sun4v sparc machine In-Reply-To: <5d0a8a1c-2ba0-becf-49c0-3e5532073a0e@oracle.com> References: <5d0a8a1c-2ba0-becf-49c0-3e5532073a0e@oracle.com> Message-ID: <469768d9-a34d-30a8-5332-d4be4c6864f2@oracle.com> On 2018-02-17 00:04, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8194870 > diff inline below : > It seems to be sufficient to make this change. > If there is some? Sun Studio / linker args needed to ensure the > undefined symbols > are allowed they are apparently already present .. > > Details in the bug report. And as noted there I have left the AIX line > alone. > > diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk > +++ b/make/lib/Awt2dLibraries.gmk > @@ -691,7 +691,7 @@ > ???? LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ > ???? LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \ > ???? LIBS_linux := -lc, \ > -??? LIBS_solaris := -lawt_headless -lc, \ > +??? LIBS_solaris := -lc, \ > ???? LIBS_aix := -lawt_headless,\ > ???? LIBS_windows := $(WIN_JAVA_LIB) advapi32.lib user32.lib gdi32.lib \ > ???????? $(WIN_AWT_LIB), \ Looks good to me. But the inter-relationship between the awt libraries is really messy. :-( I think it would be worth the effort to try and pry them apart more cleanly. /Magnus > > -phil. From magnus.ihse.bursie at oracle.com Fri Feb 16 23:01:47 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 17 Feb 2018 00:01:47 +0100 Subject: RFR: JDK-8198318 Make build comparisons clean again Message-ID: Over time, small differences has accumulated in the build that makes it non-reproducible. This patch addresses some of these, and modifies compare.sh to properly handles those that cannot be fixed. This patch is mainly due to Erik, who wrote most of it. I've mostly finished it up. Bug: https://bugs.openjdk.java.net/browse/JDK-8198318 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8198318-make-build-comparisons-clean-again/webrev.01 /Magnus From tim.bell at oracle.com Fri Feb 16 23:34:03 2018 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 16 Feb 2018 15:34:03 -0800 Subject: RFR: JDK-8198318 Make build comparisons clean again In-Reply-To: References: Message-ID: <5A876A6B.1090700@oracle.com> Magnus: > Over time, small differences has accumulated in the build that makes it > non-reproducible. This patch addresses some of these, and modifies > compare.sh to properly handles those that cannot be fixed. > > This patch is mainly due to Erik, who wrote most of it. I've mostly > finished it up. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198318 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198318-make-build-comparisons-clean-again/webrev.01 One typo: make/common/MakeBase.gmk 548 # Work around a weirdness with cp on Macosx. When coying a symlink, if Should be 'when copying'. No need to respin the webrev. Looks good otherwise. /Tim From erik.joelsson at oracle.com Fri Feb 16 23:47:19 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 16 Feb 2018 15:47:19 -0800 Subject: RFR: JDK-8198318 Make build comparisons clean again In-Reply-To: References: Message-ID: <0aaae8a7-095d-d65f-1489-cb0b0e8c0b56@oracle.com> Looks good except for my typo that Tim pointed out. I didn't know that I was so close to done. :) /Erik On 2018-02-16 15:01, Magnus Ihse Bursie wrote: > Over time, small differences has accumulated in the build that makes > it non-reproducible. This patch addresses some of these, and modifies > compare.sh to properly handles those that cannot be fixed. > > This patch is mainly due to Erik, who wrote most of it. I've mostly > finished it up. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198318 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198318-make-build-comparisons-clean-again/webrev.01 > > /Magnus From erik.joelsson at oracle.com Sat Feb 17 01:56:53 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 16 Feb 2018 17:56:53 -0800 Subject: RFR: JDK-8198328: Create devkit for Solaris with developer studio 12.6 and Solaris11.3 Message-ID: <011e1414-37ab-76d5-e9a4-2738df91edf8@oracle.com> We need a new devkit for Solaris based on Developer Studio 12.6 and with Solaris 11.3 as sysroot. This patch adds the script used to generate the kit. Bug: https://bugs.openjdk.java.net/browse/JDK-8198328 Webrev: http://cr.openjdk.java.net/~erikj/8198328/webrev.01/ /Erik From magnus.ihse.bursie at oracle.com Sun Feb 18 23:39:00 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 19 Feb 2018 00:39:00 +0100 Subject: RFR: JDK-8198328: Create devkit for Solaris with developer studio 12.6 and Solaris11.3 In-Reply-To: <011e1414-37ab-76d5-e9a4-2738df91edf8@oracle.com> References: <011e1414-37ab-76d5-e9a4-2738df91edf8@oracle.com> Message-ID: <80FC357A-F039-461D-A967-0BEE299E7B8E@oracle.com> Looks good to me. /Magnus > 17 feb. 2018 kl. 02:56 skrev Erik Joelsson : > > We need a new devkit for Solaris based on Developer Studio 12.6 and with Solaris 11.3 as sysroot. This patch adds the script used to generate the kit. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198328 > > Webrev: http://cr.openjdk.java.net/~erikj/8198328/webrev.01/ > > /Erik > From GROEGES at uk.ibm.com Mon Feb 19 12:39:09 2018 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Mon, 19 Feb 2018 12:39:09 +0000 Subject: Proposal: make/Main.gmk Add extra extension/override points to the make file In-Reply-To: <5080819e-7066-2e50-0743-3ae26a022585@oracle.com> References: <5080819e-7066-2e50-0743-3ae26a022585@oracle.com>, Message-ID: Hi Erik, Have made the changes you requested, so all should now be OK to contribute. Please let me know if there is anything else you need me to do in order to get this contributed. Here is the latest diff: diff -r b2f2bdba0472 make/Main.gmk --- a/make/Main.gmk Fri Jan 26 11:27:53 2018 -0800 +++ b/make/Main.gmk Mon Feb 19 12:31:55 2018 +0000 @@ -644,8 +644,11 @@ generate-exported-symbols: java.base-libs jdk.jdwp.agent-libs + # If not already set, set the JVM variant target so that the JVM will be built. + JVM_MAIN_LIB_TARGETS ?= hotspot-$(JVM_VARIANT_MAIN)-libs + # Building one JVM variant is enough to start building the other libs - $(LIBS_TARGETS): hotspot-$(JVM_VARIANT_MAIN)-libs + $(LIBS_TARGETS): $(JVM_MAIN_LIB_TARGETS) $(LAUNCHER_TARGETS): java.base-libs @@ -722,8 +725,11 @@ java.base-jmod: jrtfs-jar $(filter-out java.base-jmod, $(JMOD_TARGETS)) endif - # Building java.base-jmod requires all of hotspot to be built. - java.base-jmod: hotspot + # If not already set, set the JVM target so that the JVM will be built. + JVM_MAIN_TARGETS ?= hotspot + + # Building java.base-jmod requires all of VM (ie hotspot) to be built. + java.base-jmod: $(JVM_MAIN_TARGETS) # Declare dependencies from -jmod to all other module targets # When creating a BUILDJDK, the java compilation has already been done by the @@ -749,7 +755,7 @@ # in java.base-copy) and tzdb.dat (done in java.base-gendata) to the # appropriate location otherwise jimage, jlink and jmod won't start. This # also applies when creating the buildjdk. - DEFAULT_JMOD_DEPS := java.base-libs java.base-copy java.base-gendata \ + DEFAULT_JMOD_DEPS += java.base-libs java.base-copy java.base-gendata \ jdk.jlink-launchers # When cross compiling and buildjdk is to be created, depend on creating the # buildjdk instead of the default dependencies. @@ -824,9 +830,11 @@ docs-javase-api-modulegraph: exploded-image buildtools-modules docs-reference-api-modulegraph: exploded-image buildtools-modules - + # If not already set, then set the JVM specific docs targets + JVM_DOCS_TARGETS ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc + # The gensrc steps for hotspot and jdk.jdi create html spec files. - docs-jdk-specs: hotspot-$(JVM_VARIANT_MAIN)-gensrc jdk.jdi-gensrc \ + docs-jdk-specs: $(JVM_DOCS_TARGETS) jdk.jdi-gensrc \ docs-jdk-index docs-jdk-index: exploded-image buildtools-modules @@ -893,8 +901,10 @@ ################################################################################ # Virtual targets without recipes +# If not already set, set the JVM specific tools targets +JVM_TOOLS_TARGETS ?= buildtools-hotspot buildtools: buildtools-langtools interim-langtools interim-rmic \ - buildtools-jdk buildtools-hotspot + buildtools-jdk $(JVM_TOOLS_TARGETS) hotspot: $(HOTSPOT_VARIANT_TARGETS) hotspot-jsig @@ -937,7 +947,7 @@ $(foreach m, $(ALL_COPY_MODULES), $(eval $m: $m-copy)) # Building java.base includes building all of hotspot. -java.base: hotspot +java.base: $(JVM_MAIN_TARGETS) demos: demos-jdk @@ -1004,10 +1014,15 @@ # This target builds the documentation image docs-image: docs-jdk +# If not already set, set the JVM specific targets to built the test image +JVM_TEST_IMAGE_TARGETS ?= test-image-hotspot-jtreg-native test-image-hotspot-gtest + # This target builds the test image -test-image: prepare-test-image test-image-hotspot-jtreg-native \ - test-image-jdk-jtreg-native test-image-failure-handler test-image-hotspot-gtest \ - test-image-demos-jdk +test-image: prepare-test-image \ + test-image-jdk-jtreg-native test-image-failure-handler \ + test-image-demos-jdk $(JVM_TEST_IMAGE_TARGETS) + +################################################################################ # all-images builds all our deliverables as images. all-images: product-images test-image docs-image @@ -1146,7 +1161,10 @@ $(MAKESUPPORT_OUTPUTDIR)/main-targets.gmk ################################################################################ +# Hook to include the corresponding custom file, if present. +$(eval $(call IncludeCustomExtension, Main-post.gmk)) .PHONY: $(ALL_TARGETS) FRC: # Force target + Thanks Steve Groeger Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -----Erik Joelsson wrote: ----- To: Steve Groeger , build-dev at openjdk.java.net From: Erik Joelsson Date: 02/16/2018 19:19 Subject: Re: Proposal: make/Main.gmk Add extra extension/override points to the make file Hello, I would rename the JVM_VARIANT_TARGETS to JVM_MAIN_LIB_TARGETS. The purpose of this target is to be the minimal amount of prerequisites before we can start linking to -ljvm. I would also move the definition of that variable down to its first use, like the other variables. I'm not clear on the difference between JVM_BUILD_TARGETS and JVM_MAIN_TARGETS. They should probably be merged. The docs targets comment needs a newline before it. Otherwise this looks ok. /Erik On 2018-02-14 07:01, Steve Groeger wrote: diff -r b2f2bdba0472 make/Main.gmk --- a/make/Main.gmk Fri Jan 26 11:27:53 2018 -0800 +++ b/make/Main.gmk Wed Feb 14 14:37:15 2018 +0000 @@ -56,6 +56,9 @@ # All modules for the current target platform. ALL_MODULES := $(call FindAllModules) +# If not already set, set the JVM variant target so that the JVM will be built. +JVM_VARIANT_TARGETS ?= hotspot-$(JVM_VARIANT_MAIN)-libs + ################################################################################ ################################################################################ # @@ -645,7 +648,7 @@ generate-exported-symbols: java.base-libs jdk.jdwp.agent-libs # Building one JVM variant is enough to start building the other libs - $(LIBS_TARGETS): hotspot-$(JVM_VARIANT_MAIN)-libs + $(LIBS_TARGETS): $(JVM_VARIANT_TARGETS) $(LAUNCHER_TARGETS): java.base-libs @@ -722,8 +725,11 @@ java.base-jmod: jrtfs-jar $(filter-out java.base-jmod, $(JMOD_TARGETS)) endif - # Building java.base-jmod requires all of hotspot to be built. - java.base-jmod: hotspot + # If not already set, set the JVM target so that the JVM will be built. + JVM_MAIN_TARGETS ?= hotspot + + # Building java.base-jmod requires all of VM (ie hotspot) to be built. + java.base-jmod: $(JVM_MAIN_TARGETS) # Declare dependencies from -jmod to all other module targets # When creating a BUILDJDK, the java compilation has already been done by the @@ -749,7 +755,7 @@ # in java.base-copy) and tzdb.dat (done in java.base-gendata) to the # appropriate location otherwise jimage, jlink and jmod won't start. This # also applies when creating the buildjdk. - DEFAULT_JMOD_DEPS := java.base-libs java.base-copy java.base-gendata \ + DEFAULT_JMOD_DEPS += java.base-libs java.base-copy java.base-gendata \ jdk.jlink-launchers # When cross compiling and buildjdk is to be created, depend on creating the # buildjdk instead of the default dependencies. @@ -824,9 +830,11 @@ docs-javase-api-modulegraph: exploded-image buildtools-modules docs-reference-api-modulegraph: exploded-image buildtools-modules - + # If not already set, then set the JVM specific docs targets + JVM_DOCS_TARGETS ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc + # The gensrc steps for hotspot and jdk.jdi create html spec files. - docs-jdk-specs: hotspot-$(JVM_VARIANT_MAIN)-gensrc jdk.jdi-gensrc \ + docs-jdk-specs: $(JVM_DOCS_TARGETS) jdk.jdi-gensrc \ docs-jdk-index docs-jdk-index: exploded-image buildtools-modules @@ -893,8 +901,10 @@ ################################################################################ # Virtual targets without recipes +# If not already set, set the JVM specific tools targets +JVM_TOOLS_TARGETS ?= buildtools-hotspot buildtools: buildtools-langtools interim-langtools interim-rmic \ - buildtools-jdk buildtools-hotspot + buildtools-jdk $(JVM_TOOLS_TARGETS) hotspot: $(HOTSPOT_VARIANT_TARGETS) hotspot-jsig @@ -936,8 +946,11 @@ $(foreach m, $(LAUNCHER_MODULES), $(eval $m: $m-launchers)) $(foreach m, $(ALL_COPY_MODULES), $(eval $m: $m-copy)) +# If not already set, set the JVM specific build targets +JVM_BUILD_TARGETS ?= hotspot + # Building java.base includes building all of hotspot. -java.base: hotspot +java.base: $(JVM_BUILD_TARGETS) demos: demos-jdk @@ -1004,10 +1017,15 @@ # This target builds the documentation image docs-image: docs-jdk +# If not already set, set the JVM specific targets to built the test image +JVM_TEST_IMAGE_TARGETS ?= test-image-hotspot-jtreg-native test-image-hotspot-gtest + # This target builds the test image -test-image: prepare-test-image test-image-hotspot-jtreg-native \ - test-image-jdk-jtreg-native test-image-failure-handler test-image-hotspot-gtest \ - test-image-demos-jdk +test-image: prepare-test-image \ + test-image-jdk-jtreg-native test-image-failure-handler \ + test-image-demos-jdk $(JVM_TEST_IMAGE_TARGETS) + +################################################################################ # all-images builds all our deliverables as images. all-images: product-images test-image docs-image @@ -1146,7 +1164,10 @@ $(MAKESUPPORT_OUTPUTDIR)/main-targets.gmk ################################################################################ +# Hook to include the corresponding custom file, if present. +$(eval $(call IncludeCustomExtension, Main-post.gmk)) .PHONY: $(ALL_TARGETS) FRC: # Force target + Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From erik.joelsson at oracle.com Tue Feb 20 15:01:59 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 20 Feb 2018 07:01:59 -0800 Subject: Proposal: make/Main.gmk Add extra extension/override points to the make file In-Reply-To: References: <5080819e-7066-2e50-0743-3ae26a022585@oracle.com> Message-ID: <1d540921-6229-fc25-b403-1677e5dbf603@oracle.com> This looks ok, I will push it. https://bugs.openjdk.java.net/browse/JDK-8198425 /Erik On 2018-02-19 04:39, Steve Groeger wrote: > diff -r b2f2bdba0472 make/Main.gmk > --- a/make/Main.gmkFri Jan 26 11:27:53 2018 -0800 > +++ b/make/Main.gmkMon Feb 19 12:31:55 2018 +0000 > @@ -644,8 +644,11 @@ > ? ?generate-exported-symbols: java.base-libs jdk.jdwp.agent-libs > + ?# If not already set, set the JVM variant target so that the JVM > will be built. > + ?JVM_MAIN_LIB_TARGETS ?= hotspot-$(JVM_VARIANT_MAIN)-libs > + > ? ?# Building one JVM variant is enough to start building the other libs > - ?$(LIBS_TARGETS): hotspot-$(JVM_VARIANT_MAIN)-libs > + ?$(LIBS_TARGETS): $(JVM_MAIN_LIB_TARGETS) > ? ?$(LAUNCHER_TARGETS): java.base-libs > @@ -722,8 +725,11 @@ > ? ? ?java.base-jmod: jrtfs-jar $(filter-out java.base-jmod, > $(JMOD_TARGETS)) > ? ?endif > - ?# Building java.base-jmod requires all of hotspot to be built. > - ?java.base-jmod: hotspot > + ?# If not already set, set the JVM target so that the JVM will be built. > + ?JVM_MAIN_TARGETS ?= hotspot > + > + ?# Building java.base-jmod requires all of VM (ie hotspot) to be built. > + ?java.base-jmod: $(JVM_MAIN_TARGETS) > ? ?# Declare dependencies from -jmod to all other module targets > ? ?# When creating a BUILDJDK, the java compilation has already been > done by the > @@ -749,7 +755,7 @@ > ? ?# in java.base-copy) and tzdb.dat (done in java.base-gendata) to the > ? ?# appropriate location otherwise jimage, jlink and jmod won't > start. This > ? ?# also applies when creating the buildjdk. > - ?DEFAULT_JMOD_DEPS := java.base-libs java.base-copy java.base-gendata \ > + ?DEFAULT_JMOD_DEPS += java.base-libs java.base-copy java.base-gendata \ > ? ? ? ?jdk.jlink-launchers > ? ?# When cross compiling and buildjdk is to be created, depend on > creating the > ? ?# buildjdk instead of the default dependencies. > @@ -824,9 +830,11 @@ > ? ?docs-javase-api-modulegraph: exploded-image buildtools-modules > ? ?docs-reference-api-modulegraph: exploded-image buildtools-modules > - > + ?# If not already set, then set the JVM specific docs targets > + ?JVM_DOCS_TARGETS ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc > + > ? ?# The gensrc steps for hotspot and jdk.jdi create html spec files. > - ?docs-jdk-specs: hotspot-$(JVM_VARIANT_MAIN)-gensrc jdk.jdi-gensrc \ > + ?docs-jdk-specs: $(JVM_DOCS_TARGETS) jdk.jdi-gensrc \ > ? ? ? ?docs-jdk-index > ? ?docs-jdk-index: exploded-image buildtools-modules > @@ -893,8 +901,10 @@ > ?################################################################################ > ?# Virtual targets without recipes > +# If not already set, set the JVM specific tools targets > +JVM_TOOLS_TARGETS ?= buildtools-hotspot > ?buildtools: buildtools-langtools interim-langtools interim-rmic \ > - ? ?buildtools-jdk buildtools-hotspot > + ? ?buildtools-jdk $(JVM_TOOLS_TARGETS) > ?hotspot: $(HOTSPOT_VARIANT_TARGETS) hotspot-jsig > @@ -937,7 +947,7 @@ > ?$(foreach m, $(ALL_COPY_MODULES), $(eval $m: $m-copy)) > ?# Building java.base includes building all of hotspot. > -java.base: hotspot > +java.base: $(JVM_MAIN_TARGETS) > ?demos: demos-jdk > @@ -1004,10 +1014,15 @@ > ?# This target builds the documentation image > ?docs-image: docs-jdk > +# If not already set, set the JVM specific targets to built the test > image > +JVM_TEST_IMAGE_TARGETS ?= test-image-hotspot-jtreg-native > test-image-hotspot-gtest > + > ?# This target builds the test image > -test-image: prepare-test-image test-image-hotspot-jtreg-native \ > - ? ?test-image-jdk-jtreg-native test-image-failure-handler > test-image-hotspot-gtest \ > - ? ?test-image-demos-jdk > +test-image: prepare-test-image \ > + ? ?test-image-jdk-jtreg-native test-image-failure-handler \ > + ? ?test-image-demos-jdk $(JVM_TEST_IMAGE_TARGETS) > + > +################################################################################ > ?# all-images builds all our deliverables as images. > ?all-images: product-images test-image docs-image > @@ -1146,7 +1161,10 @@ > ? ? ?$(MAKESUPPORT_OUTPUTDIR)/main-targets.gmk > ?################################################################################ > +# Hook to include the corresponding custom file, if present. > +$(eval $(call IncludeCustomExtension, Main-post.gmk)) > ?.PHONY: $(ALL_TARGETS) > ?FRC: # Force target From erik.joelsson at oracle.com Tue Feb 20 15:40:20 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 20 Feb 2018 07:40:20 -0800 Subject: RFR: 8194870: Some regression tests throw NPE exception on a specific Solaris 11.2 sun4v sparc machine In-Reply-To: <5d0a8a1c-2ba0-becf-49c0-3e5532073a0e@oracle.com> References: <5d0a8a1c-2ba0-becf-49c0-3e5532073a0e@oracle.com> Message-ID: <0a6e2781-4a17-5ab2-f1ba-1ce0be6c6501@oracle.com> Looks good to me. /Erik On 2018-02-16 15:04, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8194870 > diff inline below : > It seems to be sufficient to make this change. > If there is some? Sun Studio / linker args needed to ensure the > undefined symbols > are allowed they are apparently already present .. > > Details in the bug report. And as noted there I have left the AIX line > alone. > > diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk > +++ b/make/lib/Awt2dLibraries.gmk > @@ -691,7 +691,7 @@ > ???? LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ > ???? LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \ > ???? LIBS_linux := -lc, \ > -??? LIBS_solaris := -lawt_headless -lc, \ > +??? LIBS_solaris := -lc, \ > ???? LIBS_aix := -lawt_headless,\ > ???? LIBS_windows := $(WIN_JAVA_LIB) advapi32.lib user32.lib gdi32.lib \ > ???????? $(WIN_AWT_LIB), \ > > -phil. From tim.bell at oracle.com Tue Feb 20 16:00:13 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 20 Feb 2018 08:00:13 -0800 Subject: RFR: JDK-8198328: Create devkit for Solaris with developer studio 12.6 and Solaris11.3 In-Reply-To: <80FC357A-F039-461D-A967-0BEE299E7B8E@oracle.com> References: <011e1414-37ab-76d5-e9a4-2738df91edf8@oracle.com> <80FC357A-F039-461D-A967-0BEE299E7B8E@oracle.com> Message-ID: <5A8C460D.8040200@oracle.com> Erik: Looks good to me as well. Tim On 02/18/18 15:39, Magnus Ihse Bursie wrote: > Looks good to me. > > /Magnus > >> 17 feb. 2018 kl. 02:56 skrev Erik Joelsson : >> >> We need a new devkit for Solaris based on Developer Studio 12.6 and with Solaris 11.3 as sysroot. This patch adds the script used to generate the kit. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198328 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8198328/webrev.01/ >> >> /Erik >> > From erik.joelsson at oracle.com Tue Feb 20 18:05:36 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 20 Feb 2018 10:05:36 -0800 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files Message-ID: Hello, This patch adds a build time check for uses of global operators new and delete in hotspot C++ code. The check is only run with toolchains GCC and Clang (Linux and Macos builds). I have also modified the Oracle devkit on Linux to add the necessary symlink so that objdump will get picked up by configure. This change is depending on several fixes removing such uses that are currently in jdk/hs so this change will need to be pushed there as well. Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ /Erik From tim.bell at oracle.com Tue Feb 20 18:52:03 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 20 Feb 2018 10:52:03 -0800 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: References: Message-ID: <5A8C6E53.4040702@oracle.com> Erik: > This patch adds a build time check for uses of global operators new and > delete in hotspot C++ code. The check is only run with toolchains GCC > and Clang (Linux and Macos builds). I have also modified the Oracle > devkit on Linux to add the necessary symlink so that objdump will get > picked up by configure. > > This change is depending on several fixes removing such uses that are > currently in jdk/hs so this change will need to be pushed there as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 > > Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ Looks good. Tim From magnus.ihse.bursie at oracle.com Tue Feb 20 19:47:40 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 20 Feb 2018 20:47:40 +0100 Subject: RFR: JDK-8198450 Make jdk.internal.vm.compiler/module-info.java.extra reproducable Message-ID: <362792d8-1fc4-e6e2-ad9c-a9f0e20774f2@oracle.com> The file jdk.internal.vm.compiler/module-info.java.extra is generated on build time. On systems with non-sorted output from ls and find, the file contents will change and thus not be reproducible. Fix is to sort file system information before using it. Bug: https://bugs.openjdk.java.net/browse/JDK-8198450 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8198450-make-compiler-module-info_java_extra-reproducable/webrev.01 /Magnus From erik.joelsson at oracle.com Tue Feb 20 20:11:08 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 20 Feb 2018 12:11:08 -0800 Subject: RFR: JDK-8198450 Make jdk.internal.vm.compiler/module-info.java.extra reproducable In-Reply-To: <362792d8-1fc4-e6e2-ad9c-a9f0e20774f2@oracle.com> References: <362792d8-1fc4-e6e2-ad9c-a9f0e20774f2@oracle.com> Message-ID: <80ee652c-6808-5e6d-f4ac-ffffef5c6217@oracle.com> Looks good. /Erik On 2018-02-20 11:47, Magnus Ihse Bursie wrote: > The file jdk.internal.vm.compiler/module-info.java.extra is generated > on build time. On systems with non-sorted output from ls and find, the > file contents will change and thus not be reproducible. > > Fix is to sort file system information before using it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198450 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198450-make-compiler-module-info_java_extra-reproducable/webrev.01 > > /Magnus From mandy.chung at oracle.com Tue Feb 20 20:21:41 2018 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 20 Feb 2018 12:21:41 -0800 Subject: RFR: JDK-8198450 Make jdk.internal.vm.compiler/module-info.java.extra reproducable In-Reply-To: <362792d8-1fc4-e6e2-ad9c-a9f0e20774f2@oracle.com> References: <362792d8-1fc4-e6e2-ad9c-a9f0e20774f2@oracle.com> Message-ID: <91a8e384-6ee1-cce7-20c4-4ee8e2c4de66@oracle.com> +1 Mandy On 2/20/18 11:47 AM, Magnus Ihse Bursie wrote: > The file jdk.internal.vm.compiler/module-info.java.extra is generated > on build time. On systems with non-sorted output from ls and find, the > file contents will change and thus not be reproducible. > > Fix is to sort file system information before using it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198450 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198450-make-compiler-module-info_java_extra-reproducable/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Tue Feb 20 20:51:32 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 20 Feb 2018 21:51:32 +0100 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: References: Message-ID: On 2018-02-20 19:05, Erik Joelsson wrote: > Hello, > > This patch adds a build time check for uses of global operators new > and delete in hotspot C++ code. The check is only run with toolchains > GCC and Clang (Linux and Macos builds). I have also modified the > Oracle devkit on Linux to add the necessary symlink so that objdump > will get picked up by configure. > > This change is depending on several fixes removing such uses that are > currently in jdk/hs so this change will need to be pushed there as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 > > Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ It seems dtrace disappeared when you sorted the line in make/devkit/Tools.gmk. There's a new dwp, should it be there? Otherwise it looks good. /Magnus > > /Erik > From erik.joelsson at oracle.com Tue Feb 20 21:35:29 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 20 Feb 2018 13:35:29 -0800 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: References: Message-ID: <9729f0a6-599a-90e4-84f0-e69e66a22052@oracle.com> On 2018-02-20 12:51, Magnus Ihse Bursie wrote: > > On 2018-02-20 19:05, Erik Joelsson wrote: >> Hello, >> >> This patch adds a build time check for uses of global operators new >> and delete in hotspot C++ code. The check is only run with toolchains >> GCC and Clang (Linux and Macos builds). I have also modified the >> Oracle devkit on Linux to add the necessary symlink so that objdump >> will get picked up by configure. >> >> This change is depending on several fixes removing such uses that are >> currently in jdk/hs so this change will need to be pushed there as well. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ > It seems dtrace disappeared when you sorted the line in > make/devkit/Tools.gmk. There's a new dwp, should it be there? > Yes and yes. I added links for all the missing tools (which was dwp and objdump) and removed dtrace which was accidentally added in JDK-8196998 (new devkit with 7.3). Dtrace is actually handled separately a few lines above. /Erik > Otherwise it looks good. > > /Magnus > >> >> /Erik >> > From david.holmes at oracle.com Wed Feb 21 05:33:54 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Feb 2018 15:33:54 +1000 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: References: Message-ID: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> Hi Erik, This seems okay. Just wondering: a) how much time it adds to the build? b) why this doesn't work for Solaris Studio? Thanks, David On 21/02/2018 4:05 AM, Erik Joelsson wrote: > Hello, > > This patch adds a build time check for uses of global operators new and > delete in hotspot C++ code. The check is only run with toolchains GCC > and Clang (Linux and Macos builds). I have also modified the Oracle > devkit on Linux to add the necessary symlink so that objdump will get > picked up by configure. > > This change is depending on several fixes removing such uses that are > currently in jdk/hs so this change will need to be pushed there as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 > > Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ > > /Erik > From abhi.saha at oracle.com Wed Feb 21 07:09:41 2018 From: abhi.saha at oracle.com (Abhijit Saha) Date: Tue, 20 Feb 2018 23:09:41 -0800 Subject: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20 Message-ID: <72502983-8ae7-ee2f-dc33-3622f14756e2@oracle.com> It's a retroactive review request. Fix has been integrated after reviewed internally. jdk11+1 (first build of jdk11) was promoted with incorrect Release Date. Need to be updated with correct GA date as per internal release roadmap. Bug: https://bugs.openjdk.java.net/browse/JDK-8198303 Webrev: http://cr.openjdk.java.net/~asaha/8198303/webrev.01/ Thanks Abhijit From david.holmes at oracle.com Wed Feb 21 07:56:57 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Feb 2018 17:56:57 +1000 Subject: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20 In-Reply-To: <72502983-8ae7-ee2f-dc33-3622f14756e2@oracle.com> References: <72502983-8ae7-ee2f-dc33-3622f14756e2@oracle.com> Message-ID: Retroactively Reviewed. Thanks, David On 21/02/2018 5:09 PM, Abhijit Saha wrote: > It's a retroactive review request. Fix has been integrated after > reviewed internally. > > jdk11+1 (first build of jdk11) was promoted with incorrect Release Date. > Need to be updated with correct GA date as per internal release roadmap. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198303 > > Webrev: http://cr.openjdk.java.net/~asaha/8198303/webrev.01/ > > > Thanks > Abhijit From magnus.ihse.bursie at oracle.com Wed Feb 21 13:31:56 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 21 Feb 2018 14:31:56 +0100 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <9729f0a6-599a-90e4-84f0-e69e66a22052@oracle.com> References: <9729f0a6-599a-90e4-84f0-e69e66a22052@oracle.com> Message-ID: > 20 feb. 2018 kl. 22:35 skrev Erik Joelsson : > > >> On 2018-02-20 12:51, Magnus Ihse Bursie wrote: >> >>> On 2018-02-20 19:05, Erik Joelsson wrote: >>> Hello, >>> >>> This patch adds a build time check for uses of global operators new and delete in hotspot C++ code. The check is only run with toolchains GCC and Clang (Linux and Macos builds). I have also modified the Oracle devkit on Linux to add the necessary symlink so that objdump will get picked up by configure. >>> >>> This change is depending on several fixes removing such uses that are currently in jdk/hs so this change will need to be pushed there as well. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ >> It seems dtrace disappeared when you sorted the line in make/devkit/Tools.gmk. There's a new dwp, should it be there? >> > Yes and yes. I added links for all the missing tools (which was dwp and objdump) and removed dtrace which was accidentally added in JDK-8196998 (new devkit with 7.3). Dtrace is actually handled separately a few lines above. Then I'm ok with it. /Magnus > > /Erik >> Otherwise it looks good. >> >> /Magnus >> >>> >>> /Erik >>> >> > From magnus.ihse.bursie at oracle.com Wed Feb 21 13:33:32 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 21 Feb 2018 14:33:32 +0100 Subject: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20 In-Reply-To: <72502983-8ae7-ee2f-dc33-3622f14756e2@oracle.com> References: <72502983-8ae7-ee2f-dc33-3622f14756e2@oracle.com> Message-ID: <587321F8-7E48-4B4C-923C-8C73E78E35FD@oracle.com> Looks good. /Magnus > 21 feb. 2018 kl. 08:09 skrev Abhijit Saha : > > It's a retroactive review request. Fix has been integrated after reviewed internally. > > jdk11+1 (first build of jdk11) was promoted with incorrect Release Date. Need to be updated with correct GA date as per internal release roadmap. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198303 > > Webrev: http://cr.openjdk.java.net/~asaha/8198303/webrev.01/ > > > Thanks > Abhijit From abhi.saha at oracle.com Wed Feb 21 16:12:38 2018 From: abhi.saha at oracle.com (Abhijit Saha) Date: Wed, 21 Feb 2018 08:12:38 -0800 Subject: RFR: JDK-8198301 - jdk11+1 was built as 'fcs' instead of 'ea' Message-ID: It's a retroactive review request. Fix has been integrated after reviewed internally. jdk11+1 (first build of jdk11) was promoted with incorrect milestone. It was built with GA milestone instead of 'ea'. Need to be updated with correct 'ea' milestone. Bug: https://bugs.openjdk.java.net/browse/JDK-8198301 Webrev: http://cr.openjdk.java.net/~asaha/8198301/webrev.01/ Thanks Abhijit From tim.bell at oracle.com Wed Feb 21 16:18:14 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 21 Feb 2018 08:18:14 -0800 Subject: RFR: JDK-8198301 - jdk11+1 was built as 'fcs' instead of 'ea' In-Reply-To: References: Message-ID: <5A8D9BC6.8000801@oracle.com> Abhijit: > It's a retroactive review request. Fix has been integrated after > reviewed internally. > > jdk11+1 (first build of jdk11) was promoted with incorrect milestone. It > was built with GA milestone instead of 'ea'. Need to be updated with > correct 'ea' milestone. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198301 > > Webrev: http://cr.openjdk.java.net/~asaha/8198301/webrev.01/ Looks good. /Tim From erik.joelsson at oracle.com Wed Feb 21 18:07:41 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 21 Feb 2018 10:07:41 -0800 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> Message-ID: <670ef618-704c-652e-d230-acadd63b990e@oracle.com> Hello, On 2018-02-20 21:33, David Holmes wrote: > > a) how much time it adds to the build? > I have not done extensive testing, but on my Linux workstation with 32 hw threads, building just hotspot release build from a clean workspace increased maybe 1 or 2 seconds (at around 90s total), but the variance was around the same amount as that. > b) why this doesn't work for Solaris Studio? > I didn't put a lot of effort into trying to figure it out. The check used was provided by Kim Barrett, for Linux only. I figured it would be simple enough to get it to work on mac and succeeded there. It should certainly be possible to implement a similar check on Solaris, but is it worth the time to do it? Both development time and increased build time on one of the slower build platforms? /Erik > Thanks, > David > > On 21/02/2018 4:05 AM, Erik Joelsson wrote: >> Hello, >> >> This patch adds a build time check for uses of global operators new >> and delete in hotspot C++ code. The check is only run with toolchains >> GCC and Clang (Linux and Macos builds). I have also modified the >> Oracle devkit on Linux to add the necessary symlink so that objdump >> will get picked up by configure. >> >> This change is depending on several fixes removing such uses that are >> currently in jdk/hs so this change will need to be pushed there as well. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ >> >> /Erik >> From martinrb at google.com Wed Feb 21 20:54:36 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 21 Feb 2018 12:54:36 -0800 Subject: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20 In-Reply-To: <72502983-8ae7-ee2f-dc33-3622f14756e2@oracle.com> References: <72502983-8ae7-ee2f-dc33-3622f14756e2@oracle.com> Message-ID: On Tue, Feb 20, 2018 at 11:09 PM, Abhijit Saha wrote: > It's a retroactive review request. Fix has been integrated after reviewed > internally. > > jdk11+1 (first build of jdk11) was promoted with incorrect Release Date. > Need to be updated with correct GA date as per internal release roadmap. > Where are my shiny jdk11+1 binaries for download ?! It would be nice if version information was always correct, which would mean part of the checklist of creating a release repo would be setting the release date of jdk/jdk/ 6 months later and marking it "ea" and updating the version to self-identify as java N+1. jdk binaries built from jdk/jdk have been misidentifying themselves since the jdk 10 repo was created. From joe.darcy at oracle.com Thu Feb 22 01:47:49 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 21 Feb 2018 17:47:49 -0800 Subject: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20 In-Reply-To: References: <72502983-8ae7-ee2f-dc33-3622f14756e2@oracle.com> Message-ID: <8a485f43-b7c2-a34a-67aa-ab434acb84eb@oracle.com> On 2/21/2018 12:54 PM, Martin Buchholz wrote: > On Tue, Feb 20, 2018 at 11:09 PM, Abhijit Saha wrote: > >> It's a retroactive review request. Fix has been integrated after reviewed >> internally. >> >> jdk11+1 (first build of jdk11) was promoted with incorrect Release Date. >> Need to be updated with correct GA date as per internal release roadmap. >> > Where are my shiny jdk11+1 binaries for download ?! > > It would be nice if version information was always correct, which would > mean part of the checklist of creating a release repo would be setting the > release date of jdk/jdk/ 6 months later and marking it "ea" and updating > the version to self-identify as java N+1. jdk binaries built from jdk/jdk > have been misidentifying themselves since the jdk 10 repo was created. Certainly it would be preferable if the version update occurred sooner. However, binaries build from jdk/jdk have been correctly identifying themselves as "JDK 11" since David Holmes pushed the fix for 8173401: "Update VERSION_FEATURE for JDK 11" on February 6, 2018. There are about half a dozen distinct changes that need to occur for a full conceptual version update going from JDK N to JDK (N+1). Besides the actual version update, there are -source/-target changes to javac, minor API changes, etc. Some of the changes made in JDK 11 b01 were done specifically to ease future version updates. This included hardening various tests against version updates. Since the version updates are happening more often now, there is more motivation to streamline the process (https://xkcd.com/1205/). -Joe From david.holmes at oracle.com Thu Feb 22 05:06:42 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 22 Feb 2018 15:06:42 +1000 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <670ef618-704c-652e-d230-acadd63b990e@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> Message-ID: <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> On 22/02/2018 4:07 AM, Erik Joelsson wrote: > Hello, > > > On 2018-02-20 21:33, David Holmes wrote: >> >> a) how much time it adds to the build? >> > I have not done extensive testing, but on my Linux workstation with 32 > hw threads, building just hotspot release build from a clean workspace > increased maybe 1 or 2 seconds (at around 90s total), but the variance > was around the same amount as that. >> b) why this doesn't work for Solaris Studio? >> > I didn't put a lot of effort into trying to figure it out. The check > used was provided by Kim Barrett, for Linux only. I figured it would be > simple enough to get it to work on mac and succeeded there. It should > certainly be possible to implement a similar check on Solaris, but is it > worth the time to do it? Both development time and increased build time > on one of the slower build platforms? Depends how concerned we are with detecting this problem in OS specific source code? To be honest I'm not sure this pulls its own weight regardless. David > /Erik >> Thanks, >> David >> >> On 21/02/2018 4:05 AM, Erik Joelsson wrote: >>> Hello, >>> >>> This patch adds a build time check for uses of global operators new >>> and delete in hotspot C++ code. The check is only run with toolchains >>> GCC and Clang (Linux and Macos builds). I have also modified the >>> Oracle devkit on Linux to add the necessary symlink so that objdump >>> will get picked up by configure. >>> >>> This change is depending on several fixes removing such uses that are >>> currently in jdk/hs so this change will need to be pushed there as well. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ >>> >>> /Erik >>> > From erik.joelsson at oracle.com Thu Feb 22 19:41:12 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 Feb 2018 11:41:12 -0800 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> Message-ID: <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> On 2018-02-21 21:06, David Holmes wrote: > On 22/02/2018 4:07 AM, Erik Joelsson wrote: >> Hello, >> >> >> On 2018-02-20 21:33, David Holmes wrote: >>> >>> a) how much time it adds to the build? >>> >> I have not done extensive testing, but on my Linux workstation with >> 32 hw threads, building just hotspot release build from a clean >> workspace increased maybe 1 or 2 seconds (at around 90s total), but >> the variance was around the same amount as that. >>> b) why this doesn't work for Solaris Studio? >>> >> I didn't put a lot of effort into trying to figure it out. The check >> used was provided by Kim Barrett, for Linux only. I figured it would >> be simple enough to get it to work on mac and succeeded there. It >> should certainly be possible to implement a similar check on Solaris, >> but is it worth the time to do it? Both development time and >> increased build time on one of the slower build platforms? > > Depends how concerned we are with detecting this problem in OS > specific source code? > I investigated this some more. I was able to do it successfully, but the build time cost is way too large here. The culprit is c++filt on Solaris which is incredibly costly, and the gnu version does not demangle Solaris Studio symbols. I don't think we should do this on Solaris. We could grep for the mangled strings for the operators instead, which is super fast. Problem is just figuring out all the possible combinations. /Erik > To be honest I'm not sure this pulls its own weight regardless. > > David > >> /Erik >>> Thanks, >>> David >>> >>> On 21/02/2018 4:05 AM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> This patch adds a build time check for uses of global operators new >>>> and delete in hotspot C++ code. The check is only run with >>>> toolchains GCC and Clang (Linux and Macos builds). I have also >>>> modified the Oracle devkit on Linux to add the necessary symlink so >>>> that objdump will get picked up by configure. >>>> >>>> This change is depending on several fixes removing such uses that >>>> are currently in jdk/hs so this change will need to be pushed there >>>> as well. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ >>>> >>>> /Erik >>>> >> From john.r.rose at oracle.com Thu Feb 22 20:00:03 2018 From: john.r.rose at oracle.com (John Rose) Date: Thu, 22 Feb 2018 12:00:03 -0800 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> Message-ID: <04E4FCB2-2009-4046-B97C-7773A9BCC80A@oracle.com> On Feb 22, 2018, at 11:41 AM, Erik Joelsson wrote: > > We could grep for the mangled strings for the operators instead, which is super fast. Problem is just figuring out all the possible combinations. Idea: Do a config-style move where you compile a test file of C++ code, strip out all the names from the object file, and throw the rest away. Even if we just had a hand-maintained list of strings, it might catch bugs fast enough to make it worth chasing the bit-rot of the names. Basically, have a black list of linker names (per OS?or not?), and keep it updated as people notice problems. ? John From erik.joelsson at oracle.com Thu Feb 22 22:26:49 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 Feb 2018 14:26:49 -0800 Subject: RFR: JDK-8198569: SetupTextFileProcessing should use sed with 'g' Message-ID: <4e1da756-7dec-d222-53c3-71c77b0e6549@oracle.com> I'm currently trying to use SetupTextFileProcessing with a file where the same replacement string appears twice on the same row. This doesn't work. To fix it, I would like to add /g on the sed replacement expressions. Webrev: http://cr.openjdk.java.net/~erikj/8198569/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8198569 /Erik From tim.bell at oracle.com Fri Feb 23 00:43:10 2018 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 22 Feb 2018 16:43:10 -0800 Subject: RFR: JDK-8198569: SetupTextFileProcessing should use sed with 'g' In-Reply-To: <4e1da756-7dec-d222-53c3-71c77b0e6549@oracle.com> References: <4e1da756-7dec-d222-53c3-71c77b0e6549@oracle.com> Message-ID: <5A8F639E.9020606@oracle.com> Erik: > I'm currently trying to use SetupTextFileProcessing with a file where > the same replacement string appears twice on the same row. This doesn't > work. To fix it, I would like to add /g on the sed replacement expressions. > > Webrev: http://cr.openjdk.java.net/~erikj/8198569/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198569 Looks good. /Tim From chris.plummer at oracle.com Fri Feb 23 01:03:55 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 22 Feb 2018 17:03:55 -0800 Subject: RFR(S): 8196992: Resolve disabled warnings for libdt_socket Message-ID: Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8196992 diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk b/make/lib/Lib-jdk.jdwp.agent.gmk --- a/make/lib/Lib-jdk.jdwp.agent.gmk +++ b/make/lib/Lib-jdk.jdwp.agent.gmk @@ -43,7 +43,6 @@ ???? OPTIMIZATION := LOW, \ ???? CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP \ ???????? $(LIBDT_SOCKET_CPPFLAGS), \ -??? DISABLED_WARNINGS_gcc := shift-negative-value, \ ???? MAPFILE := $(TOPDIR)/make/mapfiles/libdt_socket/mapfile-vers, \ ???? LDFLAGS := $(LDFLAGS_JDKLIB) \ ???????? $(call SET_SHARED_LIBRARY_ORIGIN), \ This change is undoing the makefile change done as part of JDK-8196985. The only warning that was turning up in libdt_socket code before JDK-8196985 was done has already been fixed by JDK-8196909. Thus no warnings need to be fixed. After removing the above makefile code, I tested by building with the new toolchain. As a first test I undid the socketTransport.cpp fix from JDK-8196909 to verify that the new toolchain exposed the warning. Then I reverted socketTransport.cpp back to tip sources and saw no warnings with the new toolchain. thanks, Chris From christoph.langer at sap.com Fri Feb 23 08:48:46 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 23 Feb 2018 08:48:46 +0000 Subject: RFR(S): 8196992: Resolve disabled warnings for libdt_socket In-Reply-To: References: Message-ID: Looks good, Chris. > -----Original Message----- > From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of > Chris Plummer > Sent: Freitag, 23. Februar 2018 02:04 > To: build-dev at openjdk.java.net build-dev ; > serviceability-dev > Subject: RFR(S): 8196992: Resolve disabled warnings for libdt_socket > > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8196992 > > diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk > b/make/lib/Lib-jdk.jdwp.agent.gmk > --- a/make/lib/Lib-jdk.jdwp.agent.gmk > +++ b/make/lib/Lib-jdk.jdwp.agent.gmk > @@ -43,7 +43,6 @@ > ???? OPTIMIZATION := LOW, \ > ???? CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP \ > ???????? $(LIBDT_SOCKET_CPPFLAGS), \ > -??? DISABLED_WARNINGS_gcc := shift-negative-value, \ > ???? MAPFILE := $(TOPDIR)/make/mapfiles/libdt_socket/mapfile-vers, \ > ???? LDFLAGS := $(LDFLAGS_JDKLIB) \ > ???????? $(call SET_SHARED_LIBRARY_ORIGIN), \ > > This change is undoing the makefile change done as part of JDK-8196985. > The only warning that was turning up in libdt_socket code before > JDK-8196985 was done has already been fixed by JDK-8196909. Thus no > warnings need to be fixed. > > After removing the above makefile code, I tested by building with the > new toolchain. As a first test I undid the socketTransport.cpp fix from > JDK-8196909 to verify that the new toolchain exposed the warning. Then I > reverted socketTransport.cpp back to tip sources and saw no warnings > with the new toolchain. > > thanks, > > Chris From serguei.spitsyn at oracle.com Fri Feb 23 10:15:52 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 23 Feb 2018 02:15:52 -0800 Subject: RFR(S): 8196992: Resolve disabled warnings for libdt_socket In-Reply-To: References: Message-ID: <1253244c-6fcb-19c4-e645-bc7838219428@oracle.com> Chris, This looks good to me too. Thanks, Serguei On 2/23/18 00:48, Langer, Christoph wrote: > Looks good, Chris. > >> -----Original Message----- >> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of >> Chris Plummer >> Sent: Freitag, 23. Februar 2018 02:04 >> To: build-dev at openjdk.java.net build-dev ; >> serviceability-dev >> Subject: RFR(S): 8196992: Resolve disabled warnings for libdt_socket >> >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8196992 >> >> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk >> b/make/lib/Lib-jdk.jdwp.agent.gmk >> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >> @@ -43,7 +43,6 @@ >> ???? OPTIMIZATION := LOW, \ >> ???? CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP \ >> ???????? $(LIBDT_SOCKET_CPPFLAGS), \ >> -??? DISABLED_WARNINGS_gcc := shift-negative-value, \ >> ???? MAPFILE := $(TOPDIR)/make/mapfiles/libdt_socket/mapfile-vers, \ >> ???? LDFLAGS := $(LDFLAGS_JDKLIB) \ >> ???????? $(call SET_SHARED_LIBRARY_ORIGIN), \ >> >> This change is undoing the makefile change done as part of JDK-8196985. >> The only warning that was turning up in libdt_socket code before >> JDK-8196985 was done has already been fixed by JDK-8196909. Thus no >> warnings need to be fixed. >> >> After removing the above makefile code, I tested by building with the >> new toolchain. As a first test I undid the socketTransport.cpp fix from >> JDK-8196909 to verify that the new toolchain exposed the warning. Then I >> reverted socketTransport.cpp back to tip sources and saw no warnings >> with the new toolchain. >> >> thanks, >> >> Chris From magnus.ihse.bursie at oracle.com Fri Feb 23 12:49:47 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Feb 2018 13:49:47 +0100 Subject: RFR(S): 8196992: Resolve disabled warnings for libdt_socket In-Reply-To: References: Message-ID: <04b2eccf-02c3-82b7-7042-e12375a1e5b2@oracle.com> On 2018-02-23 02:03, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8196992 > > diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk > b/make/lib/Lib-jdk.jdwp.agent.gmk > --- a/make/lib/Lib-jdk.jdwp.agent.gmk > +++ b/make/lib/Lib-jdk.jdwp.agent.gmk > @@ -43,7 +43,6 @@ > ???? OPTIMIZATION := LOW, \ > ???? CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP \ > ???????? $(LIBDT_SOCKET_CPPFLAGS), \ > -??? DISABLED_WARNINGS_gcc := shift-negative-value, \ > ???? MAPFILE := $(TOPDIR)/make/mapfiles/libdt_socket/mapfile-vers, \ > ???? LDFLAGS := $(LDFLAGS_JDKLIB) \ > ???????? $(call SET_SHARED_LIBRARY_ORIGIN), \ Looks good. Thanks for fixing these code quality issues! /Magnus > > This change is undoing the makefile change done as part of > JDK-8196985. The only warning that was turning up in libdt_socket code > before JDK-8196985 was done has already been fixed by JDK-8196909. > Thus no warnings need to be fixed. > > After removing the above makefile code, I tested by building with the > new toolchain. As a first test I undid the socketTransport.cpp fix > from JDK-8196909 to verify that the new toolchain exposed the warning. > Then I reverted socketTransport.cpp back to tip sources and saw no > warnings with the new toolchain. > > thanks, > > Chris > From magnus.ihse.bursie at oracle.com Fri Feb 23 12:50:33 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Feb 2018 13:50:33 +0100 Subject: RFR: JDK-8198569: SetupTextFileProcessing should use sed with 'g' In-Reply-To: <4e1da756-7dec-d222-53c3-71c77b0e6549@oracle.com> References: <4e1da756-7dec-d222-53c3-71c77b0e6549@oracle.com> Message-ID: <23ff84b0-9aaf-a24c-c05d-49f62fb98ef6@oracle.com> On 2018-02-22 23:26, Erik Joelsson wrote: > I'm currently trying to use SetupTextFileProcessing with a file where > the same replacement string appears twice on the same row. This > doesn't work. To fix it, I would like to add /g on the sed replacement > expressions. Oops :) > > Webrev: http://cr.openjdk.java.net/~erikj/8198569/webrev.01/ Looks good. /Magnus > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198569 > > /Erik > From magnus.ihse.bursie at oracle.com Fri Feb 23 13:24:55 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Feb 2018 14:24:55 +0100 Subject: RFR: JDK-8198627 JDK-8198318 broke readlink testing Message-ID: <79ae7b28-10c7-bc43-38c1-1a7818b9e973@oracle.com> The if line introduced in JDK-8198318 is missing a "test". Thanks to Jon and Erik for discovering the problem and the solution. Bug: https://bugs.openjdk.java.net/browse/JDK-8198627 Patch inline: diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4 --- a/make/autoconf/basics.m4 +++ b/make/autoconf/basics.m4 @@ -263,7 +263,7 @@ ?????? READLINK_TESTED=yes ???? fi -??? if test "x$READLINK" != x && "x$READLINK_ISGNU" != x; then +??? if test "x$READLINK" != x && test "x$READLINK_ISGNU" != x; then ?????? $1=`$READLINK -f [$]$1` ???? else ?????? # Save the current directory for restoring afterwards /Magnus From magnus.ihse.bursie at oracle.com Fri Feb 23 13:27:41 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Feb 2018 14:27:41 +0100 Subject: RFR: JDK-8198243: Add build time check for global operator new/delete in object files In-Reply-To: <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> References: <71865dc2-c7ad-fab5-7a78-a13875b9dbe8@oracle.com> <670ef618-704c-652e-d230-acadd63b990e@oracle.com> <47cf6f6c-aa30-445c-7c0a-0c279d26ebf5@oracle.com> <4713fd68-4f61-ba8c-c8f9-b2988ae713df@oracle.com> Message-ID: <1fca4095-95ca-7571-d243-d2e9cc2dcacc@oracle.com> On 2018-02-22 20:41, Erik Joelsson wrote: > > > On 2018-02-21 21:06, David Holmes wrote: >> On 22/02/2018 4:07 AM, Erik Joelsson wrote: >>> Hello, >>> >>> >>> On 2018-02-20 21:33, David Holmes wrote: >>>> >>>> a) how much time it adds to the build? >>>> >>> I have not done extensive testing, but on my Linux workstation with >>> 32 hw threads, building just hotspot release build from a clean >>> workspace increased maybe 1 or 2 seconds (at around 90s total), but >>> the variance was around the same amount as that. >>>> b) why this doesn't work for Solaris Studio? >>>> >>> I didn't put a lot of effort into trying to figure it out. The check >>> used was provided by Kim Barrett, for Linux only. I figured it would >>> be simple enough to get it to work on mac and succeeded there. It >>> should certainly be possible to implement a similar check on >>> Solaris, but is it worth the time to do it? Both development time >>> and increased build time on one of the slower build platforms? >> >> Depends how concerned we are with detecting this problem in OS >> specific source code? >> > I investigated this some more. I was able to do it successfully, but > the build time cost is way too large here. The culprit is c++filt on > Solaris which is incredibly costly, and the gnu version does not > demangle Solaris Studio symbols. I don't think we should do this on > Solaris. I agree, it's not worth it. Not all programmer's mistakes are reasonable to catch in technical traps. It we *should* spend time on getting automatic tool for keeping code quality up (and, yes, I really do think we should), there's most likely to be much better areas to spend that effort in, in making a lot of prone-to-break scripts for catching a single kind of problem. /Magnus > > We could grep for the mangled strings for the operators instead, which > is super fast. Problem is just figuring out all the possible > combinations. > > /Erik >> To be honest I'm not sure this pulls its own weight regardless. >> >> David >> >>> /Erik >>>> Thanks, >>>> David >>>> >>>> On 21/02/2018 4:05 AM, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> This patch adds a build time check for uses of global operators >>>>> new and delete in hotspot C++ code. The check is only run with >>>>> toolchains GCC and Clang (Linux and Macos builds). I have also >>>>> modified the Oracle devkit on Linux to add the necessary symlink >>>>> so that objdump will get picked up by configure. >>>>> >>>>> This change is depending on several fixes removing such uses that >>>>> are currently in jdk/hs so this change will need to be pushed >>>>> there as well. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198243 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/ >>>>> >>>>> /Erik >>>>> >>> > From erik.joelsson at oracle.com Fri Feb 23 14:52:24 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 23 Feb 2018 06:52:24 -0800 Subject: RFR: JDK-8198627 JDK-8198318 broke readlink testing In-Reply-To: <79ae7b28-10c7-bc43-38c1-1a7818b9e973@oracle.com> References: <79ae7b28-10c7-bc43-38c1-1a7818b9e973@oracle.com> Message-ID: <3dfadca6-aba8-5355-1d74-f28276975cb6@oracle.com> Looks good and thanks for picking this up! I never got around to it yesterday. /Erik On 2018-02-23 05:24, Magnus Ihse Bursie wrote: > The if line introduced in JDK-8198318 is missing a "test". > Thanks to Jon and Erik for discovering the problem and the solution. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198627 > Patch inline: > > diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4 > --- a/make/autoconf/basics.m4 > +++ b/make/autoconf/basics.m4 > @@ -263,7 +263,7 @@ > ?????? READLINK_TESTED=yes > ???? fi > > -??? if test "x$READLINK" != x && "x$READLINK_ISGNU" != x; then > +??? if test "x$READLINK" != x && test "x$READLINK_ISGNU" != x; then > ?????? $1=`$READLINK -f [$]$1` > ???? else > ?????? # Save the current directory for restoring afterwards > > /Magnus From tim.bell at oracle.com Fri Feb 23 15:11:09 2018 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 23 Feb 2018 07:11:09 -0800 Subject: RFR: JDK-8198627 JDK-8198318 broke readlink testing In-Reply-To: <3dfadca6-aba8-5355-1d74-f28276975cb6@oracle.com> References: <79ae7b28-10c7-bc43-38c1-1a7818b9e973@oracle.com> <3dfadca6-aba8-5355-1d74-f28276975cb6@oracle.com> Message-ID: <5A902F0D.1040902@oracle.com> Magnus- Looks good to me as well. Thanks- /Tim On 02/23/18 06:52, Erik Joelsson wrote: > Looks good and thanks for picking this up! I never got around to it > yesterday. > > /Erik > > > On 2018-02-23 05:24, Magnus Ihse Bursie wrote: >> The if line introduced in JDK-8198318 is missing a "test". >> Thanks to Jon and Erik for discovering the problem and the solution. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198627 >> Patch inline: >> >> diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4 >> --- a/make/autoconf/basics.m4 >> +++ b/make/autoconf/basics.m4 >> @@ -263,7 +263,7 @@ >> READLINK_TESTED=yes >> fi >> >> - if test "x$READLINK" != x && "x$READLINK_ISGNU" != x; then >> + if test "x$READLINK" != x && test "x$READLINK_ISGNU" != x; then >> $1=`$READLINK -f [$]$1` >> else >> # Save the current directory for restoring afterwards >> >> /Magnus > From volker.simonis at gmail.com Fri Feb 23 15:19:30 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 23 Feb 2018 16:19:30 +0100 Subject: RFR: JDK-8198627 JDK-8198318 broke readlink testing In-Reply-To: <79ae7b28-10c7-bc43-38c1-1a7818b9e973@oracle.com> References: <79ae7b28-10c7-bc43-38c1-1a7818b9e973@oracle.com> Message-ID: Good patch, Magnus! We've been affected by this as well but instead of digging deeper into the problem we've installed "readlink" on our AIX build machines, where it wasn't available until now. Good to know that "readlink" is still not a mandatory requirement for the build :) On Fri, Feb 23, 2018 at 2:24 PM, Magnus Ihse Bursie wrote: > The if line introduced in JDK-8198318 is missing a "test". > Thanks to Jon and Erik for discovering the problem and the solution. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198627 > Patch inline: > > diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4 > --- a/make/autoconf/basics.m4 > +++ b/make/autoconf/basics.m4 > @@ -263,7 +263,7 @@ > READLINK_TESTED=yes > fi > > - if test "x$READLINK" != x && "x$READLINK_ISGNU" != x; then > + if test "x$READLINK" != x && test "x$READLINK_ISGNU" != x; then > $1=`$READLINK -f [$]$1` > else > # Save the current directory for restoring afterwards > > /Magnus From philip.race at oracle.com Fri Feb 23 16:58:20 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 23 Feb 2018 08:58:20 -0800 Subject: RFR: JDK-8198627 JDK-8198318 broke readlink testing In-Reply-To: <3dfadca6-aba8-5355-1d74-f28276975cb6@oracle.com> References: <79ae7b28-10c7-bc43-38c1-1a7818b9e973@oracle.com> <3dfadca6-aba8-5355-1d74-f28276975cb6@oracle.com> Message-ID: <87cf6792-be41-9c6e-3542-4c04ad3e81a2@oracle.com> +1 . This fixed it for me when I tried it yesterday. -phil. On 02/23/2018 06:52 AM, Erik Joelsson wrote: > Looks good and thanks for picking this up! I never got around to it > yesterday. > > /Erik > > > On 2018-02-23 05:24, Magnus Ihse Bursie wrote: >> The if line introduced in JDK-8198318 is missing a "test". >> Thanks to Jon and Erik for discovering the problem and the solution. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198627 >> Patch inline: >> >> diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4 >> --- a/make/autoconf/basics.m4 >> +++ b/make/autoconf/basics.m4 >> @@ -263,7 +263,7 @@ >> READLINK_TESTED=yes >> fi >> >> - if test "x$READLINK" != x && "x$READLINK_ISGNU" != x; then >> + if test "x$READLINK" != x && test "x$READLINK_ISGNU" != x; then >> $1=`$READLINK -f [$]$1` >> else >> # Save the current directory for restoring afterwards >> >> /Magnus > From lois.foltan at oracle.com Fri Feb 23 17:54:52 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 23 Feb 2018 12:54:52 -0500 Subject: (11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp Message-ID: Please review this small fix to set HOTSPOT_BUILD_COMPILER correctly for VS2017. open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/ bug link https://bugs.openjdk.java.net/browse/JDK-8198312 Testing: hs-tier(1-3), jdk-tier(1-3) complete Thanks, Lois From erik.joelsson at oracle.com Fri Feb 23 18:05:58 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 23 Feb 2018 10:05:58 -0800 Subject: (11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp In-Reply-To: References: Message-ID: <09b4db01-4928-ab93-0bb7-e0b07d302d33@oracle.com> Hello Lois, This looks good, but I would suggest to also add 1900 for VS2015, for completeness. /Erik On 2018-02-23 09:54, Lois Foltan wrote: > Please review this small fix to set HOTSPOT_BUILD_COMPILER correctly > for VS2017. > > open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/ > bug link https://bugs.openjdk.java.net/browse/JDK-8198312 > > Testing: hs-tier(1-3), jdk-tier(1-3) complete > > Thanks, > Lois > From lois.foltan at oracle.com Fri Feb 23 19:16:33 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 23 Feb 2018 14:16:33 -0500 Subject: (11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp In-Reply-To: <09b4db01-4928-ab93-0bb7-e0b07d302d33@oracle.com> References: <09b4db01-4928-ab93-0bb7-e0b07d302d33@oracle.com> Message-ID: On 2/23/2018 1:05 PM, Erik Joelsson wrote: > Hello Lois, > > This looks good, but I would suggest to also add 1900 for VS2015, for > completeness. Thanks for the review Erik!? I have updated the webrev to add 1900, however, I couldn't find a release # for VS2015, since all documentation I could find seemed to indicated that only 2015 and updates 1-3 were released.? If you have more info on this let me know! http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.1/webrev/ Thanks, Lois > > /Erik > > > On 2018-02-23 09:54, Lois Foltan wrote: >> Please review this small fix to set HOTSPOT_BUILD_COMPILER correctly >> for VS2017. >> >> open webrev at >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8198312 >> >> Testing: hs-tier(1-3), jdk-tier(1-3) complete >> >> Thanks, >> Lois >> > From erik.joelsson at oracle.com Fri Feb 23 19:31:22 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 23 Feb 2018 11:31:22 -0800 Subject: (11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp In-Reply-To: References: <09b4db01-4928-ab93-0bb7-e0b07d302d33@oracle.com> Message-ID: On 2018-02-23 11:16, Lois Foltan wrote: > On 2/23/2018 1:05 PM, Erik Joelsson wrote: > >> Hello Lois, >> >> This looks good, but I would suggest to also add 1900 for VS2015, for >> completeness. > Thanks for the review Erik!? I have updated the webrev to add 1900, > however, I couldn't find a release # for VS2015, since all > documentation I could find seemed to indicated that only 2015 and > updates 1-3 were released.? If you have more info on this let me know! > My installation of 2015 was put in "Microsoft Visual Studio 14.0" following the pattern of previous versions (12.0, 11.0, 10.0 etc), so I think that would be the appropriate number here. Otherwise I think this looks good. /Erik > http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.1/webrev/ > > Thanks, > Lois > >> >> /Erik >> >> >> On 2018-02-23 09:54, Lois Foltan wrote: >>> Please review this small fix to set HOTSPOT_BUILD_COMPILER correctly >>> for VS2017. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8198312 >>> >>> Testing: hs-tier(1-3), jdk-tier(1-3) complete >>> >>> Thanks, >>> Lois >>> >> > From lois.foltan at oracle.com Fri Feb 23 19:48:54 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 23 Feb 2018 14:48:54 -0500 Subject: (11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp In-Reply-To: <62c9ef99-5a6f-40e8-4fb5-9f8a0e9ff5c7@oracle.com> References: <09b4db01-4928-ab93-0bb7-e0b07d302d33@oracle.com> <8994b07f-794f-a986-972b-6c8adad854fb@oracle.com> <62c9ef99-5a6f-40e8-4fb5-9f8a0e9ff5c7@oracle.com> Message-ID: <766a33d2-11ce-7af6-fbfb-5e4130560fc7@oracle.com> Thanks again for the review Erik! Lois On 2/23/2018 2:44 PM, Erik Joelsson wrote: > Looks good! > > /Erik > > > On 2018-02-23 11:39, Lois Foltan wrote: >> On 2/23/2018 2:31 PM, Erik Joelsson wrote: >> >>> On 2018-02-23 11:16, Lois Foltan wrote: >>>> On 2/23/2018 1:05 PM, Erik Joelsson wrote: >>>> >>>>> Hello Lois, >>>>> >>>>> This looks good, but I would suggest to also add 1900 for VS2015, >>>>> for completeness. >>>> Thanks for the review Erik!? I have updated the webrev to add 1900, >>>> however, I couldn't find a release # for VS2015, since all >>>> documentation I could find seemed to indicated that only 2015 and >>>> updates 1-3 were released.? If you have more info on this let me know! >>>> >>> My installation of 2015 was put in "Microsoft Visual Studio 14.0" >>> following the pattern of previous versions (12.0, 11.0, 10.0 etc), >>> so I think that would be the appropriate number here. Otherwise I >>> think this looks good. >> >> Got it, hopefully final webrev at >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.2/webrev/ >> Thanks again! >> Lois >> >>> >>> /Erik >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.1/webrev/ >>>> >>>> Thanks, >>>> Lois >>>> >>>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2018-02-23 09:54, Lois Foltan wrote: >>>>>> Please review this small fix to set HOTSPOT_BUILD_COMPILER >>>>>> correctly for VS2017. >>>>>> >>>>>> open webrev at >>>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/ >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8198312 >>>>>> >>>>>> Testing: hs-tier(1-3), jdk-tier(1-3) complete >>>>>> >>>>>> Thanks, >>>>>> Lois >>>>>> >>>>> >>>> >>> >> > From lois.foltan at oracle.com Fri Feb 23 19:39:12 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 23 Feb 2018 14:39:12 -0500 Subject: (11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp In-Reply-To: References: <09b4db01-4928-ab93-0bb7-e0b07d302d33@oracle.com> Message-ID: <8994b07f-794f-a986-972b-6c8adad854fb@oracle.com> On 2/23/2018 2:31 PM, Erik Joelsson wrote: > On 2018-02-23 11:16, Lois Foltan wrote: >> On 2/23/2018 1:05 PM, Erik Joelsson wrote: >> >>> Hello Lois, >>> >>> This looks good, but I would suggest to also add 1900 for VS2015, >>> for completeness. >> Thanks for the review Erik!? I have updated the webrev to add 1900, >> however, I couldn't find a release # for VS2015, since all >> documentation I could find seemed to indicated that only 2015 and >> updates 1-3 were released.? If you have more info on this let me know! >> > My installation of 2015 was put in "Microsoft Visual Studio 14.0" > following the pattern of previous versions (12.0, 11.0, 10.0 etc), so > I think that would be the appropriate number here. Otherwise I think > this looks good. Got it, hopefully final webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.2/webrev/ Thanks again! Lois > > /Erik >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.1/webrev/ >> >> Thanks, >> Lois >> >>> >>> /Erik >>> >>> >>> On 2018-02-23 09:54, Lois Foltan wrote: >>>> Please review this small fix to set HOTSPOT_BUILD_COMPILER >>>> correctly for VS2017. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8198312 >>>> >>>> Testing: hs-tier(1-3), jdk-tier(1-3) complete >>>> >>>> Thanks, >>>> Lois >>>> >>> >> > From erik.joelsson at oracle.com Fri Feb 23 19:44:34 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 23 Feb 2018 11:44:34 -0800 Subject: (11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp In-Reply-To: <8994b07f-794f-a986-972b-6c8adad854fb@oracle.com> References: <09b4db01-4928-ab93-0bb7-e0b07d302d33@oracle.com> <8994b07f-794f-a986-972b-6c8adad854fb@oracle.com> Message-ID: <62c9ef99-5a6f-40e8-4fb5-9f8a0e9ff5c7@oracle.com> Looks good! /Erik On 2018-02-23 11:39, Lois Foltan wrote: > On 2/23/2018 2:31 PM, Erik Joelsson wrote: > >> On 2018-02-23 11:16, Lois Foltan wrote: >>> On 2/23/2018 1:05 PM, Erik Joelsson wrote: >>> >>>> Hello Lois, >>>> >>>> This looks good, but I would suggest to also add 1900 for VS2015, >>>> for completeness. >>> Thanks for the review Erik!? I have updated the webrev to add 1900, >>> however, I couldn't find a release # for VS2015, since all >>> documentation I could find seemed to indicated that only 2015 and >>> updates 1-3 were released.? If you have more info on this let me know! >>> >> My installation of 2015 was put in "Microsoft Visual Studio 14.0" >> following the pattern of previous versions (12.0, 11.0, 10.0 etc), so >> I think that would be the appropriate number here. Otherwise I think >> this looks good. > > Got it, hopefully final webrev at > http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.2/webrev/ > Thanks again! > Lois > >> >> /Erik >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.1/webrev/ >>> >>> Thanks, >>> Lois >>> >>>> >>>> /Erik >>>> >>>> >>>> On 2018-02-23 09:54, Lois Foltan wrote: >>>>> Please review this small fix to set HOTSPOT_BUILD_COMPILER >>>>> correctly for VS2017. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/ >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8198312 >>>>> >>>>> Testing: hs-tier(1-3), jdk-tier(1-3) complete >>>>> >>>>> Thanks, >>>>> Lois >>>>> >>>> >>> >> > From lois.foltan at oracle.com Fri Feb 23 20:11:02 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 23 Feb 2018 15:11:02 -0500 Subject: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization Message-ID: <9d08bbb6-ee4e-5092-9ffa-1c9cf2ebcd1e@oracle.com> Please review this fix to ignore linker warning (LNK4281).? This is a new linker warning generated by VS2017 v15.5 to "to point out any 64-bit image specified to link with a lower than 4GB base address doesn't get best ASLR optimization". The Hotspot jvm.dll is specifically linked with -base:0x8000000.? As recommended by https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html, this linker warning can be suppressed with -ignore. open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/ bug link https://bugs.openjdk.java.net/browse/JDK-8198640 Testing (hs-tier1-3 & jdk-tier1-3) in progress Thanks, Lois From christian.tornqvist at oracle.com Fri Feb 23 20:18:29 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 23 Feb 2018 15:18:29 -0500 Subject: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization In-Reply-To: <9d08bbb6-ee4e-5092-9ffa-1c9cf2ebcd1e@oracle.com> References: <9d08bbb6-ee4e-5092-9ffa-1c9cf2ebcd1e@oracle.com> Message-ID: <71C7BC17-DEE6-4B5C-9BA4-12E5FCCA8173@oracle.com> Hi Lois, Why do we link jvm.dll with -base? Thanks, Christian > On Feb 23, 2018, at 3:11 PM, Lois Foltan wrote: > > Please review this fix to ignore linker warning (LNK4281). This is a new linker warning generated by VS2017 v15.5 to "to point out any 64-bit image specified to link with a lower than 4GB base address doesn't get best ASLR optimization". The Hotspot jvm.dll is specifically linked with -base:0x8000000. As recommended by https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html, this linker warning can be suppressed with -ignore. > > open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/ > bug link https://bugs.openjdk.java.net/browse/JDK-8198640 > > Testing (hs-tier1-3 & jdk-tier1-3) in progress > > Thanks, > Lois > > From lois.foltan at oracle.com Fri Feb 23 20:22:08 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 23 Feb 2018 15:22:08 -0500 Subject: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization In-Reply-To: <71C7BC17-DEE6-4B5C-9BA4-12E5FCCA8173@oracle.com> References: <9d08bbb6-ee4e-5092-9ffa-1c9cf2ebcd1e@oracle.com> <71C7BC17-DEE6-4B5C-9BA4-12E5FCCA8173@oracle.com> Message-ID: <0ec5f3ec-904d-bd58-6e1f-75243ae11c66@oracle.com> On 2/23/2018 3:18 PM, Christian Tornqvist wrote: > Hi Lois, > > Why do we link jvm.dll with -base? Hi Christian, It is not clear to me why we do, so I was going to follow up with an RFE to investigate & suggest the removal of -base if unnecessary. Lois > > Thanks, > Christian > >> On Feb 23, 2018, at 3:11 PM, Lois Foltan wrote: >> >> Please review this fix to ignore linker warning (LNK4281). This is a new linker warning generated by VS2017 v15.5 to "to point out any 64-bit image specified to link with a lower than 4GB base address doesn't get best ASLR optimization". The Hotspot jvm.dll is specifically linked with -base:0x8000000. As recommended by https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html, this linker warning can be suppressed with -ignore. >> >> open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8198640 >> >> Testing (hs-tier1-3 & jdk-tier1-3) in progress >> >> Thanks, >> Lois >> >> From christian.tornqvist at oracle.com Fri Feb 23 20:53:07 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 23 Feb 2018 15:53:07 -0500 Subject: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization In-Reply-To: <0ec5f3ec-904d-bd58-6e1f-75243ae11c66@oracle.com> References: <9d08bbb6-ee4e-5092-9ffa-1c9cf2ebcd1e@oracle.com> <71C7BC17-DEE6-4B5C-9BA4-12E5FCCA8173@oracle.com> <0ec5f3ec-904d-bd58-6e1f-75243ae11c66@oracle.com> Message-ID: Sounds like a good plan :) Thanks, Christian > On Feb 23, 2018, at 3:22 PM, Lois Foltan wrote: > >> On 2/23/2018 3:18 PM, Christian Tornqvist wrote: >> >> Hi Lois, >> >> Why do we link jvm.dll with -base? > Hi Christian, > It is not clear to me why we do, so I was going to follow up with an RFE to investigate & suggest the removal of -base if unnecessary. > Lois > >> >> Thanks, >> Christian >> >>> On Feb 23, 2018, at 3:11 PM, Lois Foltan wrote: >>> >>> Please review this fix to ignore linker warning (LNK4281). This is a new linker warning generated by VS2017 v15.5 to "to point out any 64-bit image specified to link with a lower than 4GB base address doesn't get best ASLR optimization". The Hotspot jvm.dll is specifically linked with -base:0x8000000. As recommended by https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html, this linker warning can be suppressed with -ignore. >>> >>> open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8198640 >>> >>> Testing (hs-tier1-3 & jdk-tier1-3) in progress >>> >>> Thanks, >>> Lois >>> >>> > From christian.tornqvist at oracle.com Fri Feb 23 20:54:10 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 23 Feb 2018 15:54:10 -0500 Subject: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization In-Reply-To: References: <9d08bbb6-ee4e-5092-9ffa-1c9cf2ebcd1e@oracle.com> <71C7BC17-DEE6-4B5C-9BA4-12E5FCCA8173@oracle.com> <0ec5f3ec-904d-bd58-6e1f-75243ae11c66@oracle.com> Message-ID: Forgot to say that the webrev looks good! > On Feb 23, 2018, at 3:53 PM, Christian Tornqvist wrote: > > Sounds like a good plan :) > > Thanks, > Christian > >>> On Feb 23, 2018, at 3:22 PM, Lois Foltan wrote: >>> >>> On 2/23/2018 3:18 PM, Christian Tornqvist wrote: >>> >>> Hi Lois, >>> >>> Why do we link jvm.dll with -base? >> Hi Christian, >> It is not clear to me why we do, so I was going to follow up with an RFE to investigate & suggest the removal of -base if unnecessary. >> Lois >> >>> >>> Thanks, >>> Christian >>> >>>> On Feb 23, 2018, at 3:11 PM, Lois Foltan wrote: >>>> >>>> Please review this fix to ignore linker warning (LNK4281). This is a new linker warning generated by VS2017 v15.5 to "to point out any 64-bit image specified to link with a lower than 4GB base address doesn't get best ASLR optimization". The Hotspot jvm.dll is specifically linked with -base:0x8000000. As recommended by https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html, this linker warning can be suppressed with -ignore. >>>> >>>> open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8198640 >>>> >>>> Testing (hs-tier1-3 & jdk-tier1-3) in progress >>>> >>>> Thanks, >>>> Lois >>>> >>>> >> From lois.foltan at oracle.com Fri Feb 23 21:05:51 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 23 Feb 2018 16:05:51 -0500 Subject: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization In-Reply-To: References: <9d08bbb6-ee4e-5092-9ffa-1c9cf2ebcd1e@oracle.com> <71C7BC17-DEE6-4B5C-9BA4-12E5FCCA8173@oracle.com> <0ec5f3ec-904d-bd58-6e1f-75243ae11c66@oracle.com> Message-ID: <1093fd16-2b6c-77d1-6b77-71bd8e0985cc@oracle.com> Thank you for the review Christian!? I have gone forward and created the RFE at https://bugs.openjdk.java.net/browse/JDK-8198652. Lois On 2/23/2018 3:54 PM, Christian Tornqvist wrote: > Forgot to say that the webrev looks good! > >> On Feb 23, 2018, at 3:53 PM, Christian Tornqvist wrote: >> >> Sounds like a good plan :) >> >> Thanks, >> Christian >> >>>> On Feb 23, 2018, at 3:22 PM, Lois Foltan wrote: >>>> >>>> On 2/23/2018 3:18 PM, Christian Tornqvist wrote: >>>> >>>> Hi Lois, >>>> >>>> Why do we link jvm.dll with -base? >>> Hi Christian, >>> It is not clear to me why we do, so I was going to follow up with an RFE to investigate & suggest the removal of -base if unnecessary. >>> Lois >>> >>>> Thanks, >>>> Christian >>>> >>>>> On Feb 23, 2018, at 3:11 PM, Lois Foltan wrote: >>>>> >>>>> Please review this fix to ignore linker warning (LNK4281). This is a new linker warning generated by VS2017 v15.5 to "to point out any 64-bit image specified to link with a lower than 4GB base address doesn't get best ASLR optimization". The Hotspot jvm.dll is specifically linked with -base:0x8000000. As recommended by https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html, this linker warning can be suppressed with -ignore. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/ >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8198640 >>>>> >>>>> Testing (hs-tier1-3 & jdk-tier1-3) in progress >>>>> >>>>> Thanks, >>>>> Lois >>>>> >>>>> From erik.joelsson at oracle.com Fri Feb 23 21:08:25 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 23 Feb 2018 13:08:25 -0800 Subject: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization In-Reply-To: <9d08bbb6-ee4e-5092-9ffa-1c9cf2ebcd1e@oracle.com> References: <9d08bbb6-ee4e-5092-9ffa-1c9cf2ebcd1e@oracle.com> Message-ID: <2994afcc-cf1f-88e0-025d-52adc7ea41ba@oracle.com> Looks good. /Erik On 2018-02-23 12:11, Lois Foltan wrote: > Please review this fix to ignore linker warning (LNK4281).? This is a > new linker warning generated by VS2017 v15.5 to "to point out any > 64-bit image specified to link with a lower than 4GB base address > doesn't get best ASLR optimization". The Hotspot jvm.dll is > specifically linked with -base:0x8000000.? As recommended by > https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html, > this linker warning can be suppressed with -ignore. > > open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/ > bug link https://bugs.openjdk.java.net/browse/JDK-8198640 > > Testing (hs-tier1-3 & jdk-tier1-3) in progress > > Thanks, > Lois > > From lois.foltan at oracle.com Fri Feb 23 21:12:33 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 23 Feb 2018 16:12:33 -0500 Subject: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization In-Reply-To: <2994afcc-cf1f-88e0-025d-52adc7ea41ba@oracle.com> References: <9d08bbb6-ee4e-5092-9ffa-1c9cf2ebcd1e@oracle.com> <2994afcc-cf1f-88e0-025d-52adc7ea41ba@oracle.com> Message-ID: Thanks Erik! Lois On 2/23/2018 4:08 PM, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2018-02-23 12:11, Lois Foltan wrote: >> Please review this fix to ignore linker warning (LNK4281).? This is a >> new linker warning generated by VS2017 v15.5 to "to point out any >> 64-bit image specified to link with a lower than 4GB base address >> doesn't get best ASLR optimization". The Hotspot jvm.dll is >> specifically linked with -base:0x8000000.? As recommended by >> https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html, >> this linker warning can be suppressed with -ignore. >> >> open webrev at >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8198640 >> >> Testing (hs-tier1-3 & jdk-tier1-3) in progress >> >> Thanks, >> Lois >> >> > From magnus.ihse.bursie at oracle.com Mon Feb 26 14:35:19 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 26 Feb 2018 15:35:19 +0100 Subject: RFR: JDK-8198627 JDK-8198318 broke readlink testing In-Reply-To: References: <79ae7b28-10c7-bc43-38c1-1a7818b9e973@oracle.com> Message-ID: <438905A2-79F3-4F67-B052-92948445DDE0@oracle.com> I apologize for the extra work my mistake caused you. :( /Magnus > 23 feb. 2018 kl. 16:19 skrev Volker Simonis : > > Good patch, Magnus! > > We've been affected by this as well but instead of digging deeper into > the problem we've installed "readlink" on our AIX build machines, > where it wasn't available until now. Good to know that "readlink" is > still not a mandatory requirement for the build :) > > > On Fri, Feb 23, 2018 at 2:24 PM, Magnus Ihse Bursie > wrote: >> The if line introduced in JDK-8198318 is missing a "test". >> Thanks to Jon and Erik for discovering the problem and the solution. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198627 >> Patch inline: >> >> diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4 >> --- a/make/autoconf/basics.m4 >> +++ b/make/autoconf/basics.m4 >> @@ -263,7 +263,7 @@ >> READLINK_TESTED=yes >> fi >> >> - if test "x$READLINK" != x && "x$READLINK_ISGNU" != x; then >> + if test "x$READLINK" != x && test "x$READLINK_ISGNU" != x; then >> $1=`$READLINK -f [$]$1` >> else >> # Save the current directory for restoring afterwards >> >> /Magnus From igor.ignatyev at oracle.com Mon Feb 26 19:47:47 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 26 Feb 2018 11:47:47 -0800 Subject: RFR(S) 8197453 : Add support of extra problem list In-Reply-To: References: Message-ID: adding build-dev alias -- Igor > On Feb 8, 2018, at 3:08 PM, Ekaterina Pavlova wrote: > > Hi all, > > ProblemList.txt files used by makefiles for jtreg testing allow to specify list of tests to be excluded > from execution on all or specific platforms. However to test such features like Graal we want to be able > to specify list of failed tests which fail in particular JVM mode only. > Please review this change which adds support of extra problem list and introduces 2 Graal specific problem list files. > - test/hotspot/jtreg/ProblemList-graal.txt > - test/jdk/ProblemList-graal.txt > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8197453 > webrev: http://cr.openjdk.java.net/~epavlova//8197453/webrev.00/ > testing: precheckin, tier1 and tier2 with empty EXTRA_PROBLEM_LISTS. > testing in Graal mode with EXTRA_PROBLEM_LISTS=ProblemList-graal.txt > > thanks, > -katya > > p.s. > Igor Ignatyev volunteered to sponsor this change. From jonathan.gibbons at oracle.com Mon Feb 26 20:02:38 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 26 Feb 2018 12:02:38 -0800 Subject: RFR(S) 8197453 : Add support of extra problem list In-Reply-To: References: Message-ID: If these new problem-list files are destined for use by jtreg, I would encourage adding a platform specifier on each line, after the bug number. If you want to mark the test as excluded on all platforms, the convention is to use "generic-all". -- Jon On 2/26/18 11:47 AM, Igor Ignatyev wrote: > adding build-dev alias > > -- Igor > >> On Feb 8, 2018, at 3:08 PM, Ekaterina Pavlova wrote: >> >> Hi all, >> >> ProblemList.txt files used by makefiles for jtreg testing allow to specify list of tests to be excluded >> from execution on all or specific platforms. However to test such features like Graal we want to be able >> to specify list of failed tests which fail in particular JVM mode only. >> Please review this change which adds support of extra problem list and introduces 2 Graal specific problem list files. >> - test/hotspot/jtreg/ProblemList-graal.txt >> - test/jdk/ProblemList-graal.txt >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8197453 >> webrev: http://cr.openjdk.java.net/~epavlova//8197453/webrev.00/ >> testing: precheckin, tier1 and tier2 with empty EXTRA_PROBLEM_LISTS. >> testing in Graal mode with EXTRA_PROBLEM_LISTS=ProblemList-graal.txt >> >> thanks, >> -katya >> >> p.s. >> Igor Ignatyev volunteered to sponsor this change. From magnus.ihse.bursie at oracle.com Mon Feb 26 20:38:43 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 26 Feb 2018 21:38:43 +0100 Subject: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs Message-ID: It was recently discovered that some URLs in JDK 10 still pointed to the "javase9" URL base. I intend to push this to jdk10/master, given suffient approval. Bug: https://bugs.openjdk.java.net/browse/JDK-8198658 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8198658-update-docs-links-to-javase10/webrev.01 /Magnus From joe.darcy at oracle.com Mon Feb 26 20:57:30 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 26 Feb 2018 12:57:30 -0800 Subject: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs In-Reply-To: References: Message-ID: <8879f698-c34e-8a8c-affa-9a01cba95934@oracle.com> Hi Magnus, Looks okay for now, but longer term should the version be queried from the environment some way? Thanks, -Joe On 2/26/2018 12:38 PM, Magnus Ihse Bursie wrote: > It was recently discovered that some URLs in JDK 10 still pointed to > the "javase9" URL base. > > I intend to push this to jdk10/master, given suffient approval. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198658 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198658-update-docs-links-to-javase10/webrev.01 > > /Magnus > From martinrb at google.com Mon Feb 26 21:01:03 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 26 Feb 2018 13:01:03 -0800 Subject: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs In-Reply-To: References: Message-ID: http://www.oracle.com/pls/topic/lookup?ctx=javase10 currently takes you to java 9 docs On Mon, Feb 26, 2018 at 12:38 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > It was recently discovered that some URLs in JDK 10 still pointed to the > "javase9" URL base. > > I intend to push this to jdk10/master, given suffient approval. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198658 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8198658-update-docs-lin > ks-to-javase10/webrev.01 > > /Magnus > > From magnus.ihse.bursie at oracle.com Mon Feb 26 21:13:19 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 26 Feb 2018 22:13:19 +0100 Subject: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs In-Reply-To: References: Message-ID: <1b9c6eea-a2ed-b224-4026-655ba75d7046@oracle.com> On 2018-02-26 22:01, Martin Buchholz wrote: > http://www.oracle.com/pls/topic/lookup?ctx=javase10 currently takes > you to java 9 docs Noted. I assume the team on Oracle handling public web documentation will update this before the release of JDK 10. In any case, unless we fix the URL, there is nothing they can do. :-) /Magnus > > On Mon, Feb 26, 2018 at 12:38 PM, Magnus Ihse Bursie > > > wrote: > > It was recently discovered that some URLs in JDK 10 still pointed > to the "javase9" URL base. > > I intend to push this to jdk10/master, given suffient approval. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198658 > > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198658-update-docs-links-to-javase10/webrev.01 > > > /Magnus > > From magnus.ihse.bursie at oracle.com Mon Feb 26 21:12:24 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 26 Feb 2018 22:12:24 +0100 Subject: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs In-Reply-To: <8879f698-c34e-8a8c-affa-9a01cba95934@oracle.com> References: <8879f698-c34e-8a8c-affa-9a01cba95934@oracle.com> Message-ID: <5f0186a4-3b40-2d34-c050-0a28fde50dd0@oracle.com> On 2018-02-26 21:57, joe darcy wrote: > Hi Magnus, > > Looks okay for now, but longer term should the version be queried from > the environment some way? We'll have to look into the best way to solve this in a more robust way. I opened https://bugs.openjdk.java.net/browse/JDK-8198718 for that. /Magnus > > Thanks, > > -Joe > > > On 2/26/2018 12:38 PM, Magnus Ihse Bursie wrote: >> It was recently discovered that some URLs in JDK 10 still pointed to >> the "javase9" URL base. >> >> I intend to push this to jdk10/master, given suffient approval. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198658 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8198658-update-docs-links-to-javase10/webrev.01 >> >> /Magnus >> > From tim.bell at oracle.com Mon Feb 26 21:29:28 2018 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 26 Feb 2018 13:29:28 -0800 Subject: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs In-Reply-To: References: Message-ID: <5A947C38.9070701@oracle.com> Magnus: > It was recently discovered that some URLs in JDK 10 still pointed to the > "javase9" URL base. > > I intend to push this to jdk10/master, given suffient approval. Acting as leader of the build group, I decorated the bug report and applied a 'jdk10-fix-yes' label. > Bug: https://bugs.openjdk.java.net/browse/JDK-8198658 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198658-update-docs-links-to-javase10/webrev.01 Looks good. Tim From igor.ignatyev at oracle.com Mon Feb 26 23:07:54 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 26 Feb 2018 15:07:54 -0800 Subject: RFR(S) 8197453 : Add support of extra problem list In-Reply-To: References: Message-ID: <021011D1-8B1C-4E38-B57E-3B328BB4E308@oracle.com> Hi Jon, yes, they are. we will generic-all to each line. do you think it makes sense to file an RFE for jtreg to report a missed platform specifier as an error? Thanks, -- Igor > On Feb 26, 2018, at 12:02 PM, Jonathan Gibbons wrote: > > If these new problem-list files are destined for use by jtreg, I would encourage adding a platform specifier on each line, after the bug number. If you want to mark the test as excluded on all platforms, the convention is to use "generic-all". > > -- Jon > > > On 2/26/18 11:47 AM, Igor Ignatyev wrote: >> adding build-dev alias >> >> -- Igor >> >>> On Feb 8, 2018, at 3:08 PM, Ekaterina Pavlova wrote: >>> >>> Hi all, >>> >>> ProblemList.txt files used by makefiles for jtreg testing allow to specify list of tests to be excluded >>> from execution on all or specific platforms. However to test such features like Graal we want to be able >>> to specify list of failed tests which fail in particular JVM mode only. >>> Please review this change which adds support of extra problem list and introduces 2 Graal specific problem list files. >>> - test/hotspot/jtreg/ProblemList-graal.txt >>> - test/jdk/ProblemList-graal.txt >>> >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8197453 >>> webrev: http://cr.openjdk.java.net/~epavlova//8197453/webrev.00/ >>> testing: precheckin, tier1 and tier2 with empty EXTRA_PROBLEM_LISTS. >>> testing in Graal mode with EXTRA_PROBLEM_LISTS=ProblemList-graal.txt >>> >>> thanks, >>> -katya >>> >>> p.s. >>> Igor Ignatyev volunteered to sponsor this change. > From jonathan.gibbons at oracle.com Mon Feb 26 23:17:20 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 26 Feb 2018 15:17:20 -0800 Subject: RFR(S) 8197453 : Add support of extra problem list In-Reply-To: <021011D1-8B1C-4E38-B57E-3B328BB4E308@oracle.com> References: <021011D1-8B1C-4E38-B57E-3B328BB4E308@oracle.com> Message-ID: <5A949580.2050408@oracle.com> Igor, I think this is more a style issue than an issue we want to enforce. I think it is good style to use a platform specifier, including generic-all for "all platforms", so that people will realize they can put some more restrictive alternative. -- Jon On 02/26/2018 03:07 PM, Igor Ignatyev wrote: > Hi Jon, > > yes, they are. we will generic-all to each line. > > do you think it makes sense to file an RFE for jtreg to report a missed platform specifier as an error? > > Thanks, > -- Igor > >> On Feb 26, 2018, at 12:02 PM, Jonathan Gibbons wrote: >> >> If these new problem-list files are destined for use by jtreg, I would encourage adding a platform specifier on each line, after the bug number. If you want to mark the test as excluded on all platforms, the convention is to use "generic-all". >> >> -- Jon >> >> >> On 2/26/18 11:47 AM, Igor Ignatyev wrote: >>> adding build-dev alias >>> >>> -- Igor >>> >>>> On Feb 8, 2018, at 3:08 PM, Ekaterina Pavlova wrote: >>>> >>>> Hi all, >>>> >>>> ProblemList.txt files used by makefiles for jtreg testing allow to specify list of tests to be excluded >>>> from execution on all or specific platforms. However to test such features like Graal we want to be able >>>> to specify list of failed tests which fail in particular JVM mode only. >>>> Please review this change which adds support of extra problem list and introduces 2 Graal specific problem list files. >>>> - test/hotspot/jtreg/ProblemList-graal.txt >>>> - test/jdk/ProblemList-graal.txt >>>> >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8197453 >>>> webrev: http://cr.openjdk.java.net/~epavlova//8197453/webrev.00/ >>>> testing: precheckin, tier1 and tier2 with empty EXTRA_PROBLEM_LISTS. >>>> testing in Graal mode with EXTRA_PROBLEM_LISTS=ProblemList-graal.txt >>>> >>>> thanks, >>>> -katya >>>> >>>> p.s. >>>> Igor Ignatyev volunteered to sponsor this change. From magnus.ihse.bursie at oracle.com Mon Feb 26 23:40:50 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 27 Feb 2018 00:40:50 +0100 Subject: RFR: JDK-8198724 Refactor FLAGS handling in configure Message-ID: <92e6dbcd-dd59-7902-0bf9-fcae26c72346@oracle.com> The current way we're handling FLAGS (CFLAGS/CXXFLAGS, LDFLAGS, etc) is laden with technical debt. It's a sorry mess, hard to do anything constructive about. This is the first step towards a better solution. The main goal is to have a set of more specific flags, more like how the SYSROOT flags work today, that can be individually included, instead of a huge CFLAGS_JDKLIB. To make such a change manageable, this first step will (almost) only refactor the autoconf code, but will output the same flags in the spec.gmk. To minimize special cases, I have accepted the following differences: * On linux/gcc, we will get a -m, e.g. -m64 always (as on aix/solaris). * On macosx/clang, we will get a -m, e.g. -m64 always (as on aix/solaris). * On macosx/clang, we will now "hardcode" the max/min version number without dots. * On macosx/clang, the JVM_CFLAGS for the build toolchain will now also get an -fPIC (this was mysteriously missing before). * On windows/microsoft, the build toolchain will now get -nologo added as well, and also -homeparams for debug builds. * On solaris/solstudio, the JDKEXE flags will now include -errfmt, and CFLAGS_JDKEXE will include -errtags=yes. The duplication of -errtags=yes in CXXFLAGS_JDKLIB is removed. * On solaris/solstudio, we now always use -KPIC as pic flag. (Previously, we used -xcode=pic32 on sparc, but this is equivalent to -KPIC, so there's no reason for a special case.) * On solaris/solstudio, we now use e.g. "-Wc,-Qrm-s" instead of "-Qoption cg -Qrm-s" for C++ as well as for C code. The two formats are equivalent (for passing options to a certain compilation phase), and there was no reason to use different ones for C and C++. And for clarity, I have also renamed some exported flags to clearly show that they are consumed by LIBJSIG and ADLC. I have also renamed "/STACK" on the Microsoft linker to "-stack", to match how we write options elsewhere. I believe none of these should have any real effect, but if anything, they could probably be considered bug fixes. I have considered whitespace and ordering differences as irrelevant. I have manually verified that the generated spec.gmk and buildjdk-spec.gmk matches this (no changes apart from the one listed above) for linux/x64/gcc, solaris/sparcv9/solstudio, windows/x64/microsoft and macosx/x64/clang, for release and fastdebug. I am also currently running a test job using the COMPARE_BUILD functionality on our internal build system. I would appreciate if comments are more in the form of "think of this for subsequent updates to the flag handling" rather than requests to change this patch, at least for requests that are just not small fixes. (I've been juggling this for a while, trying to get it right...) Bug: https://bugs.openjdk.java.net/browse/JDK-8198724 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8198724-refactor-flags-step-1/webrev.01 /Magnus From joe.darcy at oracle.com Tue Feb 27 00:31:16 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 26 Feb 2018 16:31:16 -0800 Subject: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20 In-Reply-To: <8a485f43-b7c2-a34a-67aa-ab434acb84eb@oracle.com> References: <72502983-8ae7-ee2f-dc33-3622f14756e2@oracle.com> <8a485f43-b7c2-a34a-67aa-ab434acb84eb@oracle.com> Message-ID: <379975ce-6344-9612-30e6-3ac6374aa59e@oracle.com> PS JDK 11 b02 bits now available for download: ??? http://jdk.java.net/11/ Cheers, -Joe On 2/21/2018 5:47 PM, joe darcy wrote: > On 2/21/2018 12:54 PM, Martin Buchholz wrote: > >> On Tue, Feb 20, 2018 at 11:09 PM, Abhijit Saha >> wrote: >> >>> It's a retroactive review request. Fix has been integrated after >>> reviewed >>> internally. >>> >>> jdk11+1 (first build of jdk11) was promoted with incorrect Release >>> Date. >>> Need to be updated with correct GA date as per internal release >>> roadmap. >>> >> Where are my shiny jdk11+1 binaries for download ?! >> >> It would be nice if version information was always correct, which would >> mean part of the checklist of creating a release repo would be >> setting the >> release date of jdk/jdk/ 6 months later and marking it "ea" and updating >> the version to self-identify as java N+1.? jdk binaries built from >> jdk/jdk >> have been misidentifying themselves since the jdk 10 repo was created. > > Certainly it would be preferable if the version update occurred sooner. > > However, binaries build from jdk/jdk have been correctly identifying > themselves as "JDK 11" since David Holmes pushed the fix for 8173401: > "Update VERSION_FEATURE for JDK 11" on February 6, 2018. > > There are about half a dozen distinct changes that need to occur for a > full conceptual version update going from JDK N to JDK (N+1). Besides > the actual version update, there are -source/-target changes to javac, > minor API changes, etc. > > Some of the changes made in JDK 11 b01 were done specifically to ease > future version updates. This included hardening various tests against > version updates. Since the version updates are happening more often > now, there is more motivation to streamline the process > (https://xkcd.com/1205/). > > -Joe From martinrb at google.com Tue Feb 27 04:22:08 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 26 Feb 2018 20:22:08 -0800 Subject: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20 In-Reply-To: <379975ce-6344-9612-30e6-3ac6374aa59e@oracle.com> References: <72502983-8ae7-ee2f-dc33-3622f14756e2@oracle.com> <8a485f43-b7c2-a34a-67aa-ab434acb84eb@oracle.com> <379975ce-6344-9612-30e6-3ac6374aa59e@oracle.com> Message-ID: On Mon, Feb 26, 2018 at 4:31 PM, joe darcy wrote: > PS JDK 11 b02 bits now available for download: > > http://jdk.java.net/11/ Thanks, I am enjoying my jdk-11-ea+02 binaries. Consistent with the new model of a repo always at head (which is awesome) how about simply continuously putting out a new build every week? No need for hiatus due to release N-1 schedule concerns. And could someone provide api javadoc at a stable location so that I can link to it in a way that won't become dangling? https://download.java.net/java/early_access/jdk11/docs/api/overview-summary.html is nice but is too ephemeral. From magnus.ihse.bursie at oracle.com Tue Feb 27 11:15:45 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 27 Feb 2018 12:15:45 +0100 Subject: RFR: JDK-8198751 Refactor SetupNativeCompilation to take NAME and TYPE Message-ID: Currently, SetupNativeCompilation takes as "main" argument either LIBRARY := $name, PROGRAM := $name or STATIC_LIBRARY := $name. This confounds two distinct concepts: the name of the generated binary, and the type of binary to create. Instead, we should have a NAME argument and a TYPE argument. I also took the liberty of updating the code to more modern standards wrt whitespace, and fixed the "Yoda style" if conditions. Bug: https://bugs.openjdk.java.net/browse/JDK-8198751 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8198751-fix-NativeCompilation-NAME-and-TYPE/webrev.01 /Magnus From ekaterina.pavlova at oracle.com Tue Feb 27 17:45:57 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Tue, 27 Feb 2018 09:45:57 -0800 Subject: RFR(S) 8197453 : Add support of extra problem list In-Reply-To: References: Message-ID: <565cbc8c-64e7-8fd8-65a8-84564b2ce49b@oracle.com> Jon, thanks for the review. I have updated the webrev. thanks, -katya On 2/26/18 12:02 PM, Jonathan Gibbons wrote: > If these new problem-list files are destined for use by jtreg, I would encourage adding a platform specifier on each line, after the bug number. If you want to mark the test as excluded on all platforms, the convention is to use "generic-all". > > -- Jon > > > On 2/26/18 11:47 AM, Igor Ignatyev wrote: >> adding build-dev alias >> >> -- Igor >> >>> On Feb 8, 2018, at 3:08 PM, Ekaterina Pavlova wrote: >>> >>> Hi all, >>> >>> ProblemList.txt files used by makefiles for jtreg testing allow to specify list of tests to be excluded >>> from execution on all or specific platforms. However to test such features like Graal we want to be able >>> to specify list of failed tests which fail in particular JVM mode only. >>> Please review this change which adds support of extra problem list and introduces 2 Graal specific problem list files. >>> - test/hotspot/jtreg/ProblemList-graal.txt >>> - test/jdk/ProblemList-graal.txt >>> >>> >>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8197453 >>> ? webrev: http://cr.openjdk.java.net/~epavlova//8197453/webrev.00/ >>> testing: precheckin, tier1 and tier2 with empty EXTRA_PROBLEM_LISTS. >>> ????????? testing in Graal mode with EXTRA_PROBLEM_LISTS=ProblemList-graal.txt >>> >>> thanks, >>> -katya >>> >>> p.s. >>> Igor Ignatyev volunteered to sponsor this change. > From igor.ignatyev at oracle.com Tue Feb 27 22:57:40 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 27 Feb 2018 14:57:40 -0800 Subject: RFR(S) 8197453 : Add support of extra problem list In-Reply-To: <565cbc8c-64e7-8fd8-65a8-84564b2ce49b@oracle.com> References: <565cbc8c-64e7-8fd8-65a8-84564b2ce49b@oracle.com> Message-ID: <2DABAAAE-077E-4832-999D-000D021019B8@oracle.com> Hi Katya, the fix looks good to me. -- Igor > On Feb 27, 2018, at 9:45 AM, Ekaterina Pavlova wrote: > > Jon, > > thanks for the review. > I have updated the webrev. > > thanks, > -katya > > > On 2/26/18 12:02 PM, Jonathan Gibbons wrote: >> If these new problem-list files are destined for use by jtreg, I would encourage adding a platform specifier on each line, after the bug number. If you want to mark the test as excluded on all platforms, the convention is to use "generic-all". >> -- Jon >> On 2/26/18 11:47 AM, Igor Ignatyev wrote: >>> adding build-dev alias >>> >>> -- Igor >>> >>>> On Feb 8, 2018, at 3:08 PM, Ekaterina Pavlova wrote: >>>> >>>> Hi all, >>>> >>>> ProblemList.txt files used by makefiles for jtreg testing allow to specify list of tests to be excluded >>>> from execution on all or specific platforms. However to test such features like Graal we want to be able >>>> to specify list of failed tests which fail in particular JVM mode only. >>>> Please review this change which adds support of extra problem list and introduces 2 Graal specific problem list files. >>>> - test/hotspot/jtreg/ProblemList-graal.txt >>>> - test/jdk/ProblemList-graal.txt >>>> >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8197453 >>>> webrev: http://cr.openjdk.java.net/~epavlova//8197453/webrev.00/ >>>> testing: precheckin, tier1 and tier2 with empty EXTRA_PROBLEM_LISTS. >>>> testing in Graal mode with EXTRA_PROBLEM_LISTS=ProblemList-graal.txt >>>> >>>> thanks, >>>> -katya >>>> >>>> p.s. >>>> Igor Ignatyev volunteered to sponsor this change. > From tim.bell at oracle.com Wed Feb 28 16:38:14 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 28 Feb 2018 08:38:14 -0800 Subject: RFR: JDK-8198751 Refactor SetupNativeCompilation to take NAME and TYPE In-Reply-To: References: Message-ID: <5A96DAF6.5050103@oracle.com> Magnus: > Currently, SetupNativeCompilation takes as "main" argument either > LIBRARY := $name, PROGRAM := $name or STATIC_LIBRARY := $name. > > This confounds two distinct concepts: the name of the generated binary, > and the type of binary to create. Instead, we should have a NAME > argument and a TYPE argument. > > I also took the liberty of updating the code to more modern standards > wrt whitespace, and fixed the "Yoda style" if conditions. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198751 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8198751-fix-NativeCompilation-NAME-and-TYPE/webrev.01 Looks good. /Tim From lance.andersen at oracle.com Wed Feb 28 18:25:55 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 28 Feb 2018 13:25:55 -0500 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module Message-ID: Hi all, This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa package will be subsumed by Java SE. There should be no compatibility issues with this change. Any module that `requires java.sql` will continue to have access to the public classes in the javax.transaction.xa package at both compile-time and run-time. The CSR has been approved The webrev can be found at: http://cr.openjdk.java.net/~lancea/8197533/webrev.00/ Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From paul.sandoz at oracle.com Wed Feb 28 18:40:38 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 28 Feb 2018 10:40:38 -0800 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module In-Reply-To: References: Message-ID: Compatible module refactoring in action! Looks good, one comment: test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java This is not a valid Java source file can you merge the jtreg meta data into XAExceptionTests instead? Paul. > On Feb 28, 2018, at 10:25 AM, Lance Andersen wrote: > > Hi all, > > This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa package will be subsumed by Java SE. > > There should be no compatibility issues with this change. Any module that `requires java.sql` will continue to have access to the public classes in the javax.transaction.xa package at both compile-time and run-time. > > > The CSR has been approved > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8197533/webrev.00/ > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Wed Feb 28 19:20:45 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 28 Feb 2018 14:20:45 -0500 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module In-Reply-To: References: Message-ID: <0EC6FFD0-31EA-4D24-B82D-C4D5DCAB8E65@oracle.com> Hi Paul, Thank you for the review. > On Feb 28, 2018, at 1:40 PM, Paul Sandoz wrote: > > Compatible module refactoring in action! > > Looks good, one comment: > > test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java > > This is not a valid Java source file can you merge the jtreg meta data into XAExceptionTests instead? As we discussed offline, I will change the above file and Driver.java. I naively assumed this was OK as the change to add Driver.java was made after I had originally added these tests in 2015. Best Lance > > Paul. > >> On Feb 28, 2018, at 10:25 AM, Lance Andersen > wrote: >> >> Hi all, >> >> This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa package will be subsumed by Java SE. >> >> There should be no compatibility issues with this change. Any module that `requires java.sql` will continue to have access to the public classes in the javax.transaction.xa package at both compile-time and run-time. >> >> >> The CSR has been approved >> >> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8197533/webrev.00/ >> >> Best >> Lance >> > >> > > >> >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Wed Feb 28 19:43:59 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Feb 2018 19:43:59 +0000 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module In-Reply-To: References: Message-ID: On 28/02/2018 18:25, Lance Andersen wrote: > Hi all, > > This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa package will be subsumed by Java SE. > > There should be no compatibility issues with this change. Any module that `requires java.sql` will continue to have access to the public classes in the javax.transaction.xa package at both compile-time and run-time. > > I skipped the tests but everything else looks good. It is a compatible change as you noted. Is there any XA text from the original JTA spec that should be added to the module description as part of this? Another way to ask this is whether the JTA 1.3 drops any text dealing with the XA part. -Alan From lance.andersen at oracle.com Wed Feb 28 19:54:56 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 28 Feb 2018 14:54:56 -0500 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module In-Reply-To: References: Message-ID: <98DD56F9-A3F0-4D1D-BCCA-C72220225074@oracle.com> > On Feb 28, 2018, at 2:43 PM, Alan Bateman wrote: > > On 28/02/2018 18:25, Lance Andersen wrote: >> Hi all, >> >> This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa package will be subsumed by Java SE. >> >> There should be no compatibility issues with this change. Any module that `requires java.sql` will continue to have access to the public classes in the javax.transaction.xa package at both compile-time and run-time. >> >> > I skipped the tests but everything else looks good. It is a compatible change as you noted. Thank you Alan > > Is there any XA text from the original JTA spec that should be added to the module description as part of this? Another way to ask this is whether the JTA 1.3 drops any text dealing with the XA part. Still waiting to see what changes are made to the PDF spec, that is still needing to be completed. So I think for now, we go with what we have and can circle back if needed. Best Lance > > -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From magnus.ihse.bursie at oracle.com Wed Feb 28 20:12:49 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Feb 2018 21:12:49 +0100 Subject: RFR: JDK-8198844 Clean up GensrcX11Wrappers Message-ID: My hunt on technical debt continues. This time my aim has been on the sorry mess known as GensrcX11Wrappers. I've disentangled it into two functions, one simple gensrc part that is actually run during the build, and which involves just a simple java tool and some pre-calculated data files, and a separate step for updating those pre-calculated data files. This step is now run using "make update-x11wrappers". It involves compiling a native binary, and running it on the target platform, so just as before, this assumes that you are not cross-compiling. I'm not sure what role the "verification" step we had before ever played. For all the years we've been "verifying" this, we've detected no differences. In fact, as far as I understand, what we *really* would need to verify against, is the X11 libraries on the runtime system, i.e. where the users executes the JRE. But then again, we can assume that this matches, just as anyone compiling with header files on one place can assume that they can use the libraries elsewhere. The only reason, as I see it, to keep the generation in the makefiles at all, is to document how the files were generated, and to be ready for the need to update the files if the list of datatypes in xlibtypes.txt changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8198844 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.01 /Magnus From lance.andersen at oracle.com Wed Feb 28 21:22:15 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 28 Feb 2018 16:22:15 -0500 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module In-Reply-To: <0EC6FFD0-31EA-4D24-B82D-C4D5DCAB8E65@oracle.com> References: <0EC6FFD0-31EA-4D24-B82D-C4D5DCAB8E65@oracle.com> Message-ID: <144F8EF0-0020-4577-8F9B-3FC86AF8ED4A@oracle.com> > On Feb 28, 2018, at 2:20 PM, Lance Andersen wrote: > > Hi Paul, > > Thank you for the review. >> On Feb 28, 2018, at 1:40 PM, Paul Sandoz > wrote: >> >> Compatible module refactoring in action! >> >> Looks good, one comment: >> >> test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java >> >> This is not a valid Java source file can you merge the jtreg meta data into XAExceptionTests instead? > > As we discussed offline, I will change the above file and Driver.java. I naively assumed this was OK as the change to add Driver.java was made after I had originally added these tests in 2015. http://cr.openjdk.java.net/~lancea/8197533/webrev.01/ has the updated tests Best Lance > > Best > Lance >> >> Paul. >> >>> On Feb 28, 2018, at 10:25 AM, Lance Andersen >> wrote: >>> >>> Hi all, >>> >>> This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa package will be subsumed by Java SE. >>> >>> There should be no compatibility issues with this change. Any module that `requires java.sql` will continue to have access to the public classes in the javax.transaction.xa package at both compile-time and run-time. >>> >>> >>> The CSR has been approved >>> >>> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8197533/webrev.00/ >>> >>> Best >>> Lance >>> >> >>> >> >> >>> >>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com > >> > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From magnus.ihse.bursie at oracle.com Wed Feb 28 21:51:53 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Feb 2018 22:51:53 +0100 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module In-Reply-To: References: Message-ID: On 2018-02-28 19:25, Lance Andersen wrote: > Hi all, > > This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa package will be subsumed by Java SE. > > There should be no compatibility issues with this change. Any module that `requires java.sql` will continue to have access to the public classes in the javax.transaction.xa package at both compile-time and run-time. > > > The CSR has been approved > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8197533/webrev.00/ Build changes look good. /Magnus > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From joe.darcy at oracle.com Wed Feb 28 21:55:15 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 28 Feb 2018 13:55:15 -0800 Subject: RFR JDK-8197533 move javax.transaction.xa into its own module In-Reply-To: <144F8EF0-0020-4577-8F9B-3FC86AF8ED4A@oracle.com> References: <0EC6FFD0-31EA-4D24-B82D-C4D5DCAB8E65@oracle.com> <144F8EF0-0020-4577-8F9B-3FC86AF8ED4A@oracle.com> Message-ID: <5da666dc-07e7-17ee-80bc-25fa08aa1830@oracle.com> Hi Lance, I'd prefer if src/java.sql/share/classes/javax/transaction/xa/package.html was replaced by a package-info.java files as opposed to another package.html file in the new module. Thanks, -Joe On 2/28/2018 1:22 PM, Lance Andersen wrote: >> On Feb 28, 2018, at 2:20 PM, Lance Andersen wrote: >> >> Hi Paul, >> >> Thank you for the review. >>> On Feb 28, 2018, at 1:40 PM, Paul Sandoz > wrote: >>> >>> Compatible module refactoring in action! >>> >>> Looks good, one comment: >>> >>> test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java >>> >>> This is not a valid Java source file can you merge the jtreg meta data into XAExceptionTests instead? >> As we discussed offline, I will change the above file and Driver.java. I naively assumed this was OK as the change to add Driver.java was made after I had originally added these tests in 2015. > http://cr.openjdk.java.net/~lancea/8197533/webrev.01/ has the updated tests > Best > Lance >> Best >> Lance >>> Paul. >>> >>>> On Feb 28, 2018, at 10:25 AM, Lance Andersen >> wrote: >>>> >>>> Hi all, >>>> >>>> This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa package will be subsumed by Java SE. >>>> >>>> There should be no compatibility issues with this change. Any module that `requires java.sql` will continue to have access to the public classes in the javax.transaction.xa package at both compile-time and run-time. >>>> >>>> >>>> The CSR has been approved >>>> >>>> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8197533/webrev.00/ >>>> >>>> Best >>>> Lance >>>> >> >>>> >> >> >>>> >>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com > >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > >