From erik.joelsson at oracle.com Fri Jul 1 14:07:17 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Jul 2016 16:07:17 +0200 Subject: RFR: JDK-8160722: Module summary generation fails on Windows 32bit Message-ID: <57767915.4010406@oracle.com> Hello, Again we are hit with a build problem involving -Xmx and only building server on Windows 32bit. The module summary generation build step is run on the just built jdk (just like a bootcycle build). Now we face a similar issue with this summary generation, which uses a fixed setting of -Xmx1100M. In JDK-8160571 we learned that this is sometimes too much for the server JVM on Windows 32bit and now we see failures because of it. My proposed fix is to set the jvm arguments for this to the same as is now being calculated for the bootcycle jvm args since JDK-8160571. Bug: https://bugs.openjdk.java.net/browse/JDK-8160722 Patch: diff -r 31261e7238af common/autoconf/spec.gmk.in --- a/common/autoconf/spec.gmk.in +++ b/common/autoconf/spec.gmk.in @@ -578,7 +578,7 @@ JAVAC_FLAGS?=@JAVAC_FLAGS@ -BUILD_JAVA_FLAGS:=-Xms64M -Xmx1100M +BUILD_JAVA_FLAGS := @BOOTCYCLE_JVM_ARGS_BIG@ BUILD_JAVA=@FIXPATH@ $(BUILD_JDK)/bin/java $(BUILD_JAVA_FLAGS) # Use ?= as this can be overridden from bootcycle-spec.gmk /Erik From tim.bell at oracle.com Fri Jul 1 14:49:23 2016 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 01 Jul 2016 07:49:23 -0700 Subject: RFR: JDK-8160722: Module summary generation fails on Windows 32bit In-Reply-To: <57767915.4010406@oracle.com> References: <57767915.4010406@oracle.com> Message-ID: <577682F3.6070807@oracle.com> Erik: > Again we are hit with a build problem involving -Xmx and only building > server on Windows 32bit. The module summary generation build step is > run on the just built jdk (just like a bootcycle build). Now we face a > similar issue with this summary generation, which uses a fixed setting > of -Xmx1100M. In JDK-8160571 we learned that this is sometimes too > much for the server JVM on Windows 32bit and now we see failures > because of it. > > My proposed fix is to set the jvm arguments for this to the same as is > now being calculated for the bootcycle jvm args since JDK-8160571. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160722 > Patch: > diff -r 31261e7238af common/autoconf/spec.gmk.in > --- a/common/autoconf/spec.gmk.in > +++ b/common/autoconf/spec.gmk.in > @@ -578,7 +578,7 @@ > JAVAC_FLAGS?=@JAVAC_FLAGS@ > > > -BUILD_JAVA_FLAGS:=-Xms64M -Xmx1100M > +BUILD_JAVA_FLAGS := @BOOTCYCLE_JVM_ARGS_BIG@ > BUILD_JAVA=@FIXPATH@ $(BUILD_JDK)/bin/java $(BUILD_JAVA_FLAGS) > > # Use ?= as this can be overridden from bootcycle-spec.gmk Looks good to me. /Tim From erik.joelsson at oracle.com Fri Jul 1 15:44:24 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Jul 2016 17:44:24 +0200 Subject: RFR: JDK-8160728: Update compare script to clean baseline Message-ID: <57768FD8.8050606@oracle.com> Several things have happened recently that affect the compare script's ability to do clean comparisons for build change verification. * The SystemModules.class has even more randomness in it and it currently doesn't look like it can be reliably compared at all. * The new lib/classlist file may have lines in different order between builds. * Support comparing the new licensee-src build mode. By fixing this I'm again able to do a full -testset buildinfra JPRT COMPARE_BUILD build using an empty patch and get a clean result. Bug: https://bugs.openjdk.java.net/browse/JDK-8160728 Webrev: http://cr.openjdk.java.net/~erikj/8160728/webrev.top.01/ /Erik From tim.bell at oracle.com Fri Jul 1 15:56:28 2016 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 01 Jul 2016 08:56:28 -0700 Subject: RFR: JDK-8160728: Update compare script to clean baseline In-Reply-To: <57768FD8.8050606@oracle.com> References: <57768FD8.8050606@oracle.com> Message-ID: <577692AC.2000106@oracle.com> Erik: > Several things have happened recently that affect the compare script's > ability to do clean comparisons for build change verification. > > * The SystemModules.class has even more randomness in it and it > currently doesn't look like it can be reliably compared at all. > * The new lib/classlist file may have lines in different order between > builds. > * Support comparing the new licensee-src build mode. > > By fixing this I'm again able to do a full -testset buildinfra JPRT > COMPARE_BUILD build using an empty patch and get a clean result. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160728 > Webrev: http://cr.openjdk.java.net/~erikj/8160728/webrev.top.01/ Looks good to me. /Tim From erik.joelsson at oracle.com Fri Jul 1 17:47:06 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Jul 2016 19:47:06 +0200 Subject: RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed Message-ID: <5776AC9A.5000400@oracle.com> The separation between OpenJDK and Oracle's closed additions have historically been quite messy. The build-infra project has tried to improve on this, but failed in one regard, which was to hard code all references to "closed" source instead of using a variable. I decided to finally fix this. Along the way, I found that there weren't that many references left in open makefiles, which is a good thing. OpenJDK should not be tainted with Oracle specific stuff unnecessarily. So then I decided to completely remove the last references as part of fixing this bug. With this patch, the following is now in effect: * There is no longer a variable named "OPENJDK". That variable was confusing and got in the way of other people trying to add custom additions to the OpenJDK code base. In configure there is now only "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only option. This variable can be read by custom extensions to configure and should be used to disable those custom extensions. * There is no Oracle specific logic left in open makefiles. All customizations and references to custom source should be done in custom makefiles, included using the IncludeCustomExtension macro. I have converted the last uses of "ifndef OPENJDK" to such constructs. I have moved all Oracle specific mapfiles out of the open jdk repository. Specifically to 2d-dev reviewers, I have moved jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java out of the open as well. This file has been explicitly excluded from all open builds since forever AFAICT. I see no reason for it be in the open. If someone would like to read the source outside of Oracle, it will still be in the hg history. I have tested these changes extensively using the compare script and -testset buildinfra in JPRT. This covers a wide variety of build configurations so I feel pretty confident that it won't break anything. Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ /Erik From philip.race at oracle.com Fri Jul 1 17:59:38 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 01 Jul 2016 10:59:38 -0700 Subject: RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <5776AC9A.5000400@oracle.com> References: <5776AC9A.5000400@oracle.com> Message-ID: <5776AF8A.9040505@oracle.com> erik, SUPPRESS_CUSTOM_SOURCE" FWIW "CLOSED" implies better to me what this is about than "CUSTOM". Can't this be SUPPRESS_CLOSED_SOURCE ? http://cr.openjdk.java.net/~erikj/8003593/webrev.01/jdk/make/mapfiles/libfontmanager/mapfile-vers.sdiff.html Regarding all the freetype symbols in here .. they aren't used in the Oracle JDK, so is there another closed version of this file for the 'custom' source ? 57 ifdef OPENJDK 458 BUILD_LIBJAVAJPEG_MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers 459 else 460 BUILD_LIBJAVAJPEG_MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers-closed 461 LIBJAVAJPEG_SRC += $(JDK_TOPDIR)/src/closed/java.desktop/share/native/libjavajpeg 462 endif 463 Where is the closed replacement for this ? In another review you will send out internally ? > I have tested these changes extensively using the compare script and -testset buildinfra in JPRT So this verifies the resulting "bits" are correct ? .. and that includes the various combinations you are providing ? - build openjdk in presence of only openjdk - build oracle jdk in presence of open+closed - build 'openjdk-only" in presence of open+closed -phil. On 07/01/2016 10:47 AM, Erik Joelsson wrote: > The separation between OpenJDK and Oracle's closed additions have > historically been quite messy. The build-infra project has tried to > improve on this, but failed in one regard, which was to hard code all > references to "closed" source instead of using a variable. I decided > to finally fix this. Along the way, I found that there weren't that > many references left in open makefiles, which is a good thing. OpenJDK > should not be tainted with Oracle specific stuff unnecessarily. So > then I decided to completely remove the last references as part of > fixing this bug. With this patch, the following is now in effect: > > * There is no longer a variable named "OPENJDK". That variable was > confusing and got in the way of other people trying to add custom > additions to the OpenJDK code base. In configure there is now only > "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only > option. This variable can be read by custom extensions to configure > and should be used to disable those custom extensions. > > * There is no Oracle specific logic left in open makefiles. All > customizations and references to custom source should be done in > custom makefiles, included using the IncludeCustomExtension macro. I > have converted the last uses of "ifndef OPENJDK" to such constructs. > > I have moved all Oracle specific mapfiles out of the open jdk repository. > > Specifically to 2d-dev reviewers, I have moved > jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java > out of the open as well. This file has been explicitly excluded from > all open builds since forever AFAICT. I see no reason for it be in the > open. If someone would like to read the source outside of Oracle, it > will still be in the hg history. > > I have tested these changes extensively using the compare script and > -testset buildinfra in JPRT. This covers a wide variety of build > configurations so I feel pretty confident that it won't break anything. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 > Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ > > /Erik From erik.joelsson at oracle.com Fri Jul 1 18:16:33 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Jul 2016 20:16:33 +0200 Subject: RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <5776AF8A.9040505@oracle.com> References: <5776AC9A.5000400@oracle.com> <5776AF8A.9040505@oracle.com> Message-ID: <5776B381.9020304@oracle.com> On 2016-07-01 19:59, Phil Race wrote: > erik, > > SUPPRESS_CUSTOM_SOURCE" > FWIW "CLOSED" implies better to me what this is about than "CUSTOM". > Can't this be SUPPRESS_CLOSED_SOURCE ? > "custom" is a term that we have been using for a while now instead of "closed" in the open parts of the build to refer to any kind of custom addition to OpenJDK. There are quite a few instances of macros and variables named that way, mostly in configure but also in the makefiles. If we were to change this variable to "closed", then the other places should go with it to match. I think that's a separate change that require a separate discussion. > http://cr.openjdk.java.net/~erikj/8003593/webrev.01/jdk/make/mapfiles/libfontmanager/mapfile-vers.sdiff.html > > > Regarding all the freetype symbols in here .. they aren't used in the > Oracle JDK, so is there another > closed version of this file for the 'custom' source ? > Yes, it's in the closed review. The pattern is to have open mapfiles in the open and OracleJDK specific mapfiles in the Oracle closed repository. > 57 ifdef OPENJDK > 458 BUILD_LIBJAVAJPEG_MAPFILE := > $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers > 459 else > 460 BUILD_LIBJAVAJPEG_MAPFILE := > $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers-closed > 461 LIBJAVAJPEG_SRC += > $(JDK_TOPDIR)/src/closed/java.desktop/share/native/libjavajpeg > 462 endif > 463 > > Where is the closed replacement for this ? In another review you will > send out internally ? > Yes. >> I have tested these changes extensively using the compare script and >> -testset buildinfra in JPRT > So this verifies the resulting "bits" are correct ? > Yes. I went through a number of iterations to iron out all the details using this technique. It's quite powerful. > .. and that includes the various combinations you are providing ? > - build openjdk in presence of only openjdk > - build oracle jdk in presence of open+closed > - build 'openjdk-only" in presence of open+closed > Actually the first one is missing because of how JPRT works, but I could run an extra round with just that. That case is the least complicated however since it will just build what is there. /Erik From rob at bits2order.com Fri Jul 1 22:50:20 2016 From: rob at bits2order.com (Bits2Order) Date: Fri, 1 Jul 2016 17:50:20 -0500 Subject: CoreServices/CoreServices.h problem building JDK 9 for IOS Message-ID: <5732EAB3-76EF-4DA8-B6CC-CC3879CD449A@bits2order.com> Resending, my apologies if this is a duplicate. I?ve been trying to build JDK 9 for IOS following these instructions . I?ve set LOG=debug when I build to get as much information as possible. I?m running OS X 10.11.5 and Xcode 7.3.1 I?m able to create a simple c that includes CoreServices/CoreServices.h and build without any problem, I?m not sure if the build points to an incorrect build path for CoreServices, but if it does I didn?t see where. Any help would be appreciated. Compiling KeystoreImpl.m (for libosxsecurity.dylib) /usr/bin/sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e 's/^[ ]*//' -e '/^$/ d' -e 's/$/ :/' /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libnio/Net.d > /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libnio/Net.d.targets ( ( /usr/bin/clang -x objective-c -D_LITTLE_ENDIAN -DMACOSX -D_LP64=1 -DARCH='"x86_64"' -Dx86_64 -DNDEBUG -DMACOSX -D_ALLBSD_SOURCE -D_DARWIN_UNLIMITED_SELECT -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/share/native/include -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/macosx/native/include -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/unix/native/include -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/share/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/unix/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/macosx/native/libosxsecurity -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/macosx/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/unix/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/share/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/macosx/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/unix/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/share/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/headers/java.base -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk -iframework /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks -F /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks/JavaVM.framework/Frameworks -Os -DTHIS_FILE='"KeystoreImpl.m"' -c -MMD -MF /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libosxsecurity/KeystoreImpl.d -o /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libosxsecurity/KeystoreImpl.o /Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m > >(/usr/bin/tee /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libosxsecurity/KeystoreImpl.o.log) 2> >(/usr/bin/tee /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libosxsecurity/KeystoreImpl.o.log >&2) || ( exitcode=$? && /bin/cp /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libosxsecurity/KeystoreImpl.o.log /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/make-support/failure-logs/buildjdk_support_native_java.base_libosxsecurity_KeystoreImpl.o.log && exit $exitcode ) ) && wait ) Linking libverify.dylib /Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/macosx/native/libnio/fs/UTIFileTypeDetector.c:30:10: fatal error: 'CoreServices/CoreServices.h' file not found #include From david.holmes at oracle.com Sat Jul 2 11:53:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 2 Jul 2016 21:53:36 +1000 Subject: Status of building problem with GCC 6 In-Reply-To: <368525CD-7C70-421F-9AEF-0A3D47952DAA@oracle.com> References: <055c177f-a26b-39b1-41a3-50df6aead626@gmail.com> <368525CD-7C70-421F-9AEF-0A3D47952DAA@oracle.com> Message-ID: <9f772d6d-88a6-55be-5fab-7654f7d8f558@oracle.com> cc'ing build-dev - don't understand why they are not part of this. The build team now owns the hotspot build. Unfortunately Erik J. is now on vacation for a couple of weeks. David On 2/07/2016 5:13 AM, Kim Barrett wrote: >> On Jul 1, 2016, at 10:17 AM, Yasumasa Suenaga wrote: >> For HotSpot, I think JDK-8156980 should be fixed at first. >> I've proposed changes as below: >> >> ----------- >> diff -r ba08710f3b6c make/lib/CompileJvm.gmk >> --- a/make/lib/CompileJvm.gmk Mon Jun 27 09:35:18 2016 +0200 >> +++ b/make/lib/CompileJvm.gmk Tue Jun 28 12:10:09 2016 +0900 >> @@ -187,6 +187,11 @@ >> >> JVM_OPTIMIZATION ?= HIGHEST_JVM >> >> +JVM_CXXFLAGS := $(JVM_CFLAGS) >> +ifeq ($(TOOLCHAIN_TYPE), gcc) >> + JVM_CXXFLAGS += -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse >> +endif >> + >> ################################################################################ >> # Now set up the actual compilation of the main hotspot native library >> >> @@ -202,6 +207,7 @@ >> CFLAGS := $(JVM_CFLAGS), \ >> CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ >> CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ >> + CXXFLAGS := $(JVM_CXXFLAGS), \ >> vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ >> DISABLED_WARNINGS_clang := delete-non-virtual-dtor dynamic-class-memaccess \ >> empty-body format logical-op-parentheses parentheses \ >> ????? > > Please keep in mind that my understanding of the new build system is > pretty weak. That said, this doesn't look to me like the right way to > fix JDK-8156980. > > There is already code that is supposed to deal with both the -std > option and the additional code generation options, which seems to work > for some of the packages that we build, but is not affecting the > Hotspot build for some reason. Adding a completely separate way to > deal with this just for Hotspot seems contrary to the unification > effort that was part of the new build system. > > -fno-lifetime-dse is a relatively recent option, and needs to be > conditionalized. And discussion during the review of JDK-8151841 led > to the additional code generation options being limited to gcc6+. > The existing code mentioned above is conditionalizing that way, except > it's just not working for Hotspot. > From david.holmes at oracle.com Sat Jul 2 21:39:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Sun, 3 Jul 2016 07:39:30 +1000 Subject: CoreServices/CoreServices.h problem building JDK 9 for IOS In-Reply-To: <5732EAB3-76EF-4DA8-B6CC-CC3879CD449A@bits2order.com> References: <5732EAB3-76EF-4DA8-B6CC-CC3879CD449A@bits2order.com> Message-ID: Moving to mobile-dev list David On 2/07/2016 8:50 AM, Bits2Order wrote: > Resending, my apologies if this is a duplicate. > > I?ve been trying to build JDK 9 for IOS following these instructions . I?ve set LOG=debug when I build to get as much information as possible. I?m running OS X 10.11.5 and Xcode 7.3.1 I?m able to create a simple c that includes CoreServices/CoreServices.h and build without any problem, I?m not sure if the build points to an incorrect build path for CoreServices, but if it does I didn?t see where. Any help would be appreciated. > > > Compiling KeystoreImpl.m (for libosxsecurity.dylib) > /usr/bin/sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e 's/^[ ]*//' -e '/^$/ d' -e 's/$/ :/' /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libnio/Net.d > /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libnio/Net.d.targets > ( ( /usr/bin/clang -x objective-c -D_LITTLE_ENDIAN -DMACOSX -D_LP64=1 -DARCH='"x86_64"' -Dx86_64 -DNDEBUG -DMACOSX -D_ALLBSD_SOURCE -D_DARWIN_UNLIMITED_SELECT -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/share/native/include -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/macosx/native/include -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/unix/native/include -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/share/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/unix/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/macosx/native/libosxsecurity -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/macosx/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/unix/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/share/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/macosx/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/unix/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/share/native/libjava -I/Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/headers/java.base -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk -iframework /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks -F /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks/JavaVM.framework/Frameworks -Os -DTHIS_FILE='"KeystoreImpl.m"' -c -MMD -MF /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libosxsecurity/KeystoreImpl.d -o /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libosxsecurity/KeystoreImpl.o /Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m > >(/usr/bin/tee /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libosxsecurity/KeystoreImpl.o.log) 2> >(/usr/bin/tee /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libosxsecurity/KeystoreImpl.o.log >&2) || ( exitcode=$? && /bin/cp /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/buildjdk/support/native/java.base/libosxsecurity/KeystoreImpl.o.log /Users/rob/jdk9mobile/mobile-dev/build/ios-x86_64-normal-minimal1-release/make-support/failure-logs/buildjdk_support_native_java.base_libosxsecurity_KeystoreImpl.o.log && exit $exitcode ) ) && wait ) > Linking libverify.dylib > /Users/rob/jdk9mobile/mobile-dev/jdk/src/java.base/macosx/native/libnio/fs/UTIFileTypeDetector.c:30:10: fatal error: 'CoreServices/CoreServices.h' file not found > #include > From david.holmes at oracle.com Sun Jul 3 21:54:47 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 07:54:47 +1000 Subject: RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <5776B381.9020304@oracle.com> References: <5776AC9A.5000400@oracle.com> <5776AF8A.9040505@oracle.com> <5776B381.9020304@oracle.com> Message-ID: <692670b0-14f4-8d59-a129-d4555e0f9a00@oracle.com> On 2/07/2016 4:16 AM, Erik Joelsson wrote: > > > On 2016-07-01 19:59, Phil Race wrote: >> erik, >> >> SUPPRESS_CUSTOM_SOURCE" >> FWIW "CLOSED" implies better to me what this is about than "CUSTOM". >> Can't this be SUPPRESS_CLOSED_SOURCE ? >> > "custom" is a term that we have been using for a while now instead of > "closed" in the open parts of the build to refer to any kind of custom > addition to OpenJDK. There are quite a few instances of macros and > variables named that way, mostly in configure but also in the makefiles. > If we were to change this variable to "closed", then the other places > should go with it to match. I think that's a separate change that > require a separate discussion. Since we started supporting the oracle "closed" builds in the shared code the term we have used is CUSTOM because this was always intended to be a general customization mechanism that anyone could use to combine their own "customizations" with the OpenJDK sources. "closed" is just the Oracle name for their customizations. Cheers, David >> http://cr.openjdk.java.net/~erikj/8003593/webrev.01/jdk/make/mapfiles/libfontmanager/mapfile-vers.sdiff.html >> >> >> Regarding all the freetype symbols in here .. they aren't used in the >> Oracle JDK, so is there another >> closed version of this file for the 'custom' source ? >> > Yes, it's in the closed review. The pattern is to have open mapfiles in > the open and OracleJDK specific mapfiles in the Oracle closed repository. >> 57 ifdef OPENJDK >> 458 BUILD_LIBJAVAJPEG_MAPFILE := >> $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers >> 459 else >> 460 BUILD_LIBJAVAJPEG_MAPFILE := >> $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers-closed >> 461 LIBJAVAJPEG_SRC += >> $(JDK_TOPDIR)/src/closed/java.desktop/share/native/libjavajpeg >> 462 endif >> 463 >> >> Where is the closed replacement for this ? In another review you will >> send out internally ? >> > Yes. >>> I have tested these changes extensively using the compare script and >>> -testset buildinfra in JPRT >> So this verifies the resulting "bits" are correct ? >> > Yes. I went through a number of iterations to iron out all the details > using this technique. It's quite powerful. >> .. and that includes the various combinations you are providing ? >> - build openjdk in presence of only openjdk >> - build oracle jdk in presence of open+closed >> - build 'openjdk-only" in presence of open+closed >> > Actually the first one is missing because of how JPRT works, but I could > run an extra round with just that. That case is the least complicated > however since it will just build what is there. > > /Erik From david.holmes at oracle.com Sun Jul 3 23:01:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 09:01:21 +1000 Subject: RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <5776AC9A.5000400@oracle.com> References: <5776AC9A.5000400@oracle.com> Message-ID: <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> Hi Erik, On 2/07/2016 3:47 AM, Erik Joelsson wrote: > The separation between OpenJDK and Oracle's closed additions have > historically been quite messy. The build-infra project has tried to > improve on this, but failed in one regard, which was to hard code all > references to "closed" source instead of using a variable. I decided to > finally fix this. Great this is getting fixed. For the record we tried to do this originally in the build (using "custom" variables) and in hotspot Using ALT_SRC variables). But other parts of the sources tended to hardwire the xxx/closed paths. That said there are still issues with trying to provide a mechanism for other customizations to use - more below. > Along the way, I found that there weren't that many > references left in open makefiles, which is a good thing. OpenJDK should > not be tainted with Oracle specific stuff unnecessarily. So then I > decided to completely remove the last references as part of fixing this > bug. With this patch, the following is now in effect: > > * There is no longer a variable named "OPENJDK". That variable was > confusing and got in the way of other people trying to add custom > additions to the OpenJDK code base. In configure there is now only > "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only > option. This variable can be read by custom extensions to configure and > should be used to disable those custom extensions. Only nit with that is the "source" tend to imply source code and of course this "source" can be quite a range of artifacts. SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. > * There is no Oracle specific logic left in open makefiles. All > customizations and references to custom source should be done in custom > makefiles, included using the IncludeCustomExtension macro. I have > converted the last uses of "ifndef OPENJDK" to such constructs. Just an observation as this is a problem we have hit a few times with the customization mechanism. The placement of the custom includes ( eg IncludeCustomExtension macro) is generally dictated by the custom extension you are trying to accommodate. So including at the start/end/middle of a file may work well for the related Oracle extensions, but that doesn't necessarily generalize to other customizations. I see this is partly addressed by using a "post" variant of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) which seems wrong as the default seems to be pre. Similarly the choice of replacing or updating variables is also being dictated by the way the Oracle extension works. For example, in jdk/make/gendata/GendataBlacklistedCerts.gmk you have: GENDATA_BLACKLISTED_CERTS_SRC += $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem which allows the variable to be extended. In contrast in jdk/make/gendata/GendataFontConfig.gmk you have: GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig which allows the variable to be replaced. There is no general solution here of course - how to replace/augment depends on which operators are used and where the custom include location is. > > I have moved all Oracle specific mapfiles out of the open jdk repository. Ok. Some specific comments: jdk/make/lib/Awt2dLibraries.gmk You seem to have lost the ability to customise the libjavajpeg mapfile. Is that just because it is not needed on the Oracle side? jdk/make/mapfiles/libfontmanager/mapfile-vers Would it be better to delete the above file and hg rename mapfile- version instead? Thanks, David ----- > Specifically to 2d-dev reviewers, I have moved > jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java out > of the open as well. This file has been explicitly excluded from all > open builds since forever AFAICT. I see no reason for it be in the open. > If someone would like to read the source outside of Oracle, it will > still be in the hg history. > > I have tested these changes extensively using the compare script and > -testset buildinfra in JPRT. This covers a wide variety of build > configurations so I feel pretty confident that it won't break anything. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 > Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ > > /Erik From philip.race at oracle.com Sun Jul 3 23:55:33 2016 From: philip.race at oracle.com (Phil Race) Date: Sun, 3 Jul 2016 16:55:33 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> References: <5776AC9A.5000400@oracle.com> <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> Message-ID: <4A94DD27-9EF9-49E7-83AF-63295C04B64F@oracle.com> It is it all "extensions". It is mostly just different internal code as far as we (se client) are concerned so the word extension has entirely the wrong connotation for people in SE api land. -Phil. > On Jul 3, 2016, at 4:01 PM, David Holmes wrote: > > Hi Erik, > >> On 2/07/2016 3:47 AM, Erik Joelsson wrote: >> The separation between OpenJDK and Oracle's closed additions have >> historically been quite messy. The build-infra project has tried to >> improve on this, but failed in one regard, which was to hard code all >> references to "closed" source instead of using a variable. I decided to >> finally fix this. > > Great this is getting fixed. For the record we tried to do this originally in the build (using "custom" variables) and in hotspot Using ALT_SRC variables). But other parts of the sources tended to hardwire the xxx/closed paths. > > That said there are still issues with trying to provide a mechanism for other customizations to use - more below. > >> Along the way, I found that there weren't that many >> references left in open makefiles, which is a good thing. OpenJDK should >> not be tainted with Oracle specific stuff unnecessarily. So then I >> decided to completely remove the last references as part of fixing this >> bug. With this patch, the following is now in effect: >> >> * There is no longer a variable named "OPENJDK". That variable was >> confusing and got in the way of other people trying to add custom >> additions to the OpenJDK code base. In configure there is now only >> "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only >> option. This variable can be read by custom extensions to configure and >> should be used to disable those custom extensions. > > Only nit with that is the "source" tend to imply source code and of course this "source" can be quite a range of artifacts. SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. > >> * There is no Oracle specific logic left in open makefiles. All >> customizations and references to custom source should be done in custom >> makefiles, included using the IncludeCustomExtension macro. I have >> converted the last uses of "ifndef OPENJDK" to such constructs. > > Just an observation as this is a problem we have hit a few times with the customization mechanism. The placement of the custom includes ( eg IncludeCustomExtension macro) is generally dictated by the custom extension you are trying to accommodate. So including at the start/end/middle of a file may work well for the related Oracle extensions, but that doesn't necessarily generalize to other customizations. I see this is partly addressed by using a "post" variant of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) which seems wrong as the default seems to be pre. > > Similarly the choice of replacing or updating variables is also being dictated by the way the Oracle extension works. For example, in > > jdk/make/gendata/GendataBlacklistedCerts.gmk > > you have: > > GENDATA_BLACKLISTED_CERTS_SRC += $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem > > which allows the variable to be extended. In contrast in > > jdk/make/gendata/GendataFontConfig.gmk > > you have: > > GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig > > which allows the variable to be replaced. > > There is no general solution here of course - how to replace/augment depends on which operators are used and where the custom include location is. > >> >> I have moved all Oracle specific mapfiles out of the open jdk repository. > > Ok. > > Some specific comments: > > jdk/make/lib/Awt2dLibraries.gmk > > You seem to have lost the ability to customise the libjavajpeg mapfile. Is that just because it is not needed on the Oracle side? > > jdk/make/mapfiles/libfontmanager/mapfile-vers > > Would it be better to delete the above file and hg rename mapfile- version instead? > > Thanks, > David > ----- > >> Specifically to 2d-dev reviewers, I have moved >> jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java out >> of the open as well. This file has been explicitly excluded from all >> open builds since forever AFAICT. I see no reason for it be in the open. >> If someone would like to read the source outside of Oracle, it will >> still be in the hg history. >> >> I have tested these changes extensively using the compare script and >> -testset buildinfra in JPRT. This covers a wide variety of build >> configurations so I feel pretty confident that it won't break anything. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 >> Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ >> >> /Erik From philip.race at oracle.com Mon Jul 4 00:21:03 2016 From: philip.race at oracle.com (Phil Race) Date: Sun, 3 Jul 2016 17:21:03 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <4A94DD27-9EF9-49E7-83AF-63295C04B64F@oracle.com> References: <5776AC9A.5000400@oracle.com> <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> <4A94DD27-9EF9-49E7-83AF-63295C04B64F@oracle.com> Message-ID: -Phil. > On Jul 3, 2016, at 4:55 PM, Phil Race wrote: > > It is it all "extensions". That should have read : It is "not" all ... - Phil > It is mostly just different internal code as far as we (se client) are concerned so the word extension has entirely the wrong connotation for people in SE api land. > > -Phil. > >> On Jul 3, 2016, at 4:01 PM, David Holmes wrote: >> >> Hi Erik, >> >>> On 2/07/2016 3:47 AM, Erik Joelsson wrote: >>> The separation between OpenJDK and Oracle's closed additions have >>> historically been quite messy. The build-infra project has tried to >>> improve on this, but failed in one regard, which was to hard code all >>> references to "closed" source instead of using a variable. I decided to >>> finally fix this. >> >> Great this is getting fixed. For the record we tried to do this originally in the build (using "custom" variables) and in hotspot Using ALT_SRC variables). But other parts of the sources tended to hardwire the xxx/closed paths. >> >> That said there are still issues with trying to provide a mechanism for other customizations to use - more below. >> >>> Along the way, I found that there weren't that many >>> references left in open makefiles, which is a good thing. OpenJDK should >>> not be tainted with Oracle specific stuff unnecessarily. So then I >>> decided to completely remove the last references as part of fixing this >>> bug. With this patch, the following is now in effect: >>> >>> * There is no longer a variable named "OPENJDK". That variable was >>> confusing and got in the way of other people trying to add custom >>> additions to the OpenJDK code base. In configure there is now only >>> "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only >>> option. This variable can be read by custom extensions to configure and >>> should be used to disable those custom extensions. >> >> Only nit with that is the "source" tend to imply source code and of course this "source" can be quite a range of artifacts. SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. >> >>> * There is no Oracle specific logic left in open makefiles. All >>> customizations and references to custom source should be done in custom >>> makefiles, included using the IncludeCustomExtension macro. I have >>> converted the last uses of "ifndef OPENJDK" to such constructs. >> >> Just an observation as this is a problem we have hit a few times with the customization mechanism. The placement of the custom includes ( eg IncludeCustomExtension macro) is generally dictated by the custom extension you are trying to accommodate. So including at the start/end/middle of a file may work well for the related Oracle extensions, but that doesn't necessarily generalize to other customizations. I see this is partly addressed by using a "post" variant of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) which seems wrong as the default seems to be pre. >> >> Similarly the choice of replacing or updating variables is also being dictated by the way the Oracle extension works. For example, in >> >> jdk/make/gendata/GendataBlacklistedCerts.gmk >> >> you have: >> >> GENDATA_BLACKLISTED_CERTS_SRC += $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem >> >> which allows the variable to be extended. In contrast in >> >> jdk/make/gendata/GendataFontConfig.gmk >> >> you have: >> >> GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig >> >> which allows the variable to be replaced. >> >> There is no general solution here of course - how to replace/augment depends on which operators are used and where the custom include location is. >> >>> >>> I have moved all Oracle specific mapfiles out of the open jdk repository. >> >> Ok. >> >> Some specific comments: >> >> jdk/make/lib/Awt2dLibraries.gmk >> >> You seem to have lost the ability to customise the libjavajpeg mapfile. Is that just because it is not needed on the Oracle side? >> >> jdk/make/mapfiles/libfontmanager/mapfile-vers >> >> Would it be better to delete the above file and hg rename mapfile- version instead? >> >> Thanks, >> David >> ----- >> >>> Specifically to 2d-dev reviewers, I have moved >>> jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java out >>> of the open as well. This file has been explicitly excluded from all >>> open builds since forever AFAICT. I see no reason for it be in the open. >>> If someone would like to read the source outside of Oracle, it will >>> still be in the hg history. >>> >>> I have tested these changes extensively using the compare script and >>> -testset buildinfra in JPRT. This covers a wide variety of build >>> configurations so I feel pretty confident that it won't break anything. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 >>> Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ >>> >>> /Erik > From david.holmes at oracle.com Mon Jul 4 01:02:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 11:02:49 +1000 Subject: RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> References: <5776AC9A.5000400@oracle.com> <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> Message-ID: <7057488a-b671-c7df-04e1-8900e90b070b@oracle.com> Fix typo ... On 4/07/2016 9:01 AM, David Holmes wrote: > Hi Erik, > > On 2/07/2016 3:47 AM, Erik Joelsson wrote: >> The separation between OpenJDK and Oracle's closed additions have >> historically been quite messy. The build-infra project has tried to >> improve on this, but failed in one regard, which was to hard code all >> references to "closed" source instead of using a variable. I decided to >> finally fix this. > > Great this is getting fixed. For the record we tried to do this > originally in the build (using "custom" variables) and in hotspot Using > ALT_SRC variables). But other parts of the sources tended to hardwire > the xxx/closed paths. > > That said there are still issues with trying to provide a mechanism for > other customizations to use - more below. > >> Along the way, I found that there weren't that many >> references left in open makefiles, which is a good thing. OpenJDK should >> not be tainted with Oracle specific stuff unnecessarily. So then I >> decided to completely remove the last references as part of fixing this >> bug. With this patch, the following is now in effect: >> >> * There is no longer a variable named "OPENJDK". That variable was >> confusing and got in the way of other people trying to add custom >> additions to the OpenJDK code base. In configure there is now only >> "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only >> option. This variable can be read by custom extensions to configure and >> should be used to disable those custom extensions. > > Only nit with that is the "source" tend to imply source code and of > course this "source" can be quite a range of artifacts. > SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. > >> * There is no Oracle specific logic left in open makefiles. All >> customizations and references to custom source should be done in custom >> makefiles, included using the IncludeCustomExtension macro. I have >> converted the last uses of "ifndef OPENJDK" to such constructs. > > Just an observation as this is a problem we have hit a few times with > the customization mechanism. The placement of the custom includes ( eg > IncludeCustomExtension macro) is generally dictated by the custom > extension you are trying to accommodate. So including at the > start/end/middle of a file may work well for the related Oracle > extensions, but that doesn't necessarily generalize to other > customizations. I see this is partly addressed by using a "post" variant > of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) > which seems wrong as the default seems to be pre. > > Similarly the choice of replacing or updating variables is also being > dictated by the way the Oracle extension works. For example, in > > jdk/make/gendata/GendataBlacklistedCerts.gmk > > you have: > > GENDATA_BLACKLISTED_CERTS_SRC += > $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem > > which allows the variable to be extended. In contrast in > > jdk/make/gendata/GendataFontConfig.gmk > > you have: > > GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig > > which allows the variable to be replaced. > > There is no general solution here of course - how to replace/augment > depends on which operators are used and where the custom include > location is. > >> >> I have moved all Oracle specific mapfiles out of the open jdk repository. > > Ok. > > Some specific comments: > > jdk/make/lib/Awt2dLibraries.gmk > > You seem to have lost the ability to customise the libjavajpeg mapfile. > Is that just because it is not needed on the Oracle side? > > jdk/make/mapfiles/libfontmanager/mapfile-vers > > Would it be better to delete the above file and hg rename mapfile- > version instead? ... hg rename the mapfile-vers.openjdk version instead ... David > Thanks, > David > ----- > >> Specifically to 2d-dev reviewers, I have moved >> jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java out >> of the open as well. This file has been explicitly excluded from all >> open builds since forever AFAICT. I see no reason for it be in the open. >> If someone would like to read the source outside of Oracle, it will >> still be in the hg history. >> >> I have tested these changes extensively using the compare script and >> -testset buildinfra in JPRT. This covers a wide variety of build >> configurations so I feel pretty confident that it won't break anything. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 >> Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ >> >> /Erik From david.holmes at oracle.com Mon Jul 4 01:10:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 11:10:31 +1000 Subject: RFR: JDK-8160722: Module summary generation fails on Windows 32bit In-Reply-To: <57767915.4010406@oracle.com> References: <57767915.4010406@oracle.com> Message-ID: <46da6e69-fe7f-5537-200c-27185eb0a166@oracle.com> On 2/07/2016 12:07 AM, Erik Joelsson wrote: > Hello, > > Again we are hit with a build problem involving -Xmx and only building > server on Windows 32bit. The module summary generation build step is run > on the just built jdk (just like a bootcycle build). Now we face a > similar issue with this summary generation, which uses a fixed setting > of -Xmx1100M. In JDK-8160571 we learned that this is sometimes too much > for the server JVM on Windows 32bit and now we see failures because of it. > > My proposed fix is to set the jvm arguments for this to the same as is > now being calculated for the bootcycle jvm args since JDK-8160571. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160722 > Patch: > diff -r 31261e7238af common/autoconf/spec.gmk.in > --- a/common/autoconf/spec.gmk.in > +++ b/common/autoconf/spec.gmk.in > @@ -578,7 +578,7 @@ > JAVAC_FLAGS?=@JAVAC_FLAGS@ > > > -BUILD_JAVA_FLAGS:=-Xms64M -Xmx1100M > +BUILD_JAVA_FLAGS := @BOOTCYCLE_JVM_ARGS_BIG@ > BUILD_JAVA=@FIXPATH@ $(BUILD_JDK)/bin/java $(BUILD_JAVA_FLAGS) Seems reasonable. Any more potholes on this road we are going to hit? I'm still worried we may see transient OOM situations due to using server + G1 by default. Thanks, David > # Use ?= as this can be overridden from bootcycle-spec.gmk > > /Erik From david.holmes at oracle.com Mon Jul 4 01:14:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 11:14:50 +1000 Subject: Status of building problem with GCC 6 In-Reply-To: <60B65F56-1958-4619-983E-11DD4C94BA61@oracle.com> References: <055c177f-a26b-39b1-41a3-50df6aead626@gmail.com> <368525CD-7C70-421F-9AEF-0A3D47952DAA@oracle.com> <60B65F56-1958-4619-983E-11DD4C94BA61@oracle.com> Message-ID: Please include the build team on this discussion - cc'd Thanks, David On 4/07/2016 2:36 AM, Kim Barrett wrote: >> On Jul 1, 2016, at 3:13 PM, Kim Barrett wrote: >> >>> On Jul 1, 2016, at 10:17 AM, Yasumasa Suenaga wrote: >>> For HotSpot, I think JDK-8156980 should be fixed at first. >>> I've proposed changes as below: >>> >>> ----------- >>> diff -r ba08710f3b6c make/lib/CompileJvm.gmk >>> --- a/make/lib/CompileJvm.gmk Mon Jun 27 09:35:18 2016 +0200 >>> +++ b/make/lib/CompileJvm.gmk Tue Jun 28 12:10:09 2016 +0900 >>> @@ -187,6 +187,11 @@ >>> >>> JVM_OPTIMIZATION ?= HIGHEST_JVM >>> >>> +JVM_CXXFLAGS := $(JVM_CFLAGS) >>> +ifeq ($(TOOLCHAIN_TYPE), gcc) >>> + JVM_CXXFLAGS += -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse >>> +endif >>> + >>> ################################################################################ >>> # Now set up the actual compilation of the main hotspot native library >>> >>> @@ -202,6 +207,7 @@ >>> CFLAGS := $(JVM_CFLAGS), \ >>> CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ >>> CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ >>> + CXXFLAGS := $(JVM_CXXFLAGS), \ >>> vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ >>> DISABLED_WARNINGS_clang := delete-non-virtual-dtor dynamic-class-memaccess \ >>> empty-body format logical-op-parentheses parentheses \ >>> ????? >> >> Please keep in mind that my understanding of the new build system is >> pretty weak. That said, this doesn't look to me like the right way to >> fix JDK-8156980. >> >> There is already code that is supposed to deal with both the -std >> option and the additional code generation options, which seems to work >> for some of the packages that we build, but is not affecting the >> Hotspot build for some reason. Adding a completely separate way to >> deal with this just for Hotspot seems contrary to the unification >> effort that was part of the new build system. >> >> -fno-lifetime-dse is a relatively recent option, and needs to be >> conditionalized. And discussion during the review of JDK-8151841 led >> to the additional code generation options being limited to gcc6+. >> The existing code mentioned above is conditionalizing that way, except >> it's just not working for Hotspot. > > I looked into why the additional code generation options aren?t being > added, and think I found 3-4 different problems, each of which would > interfere with that part. I?m working on a patch, which I hope to send > to Yasumasa in next couple of days for a gcc6 test, since I don?t have > easy access to that compiler right now. > > I?ve not (re)explored why -std=gnu++98 isn?t making it to Hotspot builds > yet, though what I?ve learned in the process of investigating the code > generation options problem has given me a possible lead. > > From david.holmes at oracle.com Mon Jul 4 01:17:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Jul 2016 11:17:09 +1000 Subject: [OpenJDK 2D-Dev] RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: References: <5776AC9A.5000400@oracle.com> <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> <4A94DD27-9EF9-49E7-83AF-63295C04B64F@oracle.com> Message-ID: <21448444-7a1e-7a31-5fe1-058f52704f75@oracle.com> On 4/07/2016 10:21 AM, Phil Race wrote: > > > -Phil. > >> On Jul 3, 2016, at 4:55 PM, Phil Race wrote: >> >> It is it all "extensions". > That should have read : > It is "not" all ... True but they are all customizations - so SUPPRESS_CUSTOMIZATIONS instead of SUPPRESS_CUSTOM_SOURCES ? David > - Phil > >> It is mostly just different internal code as far as we (se client) are concerned so the word extension has entirely the wrong connotation for people in SE api land. >> >> -Phil. >> >>> On Jul 3, 2016, at 4:01 PM, David Holmes wrote: >>> >>> Hi Erik, >>> >>>> On 2/07/2016 3:47 AM, Erik Joelsson wrote: >>>> The separation between OpenJDK and Oracle's closed additions have >>>> historically been quite messy. The build-infra project has tried to >>>> improve on this, but failed in one regard, which was to hard code all >>>> references to "closed" source instead of using a variable. I decided to >>>> finally fix this. >>> >>> Great this is getting fixed. For the record we tried to do this originally in the build (using "custom" variables) and in hotspot Using ALT_SRC variables). But other parts of the sources tended to hardwire the xxx/closed paths. >>> >>> That said there are still issues with trying to provide a mechanism for other customizations to use - more below. >>> >>>> Along the way, I found that there weren't that many >>>> references left in open makefiles, which is a good thing. OpenJDK should >>>> not be tainted with Oracle specific stuff unnecessarily. So then I >>>> decided to completely remove the last references as part of fixing this >>>> bug. With this patch, the following is now in effect: >>>> >>>> * There is no longer a variable named "OPENJDK". That variable was >>>> confusing and got in the way of other people trying to add custom >>>> additions to the OpenJDK code base. In configure there is now only >>>> "SUPPRESS_CUSTOM_SOURCE" which is set using the --enable-openjdk-only >>>> option. This variable can be read by custom extensions to configure and >>>> should be used to disable those custom extensions. >>> >>> Only nit with that is the "source" tend to imply source code and of course this "source" can be quite a range of artifacts. SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. >>> >>>> * There is no Oracle specific logic left in open makefiles. All >>>> customizations and references to custom source should be done in custom >>>> makefiles, included using the IncludeCustomExtension macro. I have >>>> converted the last uses of "ifndef OPENJDK" to such constructs. >>> >>> Just an observation as this is a problem we have hit a few times with the customization mechanism. The placement of the custom includes ( eg IncludeCustomExtension macro) is generally dictated by the custom extension you are trying to accommodate. So including at the start/end/middle of a file may work well for the related Oracle extensions, but that doesn't necessarily generalize to other customizations. I see this is partly addressed by using a "post" variant of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) which seems wrong as the default seems to be pre. >>> >>> Similarly the choice of replacing or updating variables is also being dictated by the way the Oracle extension works. For example, in >>> >>> jdk/make/gendata/GendataBlacklistedCerts.gmk >>> >>> you have: >>> >>> GENDATA_BLACKLISTED_CERTS_SRC += $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem >>> >>> which allows the variable to be extended. In contrast in >>> >>> jdk/make/gendata/GendataFontConfig.gmk >>> >>> you have: >>> >>> GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig >>> >>> which allows the variable to be replaced. >>> >>> There is no general solution here of course - how to replace/augment depends on which operators are used and where the custom include location is. >>> >>>> >>>> I have moved all Oracle specific mapfiles out of the open jdk repository. >>> >>> Ok. >>> >>> Some specific comments: >>> >>> jdk/make/lib/Awt2dLibraries.gmk >>> >>> You seem to have lost the ability to customise the libjavajpeg mapfile. Is that just because it is not needed on the Oracle side? >>> >>> jdk/make/mapfiles/libfontmanager/mapfile-vers >>> >>> Would it be better to delete the above file and hg rename mapfile- version instead? >>> >>> Thanks, >>> David >>> ----- >>> >>>> Specifically to 2d-dev reviewers, I have moved >>>> jdk/src/java.desktop/share/classes/sun/dc/DuctusRenderingEngine.java out >>>> of the open as well. This file has been explicitly excluded from all >>>> open builds since forever AFAICT. I see no reason for it be in the open. >>>> If someone would like to read the source outside of Oracle, it will >>>> still be in the hg history. >>>> >>>> I have tested these changes extensively using the compare script and >>>> -testset buildinfra in JPRT. This covers a wide variety of build >>>> configurations so I feel pretty confident that it won't break anything. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8003593 >>>> Webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.01/ >>>> >>>> /Erik >> > From gnu.andrew at redhat.com Tue Jul 5 05:27:21 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 5 Jul 2016 01:27:21 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1992594910.2166672.1467695195527.JavaMail.zimbra@redhat.com> Message-ID: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> Webrev: http://cr.openjdk.java.net/~andrew/8156980/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8156980 With "8151841: Build needs additional flags to compile with GCC 6", we added a number of compiler flags which were needed to build OpenJDK with GCC 6. Checks for these flags were added to configure, and the flags passed to the JDK and HotSpot builds by CFLAGS/CXXFLAGS_JDK and hotspot-spec.gmk.in respectively. Following "8152666: The new Hotspot Build System" and "8150601: Remove the old Hotspot build system", the hotspot-spec.gmk.in file was removed, so the flags were no longer passed to the HotSpot build. HotSpot now uses JVM_CFLAGS via the same configure process as the JDK obtains CFLAGS_JDK and CXXFLAGS_JDK[*]. This webrev fixes the regression introduced by 8152666 by adding the flags to JVM_CFLAGS. It also adapts FLAGS_SETUP_GCC6_COMPILER_FLAGS to take a prefix, as other macros in flags.m4 do, and calls TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS before the version check. The lack of the latter lead to configure executing: if test $OPENJDK_BUILD_COMPARABLE_ACTUAL_VERSION -ge $COMPARABLE_REFERENCE_VERSION with OPENJDK_BUILD_COMPARABLE_ACTUAL_VERSION ever being set, causing test to print an error. With this fix, the flags again make it into the build. [*] It should really be CXXFLAGS_JVM as they are flags for the C++ compiler. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From erik.joelsson at oracle.com Tue Jul 5 06:44:35 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Jul 2016 08:44:35 +0200 Subject: RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <7057488a-b671-c7df-04e1-8900e90b070b@oracle.com> References: <5776AC9A.5000400@oracle.com> <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> <7057488a-b671-c7df-04e1-8900e90b070b@oracle.com> Message-ID: <577B5753.9030807@oracle.com> Hello, New webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.02/ Only change is the name of the suppress variable. On 2016-07-04 03:02, David Holmes wrote: > Fix typo ... > > On 4/07/2016 9:01 AM, David Holmes wrote: >> Hi Erik, >> >> Only nit with that is the "source" tend to imply source code and of >> course this "source" can be quite a range of artifacts. >> SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. >> I went with this suggestion as I like it better. >>> * There is no Oracle specific logic left in open makefiles. All >>> customizations and references to custom source should be done in custom >>> makefiles, included using the IncludeCustomExtension macro. I have >>> converted the last uses of "ifndef OPENJDK" to such constructs. >> >> Just an observation as this is a problem we have hit a few times with >> the customization mechanism. The placement of the custom includes ( eg >> IncludeCustomExtension macro) is generally dictated by the custom >> extension you are trying to accommodate. So including at the >> start/end/middle of a file may work well for the related Oracle >> extensions, but that doesn't necessarily generalize to other >> customizations. I see this is partly addressed by using a "post" variant >> of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) >> which seems wrong as the default seems to be pre. >> >> Similarly the choice of replacing or updating variables is also being >> dictated by the way the Oracle extension works. For example, in >> >> jdk/make/gendata/GendataBlacklistedCerts.gmk >> >> you have: >> >> GENDATA_BLACKLISTED_CERTS_SRC += >> $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem >> >> which allows the variable to be extended. In contrast in >> >> jdk/make/gendata/GendataFontConfig.gmk >> >> you have: >> >> GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig >> >> which allows the variable to be replaced. >> >> There is no general solution here of course - how to replace/augment >> depends on which operators are used and where the custom include >> location is. >> This is all true. Different places have required different ways of overriding, appending or prepending with customizations. I will likely take another look at this and see if I can clean it up some at least. Perhaps unify the pre/post semantics. At least now we have captured all the current needs for customizations and gained some experience in what kind of constructs are needed. >>> >>> I have moved all Oracle specific mapfiles out of the open jdk >>> repository. >> >> Ok. >> >> Some specific comments: >> >> jdk/make/lib/Awt2dLibraries.gmk >> >> You seem to have lost the ability to customise the libjavajpeg mapfile. >> Is that just because it is not needed on the Oracle side? >> >> jdk/make/mapfiles/libfontmanager/mapfile-vers >> >> Would it be better to delete the above file and hg rename mapfile- >> version instead? > > ... hg rename the mapfile-vers.openjdk version instead ... > They are identical, which is why I just removed the logic. Historically there has been a difference but it was removed. Regarding which file we should save the history for, I'm not sure which is best. Delete-rename to the same file name can be confusing too. /Erik From erik.joelsson at oracle.com Tue Jul 5 06:58:40 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Jul 2016 08:58:40 +0200 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> Message-ID: <577B5AA0.8050207@oracle.com> Hello, In general it looks good. It's nice to see that this also fixes that warning output from configure. My only nit is the comment describing the parameters for FLAGS_SETUP_GCC6_COMPILER_FLAGS. It indicates that it takes named parameters while it actually just takes positional. Please either change it to named parameters or fix the comment. Thanks for fixing this! /Erik On 2016-07-05 07:27, Andrew Hughes wrote: > Webrev: http://cr.openjdk.java.net/~andrew/8156980/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8156980 > > With "8151841: Build needs additional flags to compile with GCC 6", > we added a number of compiler flags which were needed to build > OpenJDK with GCC 6. Checks for these flags were added to configure, > and the flags passed to the JDK and HotSpot builds by CFLAGS/CXXFLAGS_JDK > and hotspot-spec.gmk.in respectively. > > Following "8152666: The new Hotspot Build System" and > "8150601: Remove the old Hotspot build system", the hotspot-spec.gmk.in > file was removed, so the flags were no longer passed to the HotSpot > build. HotSpot now uses JVM_CFLAGS via the same configure process > as the JDK obtains CFLAGS_JDK and CXXFLAGS_JDK[*]. > > This webrev fixes the regression introduced by 8152666 by adding > the flags to JVM_CFLAGS. It also adapts FLAGS_SETUP_GCC6_COMPILER_FLAGS > to take a prefix, as other macros in flags.m4 do, and calls > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS before the version check. > The lack of the latter lead to configure executing: > > if test $OPENJDK_BUILD_COMPARABLE_ACTUAL_VERSION -ge $COMPARABLE_REFERENCE_VERSION > > with OPENJDK_BUILD_COMPARABLE_ACTUAL_VERSION ever being set, causing > test to print an error. > > With this fix, the flags again make it into the build. > > [*] It should really be CXXFLAGS_JVM as they are flags for the C++ compiler. From david.holmes at oracle.com Tue Jul 5 07:42:24 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Jul 2016 17:42:24 +1000 Subject: RFR: JDK-8003593: build-infra: Paths to optional platform-specific files should not be hardwired to src/closed In-Reply-To: <577B5753.9030807@oracle.com> References: <5776AC9A.5000400@oracle.com> <789ad552-17c1-019c-13de-51674e48c4ca@oracle.com> <7057488a-b671-c7df-04e1-8900e90b070b@oracle.com> <577B5753.9030807@oracle.com> Message-ID: <12bad63c-91c1-2cc4-69fd-2150ed54f164@oracle.com> No further comments from me Erik! Looks good. Thanks, David On 5/07/2016 4:44 PM, Erik Joelsson wrote: > Hello, > > New webrev: http://cr.openjdk.java.net/~erikj/8003593/webrev.02/ > > Only change is the name of the suppress variable. > > On 2016-07-04 03:02, David Holmes wrote: >> Fix typo ... >> >> On 4/07/2016 9:01 AM, David Holmes wrote: >>> Hi Erik, >>> >>> Only nit with that is the "source" tend to imply source code and of >>> course this "source" can be quite a range of artifacts. >>> SUPPRESS_CUSTOM_EXTENSIONS may have been better in that regard. >>> > I went with this suggestion as I like it better. >>>> * There is no Oracle specific logic left in open makefiles. All >>>> customizations and references to custom source should be done in custom >>>> makefiles, included using the IncludeCustomExtension macro. I have >>>> converted the last uses of "ifndef OPENJDK" to such constructs. >>> >>> Just an observation as this is a problem we have hit a few times with >>> the customization mechanism. The placement of the custom includes ( eg >>> IncludeCustomExtension macro) is generally dictated by the custom >>> extension you are trying to accommodate. So including at the >>> start/end/middle of a file may work well for the related Oracle >>> extensions, but that doesn't necessarily generalize to other >>> customizations. I see this is partly addressed by using a "post" variant >>> of the file in places - and even on "pre" (lib/Awt2dLibraries-pre.gmk) >>> which seems wrong as the default seems to be pre. >>> >>> Similarly the choice of replacing or updating variables is also being >>> dictated by the way the Oracle extension works. For example, in >>> >>> jdk/make/gendata/GendataBlacklistedCerts.gmk >>> >>> you have: >>> >>> GENDATA_BLACKLISTED_CERTS_SRC += >>> $(JDK_TOPDIR)/make/data/blacklistedcertsconverter/blacklisted.certs.pem >>> >>> which allows the variable to be extended. In contrast in >>> >>> jdk/make/gendata/GendataFontConfig.gmk >>> >>> you have: >>> >>> GENDATA_FONT_CONFIG_DATA_DIR ?= $(JDK_TOPDIR)/make/data/fontconfig >>> >>> which allows the variable to be replaced. >>> >>> There is no general solution here of course - how to replace/augment >>> depends on which operators are used and where the custom include >>> location is. >>> > This is all true. Different places have required different ways of > overriding, appending or prepending with customizations. I will likely > take another look at this and see if I can clean it up some at least. > Perhaps unify the pre/post semantics. At least now we have captured all > the current needs for customizations and gained some experience in what > kind of constructs are needed. >>>> >>>> I have moved all Oracle specific mapfiles out of the open jdk >>>> repository. >>> >>> Ok. >>> >>> Some specific comments: >>> >>> jdk/make/lib/Awt2dLibraries.gmk >>> >>> You seem to have lost the ability to customise the libjavajpeg mapfile. >>> Is that just because it is not needed on the Oracle side? >>> >>> jdk/make/mapfiles/libfontmanager/mapfile-vers >>> >>> Would it be better to delete the above file and hg rename mapfile- >>> version instead? >> >> ... hg rename the mapfile-vers.openjdk version instead ... >> > They are identical, which is why I just removed the logic. Historically > there has been a difference but it was removed. Regarding which file we > should save the history for, I'm not sure which is best. Delete-rename > to the same file name can be confusing too. > > /Erik > From volker.simonis at gmail.com Tue Jul 5 12:34:59 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Jul 2016 14:34:59 +0200 Subject: Setting/overriding HOTSPOT_VERSION_STRING In-Reply-To: References: Message-ID: Hi Doug, HOTSPOT_VERSION_STRING comes from VERSION_STRING: hotspot/make/lib/CompileJvm.gmk: -DHOTSPOT_VERSION_STRING='"$(VERSION_STRING)" and VERSION_STRING comes from configure. In your build directory you can do: grep VERSION_STRING spec.gmk VERSION_STRING := 9-internal+0-2016-06-29-155201.d046063.jdk9-hs-comp -DVERSION_STRING='"$(VERSION_STRING)"' \ You can influence this version number with various configure options: configure --help | grep "with-version" --with-version-string Set version string [calculated] --with-version-pre Set the base part of the version 'PRE' field --with-version-opt Set version 'OPT' field (build metadata) --with-version-build Set version 'BUILD' field (build number) [not --with-version-major Set version 'MAJOR' field (first number) [current --with-version-minor Set version 'MINOR' field (second number) [current --with-version-security Set version 'SECURITY' field (third number) [current --with-version-patch Set version 'PATCH' field (fourth number) [not Regards, Volker PS: the correct list for build related questions is build-dev. build-infra-dev was for the development of the new build system. On Tue, Jul 5, 2016 at 12:21 PM, Doug Simon wrote: > Hi, > > I?m trying to customize the value set during the JDK 9 build for the java.vm.version system property. As far as I can see, it comes from HOTSPOT_VERSION_STRING. > > vm_version.cpp: > > #define VM_RELEASE HOTSPOT_VERSION_STRING > > const char* Abstract_VM_Version::vm_release() { > return VM_RELEASE; > } > > arguments.cpp: > > PropertyList_add(&_system_properties, new SystemProperty("java.vm.version", VM_Version::vm_release(), false)); > > Do you know how I can set/override the value of HOTSPOT_VERSION_STRING passed to the HotSpot build? I tried setting it as an environment variable but it didn?t work: > > dsimon at kurz ~/hs-comp> touch hotspot/src/share/vm/runtime/vm_version.cpp; env HOTSPOT_VERSION_STRING=XXXXXXXXXXXXX make CONF=release > Building configuration 'macosx-x86_64-normal-server-release' (matching CONF=release) > Building target 'default (exploded-image)' in configuration 'macosx-x86_64-normal-server-release' > Building JVM variant 'server' with features 'all-gcs cds closed-src commercial-features compiler1 compiler2 dtrace fprof jni-check jvmci jvmti management nmt services trace vm-structs' > Updating libjvm.dylib due to 1 file(s) > Finished building target 'default (exploded-image)' in configuration 'macosx-x86_64-normal-server-release' > dsimon at kurz ~/hs-comp> build/macosx-x86_64-normal-server-release/jdk/bin/java -version > java version "9-internal" > Java(TM) SE Runtime Environment (build 9-internal+0-2016-06-29-123036.dsimon.hs-comp) > Java HotSpot(TM) 64-Bit Server VM (build 9-internal+0-2016-06-29-123036.dsimon.hs-comp, mixed mode) > > -Doug > From doug.simon at oracle.com Tue Jul 5 13:42:30 2016 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 5 Jul 2016 15:42:30 +0200 Subject: Setting/overriding HOTSPOT_VERSION_STRING In-Reply-To: References: Message-ID: Thanks Volker! I think --with-version-opt is what I need. -Doug > On 05 Jul 2016, at 14:34, Volker Simonis wrote: > > Hi Doug, > > HOTSPOT_VERSION_STRING comes from VERSION_STRING: > > hotspot/make/lib/CompileJvm.gmk: > -DHOTSPOT_VERSION_STRING='"$(VERSION_STRING)" > > and VERSION_STRING comes from configure. In your build directory you can do: > > grep VERSION_STRING spec.gmk > VERSION_STRING := 9-internal+0-2016-06-29-155201.d046063.jdk9-hs-comp > -DVERSION_STRING='"$(VERSION_STRING)"' \ > > You can influence this version number with various configure options: > > configure --help | grep "with-version" > --with-version-string Set version string [calculated] > --with-version-pre Set the base part of the version 'PRE' field > --with-version-opt Set version 'OPT' field (build metadata) > --with-version-build Set version 'BUILD' field (build number) [not > --with-version-major Set version 'MAJOR' field (first number) [current > --with-version-minor Set version 'MINOR' field (second number) [current > --with-version-security Set version 'SECURITY' field (third number) [current > --with-version-patch Set version 'PATCH' field (fourth number) [not > > Regards, > Volker > > PS: the correct list for build related questions is build-dev. > build-infra-dev was for the development of the new build system. > > > > > > > On Tue, Jul 5, 2016 at 12:21 PM, Doug Simon wrote: >> Hi, >> >> I?m trying to customize the value set during the JDK 9 build for the java.vm.version system property. As far as I can see, it comes from HOTSPOT_VERSION_STRING. >> >> vm_version.cpp: >> >> #define VM_RELEASE HOTSPOT_VERSION_STRING >> >> const char* Abstract_VM_Version::vm_release() { >> return VM_RELEASE; >> } >> >> arguments.cpp: >> >> PropertyList_add(&_system_properties, new SystemProperty("java.vm.version", VM_Version::vm_release(), false)); >> >> Do you know how I can set/override the value of HOTSPOT_VERSION_STRING passed to the HotSpot build? I tried setting it as an environment variable but it didn?t work: >> >> dsimon at kurz ~/hs-comp> touch hotspot/src/share/vm/runtime/vm_version.cpp; env HOTSPOT_VERSION_STRING=XXXXXXXXXXXXX make CONF=release >> Building configuration 'macosx-x86_64-normal-server-release' (matching CONF=release) >> Building target 'default (exploded-image)' in configuration 'macosx-x86_64-normal-server-release' >> Building JVM variant 'server' with features 'all-gcs cds closed-src commercial-features compiler1 compiler2 dtrace fprof jni-check jvmci jvmti management nmt services trace vm-structs' >> Updating libjvm.dylib due to 1 file(s) >> Finished building target 'default (exploded-image)' in configuration 'macosx-x86_64-normal-server-release' >> dsimon at kurz ~/hs-comp> build/macosx-x86_64-normal-server-release/jdk/bin/java -version >> java version "9-internal" >> Java(TM) SE Runtime Environment (build 9-internal+0-2016-06-29-123036.dsimon.hs-comp) >> Java HotSpot(TM) 64-Bit Server VM (build 9-internal+0-2016-06-29-123036.dsimon.hs-comp, mixed mode) >> >> -Doug >> From gnu.andrew at redhat.com Tue Jul 5 15:22:25 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 5 Jul 2016 11:22:25 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <577B5AA0.8050207@oracle.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> Message-ID: <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > In general it looks good. It's nice to see that this also fixes that > warning output from configure. My only nit is the comment describing the > parameters for FLAGS_SETUP_GCC6_COMPILER_FLAGS. It indicates that it > takes named parameters while it actually just takes positional. Please > either change it to named parameters or fix the comment. > Ah, that's because it was named parameters for a while, then I changed it because it was easier than trying to get ARG_PREFIX instead of $1 into [$]$1CFLAGS_JDK and friends. Fixed in: http://cr.openjdk.java.net/~andrew/8156980/webrev.02/ I'll let someone on your side push it through so you can regenerate your internal configure script at the same time. > Thanks for fixing this! > Thanks :) > /Erik > > On 2016-07-05 07:27, Andrew Hughes wrote: > > Webrev: http://cr.openjdk.java.net/~andrew/8156980/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156980 > > > > With "8151841: Build needs additional flags to compile with GCC 6", > > we added a number of compiler flags which were needed to build > > OpenJDK with GCC 6. Checks for these flags were added to configure, > > and the flags passed to the JDK and HotSpot builds by CFLAGS/CXXFLAGS_JDK > > and hotspot-spec.gmk.in respectively. > > > > Following "8152666: The new Hotspot Build System" and > > "8150601: Remove the old Hotspot build system", the hotspot-spec.gmk.in > > file was removed, so the flags were no longer passed to the HotSpot > > build. HotSpot now uses JVM_CFLAGS via the same configure process > > as the JDK obtains CFLAGS_JDK and CXXFLAGS_JDK[*]. > > > > This webrev fixes the regression introduced by 8152666 by adding > > the flags to JVM_CFLAGS. It also adapts FLAGS_SETUP_GCC6_COMPILER_FLAGS > > to take a prefix, as other macros in flags.m4 do, and calls > > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS before the version check. > > The lack of the latter lead to configure executing: > > > > if test $OPENJDK_BUILD_COMPARABLE_ACTUAL_VERSION -ge > > $COMPARABLE_REFERENCE_VERSION > > > > with OPENJDK_BUILD_COMPARABLE_ACTUAL_VERSION ever being set, causing > > test to print an error. > > > > With this fix, the flags again make it into the build. > > > > [*] It should really be CXXFLAGS_JVM as they are flags for the C++ > > compiler. > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From kim.barrett at oracle.com Tue Jul 5 15:44:46 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 5 Jul 2016 11:44:46 -0400 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> Message-ID: > On Jul 5, 2016, at 11:22 AM, Andrew Hughes wrote: > > ----- Original Message ----- >> Hello, >> >> In general it looks good. It's nice to see that this also fixes that >> warning output from configure. My only nit is the comment describing the >> parameters for FLAGS_SETUP_GCC6_COMPILER_FLAGS. It indicates that it >> takes named parameters while it actually just takes positional. Please >> either change it to named parameters or fix the comment. >> > > Ah, that's because it was named parameters for a while, then I changed it > because it was easier than trying to get ARG_PREFIX instead of $1 into > [$]$1CFLAGS_JDK and friends. > > Fixed in: > > http://cr.openjdk.java.net/~andrew/8156980/webrev.02/ > > I'll let someone on your side push it through so you can regenerate > your internal configure script at the same time. I've also been looking at this area. It looks like we've found pretty much the same set of problems and have similar solutions, so that's good. I have a few suggestions or possible improvements. ------------------------------------------------------------------------------ common/autoconf/flags.m4 716 $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" There is a pre-existing bug in the setup of ${$2CXXSTD_CXXFLAG}. It is using FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, which doesn't know about the BUILD/TARGET distinction. Note that this also doesn't seem to affect some non-VM chunks of code, such as adlc (in hotspot/src/share/vm/adlc). I don't know whether that matters. ------------------------------------------------------------------------------ common/autoconf/flags.m4 771 if test "x$1" = xTARGET; then 772 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS 773 else 774 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS(BUILD_,$2) 775 fi This is a fix for https://bugs.openjdk.java.net/browse/JDK-8157358 Syntax error in TOOLCHAIN_CHECK_COMPILER_VERSION I think the change I suggested in that CR is better. ------------------------------------------------------------------------------ common/autoconf/flags.m4 1458 AC_DEFUN([FLAGS_SETUP_GCC6_COMPILER_FLAGS], Changing from AC_DEFUN_ONCE to AC_DEFUN is good. It's needed in order to pass in the prefix. Even ignoring that issue, something needed to be done because the defun_once defined later was not being expanded where used. ------------------------------------------------------------------------------ common/autoconf/flags.m4 1470 $1CFLAGS_JDK="[$]$1CFLAGS_JDK ${NO_NULL_POINTER_CHECK_CFLAG} ${NO_LIFETIME_DSE_CFLAG}" 1471 $1JVM_CFLAGS="[$]$1JVM_CFLAGS ${NO_NULL_POINTER_CHECK_CFLAG} ${NO_LIFETIME_DSE_CFLAG}" Adding the prefix to the CFLAGS variables is good. Since we've already determined we're using gcc6+ to get here, I don't think there's any benefit to the pre-existing argument checks. More importantly, FLAGS_COMPILER_CHECK_ARGUMENTS doesn't account for the BUILD / TARGET distinction, so may produce the wrong answer if the build and target compilers are different versions of gcc. So I think those checks should be eliminated. Also, I think the variables capturing the options probably also need to be prefixed, if they are retained. Aside: I also think the variable name for -fno-delete-null-pointer-checks is mildly confusing, as the absence of "DELETE" inverts the apparent meaning. ------------------------------------------------------------------------------ common/autoconf/spec.gmk [removed] 395 NO_NULL_POINTER_CHECK_FLAG=@NO_NULL_POINTER_CHECK_CFLAG@ 396 NO_LIFETIME_DSE_CFLAG=@NO_LIFETIME_DSE_CFLAG@ 397 CXXSTD_CXXFLAG=@CXXSTD_CXXFLAG@ These removals are good. This also eliminates the "FLAG" for "CFLAG" typo in NO_NULL_POINTER_CHECK_FLAG=. ------------------------------------------------------------------------------ From gnu.andrew at redhat.com Tue Jul 5 17:33:59 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 5 Jul 2016 13:33:59 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> Message-ID: <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > On Jul 5, 2016, at 11:22 AM, Andrew Hughes wrote: > > > > ----- Original Message ----- > >> Hello, > >> > >> In general it looks good. It's nice to see that this also fixes that > >> warning output from configure. My only nit is the comment describing the > >> parameters for FLAGS_SETUP_GCC6_COMPILER_FLAGS. It indicates that it > >> takes named parameters while it actually just takes positional. Please > >> either change it to named parameters or fix the comment. > >> > > > > Ah, that's because it was named parameters for a while, then I changed it > > because it was easier than trying to get ARG_PREFIX instead of $1 into > > [$]$1CFLAGS_JDK and friends. > > > > Fixed in: > > > > http://cr.openjdk.java.net/~andrew/8156980/webrev.02/ > > > > I'll let someone on your side push it through so you can regenerate > > your internal configure script at the same time. > > I've also been looking at this area. It looks like we've found pretty > much the same set of problems and have similar solutions, so that's > good. I have a few suggestions or possible improvements. > > ------------------------------------------------------------------------------ > common/autoconf/flags.m4 > 716 $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" > > There is a pre-existing bug in the setup of ${$2CXXSTD_CXXFLAG}. It > is using FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, which doesn't know about > the BUILD/TARGET distinction. This seems to be a problem with both FLAGS_C_COMPILER_CHECK_ARGUMENTS and FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, and thus with the FLAGS_COMPILER_CHECK_ARGUMENTS macro that calls them both, which are used in several places. I think this is outside the scope of this patch and something which should be fixed by completing the current half-hearted cross-compilation support. My aim here is just to fix the regression which breaks the GCC 6 support on build==target builds, and I'd rather whoever was working on the cross-compilation build continued that work. There is a solution already in the handling of the warning argument check, but it needs to be generalised to the other cases. > > Note that this also doesn't seem to affect some non-VM chunks of code, > such as adlc (in hotspot/src/share/vm/adlc). I don't know whether > that matters. Ugh, yes, so I see. It seems a couple of parts of the HotSpot build just blithely ignore all this and set their own flags unconditionally. For example, they also set -m64 regardless of whether it was successfully tested for or not. I've added a patch to pass the std setting down to these parts of the HotSpot build again, but they more generally need to be brought in line with everything else and respect the configure checks. > > ------------------------------------------------------------------------------ > common/autoconf/flags.m4 > 771 if test "x$1" = xTARGET; then > 772 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS > 773 else > 774 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS(BUILD_,$2) > 775 fi > > This is a fix for > https://bugs.openjdk.java.net/browse/JDK-8157358 > Syntax error in TOOLCHAIN_CHECK_COMPILER_VERSION > > I think the change I suggested in that CR is better. > I agree. I've reverted this part of my patch. I didn't realise it was already being worked on and it was getting in the way of working on this fix. I just went with the most local fix that got rid of the broken test invocations. > ------------------------------------------------------------------------------ > common/autoconf/flags.m4 > 1458 AC_DEFUN([FLAGS_SETUP_GCC6_COMPILER_FLAGS], > > Changing from AC_DEFUN_ONCE to AC_DEFUN is good. > > It's needed in order to pass in the prefix. Even ignoring that issue, > something needed to be done because the defun_once defined later was > not being expanded where used. It was being expanded once before, which was appropriate for a block of code that didn't take any arguments and was only used because it made the source file easier to read than trying to add that logic inside the TOOLCHAIN_CHECK_COMPILER_VERSION invocation. Now we do need to call it for both the build and target compilers, AC_DEFUN is more appropriate. > > ------------------------------------------------------------------------------ > common/autoconf/flags.m4 > 1470 $1CFLAGS_JDK="[$]$1CFLAGS_JDK ${NO_NULL_POINTER_CHECK_CFLAG} > ${NO_LIFETIME_DSE_CFLAG}" > 1471 $1JVM_CFLAGS="[$]$1JVM_CFLAGS ${NO_NULL_POINTER_CHECK_CFLAG} > ${NO_LIFETIME_DSE_CFLAG}" > > Adding the prefix to the CFLAGS variables is good. > > Since we've already determined we're using gcc6+ to get here, I don't > think there's any benefit to the pre-existing argument checks. > > More importantly, FLAGS_COMPILER_CHECK_ARGUMENTS doesn't account for > the BUILD / TARGET distinction, so may produce the wrong answer if the > build and target compilers are different versions of gcc. > > So I think those checks should be eliminated. As you may recall, these checks were originally called in all instances and we decided to limit it to GCC 6 or later in review. I still think keeping the checks is wise, as these options may not work with future compilers. If I was to eliminate anything, it would be the version check, but I realise HotSpot developers are pretty conservative about turning off these optimisations on existing builds. FLAGS_COMPILER_CHECK_ARGUMENTS does need fixing for the cross compilation case as mentioned above, and that's a more general issue that affects other calls too: $ cat common/autoconf/flags.m4|grep 'FLAGS_COMPILER_CHECK_ARGUMENTS('|grep -v '^#' FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$STACK_PROTECTOR_CFLAG -Werror], IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$ZERO_ARCHFLAG], IF_FALSE: [ZERO_ARCHFLAG=""]) FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}], FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [-Wno-this-is-a-warning-that-do-not-exist], FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [-Wno-this-is-a-warning-that-do-not-exist], FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$NO_NULL_POINTER_CHECK_CFLAG -Werror], FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$NO_LIFETIME_DSE_CFLAG -Werror], In the case of -Wno-this-is-a-warning-that-do-not-exist, there are two invocations because the target and build compilers are both checked by switching the value of CXX: # Repeate the check for the BUILD_CC and BUILD_CXX. Need to also reset # CFLAGS since any target specific flags will likely not work with the # build compiler CC_OLD="$CC" CXX_OLD="$CXX" CC="$BUILD_CC" CXX="$BUILD_CXX" CFLAGS_OLD="$CFLAGS" CFLAGS="" That really needs to be factored into a macro and applied to all these calls. > > Also, I think the variables capturing the options probably also need > to be prefixed, if they are retained. > With AC_SUBST gone, these variables are only temporary. They are reset at the start and their values are not used again once they are added to the CFLAGS. > Aside: I also think the variable name for > -fno-delete-null-pointer-checks is mildly confusing, as the absence of > "DELETE" inverts the apparent meaning. I was trying to keep it short for brevity, but I agree and have renamed it. > > ------------------------------------------------------------------------------ > common/autoconf/spec.gmk > [removed] > 395 NO_NULL_POINTER_CHECK_FLAG=@NO_NULL_POINTER_CHECK_CFLAG@ > 396 NO_LIFETIME_DSE_CFLAG=@NO_LIFETIME_DSE_CFLAG@ > 397 CXXSTD_CXXFLAG=@CXXSTD_CXXFLAG@ > > These removals are good. This also eliminates the "FLAG" for "CFLAG" > typo in NO_NULL_POINTER_CHECK_FLAG=. > > ------------------------------------------------------------------------------ > > I've had to bring back CXXSTD_CXXFLAG=@CXXSTD_CXXFLAG@ for the renegade parts of the HotSpot build. New webrevs: http://cr.openjdk.java.net/~andrew/8156980/webrev.03/root/ http://cr.openjdk.java.net/~andrew/8156980/webrev.03/hotspot/ -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From philip.race at oracle.com Tue Jul 5 20:31:36 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 05 Jul 2016 13:31:36 -0700 Subject: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt In-Reply-To: <58fd8ac4-4520-4776-8229-a7c510eba6d6@default> References: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default> <58fd8ac4-4520-4776-8229-a7c510eba6d6@default> Message-ID: <577C1928.4020803@oracle.com> It is not always clear to me what warning is being suppressed and why you have chosen a particular solution/action this next one looks like it might introduce an unused variable warning. What was it solving ? That the code was not checking a return value ? size_t bytesWritten = write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); //bytesWritten is unused Isn't the compiler's point here that you *should* be doing something with the result? Not just ignoring it differently ... ----- and this one ? I want Semyon to comment on what this code is trying to do in its original form since it was added for GTK3. @@ -1989,11 +2029,7 @@ static guint8 recode_color(gdouble channel) { guint16 result = (guint16)(channel * 65535); - if (result < 0) { - result = 0; - } else if (result > 65535) { - result = 65535; - } + return (guint8)( result >> 8); } ----- -phil. On 06/23/2016 12:09 AM, Ajit Ghaisas wrote: > Hi, > > Bug : > https://bugs.openjdk.java.net/browse/JDK-8074824 > (Resolve disabled warnings for libawt_xawt) > > As part of fixing this bug, I have - > > 1. Fixed warnings in source code after removing blanket warning suppressions from makefile. > > 2. In case the warning fix is not possible, converted blanket warning suppression for this library to suppression of warnings for individual files. > > 3. Added comments in makefile for the warning suppression that cannot be fixed. > > One type of gcc warning 'deprecated-declarations' will be fixed separately (as part of JDK-8160146) > > > I have built the changes successfully on all supported platforms. > > > Webrev : > http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/ > > Request you to review. > > Regards, > Ajit From kim.barrett at oracle.com Tue Jul 5 20:54:08 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 5 Jul 2016 16:54:08 -0400 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> Message-ID: > On Jul 5, 2016, at 1:33 PM, Andrew Hughes wrote: > > ----- Original Message ----- >>> On Jul 5, 2016, at 11:22 AM, Andrew Hughes wrote: >> common/autoconf/flags.m4 >> 716 $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" >> >> There is a pre-existing bug in the setup of ${$2CXXSTD_CXXFLAG}. It >> is using FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, which doesn't know about >> the BUILD/TARGET distinction. > > This seems to be a problem with both FLAGS_C_COMPILER_CHECK_ARGUMENTS > and FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, and thus with the > FLAGS_COMPILER_CHECK_ARGUMENTS macro that calls them both, which are used > in several places. I think this is outside the scope of this patch and > something which should be fixed by completing the current half-hearted > cross-compilation support. My aim here is just to fix the regression > which breaks the GCC 6 support on build==target builds, and I'd rather > whoever was working on the cross-compilation build continued that work. > There is a solution already in the handling of the warning argument > check, but it needs to be generalised to the other cases. I totally agree that fixing the xxx_CHECK_ARGUMENTS is out of scope for this patch. What I'm worried about is that by keeping those checks we might get and use the wrong answer in some cases where the BUILD and TARGET compilers are of different vintage. Maybe that will just encourage someone to fix them... In the specific case of -std=gnu++98, it seems unlikely we'll see such a misconfiguration any time soon. That option was introduced in gcc3.3, and it seems unlikely to me that anyone is building the JDK with such an old compiler (though it wouldn't be the first time I've been surprised in that way). OTOH, if the compiler is very new and has dropped support for that standard (e.g. some as yet not even announced version of gcc), we actually want a build failure, since our code was written for that standard and not some later one. So we're unlikely to be hurt by the use of xxx_CHECK_ARGUMENTS here. For the gcc6-specific options, see below. >> Note that this also doesn't seem to affect some non-VM chunks of code, >> such as adlc (in hotspot/src/share/vm/adlc). I don't know whether >> that matters. > > Ugh, yes, so I see. It seems a couple of parts of the HotSpot build > just blithely ignore all this and set their own flags unconditionally. > For example, they also set -m64 regardless of whether it was successfully > tested for or not. > > I've added a patch to pass the std setting down to these parts of the > HotSpot build again, but they more generally need to be brought in line > with everything else and respect the configure checks. I think there are some more that are outside of HotSpot. Searching the build directory for *.o.cmdline files that don?t contain -std=gnu++98, e.g. find . -name "*.o.cmdline" ! -exec egrep -q -e "-std=gnu\+\+98" {} \; -print | xargs dirname | uniq produces a lot of stuff in ./support/native, the afore mentioned adlc, and a smattering of others. I think those might be better addressed by more followups, to get what we?ve got so far in. >> common/autoconf/flags.m4 >> 771 if test "x$1" = xTARGET; then >> 772 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS >> 773 else >> 774 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS(BUILD_,$2) >> 775 fi >> >> This is a fix for >> https://bugs.openjdk.java.net/browse/JDK-8157358 >> Syntax error in TOOLCHAIN_CHECK_COMPILER_VERSION >> >> I think the change I suggested in that CR is better. >> > > I agree. I've reverted this part of my patch. I didn't realise it > was already being worked on and it was getting in the way of working on > this fix. I just went with the most local fix that got rid of the broken > test invocations. I wasn't planning to work on any of this, but was feeling annoyed about the situation, and then events conspired to leave me at loose ends for a bit this weekend. Though if I'd remembered how much I dislike autoconf, I might have looked harder for alternatives. But you will need that fix for JDK-8157358. I guess I should post an RFR for it... or you can just incorporate it into this patch if I don?t get that RFR done soon. >> common/autoconf/flags.m4 >> 1458 AC_DEFUN([FLAGS_SETUP_GCC6_COMPILER_FLAGS], >> >> Changing from AC_DEFUN_ONCE to AC_DEFUN is good. >> >> It's needed in order to pass in the prefix. Even ignoring that issue, >> something needed to be done because the defun_once defined later was >> not being expanded where used. > > It was being expanded once before, which was appropriate for a block of > code that didn't take any arguments and was only used because it made the > source file easier to read than trying to add that logic inside the > TOOLCHAIN_CHECK_COMPILER_VERSION invocation. You are right about it being expanded once. I must have been remembering one of the unsuccessful attempts I tried, where no code was generated at all for it. > Now we do need to call it for both the build and target compilers, AC_DEFUN > is more appropriate. Yes. >> common/autoconf/flags.m4 >> 1470 $1CFLAGS_JDK="[$]$1CFLAGS_JDK ${NO_NULL_POINTER_CHECK_CFLAG} >> ${NO_LIFETIME_DSE_CFLAG}" >> 1471 $1JVM_CFLAGS="[$]$1JVM_CFLAGS ${NO_NULL_POINTER_CHECK_CFLAG} >> ${NO_LIFETIME_DSE_CFLAG}" >> >> Adding the prefix to the CFLAGS variables is good. >> >> Since we've already determined we're using gcc6+ to get here, I don't >> think there's any benefit to the pre-existing argument checks. >> >> More importantly, FLAGS_COMPILER_CHECK_ARGUMENTS doesn't account for >> the BUILD / TARGET distinction, so may produce the wrong answer if the >> build and target compilers are different versions of gcc. >> >> So I think those checks should be eliminated. > > As you may recall, these checks were originally called in all > instances and we decided to limit it to GCC 6 or later in review. > I still think keeping the checks is wise, as these options may > not work with future compilers. If I was to eliminate anything, > it would be the version check, but I realise HotSpot developers > are pretty conservative about turning off these optimisations > on existing builds. I'm much more worried about getting and using the wrong answer for these options. Since we're already in a context where we're known to be using gcc6+, we know we're not using a too-old compiler that doesn't support them for that reason. -f[no-]delete-null-pointer-checks has been around since gcc 3.0, and seems unlikely to go away, since it has a real documented purpose (address zero isn't so special on some platforms). -f[no-]lifetime-dse is fairly new (introduced in gcc 4.9), so seems unlikely to go away soon, and if it did we would want a build failure anyway, at least until we've fixed the code that gets broken by that optimization. > FLAGS_COMPILER_CHECK_ARGUMENTS does need fixing for the cross > compilation case as mentioned above, and that's a more general > issue that affects other calls too: Yes. > > $ cat common/autoconf/flags.m4|grep 'FLAGS_COMPILER_CHECK_ARGUMENTS('|grep -v '^#' > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$STACK_PROTECTOR_CFLAG -Werror], IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$ZERO_ARCHFLAG], IF_FALSE: [ZERO_ARCHFLAG=""]) > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}], > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [-Wno-this-is-a-warning-that-do-not-exist], > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [-Wno-this-is-a-warning-that-do-not-exist], > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$NO_NULL_POINTER_CHECK_CFLAG -Werror], > FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$NO_LIFETIME_DSE_CFLAG -Werror], > > In the case of -Wno-this-is-a-warning-that-do-not-exist, there are two > invocations because the target and build compilers are both checked > by switching the value of CXX: > > # Repeate the check for the BUILD_CC and BUILD_CXX. Need to also reset > # CFLAGS since any target specific flags will likely not work with the > # build compiler > CC_OLD="$CC" > CXX_OLD="$CXX" > CC="$BUILD_CC" > CXX="$BUILD_CXX" > CFLAGS_OLD="$CFLAGS" > CFLAGS="" > > That really needs to be factored into a macro and applied to all these calls. Yes. >> Also, I think the variables capturing the options probably also need >> to be prefixed, if they are retained. >> > > With AC_SUBST gone, these variables are only temporary. They are reset at > the start and their values are not used again once they are added to the CFLAGS. Oh, right, no more AC_SUBST here. > I've had to bring back CXXSTD_CXXFLAG=@CXXSTD_CXXFLAG@ for the renegade parts > of the HotSpot build. > > New webrevs: > > http://cr.openjdk.java.net/~andrew/8156980/webrev.03/root/ > http://cr.openjdk.java.net/~andrew/8156980/webrev.03/hotspot/ ------------------------------------------------------------------------------ hotspot/make/lib/CompileDtracePostJvm.gmk 90 JVM_OFFSETS_CFLAGS := $(CXXSTD_CXXFLAG) -m64 This appears to be in a solaris-specific block, so I don't think this change should be made. ------------------------------------------------------------------------------ hotspot/make/gensrc/GensrcAdlc.gmk 54 # Set the C++ standard if supported 55 ADLC_CFLAGS += $(CXXSTD_CXXFLAG) This appears to be in a platform-independent block; I think it needs to be moved to a different location, probably the linux block starting at line 37. From gnu.andrew at redhat.com Wed Jul 6 05:23:03 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 6 Jul 2016 01:23:03 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> Message-ID: <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > On Jul 5, 2016, at 1:33 PM, Andrew Hughes wrote: > > > > ----- Original Message ----- > >>> On Jul 5, 2016, at 11:22 AM, Andrew Hughes wrote: > >> common/autoconf/flags.m4 > >> 716 $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" > >> > >> There is a pre-existing bug in the setup of ${$2CXXSTD_CXXFLAG}. It > >> is using FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, which doesn't know about > >> the BUILD/TARGET distinction. > > > > This seems to be a problem with both FLAGS_C_COMPILER_CHECK_ARGUMENTS > > and FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, and thus with the > > FLAGS_COMPILER_CHECK_ARGUMENTS macro that calls them both, which are used > > in several places. I think this is outside the scope of this patch and > > something which should be fixed by completing the current half-hearted > > cross-compilation support. My aim here is just to fix the regression > > which breaks the GCC 6 support on build==target builds, and I'd rather > > whoever was working on the cross-compilation build continued that work. > > There is a solution already in the handling of the warning argument > > check, but it needs to be generalised to the other cases. > > I totally agree that fixing the xxx_CHECK_ARGUMENTS is out of scope > for this patch. > > What I'm worried about is that by keeping those checks we might get > and use the wrong answer in some cases where the BUILD and TARGET > compilers are of different vintage. Maybe that will just encourage > someone to fix them... Thanks. I agree it's an issue. I just don't think I'm the right person to undertake rewiring all that, as I've never even used the cross-compilation support so far. Do you know if there's already a bug for this? If not, I'll file one. > > In the specific case of -std=gnu++98, it seems unlikely we'll see such > a misconfiguration any time soon. That option was introduced in > gcc3.3, and it seems unlikely to me that anyone is building the JDK > with such an old compiler (though it wouldn't be the first time I've > been surprised in that way). OTOH, if the compiler is very new and has > dropped support for that standard (e.g. some as yet not even announced > version of gcc), we actually want a build failure, since our code was > written for that standard and not some later one. So we're unlikely to > be hurt by the use of xxx_CHECK_ARGUMENTS here. > I agree it's more likely that gnu++98 is going to be dropped at some point, than we had a compiler that doesn't support the -std option. Hopefully, making what was an implicit default before now explicit will encourage developers to look at moving the code forward to a later version of the standard. That's probably something for JDK 10+ though. > For the gcc6-specific options, see below. > > >> Note that this also doesn't seem to affect some non-VM chunks of code, > >> such as adlc (in hotspot/src/share/vm/adlc). I don't know whether > >> that matters. > > > > Ugh, yes, so I see. It seems a couple of parts of the HotSpot build > > just blithely ignore all this and set their own flags unconditionally. > > For example, they also set -m64 regardless of whether it was successfully > > tested for or not. > > > > I've added a patch to pass the std setting down to these parts of the > > HotSpot build again, but they more generally need to be brought in line > > with everything else and respect the configure checks. > > I think there are some more that are outside of HotSpot. > > Searching the build directory for *.o.cmdline files that don?t contain > -std=gnu++98, e.g. > > find . -name "*.o.cmdline" ! -exec egrep -q -e "-std=gnu\+\+98" {} \; -print > | xargs dirname | uniq > > produces a lot of stuff in ./support/native, the afore mentioned adlc, and a > smattering of others. > > I think those might be better addressed by more followups, to get what we?ve > got so far in. Thanks for the .cmdline trick. I wasn't aware of that. The -std=gnu++98 switch is only appropriate for the C++ compiler. Most of the support/native object files are C files. C++ code is used in the following: hotspot/variant-server/tools/adlc/objs hotspot/variant-server/libjvm/gtest/objs hotspot/variant-server/libjvm/gtest/launcher-objs hotspot/variant-server/libjvm/objs support/native/java.base/libjimage support/native/jdk.crypto.ec/libsunec support/native/java.desktop/libfontmanager support/native/jdk.pack200/unpackexe support/native/jdk.pack200/libunpack support/demos/native/jvmti/waiters Using find . -name "*.o.cmdline" -exec egrep -q -e "g\+\+" {} \; ! -exec egrep -q -e "-std=gnu\+\+98" {} \; -print I don't see any remaining files with the latest patch. snip... > >> common/autoconf/flags.m4 > >> 771 if test "x$1" = xTARGET; then > >> 772 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS > >> 773 else > >> 774 TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS(BUILD_,$2) > >> 775 fi > >> > >> This is a fix for > >> https://bugs.openjdk.java.net/browse/JDK-8157358 > >> Syntax error in TOOLCHAIN_CHECK_COMPILER_VERSION > >> > >> I think the change I suggested in that CR is better. > >> > > > > I agree. I've reverted this part of my patch. I didn't realise it > > was already being worked on and it was getting in the way of working on > > this fix. I just went with the most local fix that got rid of the broken > > test invocations. > > I wasn't planning to work on any of this, but was feeling annoyed > about the situation, and then events conspired to leave me at loose > ends for a bit this weekend. Though if I'd remembered how much I > dislike autoconf, I might have looked harder for alternatives. > > But you will need that fix for JDK-8157358. I guess I should post an > RFR for it... or you can just incorporate it into this patch if I don?t get > that RFR done soon. I wasn't planning to either, but it was likewise bugging me when I was trying to fix the GCC 6 issue. Ironically, it took much longer to work out what was going on there than it did to realise I needed to add the flags to JVM_CFLAGS :( I've included the fix in this patch, assuming that's ok with you. > > >> common/autoconf/flags.m4 > >> 1470 $1CFLAGS_JDK="[$]$1CFLAGS_JDK ${NO_NULL_POINTER_CHECK_CFLAG} > >> ${NO_LIFETIME_DSE_CFLAG}" > >> 1471 $1JVM_CFLAGS="[$]$1JVM_CFLAGS ${NO_NULL_POINTER_CHECK_CFLAG} > >> ${NO_LIFETIME_DSE_CFLAG}" > >> > >> Adding the prefix to the CFLAGS variables is good. > >> > >> Since we've already determined we're using gcc6+ to get here, I don't > >> think there's any benefit to the pre-existing argument checks. > >> > >> More importantly, FLAGS_COMPILER_CHECK_ARGUMENTS doesn't account for > >> the BUILD / TARGET distinction, so may produce the wrong answer if the > >> build and target compilers are different versions of gcc. > >> > >> So I think those checks should be eliminated. > > > > As you may recall, these checks were originally called in all > > instances and we decided to limit it to GCC 6 or later in review. > > I still think keeping the checks is wise, as these options may > > not work with future compilers. If I was to eliminate anything, > > it would be the version check, but I realise HotSpot developers > > are pretty conservative about turning off these optimisations > > on existing builds. > > I'm much more worried about getting and using the wrong answer for > these options. Since we're already in a context where we're known to > be using gcc6+, we know we're not using a too-old compiler that > doesn't support them for that reason. > > -f[no-]delete-null-pointer-checks has been around since gcc 3.0, and > seems unlikely to go away, since it has a real documented purpose > (address zero isn't so special on some platforms). > > -f[no-]lifetime-dse is fairly new (introduced in gcc 4.9), so seems > unlikely to go away soon, and if it did we would want a build failure > anyway, at least until we've fixed the code that gets broken by that > optimization. > I see your concern; potentially, we could check that one compiler is >= GCC 6, but then run the argument checks on an older compiler. As a compromise, I've commented out the argument checks rather than removing them. I'm generally wary about trusting version checks alone rather than behaviour checks, and so I would prefer these were re-enabled when the macro is fixed. We've actually been quite lucky that the macro is only used for options which aren't enabled in every build at present (stack-protector for slowdebug, options for the Zero assembler port and the GCC 6 options). The Zero ones are particularly troublesome, because cross-compiling to a target using the Zero assembler port seems one of the most likely scenarios, as it allows a JDK to be built for a new target that doesn't yet have a boot JDK. Incidentally, both these flags are mentioned in the GCC 6 release notes [0]. snip... > > > I've had to bring back CXXSTD_CXXFLAG=@CXXSTD_CXXFLAG@ for the renegade > > parts > > of the HotSpot build. > > > > New webrevs: > > > > http://cr.openjdk.java.net/~andrew/8156980/webrev.03/root/ > > http://cr.openjdk.java.net/~andrew/8156980/webrev.03/hotspot/ > > ------------------------------------------------------------------------------ > hotspot/make/lib/CompileDtracePostJvm.gmk > 90 JVM_OFFSETS_CFLAGS := $(CXXSTD_CXXFLAG) -m64 > > This appears to be in a solaris-specific block, so I don't think this > change should be made. Ah, good catch. Removed. I was looking for CFLAGS that weren't using JVM_CFLAGS or CFLAGS_JDK and didn't check the full context on that one. > > ------------------------------------------------------------------------------ > hotspot/make/gensrc/GensrcAdlc.gmk > 54 # Set the C++ standard if supported > 55 ADLC_CFLAGS += $(CXXSTD_CXXFLAG) > > This appears to be in a platform-independent block; I think it needs > to be moved to a different location, probably the linux block starting > at line 37. I had it in the Linux block to begin with, but GCC is not specific to Linux. This distinction between toolchains and platforms is held in the main autotools code, but not in these Makefiles. From toolchain.gmk, it can be seen that gcc on MacOS X is also supported: # These toolchains are valid on different platforms VALID_TOOLCHAINS_linux="gcc clang" VALID_TOOLCHAINS_solaris="solstudio" VALID_TOOLCHAINS_macosx="gcc clang" VALID_TOOLCHAINS_aix="xlc" VALID_TOOLCHAINS_windows="microsoft" and there is the potential for gcc to be used on other platforms too (*BSD springs to mind). If gcc is not being used, CXXSTD_CXXFLAG won't be set so this should be a safe no-op. > > > Revised webrevs: http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot I'm also now seeing a problem with GCC 6 only that is unique to the latest OpenJDK 9 and what looks like the gtest code. It seems to be the result of the header changes also documented in [0] which were introduced in January [1] (and so probably weren't in earlier test versions of GCC 6). I'm able to work around it and get a completed build by setting -D_GLIBCXX_INCLUDE_NEXT_C_HEADERS, so it seems to be something to do with the changes to stdlib.h in GCC 6. Something for a separate bug. [0] https://gcc.gnu.org/gcc-6/porting_to.html [1] https://github.com/gcc-mirror/gcc/commit/6c8ced3f4f867b72a623fe2f23efa204c5786a28 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gerald.thornbrugh at oracle.com Wed Jul 6 16:19:47 2016 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Wed, 6 Jul 2016 10:19:47 -0600 Subject: Error using JIB on linux lab machine Message-ID: Hi Everyone, I am trying to use JIB to do a build on a linux lab machine (sc11137378.us.oracle.com) and get an error during the ?make? command. The ?configure? completes without error and when I do the ?make? I get an an error that seems to related to this message in the output: error: Bad owner/group: /scratch/w/gthornbr/JDK-8146598/jdk9/build/linux-x64/install/tmp/jre-rpm/SOURCES/jre-9.tar Below is more of the output: $ bash common/bin/jib.sh make [jib LOG] Mirror site main [jib LOG] Setting up jib 2.0-SNAPSHOT [jib LOG] jib 2.0-SNAPSHOT already installed [jib LOG] JDK build wrapper v2.0 bbb0e38ca66c25b2de582eeec1d5968109c9cfb1 [jib LOG] Mirror site main [jib LOG] Setting up jdk-linux_x64 8u60+1.0 [jib LOG] jdk-linux_x64 8u60+1.0 already installed [jib LOG] Build ID: 2016-07-06-085727.gthornbr.jdk9 [jib LOG] Build profile: linux-x64 [jib LOG] Build configuration: linux-x64 [jib LOG] Build platform: linux_x64 [jib LOG] Target platform: linux_x64 [jib LOG] Setting up gnumake 4.0+1.0 [jib LOG] gnumake 4.0+1.0 already installed [jib LOG] Setting up jtreg 4.2 [jib LOG] jtreg 4.2 already installed [jib LOG] Setting up tonga 4.0.0_May_12_2014+1.0 [jib LOG] tonga 4.0.0_May_12_2014+1.0 already installed [jib LOG] JT_HOME=/var/tmp/jib-gthornbr/install/java/re/jtreg/4.2/promoted/all/b02/bundles/jtreg_bin-4.2.zip/jtreg [jib LOG] TONGA_HOME=/var/tmp/jib-gthornbr/install/jpg/infra/builddeps/tonga/4.0.0_May_12_2014+1.0/tonga-4.0.0_May_12_2014+1.0.zip [jib LOG] /var/tmp/jib-gthornbr/install/jpg/infra/builddeps/gnumake-linux_x64/4.0+1.0/gnumake-linux_x64-4.0+1.0.tar.gz/bin/make CONF_NAME=linux-x64 Building configuration 'linux-x64' (matching CONF_NAME=linux-x64) . . . <<>>Recursively making ./bundles all @ Wed Jul 6 09:07:28 PDT 2016 ... make[5]: warning: -jN forced in submake: disabling jobserver mode. + uname + tr A-Z a-z + command -v bash /scratch/w/gthornbr/JDK-8146598/jdk9/install/make/share/defs/All.gmk:662: Wed Jul 6 09:07:28 PDT 2016 << + uname + tr A-Z a-z + command -v bash /scratch/w/gthornbr/JDK-8146598/jdk9/install/make/share/defs/All.gmk:662: Wed Jul 6 09:07:28 PDT 2016 << Sanity check passed. 779448 blocks ls: cannot access /scratch/w/gthornbr/JDK-8146598/jdk9/build/linux-x64/install/jre/man/man1: No such file or directory ls: cannot access /scratch/w/gthornbr/JDK-8146598/jdk9/build/linux-x64/install/jdk/man/man1: No such file or directory error: Bad owner/group: /scratch/w/gthornbr/JDK-8146598/jdk9/build/linux-x64/install/tmp/jre-rpm/SOURCES/jre-9.tar c Building for target x86_64-Sun-Linux Makefile:36: recipe for target 'j2re-rpm' failed make[6]: *** [j2re-rpm] Error 1 Makefile:16: recipe for target 'all' failed make[5]: *** [all] Error 2 Makefile:73: recipe for target 'all' failed make[4]: *** [all] Error 2 make[3]: *** [installer] Error 2 /scratch/w/gthornbr/JDK-8146598/jdk9/install/make/Makefile:104: recipe for target 'installer' failed /scratch/w/gthornbr/JDK-8146598/jdk9/closed/make/Main.gmk:57: recipe for target 'installer' failed make[2]: *** [installer] Error 1 make[2]: *** Waiting for unfinished jobs.... ERROR: Build failed for target 'default (product-bundles test-bundles docs-bundles)' in configuration 'linux-x64' (exit code 2) === Make failure sequence repeated here === Makefile:36: recipe for target 'j2re-rpm' failed Makefile:16: recipe for target 'all' failed Makefile:73: recipe for target 'all' failed /scratch/w/gthornbr/JDK-8146598/jdk9/install/make/Makefile:104: recipe for target 'installer' failed /scratch/w/gthornbr/JDK-8146598/jdk9/closed/make/Main.gmk:57: recipe for target 'installer' failed === End of repeated output === Hint: Try searching the build log for the name of the first failed target. Hint: If caused by a warning, try configure --disable-warnings-as-errors. /scratch/w/gthornbr/JDK-8146598/jdk9/make/Init.gmk:286: recipe for target 'main' failed make[1]: *** [main] Error 1 /scratch/w/gthornbr/JDK-8146598/jdk9/make/Init.gmk:185: recipe for target 'default' failed make: *** [default] Error 2 Below is the ?name -a? from sc11137378.us.oracle.com : $ uname -a Linux sc11137378 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 12:29:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Has anyone seen a failure like this? What am I doing wrong? Is the configuration of sc1113738.us.oracle.com missconfigured or not supported by JIB? Thanks! Jerry From kim.barrett at oracle.com Wed Jul 6 18:36:26 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 6 Jul 2016 14:36:26 -0400 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> Message-ID: > On Jul 6, 2016, at 1:23 AM, Andrew Hughes wrote: > > ----- Original Message ----- >>> On Jul 5, 2016, at 1:33 PM, Andrew Hughes wrote: >>> >>> ----- Original Message ----- >>>>> On Jul 5, 2016, at 11:22 AM, Andrew Hughes wrote: >>>> common/autoconf/flags.m4 >>>> 716 $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" >>>> >>>> There is a pre-existing bug in the setup of ${$2CXXSTD_CXXFLAG}. It >>>> is using FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, which doesn't know about >>>> the BUILD/TARGET distinction. >>> >>> This seems to be a problem with both FLAGS_C_COMPILER_CHECK_ARGUMENTS >>> and FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, and thus with the >>> FLAGS_COMPILER_CHECK_ARGUMENTS macro that calls them both, which are used >>> in several places. I think this is outside the scope of this patch and >>> something which should be fixed by completing the current half-hearted >>> cross-compilation support. My aim here is just to fix the regression >>> which breaks the GCC 6 support on build==target builds, and I'd rather >>> whoever was working on the cross-compilation build continued that work. >>> There is a solution already in the handling of the warning argument >>> check, but it needs to be generalised to the other cases. >> >> I totally agree that fixing the xxx_CHECK_ARGUMENTS is out of scope >> for this patch. >> >> What I'm worried about is that by keeping those checks we might get >> and use the wrong answer in some cases where the BUILD and TARGET >> compilers are of different vintage. Maybe that will just encourage >> someone to fix them... > > Thanks. I agree it's an issue. I just don't think I'm the right person > to undertake rewiring all that, as I've never even used the cross-compilation > support so far. Yeah, I feel the same way. While I've dealt with cross-compilation issues of this sort enough to recognize the presence of problems, that work wasn't with this build system. > Do you know if there's already a bug for this? If not, I'll file one. I didn't find any relevant bugs. >> In the specific case of -std=gnu++98, it seems unlikely we'll see such >> a misconfiguration any time soon. That option was introduced in >> gcc3.3, and it seems unlikely to me that anyone is building the JDK >> with such an old compiler (though it wouldn't be the first time I've >> been surprised in that way). OTOH, if the compiler is very new and has >> dropped support for that standard (e.g. some as yet not even announced >> version of gcc), we actually want a build failure, since our code was >> written for that standard and not some later one. So we're unlikely to >> be hurt by the use of xxx_CHECK_ARGUMENTS here. >> > > I agree it's more likely that gnu++98 is going to be dropped at some point, > than we had a compiler that doesn't support the -std option. Hopefully, > making what was an implicit default before now explicit will encourage > developers to look at moving the code forward to a later version of the > standard. That's probably something for JDK 10+ though. I think there is interest in that direction. >> I think there are some more that are outside of HotSpot. >> >> Searching the build directory for *.o.cmdline files that don?t contain >> -std=gnu++98, e.g. >> >> find . -name "*.o.cmdline" ! -exec egrep -q -e "-std=gnu\+\+98" {} \; -print >> | xargs dirname | uniq >> >> produces a lot of stuff in ./support/native, the afore mentioned adlc, and a >> smattering of others. >> >> I think those might be better addressed by more followups, to get what we?ve >> got so far in. > > Thanks for the .cmdline trick. I wasn't aware of that. The .o.cmdline files are a feature of the new build system that I like a lot. > The -std=gnu++98 switch is only appropriate for the C++ compiler. Most of the > support/native object files are C files. > > C++ code is used in the following: > [?] > Using find . -name "*.o.cmdline" -exec egrep -q -e "g\+\+" {} \; ! -exec egrep -q -e "-std=gnu\+\+98" {} \; -print > I don't see any remaining files with the latest patch. Yay! >> But you will need that fix for JDK-8157358. I guess I should post an >> RFR for it... or you can just incorporate it into this patch if I don?t get >> that RFR done soon. > > I wasn't planning to either, but it was likewise bugging me when I > was trying to fix the GCC 6 issue. Ironically, it took much longer to > work out what was going on there than it did to realise I needed to > add the flags to JVM_CFLAGS :( > > I've included the fix in this patch, assuming that's ok with you. Yes, that?s fine with me. > If gcc is not being used, CXXSTD_CXXFLAG won't be set so this should be a safe no-op. Oh, right. > Revised webrevs: > > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot These look good to me. > I'm also now seeing a problem with GCC 6 only that is unique to the latest OpenJDK 9 > and what looks like the gtest code. It seems to be the result of the header changes > also documented in [0] which were introduced in January [1] (and so probably weren't > in earlier test versions of GCC 6). I'm able to work around it and get a completed > build by setting -D_GLIBCXX_INCLUDE_NEXT_C_HEADERS, so it seems to be something > to do with the changes to stdlib.h in GCC 6. Something for a separate bug. What fun! > [0] https://gcc.gnu.org/gcc-6/porting_to.html > [1] https://github.com/gcc-mirror/gcc/commit/6c8ced3f4f867b72a623fe2f23efa204c5786a28 > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Jul 7 03:51:08 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 6 Jul 2016 23:51:08 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> Message-ID: <1356840573.2734504.1467863468986.JavaMail.zimbra@redhat.com> snip... > >> > >> What I'm worried about is that by keeping those checks we might get > >> and use the wrong answer in some cases where the BUILD and TARGET > >> compilers are of different vintage. Maybe that will just encourage > >> someone to fix them... > > > > Thanks. I agree it's an issue. I just don't think I'm the right person > > to undertake rewiring all that, as I've never even used the > > cross-compilation > > support so far. > > Yeah, I feel the same way. While I've dealt with cross-compilation > issues of this sort enough to recognize the presence of problems, that > work wasn't with this build system. > > > Do you know if there's already a bug for this? If not, I'll file one. > > I didn't find any relevant bugs. > I've filed one: https://bugs.openjdk.java.net/browse/JDK-8160926 snip... > > > Revised webrevs: > > > > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root > > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot > > These look good to me. > Thanks. I need someone at Oracle to push this one through, as the configure script for the closed code needs regenerating too. Apparently, I broke things last time :( > > I'm also now seeing a problem with GCC 6 only that is unique to the latest > > OpenJDK 9 > > and what looks like the gtest code. It seems to be the result of the header > > changes > > also documented in [0] which were introduced in January [1] (and so > > probably weren't > > in earlier test versions of GCC 6). I'm able to work around it and get a > > completed > > build by setting -D_GLIBCXX_INCLUDE_NEXT_C_HEADERS, so it seems to be > > something > > to do with the changes to stdlib.h in GCC 6. Something for a separate bug. > > What fun! A new batch of changes just came through which seems to have fixed it. I'm guessing this one: http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/7862a718ec47 Either way, I'm happy I don't have to debug it :-) > > > [0] https://gcc.gnu.org/gcc-6/porting_to.html > > [1] > > https://github.com/gcc-mirror/gcc/commit/6c8ced3f4f867b72a623fe2f23efa204c5786a28 > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > > Thanks for the great feedback on this patch, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From stefan.anzinger at oracle.com Thu Jul 7 08:24:43 2016 From: stefan.anzinger at oracle.com (Stefan Anzinger) Date: Thu, 7 Jul 2016 08:24:43 +0000 Subject: RFR: 8160825 Update minimum Solaris Studio compiler version to 5.13 Message-ID: <6da83532-c37d-494d-a26d-1dd2e2373276@oracle.com> This is a small change, to update the ckeck in configure to warn if the required Solaris Studio Compiler 5.13 is not available (As stated in the README-builds.html). http://cr.openjdk.java.net/~sanzinger/8160825/webrev.00/ Stefan From tim.bell at oracle.com Thu Jul 7 15:08:18 2016 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 7 Jul 2016 08:08:18 -0700 Subject: RFR: 8160825 Update minimum Solaris Studio compiler version to 5.13 In-Reply-To: <6da83532-c37d-494d-a26d-1dd2e2373276@oracle.com> References: <6da83532-c37d-494d-a26d-1dd2e2373276@oracle.com> Message-ID: <577E7062.10405@oracle.com> Hello Stefan: > This is a small change, to update the ckeck in configure to warn if > the required Solaris Studio Compiler 5.13 is not available (As stated > in the README-builds.html). > http://cr.openjdk.java.net/~sanzinger/8160825/webrev.00/ Looks good. Sun Studio 12.4 contains the C++ 5.13 compiler: % devkit/SS12u4-Solaris11u1/SS12u4/bin/CC -V CC: Sun C++ 5.13 SunOS_i386 151846-10 2015/10/30 Since this change is in an open .m4 file, remember to run common/autoconf/autogen.sh and then push both open and closed generated-configure.sh files. Tim From gnu.andrew at redhat.com Thu Jul 7 15:53:06 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Jul 2016 11:53:06 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1356840573.2734504.1467863468986.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1356840573.2734504.1467863468986.JavaMail.zimbra@redhat.com> Message-ID: <1801967885.2914575.1467906786428.JavaMail.zimbra@redhat.com> snip... > > > I'm also now seeing a problem with GCC 6 only that is unique to the > > > latest > > > OpenJDK 9 > > > and what looks like the gtest code. It seems to be the result of the > > > header > > > changes > > > also documented in [0] which were introduced in January [1] (and so > > > probably weren't > > > in earlier test versions of GCC 6). I'm able to work around it and get a > > > completed > > > build by setting -D_GLIBCXX_INCLUDE_NEXT_C_HEADERS, so it seems to be > > > something > > > to do with the changes to stdlib.h in GCC 6. Something for a separate > > > bug. > > > > What fun! > > A new batch of changes just came through which seems to have fixed it. > I'm guessing this one: > > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/7862a718ec47 > > Either way, I'm happy I don't have to debug it :-) > Sadly, I celebrated too soon; it seems that change just delayed the failure until much later in the build. I've found the problem though. In src/share/vm/utilities/globalDefinitions.hpp, we have: #ifdef max #undef max #endif #ifdef min #undef min #endif #define max(a,b) Do_not_use_max_use_MAX2_instead #define min(a,b) Do_not_use_min_use_MIN2_instead The problem is that max and min are now longer macros in the GCC 6 C++ library. So they can't be undefined. The build succeeds if I disable (#if 0) the definition of max and min. So we need to consider either removing them or _GLIBCXX_INCLUDE_NEXT_C_HEADERS needs to be defined to get the old behaviour. I prefer the former. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From ajit.ghaisas at oracle.com Thu Jul 7 16:48:35 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 7 Jul 2016 16:48:35 +0000 (UTC) Subject: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt In-Reply-To: <577C1928.4020803@oracle.com> References: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default> <58fd8ac4-4520-4776-8229-a7c510eba6d6@default> <577C1928.4020803@oracle.com> Message-ID: <3b60b430-2bbb-47f6-b37e-ec9d47fa150c@default> Thanks Phil for the review. Please find my answers below. Semyon, can you please comment on Phil's question below? Regards, Ajit -----Original Message----- From: Phil Race Sent: Wednesday, July 06, 2016 2:02 AM To: Ajit Ghaisas Cc: Sergey Bylokhov; Erik Joelsson; 2d-dev; awt-dev at openjdk.java.net; build-dev at openjdk.java.net Subject: Re: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt It is not always clear to me what warning is being suppressed and why you have chosen a particular solution/action this next one looks like it might introduce an unused variable warning. What was it solving ? That the code was not checking a return value ? size_t bytesWritten = write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); //bytesWritten is unused Isn't the compiler's point here that you *should* be doing something with the result? Not just ignoring it differently ... ---------------------------------------------- [Ajit] : there was a warning of type 'unused-result' for write() method. Now, I have just assigned that to a variable which fixes the warning. I think, we should have some code to do error check on bytesWritten and return it - but it is out of purview of this fix as it may introduce behavioral change. ---------------------------------------------- ----- and this one ? I want Semyon to comment on what this code is trying to do in its original form since it was added for GTK3. @@ -1989,11 +2029,7 @@ static guint8 recode_color(gdouble channel) { guint16 result = (guint16)(channel * 65535); - if (result < 0) { - result = 0; - } else if (result > 65535) { - result = 65535; - } + return (guint8)( result >> 8); } ----------------------------------------------------- [Ajit] : there was a warning about guint16 will not be less than 0 and larger than 65535. Hence I have removed code checking this range. ----------------------------------------------------- ----- -phil. On 06/23/2016 12:09 AM, Ajit Ghaisas wrote: > Hi, > > Bug : > https://bugs.openjdk.java.net/browse/JDK-8074824 > (Resolve disabled warnings for libawt_xawt) > > As part of fixing this bug, I have - > > 1. Fixed warnings in source code after removing blanket warning suppressions from makefile. > > 2. In case the warning fix is not possible, converted blanket warning suppression for this library to suppression of warnings for individual files. > > 3. Added comments in makefile for the warning suppression that cannot be fixed. > > One type of gcc warning 'deprecated-declarations' will be fixed > separately (as part of JDK-8160146) > > > I have built the changes successfully on all supported platforms. > > > Webrev : > http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/ > > Request you to review. > > Regards, > Ajit From semyon.sadetsky at oracle.com Thu Jul 7 17:25:17 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 7 Jul 2016 20:25:17 +0300 Subject: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt In-Reply-To: <3b60b430-2bbb-47f6-b37e-ec9d47fa150c@default> References: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default> <58fd8ac4-4520-4776-8229-a7c510eba6d6@default> <577C1928.4020803@oracle.com> <3b60b430-2bbb-47f6-b37e-ec9d47fa150c@default> Message-ID: <320e423b-9183-16fb-ad8a-9b1e668729d2@oracle.com> On 7/7/2016 7:48 PM, Ajit Ghaisas wrote: > Thanks Phil for the review. > Please find my answers below. > > Semyon, can you please comment on Phil's question below? I agree with this change. The check is not needed. --Semyon > > Regards, > Ajit > > -----Original Message----- > From: Phil Race > Sent: Wednesday, July 06, 2016 2:02 AM > To: Ajit Ghaisas > Cc: Sergey Bylokhov; Erik Joelsson; 2d-dev; awt-dev at openjdk.java.net; build-dev at openjdk.java.net > Subject: Re: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt > > It is not always clear to me what warning is being suppressed and why you have chosen a particular solution/action > > > this next one looks like it might introduce an unused variable warning. > What was it solving ? That the code was not checking a return value ? > > size_t bytesWritten = write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); //bytesWritten is unused > > Isn't the compiler's point here that you *should* be doing something with the result? > Not just ignoring it differently ... > > ---------------------------------------------- > [Ajit] : there was a warning of type 'unused-result' for write() method. Now, I have just assigned that to a variable which fixes the warning. > I think, we should have some code to do error check on bytesWritten and return it - but it is out of purview of this fix as it may introduce behavioral change. > ---------------------------------------------- > > ----- > > and this one ? I want Semyon to comment on what this code is trying to do in its original form since it was added for GTK3. > > @@ -1989,11 +2029,7 @@ > static guint8 recode_color(gdouble channel) > { > guint16 result = (guint16)(channel * 65535); > - if (result < 0) { > - result = 0; > - } else if (result > 65535) { > - result = 65535; > - } > + > return (guint8)( result >> 8); > } > > ----------------------------------------------------- > [Ajit] : there was a warning about guint16 will not be less than 0 and larger than 65535. Hence I have removed code checking this range. > ----------------------------------------------------- > > ----- > > > -phil. > > On 06/23/2016 12:09 AM, Ajit Ghaisas wrote: >> Hi, >> >> Bug : >> https://bugs.openjdk.java.net/browse/JDK-8074824 >> (Resolve disabled warnings for libawt_xawt) >> >> As part of fixing this bug, I have - >> >> 1. Fixed warnings in source code after removing blanket warning suppressions from makefile. >> >> 2. In case the warning fix is not possible, converted blanket warning suppression for this library to suppression of warnings for individual files. >> >> 3. Added comments in makefile for the warning suppression that cannot be fixed. >> >> One type of gcc warning 'deprecated-declarations' will be fixed >> separately (as part of JDK-8160146) >> >> >> I have built the changes successfully on all supported platforms. >> >> >> Webrev : >> http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/ >> >> Request you to review. >> >> Regards, >> Ajit From gnu.andrew at redhat.com Thu Jul 7 17:48:02 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Jul 2016 13:48:02 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> Message-ID: <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> snip... > > > Revised webrevs: > > > > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root > > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot > > These look good to me. > Minor revision: http://cr.openjdk.java.net/~andrew/8156980/webrev.05/root http://cr.openjdk.java.net/~andrew/8156980/webrev.05/hotspot I spotted that jsig is just a single C file and so doesn't need the -std flag. In fact, it complains about it: Compiling jsig.c (for libjsig.so) ( ( /usr/bin/gcc -fPIC -D_GNU_SOURCE -D_REENTRANT -O2 -pipe -march=core2 -std=gnu++98 -m64 -g -DTHIS_FILE='"jsig.c"' -c -MMD -\ MF /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.d -o /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o /home/andrew/p\ rojects/openjdk/upstream/dev/hotspot/src/os/linux/vm/jsig.c > >(/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsi\ g.o.log) 2> >(/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o.log >&2) || ( exitcode=$? && /bin/cp /home/and\ rew/builder/dev/hotspot/libjsig/objs/jsig.o.log /home/andrew/builder/dev/make-support/failure-logs/hotspot_libjsig_objs_jsig.o\ .log && exit $exitcode ) ) && wait ) cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ but not for C So just ADLC is fixed now. The root webrev is the same as before. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From stevensro at gmail.com Thu Jul 7 18:21:09 2016 From: stevensro at gmail.com (Robin Stevens) Date: Thu, 7 Jul 2016 20:21:09 +0200 Subject: Building JDK8 fails on OS X El Capitan: clang process gets stuck Message-ID: Hello, if you follow the build instructions to the letter ( http://hg.openjdk.java.net/jdk8u/jdk8u-dev/file/817d9fb584ba/README-builds.html), and try building JDK with XCode version 4.5.2 on El Capitan, the build never ends. At a certain point, you have a number of "clang" processes each consuming one CPU core for 100% which never end. Using XCode version 4.6.3 solves the issue. Can this be added to the build instructions ? It would have saved me a considerable amount of time if this would have been mentioned in the documentation. Thanks, Robin From stevensro at gmail.com Thu Jul 7 18:31:43 2016 From: stevensro at gmail.com (Robin Stevens) Date: Thu, 7 Jul 2016 20:31:43 +0200 Subject: Building JDK9 fails on OS X El Capitan Message-ID: Hello, it is currently not possible to build JDK9 on OS X El Capitan. The problem is the line #include in files jdk/src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.m jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m On OS X El Capitan, the Accelerate.h file contains #ifndef __VECLIB__ #include #endif where vecLib.h contains #error "The vecLib framework is deprecated. Please include instead of and link to the Accelerate framework instead of the vecLib framework." This is also the error with which the build fails. Adding #define __VECLIB__ to the two aforementioned files resolves the error, as it avoids that the Accelerate.h file loads the vecLib.h file. I have no idea of the impact of adding #define __VECLIB__ , and what it might break. The purpose of this email is more to ensure that other people who stumble against the same problem can find a solution using Google. Regards, Robin From philip.race at oracle.com Thu Jul 7 19:05:57 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 07 Jul 2016 12:05:57 -0700 Subject: Building JDK9 fails on OS X El Capitan In-Reply-To: References: Message-ID: <577EA815.6070302@oracle.com> I expect this is the SDK version you are using more than the OS version. 10.9 is the supported SDK. Any changes to this particular code should be discussed on 2d-dev at openjdk.java.net since they would not be build changes But that might not be sufficient .. you could encounter other issues that limit the ability to build using whatever SDK you have. -phil. On 07/07/2016 11:31 AM, Robin Stevens wrote: > Hello, > > it is currently not possible to build JDK9 on OS X El Capitan. > > The problem is the line > > #include > > in files > > jdk/src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.m > jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m > > On OS X El Capitan, the Accelerate.h file contains > > #ifndef __VECLIB__ > #include > #endif > > where vecLib.h contains > > #error "The vecLib framework is deprecated. Please include > instead of and link to the > Accelerate framework instead of the vecLib framework." > > This is also the error with which the build fails. > > Adding > > #define __VECLIB__ > > to the two aforementioned files resolves the error, as it avoids that the > Accelerate.h file loads the vecLib.h file. > > I have no idea of the impact of adding #define __VECLIB__ , and what it > might break. > The purpose of this email is more to ensure that other people who stumble > against the same problem can find a solution using Google. > > Regards, > > Robin From kim.barrett at oracle.com Thu Jul 7 19:10:34 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 7 Jul 2016 19:10:34 +0000 (UTC) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <577B5AA0.8050207@oracle.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> Message-ID: <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> > On Jul 7, 2016, at 1:48 PM, Andrew Hughes wrote: >>> Revised webrevs: >>> >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot >> >> These look good to me. >> > > Minor revision: > > http://cr.openjdk.java.net/~andrew/8156980/webrev.05/root > http://cr.openjdk.java.net/~andrew/8156980/webrev.05/hotspot > > I spotted that jsig is just a single C file and so doesn't > need the -std flag. In fact, it complains about it: > > Compiling jsig.c (for libjsig.so) > ( ( /usr/bin/gcc -fPIC -D_GNU_SOURCE -D_REENTRANT -O2 -pipe -march=core2 -std=gnu++98 -m64 -g -DTHIS_FILE='"jsig.c"' -c -MMD -\ > MF /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.d -o /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o /home/andrew/p\ > rojects/openjdk/upstream/dev/hotspot/src/os/linux/vm/jsig.c > >(/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsi\ > g.o.log) 2> >(/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o.log >&2) || ( exitcode=$? && /bin/cp /home/and\ > rew/builder/dev/hotspot/libjsig/objs/jsig.o.log /home/andrew/builder/dev/make-support/failure-logs/hotspot_libjsig_objs_jsig.o\ > .log && exit $exitcode ) ) && wait ) > cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ but not for C > > So just ADLC is fixed now. > > The root webrev is the same as before. Oops, glad you caught that. Looks even better. From philip.race at oracle.com Thu Jul 7 19:34:02 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 07 Jul 2016 12:34:02 -0700 Subject: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt In-Reply-To: <320e423b-9183-16fb-ad8a-9b1e668729d2@oracle.com> References: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default> <58fd8ac4-4520-4776-8229-a7c510eba6d6@default> <577C1928.4020803@oracle.com> <3b60b430-2bbb-47f6-b37e-ec9d47fa150c@default> <320e423b-9183-16fb-ad8a-9b1e668729d2@oracle.com> Message-ID: <577EAEAA.309@oracle.com> On 07/07/2016 10:25 AM, Semyon Sadetsky wrote: > On 7/7/2016 7:48 PM, Ajit Ghaisas wrote: > >> Thanks Phil for the review. >> Please find my answers below. >> >> Semyon, can you please comment on Phil's question below? > I agree with this change. The check is not needed. Ok. so the fix overall seems fine in that case although regarding >but it is out of purview of this fix as it may introduce behavioral change. I do not entirely buy it is out of purview I won't push any further on it for now but won't be surprised if someone else reports an unused variable warning. -phil. > > --Semyon >> >> Regards, >> Ajit >> >> -----Original Message----- >> From: Phil Race >> Sent: Wednesday, July 06, 2016 2:02 AM >> To: Ajit Ghaisas >> Cc: Sergey Bylokhov; Erik Joelsson; 2d-dev; awt-dev at openjdk.java.net; >> build-dev at openjdk.java.net >> Subject: Re: [9] Fix for JDK-8074824: Resolve disabled warnings for >> libawt_xawt >> >> It is not always clear to me what warning is being suppressed and why >> you have chosen a particular solution/action >> >> >> this next one looks like it might introduce an unused variable warning. >> What was it solving ? That the code was not checking a return value ? >> >> size_t bytesWritten = write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> //bytesWritten is unused >> >> Isn't the compiler's point here that you *should* be doing something >> with the result? >> Not just ignoring it differently ... >> >> ---------------------------------------------- >> [Ajit] : there was a warning of type 'unused-result' for write() >> method. Now, I have just assigned that to a variable which fixes the >> warning. >> I think, we should have some code to do error check on bytesWritten >> and return it - but it is out of purview of this fix as it may >> introduce behavioral change. >> ---------------------------------------------- >> >> ----- >> >> and this one ? I want Semyon to comment on what this code is trying >> to do in its original form since it was added for GTK3. >> >> @@ -1989,11 +2029,7 @@ >> static guint8 recode_color(gdouble channel) >> { >> guint16 result = (guint16)(channel * 65535); >> - if (result < 0) { >> - result = 0; >> - } else if (result > 65535) { >> - result = 65535; >> - } >> + >> return (guint8)( result >> 8); >> } >> >> ----------------------------------------------------- >> [Ajit] : there was a warning about guint16 will not be less than 0 >> and larger than 65535. Hence I have removed code checking this range. >> ----------------------------------------------------- >> >> ----- >> >> >> -phil. >> >> On 06/23/2016 12:09 AM, Ajit Ghaisas wrote: >>> Hi, >>> >>> Bug : >>> https://bugs.openjdk.java.net/browse/JDK-8074824 >>> (Resolve disabled warnings for libawt_xawt) >>> >>> As part of fixing this bug, I have - >>> >>> 1. Fixed warnings in source code after removing blanket >>> warning suppressions from makefile. >>> >>> 2. In case the warning fix is not possible, converted blanket >>> warning suppression for this library to suppression of warnings for >>> individual files. >>> >>> 3. Added comments in makefile for the warning suppression that >>> cannot be fixed. >>> >>> One type of gcc warning 'deprecated-declarations' will be fixed >>> separately (as part of JDK-8160146) >>> >>> >>> I have built the changes successfully on all supported platforms. >>> >>> >>> Webrev : >>> http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/ >>> >>> Request you to review. >>> >>> Regards, >>> Ajit > From gnu.andrew at redhat.com Thu Jul 7 20:21:02 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Jul 2016 16:21:02 -0400 (EDT) Subject: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6 In-Reply-To: <690318825.2951922.1467919292598.JavaMail.zimbra@redhat.com> Message-ID: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8151841 This is a backport of the original fix to support building OpenJDK with GCC 6. It was necessary to cherry-pick parts of a number of earlier fixes to make this work with the build system in 8: 8149647: Incremental enhancements from build-infra 8032045: Enable compiler and linker safety switches for debug builds and so I'm requesting a review of the 8 version of the patch here as well as approval for 8u. In brief, the patch makes OpenJDK build with GCC 6 by explicitly specifying the C++ standard to use (-std=gnu++98) and disabling two optimisations with -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further information on the changes is available in the GCC 6 release notes [0]. GCC 6 uses a newer C++ standard, C++14, with which the OpenJDK codebase is not yet compliant. The simplest way to fix this, especially for existing releases, is to explicitly request the previous default, gnu++98. The deletion of null pointer checks and more aggressive lifetime dead store elimination in 6 lead to a crashing virtual machine being built, so we disable them if GCC >= 6 is used. To make the original patch work with 8u, a number of changes from other fixes had to also be brought over: * We need to check we are using GCC 6 or above, so we need to bring over the TOOLCHAIN_CHECK_COMPILER_VERSION and TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647. TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional numbered rather than named argument macro so we don't need to backport BASIC_DEFUN_NAMED. * We bring over the introduction of COMMON_CCXXFLAGS_JDK from 8030245 as we need to apply the -std option only to the C++ compiler, not the C compiler. If passed to the C compiler, it will produce a warning, and this is converted to an error at one point in the build (a -Werror in libsctp). Generally, we've kept things in toolchain.m4 (8034788 introduced flags.m4, separating out some code, and so many of these changes are in that file in 9) and avoid named argument macros. Otherwise, it's largely the same as the 9 version. We have adopted the longer name for the -fno-delete-null-pointer-checks flag variable as suggested in the review of the update to this patch for the new HotSpot build [1]. [0] https://gcc.gnu.org/gcc-6/porting_to.html [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Jul 7 20:42:30 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Jul 2016 16:42:30 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> Message-ID: <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > On Jul 7, 2016, at 1:48 PM, Andrew Hughes wrote: > >>> Revised webrevs: > >>> > >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root > >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot > >> > >> These look good to me. > >> > > > > Minor revision: > > > > http://cr.openjdk.java.net/~andrew/8156980/webrev.05/root > > http://cr.openjdk.java.net/~andrew/8156980/webrev.05/hotspot > > > > I spotted that jsig is just a single C file and so doesn't > > need the -std flag. In fact, it complains about it: > > > > Compiling jsig.c (for libjsig.so) > > ( ( /usr/bin/gcc -fPIC -D_GNU_SOURCE -D_REENTRANT -O2 -pipe -march=core2 > > -std=gnu++98 -m64 -g -DTHIS_FILE='"jsig.c"' -c -MMD -\ > > MF /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.d -o > > /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o /home/andrew/p\ > > rojects/openjdk/upstream/dev/hotspot/src/os/linux/vm/jsig.c > > > >(/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsi\ > > g.o.log) 2> >(/usr/bin/tee > > /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o.log >&2) || ( > > exitcode=$? && /bin/cp /home/and\ > > rew/builder/dev/hotspot/libjsig/objs/jsig.o.log > > /home/andrew/builder/dev/make-support/failure-logs/hotspot_libjsig_objs_jsig.o\ > > .log && exit $exitcode ) ) && wait ) > > cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ > > but not for C > > > > So just ADLC is fixed now. > > > > The root webrev is the same as before. > > Oops, glad you caught that. > > Looks even better. > > The same warning was causing an error in the OpenJDK 8 backport of the original GCC 6 patch, so I double-checked the logs for 9 and spotted this :-) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From erik.joelsson at oracle.com Fri Jul 8 06:38:31 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Jul 2016 08:38:31 +0200 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> Message-ID: <577F4A67.7000801@oracle.com> Hello, This looks good except for the change in toolchain.m4, which looks like it might actually break cross compilation by overriding the value for compiler version for the build compiler using the target compiler. With this change we basically have: if cross compilation TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) else ... fi TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) The problem you are trying to solve is that in the case of not cross compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call in the else clause. I would instead suggest the following: if cross compilation ... else ... fi TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) Just move it out of the conditional blocks and always call it the same way. /Erik ( - on vacation and only sporadically checking email) On 2016-07-07 22:42, Andrew Hughes wrote: > > ----- Original Message ----- >>> On Jul 7, 2016, at 1:48 PM, Andrew Hughes wrote: >>>>> Revised webrevs: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root >>>>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot >>>> These look good to me. >>>> >>> Minor revision: >>> >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.05/root >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.05/hotspot >>> >>> I spotted that jsig is just a single C file and so doesn't >>> need the -std flag. In fact, it complains about it: >>> >>> Compiling jsig.c (for libjsig.so) >>> ( ( /usr/bin/gcc -fPIC -D_GNU_SOURCE -D_REENTRANT -O2 -pipe -march=core2 >>> -std=gnu++98 -m64 -g -DTHIS_FILE='"jsig.c"' -c -MMD -\ >>> MF /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.d -o >>> /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o /home/andrew/p\ >>> rojects/openjdk/upstream/dev/hotspot/src/os/linux/vm/jsig.c > >>>> (/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsi\ >>> g.o.log) 2> >(/usr/bin/tee >>> /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o.log >&2) || ( >>> exitcode=$? && /bin/cp /home/and\ >>> rew/builder/dev/hotspot/libjsig/objs/jsig.o.log >>> /home/andrew/builder/dev/make-support/failure-logs/hotspot_libjsig_objs_jsig.o\ >>> .log && exit $exitcode ) ) && wait ) >>> cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ >>> but not for C >>> >>> So just ADLC is fixed now. >>> >>> The root webrev is the same as before. >> Oops, glad you caught that. >> >> Looks even better. >> >> > The same warning was causing an error in the OpenJDK 8 backport of the original > GCC 6 patch, so I double-checked the logs for 9 and spotted this :-) From erik.joelsson at oracle.com Fri Jul 8 06:46:48 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Jul 2016 08:46:48 +0200 Subject: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6 In-Reply-To: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> Message-ID: <577F4C58.6060101@oracle.com> Hello, It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always returning yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C and C++ checks. /Erik On 2016-07-07 22:21, Andrew Hughes wrote: > Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8151841 > > This is a backport of the original fix to support building OpenJDK > with GCC 6. It was necessary to cherry-pick parts of a number of > earlier fixes to make this work with the build system in 8: > > 8149647: Incremental enhancements from build-infra > 8032045: Enable compiler and linker safety switches for debug builds > > and so I'm requesting a review of the 8 version of the patch here as well > as approval for 8u. > > In brief, the patch makes OpenJDK build with GCC 6 by explicitly specifying > the C++ standard to use (-std=gnu++98) and disabling two optimisations with > -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further information > on the changes is available in the GCC 6 release notes [0]. GCC 6 uses > a newer C++ standard, C++14, with which the OpenJDK codebase is not yet > compliant. The simplest way to fix this, especially for existing releases, > is to explicitly request the previous default, gnu++98. The deletion > of null pointer checks and more aggressive lifetime dead store elimination > in 6 lead to a crashing virtual machine being built, so we disable them > if GCC >= 6 is used. > > To make the original patch work with 8u, a number of changes from other > fixes had to also be brought over: > > * We need to check we are using GCC 6 or above, so we need to bring > over the TOOLCHAIN_CHECK_COMPILER_VERSION and > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647. > TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional > numbered rather than named argument macro so we don't need to backport > BASIC_DEFUN_NAMED. > * We bring over the introduction of COMMON_CCXXFLAGS_JDK from 8030245 > as we need to apply the -std option only to the C++ compiler, not the > C compiler. If passed to the C compiler, it will produce a warning, > and this is converted to an error at one point in the build > (a -Werror in libsctp). > > Generally, we've kept things in toolchain.m4 (8034788 introduced flags.m4, > separating out some code, and so many of these changes are in that file > in 9) and avoid named argument macros. Otherwise, it's largely the > same as the 9 version. We have adopted the longer name for > the -fno-delete-null-pointer-checks flag variable as suggested in the > review of the update to this patch for the new HotSpot build [1]. > > [0] https://gcc.gnu.org/gcc-6/porting_to.html > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html From kim.barrett at oracle.com Fri Jul 8 19:18:01 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 8 Jul 2016 15:18:01 -0400 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <577F4A67.7000801@oracle.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> <577F4A67.7000801@oracle.com> Message-ID: <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> > On Jul 8, 2016, at 2:38 AM, Erik Joelsson wrote: > > Hello, > > This looks good except for the change in toolchain.m4, which looks like it might actually break cross compilation by overriding the value for compiler version for the build compiler using the target compiler. With this change we basically have: > > if cross compilation > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) > else > ... > fi > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) > > The problem you are trying to solve is that in the case of not cross compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call in the else clause. Good catch! I totally missed that when reviewing. From gnu.andrew at redhat.com Sun Jul 10 21:05:15 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sun, 10 Jul 2016 17:05:15 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> <577F4A67.7000801@oracle.com> <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> Message-ID: <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > On Jul 8, 2016, at 2:38 AM, Erik Joelsson wrote: > > > > Hello, > > > > This looks good except for the change in toolchain.m4, which looks like it > > might actually break cross compilation by overriding the value for > > compiler version for the build compiler using the target compiler. With > > this change we basically have: > > > > if cross compilation > > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) > > else > > ... > > fi > > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) > > > > The problem you are trying to solve is that in the case of not cross > > compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't > > called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call in > > the else clause. > > Good catch! I totally missed that when reviewing. > > Yes, good catch! The indenting on the bug report must have confused me. Fixed version: http://cr.openjdk.java.net/~andrew/8156980/webrev.06/root/ http://cr.openjdk.java.net/~andrew/8156980/webrev.06/hotspot HotSpot webrev is unchanged. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Jul 11 04:56:49 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 Jul 2016 00:56:49 -0400 (EDT) Subject: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6 In-Reply-To: <577F4C58.6060101@oracle.com> References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> <577F4C58.6060101@oracle.com> Message-ID: <1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always returning > yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C and > C++ checks. > Ugh, merged a block in the wrong place by the looks of it. Fixed in http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.02/ configure:29739: checking if the C++ compiler supports "-std=gnu++98 " configure:29755: /usr/bin/g++ -c -std=gnu++98 conftest.cpp >&5 configure:29755: $? = 0 configure:29769: result: yes configure:29815: checking if the C compiler supports "-fno-delete-null-pointer-checks -Werror" configure:29832: /usr/bin/gcc -c -fno-delete-null-pointer-checks -Werror conftest.c >&5 configure:29832: $? = 0 configure:29846: result: yes configure:29855: checking if the C++ compiler supports "-fno-delete-null-pointer-checks -Werror" configure:29871: /usr/bin/g++ -c -fno-delete-null-pointer-checks -Werror conftest.cpp >&5 configure:29871: $? = 0 configure:29885: result: yes configure:29894: checking if both compilers support "-fno-delete-null-pointer-checks -Werror" configure:29899: result: yes configure:29911: checking if the C compiler supports "-fno-lifetime-dse -Werror" configure:29927: /usr/bin/gcc -c -fno-lifetime-dse -Werror conftest.c >&5 configure:29927: $? = 0 configure:29941: result: yes configure:29950: checking if the C++ compiler supports "-fno-lifetime-dse -Werror" configure:29966: /usr/bin/g++ -c -fno-lifetime-dse -Werror conftest.cpp >&5 configure:29966: $? = 0 configure:29980: result: yes configure:29989: checking if both compilers support "-fno-lifetime-dse -Werror" configure:29994: result: yes > /Erik > > On 2016-07-07 22:21, Andrew Hughes wrote: > > Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151841 > > > > This is a backport of the original fix to support building OpenJDK > > with GCC 6. It was necessary to cherry-pick parts of a number of > > earlier fixes to make this work with the build system in 8: > > > > 8149647: Incremental enhancements from build-infra > > 8032045: Enable compiler and linker safety switches for debug builds > > > > and so I'm requesting a review of the 8 version of the patch here as well > > as approval for 8u. > > > > In brief, the patch makes OpenJDK build with GCC 6 by explicitly specifying > > the C++ standard to use (-std=gnu++98) and disabling two optimisations with > > -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further information > > on the changes is available in the GCC 6 release notes [0]. GCC 6 uses > > a newer C++ standard, C++14, with which the OpenJDK codebase is not yet > > compliant. The simplest way to fix this, especially for existing releases, > > is to explicitly request the previous default, gnu++98. The deletion > > of null pointer checks and more aggressive lifetime dead store elimination > > in 6 lead to a crashing virtual machine being built, so we disable them > > if GCC >= 6 is used. > > > > To make the original patch work with 8u, a number of changes from other > > fixes had to also be brought over: > > > > * We need to check we are using GCC 6 or above, so we need to bring > > over the TOOLCHAIN_CHECK_COMPILER_VERSION and > > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647. > > TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional > > numbered rather than named argument macro so we don't need to backport > > BASIC_DEFUN_NAMED. > > * We bring over the introduction of COMMON_CCXXFLAGS_JDK from 8030245 > > as we need to apply the -std option only to the C++ compiler, not the > > C compiler. If passed to the C compiler, it will produce a warning, > > and this is converted to an error at one point in the build > > (a -Werror in libsctp). > > > > Generally, we've kept things in toolchain.m4 (8034788 introduced flags.m4, > > separating out some code, and so many of these changes are in that file > > in 9) and avoid named argument macros. Otherwise, it's largely the > > same as the 9 version. We have adopted the longer name for > > the -fno-delete-null-pointer-checks flag variable as suggested in the > > review of the update to this patch for the new HotSpot build [1]. > > > > [0] https://gcc.gnu.org/gcc-6/porting_to.html > > [1] > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From jwhiting at redhat.com Mon Jul 11 08:10:40 2016 From: jwhiting at redhat.com (Jeremy Whiting) Date: Mon, 11 Jul 2016 09:10:40 +0100 Subject: Enable hotspot builds for 4.x Linux kernels. Message-ID: <5842dfd9-7e32-9235-109d-e82c742d7d53@redhat.com> Hi, Last week I started the process to build jdk8 using a Fedora 23 environment. Followed the detailed instructions but came across an issue. Looking at the bugs database identical issues have been raised for various components [1] and jdk versions. It appears the backport missed it into the hotspot repo for jdk8. Browsing the hotspot repo shows [2] the supported os version doesn't include a 4.x Linux kernel. Can this fix be backported to the jdk8 hotspot repo as well ? $ hg diff diff -r 87ee5ee27509 make/linux/Makefile --- a/make/linux/Makefile Tue Mar 04 11:51:03 2014 -0800 +++ b/make/linux/Makefile Mon Jul 11 08:59:44 2016 +0100 @@ -225,7 +225,7 @@ # Solaris 2.5.1, 2.6). # Disable this check by setting DISABLE_HOTSPOT_OS_VERSION_CHECK=ok. -SUPPORTED_OS_VERSION = 2.4% 2.5% 2.6% 3% +SUPPORTED_OS_VERSION = 2.4% 2.5% 2.6% 3% 4% OS_VERSION := $(shell uname -r) EMPTY_IF_NOT_SUPPORTED = $(filter $(SUPPORTED_OS_VERSION),$(OS_VERSION)) $ Regards, Jeremy $ uname -a Linux burtha-f23 4.5.7-200.fc23.x86_64 #1 SMP Wed Jun 8 17:41:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [1] https://bugs.openjdk.java.net/browse/JDK-8087178?jql=text%20~%20%22Enable%20hotspot%20builds%20on%204.x%20Linux%20kernels%22 [2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/make/linux/Makefile#l228 -- Jeremy Whiting Senior Software Engineer, JBoss Performance Team Red Hat ------------------------------------------------------------ Registered Address: RED HAT UK LIMITED, Peninsular House, 30-36 Monument Street, 4th floor, London. EC3R 8NB United Kingdom Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael ("Mike") O'Neill (Ireland) and Eric Shander (US) From omajid at redhat.com Mon Jul 11 18:48:49 2016 From: omajid at redhat.com (Omair Majid) Date: Mon, 11 Jul 2016 14:48:49 -0400 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1801967885.2914575.1467906786428.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1152110990.2358404.1467732145429.JavaMail.zimbra@redhat.com> <1886892793.2381024.1467740039374.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1356840573.2734504.1467863468986.JavaMail.zimbra@redhat.com> <1801967885.2914575.1467906786428.JavaMail.zimbra@redhat.com> Message-ID: <20160711184848.GB1485@redhat.com> * Andrew Hughes [2016-07-07 11:53]: > Sadly, I celebrated too soon; it seems that change just delayed the failure > until much later in the build. > > I've found the problem though. In src/share/vm/utilities/globalDefinitions.hpp, > we have: > > #ifdef max > #undef max > #endif > > #ifdef min > #undef min > #endif > > #define max(a,b) Do_not_use_max_use_MAX2_instead > #define min(a,b) Do_not_use_min_use_MIN2_instead > > The problem is that max and min are now longer macros in the GCC 6 C++ library. > So they can't be undefined. > > The build succeeds if I disable (#if 0) the definition of max and min. So > we need to consider either removing them or _GLIBCXX_INCLUDE_NEXT_C_HEADERS > needs to be defined to get the old behaviour. I prefer the former. I ran into this too and I posted a separate patch to work around this issue that just involves changing the ordering of the includes: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023910.html Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From kim.barrett at oracle.com Mon Jul 11 21:31:07 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 11 Jul 2016 17:31:07 -0400 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> <577F4A67.7000801@oracle.com> <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> Message-ID: <6311F66F-390D-491A-9D30-92CDF9316DD4@oracle.com> > On Jul 10, 2016, at 5:05 PM, Andrew Hughes wrote: > > > > ----- Original Message ----- >>> On Jul 8, 2016, at 2:38 AM, Erik Joelsson wrote: >>> >>> Hello, >>> >>> This looks good except for the change in toolchain.m4, which looks like it >>> might actually break cross compilation by overriding the value for >>> compiler version for the build compiler using the target compiler. With >>> this change we basically have: >>> >>> if cross compilation >>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) >>> else >>> ... >>> fi >>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) >>> >>> The problem you are trying to solve is that in the case of not cross >>> compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't >>> called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call in >>> the else clause. >> >> Good catch! I totally missed that when reviewing. >> >> > Yes, good catch! The indenting on the bug report must have confused me. > > Fixed version: > > http://cr.openjdk.java.net/~andrew/8156980/webrev.06/root/ > http://cr.openjdk.java.net/~andrew/8156980/webrev.06/hotspot > > HotSpot webrev is unchanged. Looks good. From david.holmes at oracle.com Tue Jul 12 01:25:17 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2016 11:25:17 +1000 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1625613218.2454039.1467782583560.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> <577F4A67.7000801@oracle.com> <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> Message-ID: Catching up ... On 11/07/2016 7:05 AM, Andrew Hughes wrote: > > > ----- Original Message ----- >>> On Jul 8, 2016, at 2:38 AM, Erik Joelsson wrote: >>> >>> Hello, >>> >>> This looks good except for the change in toolchain.m4, which looks like it >>> might actually break cross compilation by overriding the value for >>> compiler version for the build compiler using the target compiler. With >>> this change we basically have: >>> >>> if cross compilation >>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) >>> else >>> ... >>> fi >>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) >>> >>> The problem you are trying to solve is that in the case of not cross >>> compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't >>> called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call in >>> the else clause. >> >> Good catch! I totally missed that when reviewing. >> >> > Yes, good catch! The indenting on the bug report must have confused me. > > Fixed version: > > http://cr.openjdk.java.net/~andrew/8156980/webrev.06/root/ > http://cr.openjdk.java.net/~andrew/8156980/webrev.06/hotspot I was glad to see you realized that parts of the hotspot build (libjsig, libdtrace) only deal with C programs not C++ and so don't want and should not have a C++ setting passed. But that then begs the question in the main build in flags.m4 why we have: $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" which again adds a C++ related flags to what should be the C compilation flags ?? Thanks, David ----- > HotSpot webrev is unchanged. > > Thanks, > From david.holmes at oracle.com Tue Jul 12 01:46:48 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2016 11:46:48 +1000 Subject: Enable hotspot builds for 4.x Linux kernels. In-Reply-To: <5842dfd9-7e32-9235-109d-e82c742d7d53@redhat.com> References: <5842dfd9-7e32-9235-109d-e82c742d7d53@redhat.com> Message-ID: <43118c1a-e4ad-ee23-246e-a2adef6acd17@oracle.com> Hi Jeremy, On 11/07/2016 6:10 PM, Jeremy Whiting wrote: > Hi, > > Last week I started the process to build jdk8 using a Fedora 23 > environment. Followed the detailed instructions but came across an > issue. Looking at the bugs database identical issues have been raised > for various components [1] and jdk versions. It appears the backport > missed it into the hotspot repo for jdk8. Browsing the hotspot repo > shows [2] the supported os version doesn't include a 4.x Linux kernel. > > Can this fix be backported to the jdk8 hotspot repo as well ? Sure. See: http://openjdk.java.net/projects/jdk8u/approval-template.html and http://openjdk.java.net/projects/jdk8u/groundrules.html Any 8u committer can do this. Cheers, David > > $ hg diff > diff -r 87ee5ee27509 make/linux/Makefile > --- a/make/linux/Makefile Tue Mar 04 11:51:03 2014 -0800 > +++ b/make/linux/Makefile Mon Jul 11 08:59:44 2016 +0100 > @@ -225,7 +225,7 @@ > # Solaris 2.5.1, 2.6). > # Disable this check by setting DISABLE_HOTSPOT_OS_VERSION_CHECK=ok. > > -SUPPORTED_OS_VERSION = 2.4% 2.5% 2.6% 3% > +SUPPORTED_OS_VERSION = 2.4% 2.5% 2.6% 3% 4% > OS_VERSION := $(shell uname -r) > EMPTY_IF_NOT_SUPPORTED = $(filter $(SUPPORTED_OS_VERSION),$(OS_VERSION)) > > $ > > > Regards, > > Jeremy > > > $ uname -a > Linux burtha-f23 4.5.7-200.fc23.x86_64 #1 SMP Wed Jun 8 17:41:50 UTC > 2016 x86_64 x86_64 x86_64 GNU/Linux > > [1] > https://bugs.openjdk.java.net/browse/JDK-8087178?jql=text%20~%20%22Enable%20hotspot%20builds%20on%204.x%20Linux%20kernels%22 > > > [2] > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/make/linux/Makefile#l228 > > > > From gnu.andrew at redhat.com Tue Jul 12 03:40:01 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 Jul 2016 23:40:01 -0400 (EDT) Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> <577F4A67.7000801@oracle.com> <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> Message-ID: <1630509666.3999193.1468294801972.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Catching up ... > > On 11/07/2016 7:05 AM, Andrew Hughes wrote: > > > > > > ----- Original Message ----- > >>> On Jul 8, 2016, at 2:38 AM, Erik Joelsson > >>> wrote: > >>> > >>> Hello, > >>> > >>> This looks good except for the change in toolchain.m4, which looks like > >>> it > >>> might actually break cross compilation by overriding the value for > >>> compiler version for the build compiler using the target compiler. With > >>> this change we basically have: > >>> > >>> if cross compilation > >>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) > >>> else > >>> ... > >>> fi > >>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) > >>> > >>> The problem you are trying to solve is that in the case of not cross > >>> compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't > >>> called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call > >>> in > >>> the else clause. > >> > >> Good catch! I totally missed that when reviewing. > >> > >> > > Yes, good catch! The indenting on the bug report must have confused me. > > > > Fixed version: > > > > http://cr.openjdk.java.net/~andrew/8156980/webrev.06/root/ > > http://cr.openjdk.java.net/~andrew/8156980/webrev.06/hotspot > > I was glad to see you realized that parts of the hotspot build (libjsig, > libdtrace) only deal with C programs not C++ and so don't want and > should not have a C++ setting passed. But that then begs the question in > the main build in flags.m4 why we have: > > $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" > > which again adds a C++ related flags to what should be the C compilation > flags ?? > You'd think so, but for some reason, the HotSpot build has always called the C++ compiler flags 'CFLAGS'. There is no JVM_CXXFLAGS. The same behaviour was true with the old build; we had to pass these options down to HotSpot in EXTRA_CFLAGS. JVM_CFLAGS is the main variable used in the HotSpot build (see make/lib/CompileJvm.gmk). The only C files in the HotSpot tree are for libsaproc, jsig and DTrace, all of which are handled by separate makefiles. The only one to use JVM_CFLAGS is make/lib/CompileDtracePostJvm.gmk, where it is used for a single C++ file, generateJvmOffsets.cpp: generateJvmOffsets.cpp_CXXFLAGS := $(JVM_CFLAGS) -mt -xnolib -norunpath, \ generateJvmOffsetsMain.c_CFLAGS := -library=%none -mt -m64 -norunpath -z nodefs, \ Thus, it seems JVM_CFLAGS is JVM_CXXFLAGS in all but name. If -std=gnu++98 does get passed to the C compiler, it produces a warning: cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ but not for C I don't see this at all for this patch on OpenJDK 9. It does appear in the backport to 8u [0], because the aforementioned C code in the old HotSpot build does use the same CFLAGS there. > Thanks, > David > ----- > > > HotSpot webrev is unchanged. > > > > Thanks, > > > [0] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-July/005690.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From david.holmes at oracle.com Tue Jul 12 04:41:47 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2016 14:41:47 +1000 Subject: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option In-Reply-To: <1630509666.3999193.1468294801972.JavaMail.zimbra@redhat.com> References: <1471596267.2168498.1467696441635.JavaMail.zimbra@redhat.com> <1207322568.2935478.1467913682936.JavaMail.zimbra@redhat.com> <86B97F50-E8FF-49A4-8ECC-E908530D6997@oracle.com> <408289857.2962109.1467924150748.JavaMail.zimbra@redhat.com> <577F4A67.7000801@oracle.com> <7B426F71-745C-4ABA-A01E-8C05262F641C@oracle.com> <1966824181.3476795.1468184715211.JavaMail.zimbra@redhat.com> <1630509666.3999193.1468294801972.JavaMail.zimbra@redhat.com> Message-ID: On 12/07/2016 1:40 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Catching up ... >> >> On 11/07/2016 7:05 AM, Andrew Hughes wrote: >>> >>> >>> ----- Original Message ----- >>>>> On Jul 8, 2016, at 2:38 AM, Erik Joelsson >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> This looks good except for the change in toolchain.m4, which looks like >>>>> it >>>>> might actually break cross compilation by overriding the value for >>>>> compiler version for the build compiler using the target compiler. With >>>>> this change we basically have: >>>>> >>>>> if cross compilation >>>>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_]) >>>>> else >>>>> ... >>>>> fi >>>>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_]) >>>>> >>>>> The problem you are trying to solve is that in the case of not cross >>>>> compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't >>>>> called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call >>>>> in >>>>> the else clause. >>>> >>>> Good catch! I totally missed that when reviewing. >>>> >>>> >>> Yes, good catch! The indenting on the bug report must have confused me. >>> >>> Fixed version: >>> >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.06/root/ >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.06/hotspot >> >> I was glad to see you realized that parts of the hotspot build (libjsig, >> libdtrace) only deal with C programs not C++ and so don't want and >> should not have a C++ setting passed. But that then begs the question in >> the main build in flags.m4 why we have: >> >> $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}" >> >> which again adds a C++ related flags to what should be the C compilation >> flags ?? >> > > You'd think so, but for some reason, the HotSpot build has always called the > C++ compiler flags 'CFLAGS'. There is no JVM_CXXFLAGS. Ah now I recall - this is the CPP -> CXX mess. CFLAGS meant compiler-flags; CPPFLAGS meant pre-processor-flags. People thought CPP meant C++ and changed to CXX. > The same behaviour was true with the old build; we had to pass these options > down to HotSpot in EXTRA_CFLAGS. > > JVM_CFLAGS is the main variable used in the HotSpot build (see make/lib/CompileJvm.gmk). > The only C files in the HotSpot tree are for libsaproc, jsig and DTrace, > all of which are handled by separate makefiles. The only one to use JVM_CFLAGS is > make/lib/CompileDtracePostJvm.gmk, where it is used for a single C++ file, generateJvmOffsets.cpp: > > generateJvmOffsets.cpp_CXXFLAGS := $(JVM_CFLAGS) -mt -xnolib -norunpath, \ > generateJvmOffsetsMain.c_CFLAGS := -library=%none -mt -m64 -norunpath -z nodefs, \ > > Thus, it seems JVM_CFLAGS is JVM_CXXFLAGS in all but name. Thanks for stepping through that. David > If -std=gnu++98 does get passed to the C compiler, it produces a warning: > > cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ but not for C > > I don't see this at all for this patch on OpenJDK 9. It does appear in the backport > to 8u [0], because the aforementioned C code in the old HotSpot build does use the > same CFLAGS there. > >> Thanks, >> David >> ----- >> >>> HotSpot webrev is unchanged. >>> >>> Thanks, >>> >> > > [0] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-July/005690.html > From bhavesh.x.patel at oracle.com Wed Jul 13 21:02:44 2016 From: bhavesh.x.patel at oracle.com (Bhavesh Patel) Date: Wed, 13 Jul 2016 14:02:44 -0700 Subject: RFR: 8161255, jdk build "all" (docs) fails on all platforms, error from DefaultLoggerFinder.java Message-ID: <5786AC74.8060805@oracle.com> Hi, This is the fix for the issue in which the JDK API documentation build fails due to comment in DefaultLoggerFinder.java that points to a type in an unexported (internal) API. Doclint reports this is an error during the reference check and the documentation build fails. The makefile for javadoc needs to be updated to disable the reference check in the jdk.internal.logger package. JBS: https://bugs.openjdk.java.net/browse/JDK-8161255 Webrev: http://cr.openjdk.java.net/~bpatel/8161255/webrev/ Please review this change. Thanks, Bhavesh. From joe.darcy at oracle.com Wed Jul 13 21:05:08 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 13 Jul 2016 14:05:08 -0700 Subject: RFR: 8161255, jdk build "all" (docs) fails on all platforms, error from DefaultLoggerFinder.java In-Reply-To: <5786AC74.8060805@oracle.com> References: <5786AC74.8060805@oracle.com> Message-ID: Hi Bhavesh, This looks fine to get the build going again; please push this right away. As we discussed off-list, there will probably need to be some additional javadoc mechanisms so that checking for this kind of implementation detail doesn't run afoul of doclint unnecessarily. Thanks, -Joe On 7/13/2016 2:02 PM, Bhavesh Patel wrote: > Hi, > This is the fix for the issue in which the JDK API documentation > build fails due to comment in DefaultLoggerFinder.java that points to > a type in an unexported (internal) API. Doclint reports this is an > error during the reference check and the documentation build fails. > The makefile for javadoc needs to be updated to disable the reference > check in the jdk.internal.logger package. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8161255 > Webrev: http://cr.openjdk.java.net/~bpatel/8161255/webrev/ > > Please review this change. > > Thanks, > Bhavesh. From kumar.x.srinivasan at oracle.com Wed Jul 13 21:05:05 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 13 Jul 2016 14:05:05 -0700 Subject: RFR: 8161255, jdk build "all" (docs) fails on all platforms, error from DefaultLoggerFinder.java In-Reply-To: References: <5786AC74.8060805@oracle.com> Message-ID: <5786AD01.8080005@oracle.com> +1, I have also tested on Windows. Kumar On 7/13/2016 2:05 PM, joe darcy wrote: > Hi Bhavesh, > > This looks fine to get the build going again; please push this right > away. > > As we discussed off-list, there will probably need to be some > additional javadoc mechanisms so that checking for this kind of > implementation detail doesn't run afoul of doclint unnecessarily. > > Thanks, > > -Joe > > > On 7/13/2016 2:02 PM, Bhavesh Patel wrote: >> Hi, >> This is the fix for the issue in which the JDK API documentation >> build fails due to comment in DefaultLoggerFinder.java that points to >> a type in an unexported (internal) API. Doclint reports this is an >> error during the reference check and the documentation build fails. >> The makefile for javadoc needs to be updated to disable the reference >> check in the jdk.internal.logger package. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8161255 >> Webrev: http://cr.openjdk.java.net/~bpatel/8161255/webrev/ >> >> Please review this change. >> >> Thanks, >> Bhavesh. > From tim.bell at oracle.com Wed Jul 13 21:28:56 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 13 Jul 2016 14:28:56 -0700 Subject: RFR: 8161255, jdk build "all" (docs) fails on all platforms, error from DefaultLoggerFinder.java In-Reply-To: <5786AC74.8060805@oracle.com> References: <5786AC74.8060805@oracle.com> Message-ID: <5786B298.4030208@oracle.com> Hi Bhavesh: > This is the fix for the issue in which the JDK API documentation > build fails due to comment in DefaultLoggerFinder.java that points to > a type in an unexported (internal) API. Doclint reports this is an > error during the reference check and the documentation build fails. > The makefile for javadoc needs to be updated to disable the reference > check in the jdk.internal.logger package. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8161255 > Webrev: http://cr.openjdk.java.net/~bpatel/8161255/webrev/ > > Please review this change. Looks good. Approved. Tim From jonathan.gibbons at oracle.com Wed Jul 13 21:42:43 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 13 Jul 2016 14:42:43 -0700 Subject: RFR: 8161255, jdk build "all" (docs) fails on all platforms, error from DefaultLoggerFinder.java In-Reply-To: References: <5786AC74.8060805@oracle.com> Message-ID: <5786B5D3.4010309@oracle.com> Joe, all, Work for javadoc support for modules is a work in progress. While we should have caught yesterday's problems ahead of time, it will also be the case that as javadoc moves along, we will refine the contents of the module summary page, so that items which should not be documented are correctly omitted. -- Jon On 07/13/2016 02:05 PM, joe darcy wrote: > Hi Bhavesh, > > This looks fine to get the build going again; please push this right > away. > > As we discussed off-list, there will probably need to be some > additional javadoc mechanisms so that checking for this kind of > implementation detail doesn't run afoul of doclint unnecessarily. > > Thanks, > > -Joe > > > On 7/13/2016 2:02 PM, Bhavesh Patel wrote: >> Hi, >> This is the fix for the issue in which the JDK API documentation >> build fails due to comment in DefaultLoggerFinder.java that points to >> a type in an unexported (internal) API. Doclint reports this is an >> error during the reference check and the documentation build fails. >> The makefile for javadoc needs to be updated to disable the reference >> check in the jdk.internal.logger package. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8161255 >> Webrev: http://cr.openjdk.java.net/~bpatel/8161255/webrev/ >> >> Please review this change. >> >> Thanks, >> Bhavesh. > From sean.mullan at oracle.com Fri Jul 15 11:51:49 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 15 Jul 2016 07:51:49 -0400 Subject: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option In-Reply-To: <5787F099.2020606@oracle.com> References: <5787F099.2020606@oracle.com> Message-ID: <5788CE55.60606@oracle.com> Adding build-dev for review since there is one change to a Makefile in the webrev below. Thanks, Sean On 07/14/2016 04:05 PM, Sean Mullan wrote: > Please review this change to the default Policy provider implementation > to grant de-privileged module permissions by default even when the > java.security.policy override option is specified or when the > Policy.getInstance API is used: > > http://cr.openjdk.java.net/~mullan/webrevs/8159752/webrev.00/ > > A new system-wide policy file located in > ${java.home}/lib/security/default.policy has been created. It contains > grant statements containing the permissions that need to be granted to > de-privileged modules. These grant statements were previously located in > the ${java.home}/conf/security/java.policy file and have been relocated > to the default.policy file. > > The default.policy file is now always loaded by the default Policy > provider implementation (sun/security/provider/PolicyFile). It is loaded > if the java.security.policy '=' or '==' option is specified, and also if > the application uses the Policy.getInstance methods and specifies the > "JavaPolicy" type. If the default.policy file cannot be loaded, an > InternalError is thrown, on the basis that the runtime cannot operate > correctly unless these permissions are granted. > > The rationale for making this change is that the runtime should be > responsible for granting the permissions it needs to operate correctly. > We should not expect users to have to determine or copy and paste these > permissions into their own policy files. > > Thanks, > Sean From tim.bell at oracle.com Fri Jul 15 14:14:53 2016 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 15 Jul 2016 07:14:53 -0700 Subject: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option In-Reply-To: <5788CE55.60606@oracle.com> References: <5787F099.2020606@oracle.com> <5788CE55.60606@oracle.com> Message-ID: <5788EFDD.2050109@oracle.com> The Makefile changes look fine. Tim On 07/15/16 04:51, Sean Mullan wrote: > Adding build-dev for review since there is one change to a Makefile in > the webrev below. > > Thanks, > Sean > > On 07/14/2016 04:05 PM, Sean Mullan wrote: >> Please review this change to the default Policy provider implementation >> to grant de-privileged module permissions by default even when the >> java.security.policy override option is specified or when the >> Policy.getInstance API is used: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8159752/webrev.00/ >> >> A new system-wide policy file located in >> ${java.home}/lib/security/default.policy has been created. It contains >> grant statements containing the permissions that need to be granted to >> de-privileged modules. These grant statements were previously located in >> the ${java.home}/conf/security/java.policy file and have been relocated >> to the default.policy file. >> >> The default.policy file is now always loaded by the default Policy >> provider implementation (sun/security/provider/PolicyFile). It is loaded >> if the java.security.policy '=' or '==' option is specified, and also if >> the application uses the Policy.getInstance methods and specifies the >> "JavaPolicy" type. If the default.policy file cannot be loaded, an >> InternalError is thrown, on the basis that the runtime cannot operate >> correctly unless these permissions are granted. >> >> The rationale for making this change is that the runtime should be >> responsible for granting the permissions it needs to operate correctly. >> We should not expect users to have to determine or copy and paste these >> permissions into their own policy files. >> >> Thanks, >> Sean From gnu.andrew at redhat.com Fri Jul 15 15:22:10 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 15 Jul 2016 11:22:10 -0400 (EDT) Subject: PING: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6 In-Reply-To: <1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com> References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> <577F4C58.6060101@oracle.com> <1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com> Message-ID: <788404102.5570020.1468596130974.JavaMail.zimbra@redhat.com> Ping? ----- Original Message ----- > ----- Original Message ----- > > Hello, > > > > It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always returning > > yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C and > > C++ checks. > > > > Ugh, merged a block in the wrong place by the looks of it. > > Fixed in http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.02/ > > configure:29739: checking if the C++ compiler supports "-std=gnu++98 " > configure:29755: /usr/bin/g++ -c -std=gnu++98 conftest.cpp >&5 > configure:29755: $? = 0 > configure:29769: result: yes > configure:29815: checking if the C compiler supports > "-fno-delete-null-pointer-checks -Werror" > configure:29832: /usr/bin/gcc -c -fno-delete-null-pointer-checks -Werror > conftest.c >&5 > configure:29832: $? = 0 > configure:29846: result: yes > configure:29855: checking if the C++ compiler supports > "-fno-delete-null-pointer-checks -Werror" > configure:29871: /usr/bin/g++ -c -fno-delete-null-pointer-checks -Werror > conftest.cpp >&5 > configure:29871: $? = 0 > configure:29885: result: yes > configure:29894: checking if both compilers support > "-fno-delete-null-pointer-checks -Werror" > configure:29899: result: yes > configure:29911: checking if the C compiler supports "-fno-lifetime-dse > -Werror" > configure:29927: /usr/bin/gcc -c -fno-lifetime-dse -Werror conftest.c >&5 > configure:29927: $? = 0 > configure:29941: result: yes > configure:29950: checking if the C++ compiler supports "-fno-lifetime-dse > -Werror" > configure:29966: /usr/bin/g++ -c -fno-lifetime-dse -Werror conftest.cpp >&5 > configure:29966: $? = 0 > configure:29980: result: yes > configure:29989: checking if both compilers support "-fno-lifetime-dse > -Werror" > configure:29994: result: yes > > > > /Erik > > > > On 2016-07-07 22:21, Andrew Hughes wrote: > > > Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151841 > > > > > > This is a backport of the original fix to support building OpenJDK > > > with GCC 6. It was necessary to cherry-pick parts of a number of > > > earlier fixes to make this work with the build system in 8: > > > > > > 8149647: Incremental enhancements from build-infra > > > 8032045: Enable compiler and linker safety switches for debug builds > > > > > > and so I'm requesting a review of the 8 version of the patch here as well > > > as approval for 8u. > > > > > > In brief, the patch makes OpenJDK build with GCC 6 by explicitly > > > specifying > > > the C++ standard to use (-std=gnu++98) and disabling two optimisations > > > with > > > -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further > > > information > > > on the changes is available in the GCC 6 release notes [0]. GCC 6 uses > > > a newer C++ standard, C++14, with which the OpenJDK codebase is not yet > > > compliant. The simplest way to fix this, especially for existing > > > releases, > > > is to explicitly request the previous default, gnu++98. The deletion > > > of null pointer checks and more aggressive lifetime dead store > > > elimination > > > in 6 lead to a crashing virtual machine being built, so we disable them > > > if GCC >= 6 is used. > > > > > > To make the original patch work with 8u, a number of changes from other > > > fixes had to also be brought over: > > > > > > * We need to check we are using GCC 6 or above, so we need to bring > > > over the TOOLCHAIN_CHECK_COMPILER_VERSION and > > > TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647. > > > TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional > > > numbered rather than named argument macro so we don't need to backport > > > BASIC_DEFUN_NAMED. > > > * We bring over the introduction of COMMON_CCXXFLAGS_JDK from 8030245 > > > as we need to apply the -std option only to the C++ compiler, not the > > > C compiler. If passed to the C compiler, it will produce a warning, > > > and this is converted to an error at one point in the build > > > (a -Werror in libsctp). > > > > > > Generally, we've kept things in toolchain.m4 (8034788 introduced > > > flags.m4, > > > separating out some code, and so many of these changes are in that file > > > in 9) and avoid named argument macros. Otherwise, it's largely the > > > same as the 9 version. We have adopted the longer name for > > > the -fno-delete-null-pointer-checks flag variable as suggested in the > > > review of the update to this patch for the new HotSpot build [1]. > > > > > > [0] https://gcc.gnu.org/gcc-6/porting_to.html > > > [1] > > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html > > > > > > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From naoto.sato at oracle.com Mon Jul 18 19:36:17 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 18 Jul 2016 12:36:17 -0700 Subject: [9] RFR: 8160873: (cs) JDK9 Build failure on Hindi locale Message-ID: <72c6c758-31dd-3152-909a-602f4a6147c6@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8160873 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8160873/webrev.01/ The gist of the issue is that those tools used to generate sources at build time were affected by the default locale, and if they use some number formatting functions, the results end up including locale dependent digits. The fix is to force tools to run in en-US locale by providing user.language/country properties to bootjdk arguments. Naoto From weijun.wang at oracle.com Tue Jul 19 02:15:55 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 19 Jul 2016 10:15:55 +0800 Subject: make target for javadoc for a module? Message-ID: I see there are make targets like "clean-java.security.sasl-docs", why is there no "java.security.sasl-docs"? Suppose now that I have the exploded build ready, what is the fastest way to build javadoc for the java.security.sasl module? Thanks Max From Alan.Burlison at oracle.com Tue Jul 19 17:19:34 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Tue, 19 Jul 2016 18:19:34 +0100 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed Message-ID: <578E6126.9050600@oracle.com> This removes redundant/incorrect compilation flags from the Solaris build environment. https://bugs.openjdk.java.net/browse/JDK-8161057 http://cr.openjdk.java.net/~dcubed/for_alanbur/8161057-webrev/0-jdk9-hs-all/ I already have one commend from DanD: > jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt > Copyright year updated to '2015' instead of '2016'. I've already fixed that in my workspace but it's still present in the above webrev. There were some JPRT test failures on OSX and Windows, as this changeset doesn't affect those platforms I believe they can be ignored. There is some related cleanup in deploy, that will be covered by https://bugs.openjdk.java.net/browse/JDK-8161081, by removing the Solaris-related scripts. -- Alan Burlison -- From tim.bell at oracle.com Tue Jul 19 18:56:35 2016 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 19 Jul 2016 11:56:35 -0700 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed In-Reply-To: <578E6126.9050600@oracle.com> References: <578E6126.9050600@oracle.com> Message-ID: <578E77E3.60300@oracle.com> Alan: > This removes redundant/incorrect compilation flags from the Solaris > build environment. > > https://bugs.openjdk.java.net/browse/JDK-8161057 > http://cr.openjdk.java.net/~dcubed/for_alanbur/8161057-webrev/0-jdk9-hs-all/ > > > I already have one commend from DanD: > >> jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt >> Copyright year updated to '2015' instead of '2016'. > > I've already fixed that in my workspace but it's still present in the > above webrev. > > There were some JPRT test failures on OSX and Windows, as this > changeset doesn't affect those platforms I believe they can be ignored. Looks good to me. Thanks for doing this. > There is some related cleanup in deploy, that will be covered by > https://bugs.openjdk.java.net/browse/JDK-8161081, by removing the > Solaris-related scripts. That's good to know. Tim From david.dehaven at oracle.com Tue Jul 19 19:44:05 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 19 Jul 2016 12:44:05 -0700 Subject: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method In-Reply-To: <57609177.9030308@oracle.com> References: <1f05a2b9-a68b-4684-a58a-163189c710af@default> <6CB5C96E-8B7F-4093-BA02-94702BA53047@oracle.com> <99907f0c-961d-4d66-950f-9b4de4fc96f7@default> <61539153-a0c6-474d-aded-d34b6266a1c1@default> <3d7b40f9-6c2c-340d-cd75-0050ae0d857c@oracle.com> <798891A9-B63A-4DF1-B8FE-D9F9AAC4855A@oracle.com> <1ec98193-7a52-c73a-e07c-dfed7d02c7a1@oracle.com> <5015B87E-4029-4538-9CD7-FDFD5F52D163@oracle.com> <53d819ee-a8f6-5d93-2660-1fd3e0939b41@oracle.com> <55FFCD3D-A4A4-4B71-B6D7-3C66B35C615B@oracle.com> <57609177.9030308@oracle.com> Message-ID: After having some internal discussions we've decided to set forRemoval to false as we're not certain which release it will be removed in and it's likely to be needed in at least 10. -DrD- From daniel.daugherty at oracle.com Tue Jul 19 21:31:23 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Jul 2016 15:31:23 -0600 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed In-Reply-To: <578E6126.9050600@oracle.com> References: <578E6126.9050600@oracle.com> Message-ID: <42699440-72ce-cc9e-7f55-a3d7cc26cf81@oracle.com> On 7/19/16 11:19 AM, Alan Burlison wrote: > This removes redundant/incorrect compilation flags from the Solaris > build environment. > > https://bugs.openjdk.java.net/browse/JDK-8161057 > http://cr.openjdk.java.net/~dcubed/for_alanbur/8161057-webrev/0-jdk9-hs-all/ > > > I already have one commend from DanD: > >> jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt >> Copyright year updated to '2015' instead of '2016'. > > I've already fixed that in my workspace but it's still present in the > above webrev. common/autoconf/flags.m4 No comments. common/autoconf/generated-configure.sh No comments. jdk/src/demo/share/jvmti/compiledMethodLoad/sample.makefile.txt No comments. jdk/src/demo/share/jvmti/gctest/sample.makefile.txt No comments. jdk/src/demo/share/jvmti/heapTracker/sample.makefile.txt No comments. jdk/src/demo/share/jvmti/heapViewer/sample.makefile.txt No comments. jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt No additional comments. jdk/src/demo/share/jvmti/minst/sample.makefile.txt No comments. jdk/src/demo/share/jvmti/mtrace/sample.makefile.txt No comments. jdk/src/demo/share/jvmti/versionCheck/sample.makefile.txt No comments. Thumbs up. Dan > > There were some JPRT test failures on OSX and Windows, as this > changeset doesn't affect those platforms I believe they can be ignored. > > There is some related cleanup in deploy, that will be covered by > https://bugs.openjdk.java.net/browse/JDK-8161081, by removing the > Solaris-related scripts. > From david.holmes at oracle.com Wed Jul 20 02:17:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jul 2016 12:17:21 +1000 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed In-Reply-To: <578E6126.9050600@oracle.com> References: <578E6126.9050600@oracle.com> Message-ID: Looks good Alan! Thanks for cleaning this up. One comment below ... On 20/07/2016 3:19 AM, Alan Burlison wrote: > This removes redundant/incorrect compilation flags from the Solaris > build environment. > > https://bugs.openjdk.java.net/browse/JDK-8161057 > http://cr.openjdk.java.net/~dcubed/for_alanbur/8161057-webrev/0-jdk9-hs-all/ > > > I already have one commend from DanD: > >> jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt >> Copyright year updated to '2015' instead of '2016'. > > I've already fixed that in my workspace but it's still present in the > above webrev. > > There were some JPRT test failures on OSX and Windows, as this changeset > doesn't affect those platforms I believe they can be ignored. If this is with "-testset hotspot" then it shouldn't happen, in that case please drop me an email pointing to the job. For other testsets, yes they are transient/intermittent failures. > There is some related cleanup in deploy, that will be covered by > https://bugs.openjdk.java.net/browse/JDK-8161081, by removing the > Solaris-related scripts. Not an OpenJDK issue so we will handle that internally. Thanks, David From mikael.gerdin at oracle.com Wed Jul 20 13:54:44 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 20 Jul 2016 15:54:44 +0200 Subject: RFR(XS) 8161915: Linking gtestLauncher may end up linking with non-gtest libjvm Message-ID: Hi all, Please review this small fix to work around a problem where incremental builds of hotspot would fail due to the symbol runUnitTests missing. The cause for the problem is that the unit tests launcher linker command line contains a -L path containing the standard libjvm.so [10] LDFLAGS := -Wl,-z,defs -Wl,-z,now -Wl,-z,relro -Wl,--allow-shlib-undefined -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64 -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64/server [11] LDFLAGS_unix := -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/hotspot/variant-server/libjvm/gtest -Wl,-z,origin -Wl,-rpath,\$$ORIGIN [13] LIBS_unix := -ljvm This is caused by BUILD_GTEST_LAUNCHER picking up LDFLAGS_TESTEXE which was recently modified to include -L path to the standard libjvm.so My suggested fix is to instead use LDFLAGS_JDKEXE for the gtest launcher since the only difference between them is that TESTEXE appends JAVA_BASE_LDFLAGS: flags.m4, 687: LDFLAGS_TESTEXE="$LDFLAGS_JDKEXE $JAVA_BASE_LDFLAGS" Since the fix is only one line, I'll paste it inline here: diff --git a/make/lib/CompileGtest.gmk b/make/lib/CompileGtest.gmk --- a/make/lib/CompileGtest.gmk +++ b/make/lib/CompileGtest.gmk @@ -104,7 +104,7 @@ -I$(GTEST_FRAMEWORK_SRC)/include, \ CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ - LDFLAGS := $(LDFLAGS_TESTEXE), \ + LDFLAGS := $(LDFLAGS_JDKEXE), \ LDFLAGS_unix := -L$(JVM_OUTPUTDIR)/gtest $(call SET_SHARED_LIBRARY_ORIGIN), \ LDFLAGS_solaris := -library=stlport4, \ LIBS_unix := -ljvm, \ Testing: JPRT -testset hotspot Bug link: https://bugs.openjdk.java.net/browse/JDK-8161915 Please let me know if there is any further testing I should do before pushing this. Thanks /Mikael From Alan.Burlison at oracle.com Wed Jul 20 16:05:14 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Wed, 20 Jul 2016 17:05:14 +0100 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed In-Reply-To: References: <578E6126.9050600@oracle.com> Message-ID: <578FA13A.5010505@oracle.com> On 20/07/2016 03:17, David Holmes wrote: >> There were some JPRT test failures on OSX and Windows, as this changeset >> doesn't affect those platforms I believe they can be ignored. > > If this is with "-testset hotspot" then it shouldn't happen, in that > case please drop me an email pointing to the job. For other testsets, > yes they are transient/intermittent failures. The "-testset hostpot" run was clean, it was "-testset core" that failed, with errors in the same areas that I've seen in other unrelated runs. -- Alan Burlison -- From daniel.daugherty at oracle.com Wed Jul 20 17:11:00 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Jul 2016 11:11:00 -0600 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed In-Reply-To: <578FA13A.5010505@oracle.com> References: <578E6126.9050600@oracle.com> <578FA13A.5010505@oracle.com> Message-ID: <08799ca8-166f-bebe-9b57-32d6306e1f93@oracle.com> We have three reviewers on this changeset. We don't have a review from a current Serviceability team member, but I think Tim and I can be considered as sufficient review since we're both former Serviceability team members. :-) Alan, please confirm that this is good to go. This change is applied in the repo I have setup for this change: > jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt > Copyright year updated to '2015' instead of '2016'. Dan On 7/20/16 10:05 AM, Alan Burlison wrote: > On 20/07/2016 03:17, David Holmes wrote: > >>> There were some JPRT test failures on OSX and Windows, as this >>> changeset >>> doesn't affect those platforms I believe they can be ignored. >> >> If this is with "-testset hotspot" then it shouldn't happen, in that >> case please drop me an email pointing to the job. For other testsets, >> yes they are transient/intermittent failures. > > The "-testset hostpot" run was clean, it was "-testset core" that > failed, with errors in the same areas that I've seen in other > unrelated runs. > From Alan.Burlison at oracle.com Wed Jul 20 17:38:37 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Wed, 20 Jul 2016 18:38:37 +0100 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed In-Reply-To: <08799ca8-166f-bebe-9b57-32d6306e1f93@oracle.com> References: <578E6126.9050600@oracle.com> <578FA13A.5010505@oracle.com> <08799ca8-166f-bebe-9b57-32d6306e1f93@oracle.com> Message-ID: <578FB71D.9030406@oracle.com> On 20/07/2016 18:11, Daniel D. Daugherty wrote: > We have three reviewers on this changeset. We don't have a review > from a current Serviceability team member, but I think Tim and I > can be considered as sufficient review since we're both former > Serviceability team members. :-) > > Alan, please confirm that this is good to go. > > This change is applied in the repo I have setup for this change: > > > jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt > > Copyright year updated to '2015' instead of '2016'. Yes, it is good to go, as a belt-and-braces I've sent you a patch with the change above included. Thanks, -- Alan Burlison -- From lance.andersen at oracle.com Wed Jul 20 20:01:18 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 20 Jul 2016 16:01:18 -0400 Subject: Cloning issues anyone seeing them? Message-ID: Hi all, Seeing issues with a openjdk9 clone today ???? source get_source.sh WARNING: Mercurial version 2.6.3 or later is recommended. /usr/local/bin/hg is version 2.2 # Repositories: langtools langtools: hg clone http://hg.openjdk.java.net/jdk9/dev/langtools langtools langtools: requesting all changes langtools: adding changesets langtools: adding manifests langtools: adding file changes langtools: transaction abort! langtools: rollback completed langtools: abort: stream ended unexpectedly (got 2032 bytes, expected 4304) WARNING: langtools exited abnormally (255) Saving session... ...copying shared history... ...saving history...truncating history files... ...completed. [Process completed] ????? I have experienced the above occasionally before but now it is also killing the terminal process which it never used to do? This is on el Capitan Anyone else having this experience? 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 Thu Jul 21 00:22:42 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 20 Jul 2016 20:22:42 -0400 Subject: Problem running configure on El Capitan Message-ID: <4DCD0C8A-6609-4E4F-8339-901DCA5DA0A1@oracle.com> Hi, Has there been any changes to the build requirements recently as I am getting the error: ?????? configure: error: Could not find freetype! /Users/ljanders/Documents/hg-workspaces/openjdk9/javadoc-mod/common/autoconf/generated-configure.sh: line 82: 5: Bad file descriptor configure exiting with result code 1 ???????? I have not seen this before 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 Thu Jul 21 00:40:22 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 20 Jul 2016 17:40:22 -0700 Subject: [9] RFR: 8160873: (cs) JDK9 Build failure on Hindi locale In-Reply-To: <72c6c758-31dd-3152-909a-602f4a6147c6@oracle.com> References: <72c6c758-31dd-3152-909a-602f4a6147c6@oracle.com> Message-ID: <579019F6.9000604@oracle.com> Naoto: > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8160873 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8160873/webrev.01/ > > The gist of the issue is that those tools used to generate sources at > build time were affected by the default locale, and if they use some > number formatting functions, the results end up including locale > dependent digits. The fix is to force tools to run in en-US locale by > providing user.language/country properties to bootjdk arguments. Looks good to me. It is already common practice for the build to set: LC_ALL=C export LC_ALL Tim From naoto.sato at oracle.com Thu Jul 21 00:48:12 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 20 Jul 2016 17:48:12 -0700 Subject: [9] RFR: 8160873: (cs) JDK9 Build failure on Hindi locale In-Reply-To: <579019F6.9000604@oracle.com> References: <72c6c758-31dd-3152-909a-602f4a6147c6@oracle.com> <579019F6.9000604@oracle.com> Message-ID: <682c70f5-80b6-af69-6178-3e39ac8cd6d5@oracle.com> Thanks for the review Tim! On 7/20/16 5:40 PM, Tim Bell wrote: > Naoto: > >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8160873 >> >> The proposed fix is located at: >> >> http://cr.openjdk.java.net/~naoto/8160873/webrev.01/ >> >> The gist of the issue is that those tools used to generate sources at >> build time were affected by the default locale, and if they use some >> number formatting functions, the results end up including locale >> dependent digits. The fix is to force tools to run in en-US locale by >> providing user.language/country properties to bootjdk arguments. > > Looks good to me. > > It is already common practice for the build to set: > > LC_ALL=C > export LC_ALL That works fine on Solaris/Linux platoforms, but for Windows/Linux, Java's default locale is determined from the ControlPanel/SystemPreferences user settings, thus those system properties need to be set. Naoto From tim.bell at oracle.com Thu Jul 21 00:50:38 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 20 Jul 2016 17:50:38 -0700 Subject: [9] RFR: 8160873: (cs) JDK9 Build failure on Hindi locale In-Reply-To: <682c70f5-80b6-af69-6178-3e39ac8cd6d5@oracle.com> References: <72c6c758-31dd-3152-909a-602f4a6147c6@oracle.com> <579019F6.9000604@oracle.com> <682c70f5-80b6-af69-6178-3e39ac8cd6d5@oracle.com> Message-ID: <57901C5E.6060609@oracle.com> On 07/20/16 17:48, Naoto Sato wrote: > Thanks for the review Tim! > > On 7/20/16 5:40 PM, Tim Bell wrote: >> Naoto: >> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8160873 >>> >>> The proposed fix is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8160873/webrev.01/ >>> >>> The gist of the issue is that those tools used to generate sources at >>> build time were affected by the default locale, and if they use some >>> number formatting functions, the results end up including locale >>> dependent digits. The fix is to force tools to run in en-US locale by >>> providing user.language/country properties to bootjdk arguments. >> >> Looks good to me. >> >> It is already common practice for the build to set: >> >> LC_ALL=C >> export LC_ALL > > That works fine on Solaris/Linux platoforms, but for Windows/Linux, > Java's default locale is determined from the > ControlPanel/SystemPreferences user settings, thus those system > properties need to be set. Even better, in that case. Approved- Tim From david.holmes at oracle.com Thu Jul 21 05:42:17 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jul 2016 15:42:17 +1000 Subject: RFR(XS) 8161915: Linking gtestLauncher may end up linking with non-gtest libjvm In-Reply-To: References: Message-ID: <8c400eda-1fd7-98bc-ee8c-a3ca620b6ddc@oracle.com> Hi Mikael, On 20/07/2016 11:54 PM, Mikael Gerdin wrote: > Hi all, > > Please review this small fix to work around a problem where incremental > builds of hotspot would fail due to the symbol runUnitTests missing. > > The cause for the problem is that the unit tests launcher linker command > line contains a -L path containing the standard libjvm.so > [10] LDFLAGS := -Wl,-z,defs -Wl,-z,now -Wl,-z,relro > -Wl,--allow-shlib-undefined > -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64 > -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64/server > > [11] LDFLAGS_unix := > -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/hotspot/variant-server/libjvm/gtest > -Wl,-z,origin -Wl,-rpath,\$$ORIGIN > [13] LIBS_unix := -ljvm > > This is caused by BUILD_GTEST_LAUNCHER picking up LDFLAGS_TESTEXE which > was recently modified to include -L path to the standard libjvm.so > > My suggested fix is to instead use LDFLAGS_JDKEXE for the gtest launcher > since the only difference between them is that TESTEXE appends > JAVA_BASE_LDFLAGS: > flags.m4, 687: LDFLAGS_TESTEXE="$LDFLAGS_JDKEXE $JAVA_BASE_LDFLAGS" > > Since the fix is only one line, I'll paste it inline here: > diff --git a/make/lib/CompileGtest.gmk b/make/lib/CompileGtest.gmk > --- a/make/lib/CompileGtest.gmk > +++ b/make/lib/CompileGtest.gmk > @@ -104,7 +104,7 @@ > -I$(GTEST_FRAMEWORK_SRC)/include, \ > CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ > CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ > - LDFLAGS := $(LDFLAGS_TESTEXE), \ > + LDFLAGS := $(LDFLAGS_JDKEXE), \ > LDFLAGS_unix := -L$(JVM_OUTPUTDIR)/gtest $(call > SET_SHARED_LIBRARY_ORIGIN), \ > LDFLAGS_solaris := -library=stlport4, \ > LIBS_unix := -ljvm, \ This seems like a reasonable solution at least in the short-term. It may be that gtest launcher needs it own compiler/linker options independent of other "executables" in the build. Thanks, David > > Testing: JPRT -testset hotspot > Bug link: https://bugs.openjdk.java.net/browse/JDK-8161915 > > Please let me know if there is any further testing I should do before > pushing this. > > Thanks > /Mikael From erik.helin at oracle.com Thu Jul 21 10:01:43 2016 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 21 Jul 2016 12:01:43 +0200 Subject: RFR(XS) 8161915: Linking gtestLauncher may end up linking with non-gtest libjvm In-Reply-To: References: Message-ID: <20160721100143.GA31575@ehelin.jrpg.bea.com> On 2016-07-20, Mikael Gerdin wrote: > Hi all, > > Please review this small fix to work around a problem where incremental > builds of hotspot would fail due to the symbol runUnitTests missing. > > The cause for the problem is that the unit tests launcher linker command > line contains a -L path containing the standard libjvm.so > [10] LDFLAGS := -Wl,-z,defs -Wl,-z,now -Wl,-z,relro > -Wl,--allow-shlib-undefined -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64 -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64/server > > [11] LDFLAGS_unix := -L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/hotspot/variant-server/libjvm/gtest > -Wl,-z,origin -Wl,-rpath,\$$ORIGIN > [13] LIBS_unix := -ljvm > > This is caused by BUILD_GTEST_LAUNCHER picking up LDFLAGS_TESTEXE which was > recently modified to include -L path to the standard libjvm.so > > My suggested fix is to instead use LDFLAGS_JDKEXE for the gtest launcher > since the only difference between them is that TESTEXE appends > JAVA_BASE_LDFLAGS: > flags.m4, 687: LDFLAGS_TESTEXE="$LDFLAGS_JDKEXE $JAVA_BASE_LDFLAGS" > > Since the fix is only one line, I'll paste it inline here: > diff --git a/make/lib/CompileGtest.gmk b/make/lib/CompileGtest.gmk > --- a/make/lib/CompileGtest.gmk > +++ b/make/lib/CompileGtest.gmk > @@ -104,7 +104,7 @@ > -I$(GTEST_FRAMEWORK_SRC)/include, \ > CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ > CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ > - LDFLAGS := $(LDFLAGS_TESTEXE), \ > + LDFLAGS := $(LDFLAGS_JDKEXE), \ > LDFLAGS_unix := -L$(JVM_OUTPUTDIR)/gtest $(call > SET_SHARED_LIBRARY_ORIGIN), \ > LDFLAGS_solaris := -library=stlport4, \ > LIBS_unix := -ljvm, \ Looks good, Reviewed. Thanks, Erik > Testing: JPRT -testset hotspot > Bug link: https://bugs.openjdk.java.net/browse/JDK-8161915 > > Please let me know if there is any further testing I should do before > pushing this. > > Thanks > /Mikael From Alan.Burlison at oracle.com Thu Jul 21 12:34:23 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 21 Jul 2016 13:34:23 +0100 Subject: [9] RFR: 8160873: (cs) JDK9 Build failure on Hindi locale In-Reply-To: <579019F6.9000604@oracle.com> References: <72c6c758-31dd-3152-909a-602f4a6147c6@oracle.com> <579019F6.9000604@oracle.com> Message-ID: <5790C14F.3070905@oracle.com> On 21/07/2016 01:40, Tim Bell wrote: > Looks good to me. > > It is already common practice for the build to set: > > LC_ALL=C > export LC_ALL Note that this doesn't seem to be happening for the tests run by 'make test', at least not on Solaris. The result is a bunch of date/time formatting test failures. Manually setting LC_CTYPE=C before running 'make tests' fixes the problem. It's on my list to fix... -- Alan Burlison -- From tim.bell at oracle.com Thu Jul 21 14:50:24 2016 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 21 Jul 2016 07:50:24 -0700 Subject: [9] RFR: 8160873: (cs) JDK9 Build failure on Hindi locale In-Reply-To: <5790C14F.3070905@oracle.com> References: <72c6c758-31dd-3152-909a-602f4a6147c6@oracle.com> <579019F6.9000604@oracle.com> <5790C14F.3070905@oracle.com> Message-ID: <5790E130.4040008@oracle.com> On 07/21/16 05:34, Alan Burlison wrote: > On 21/07/2016 01:40, Tim Bell wrote: > >> Looks good to me. >> >> It is already common practice for the build to set: >> >> LC_ALL=C >> export LC_ALL > > Note that this doesn't seem to be happening for the tests run by 'make > test', at least not on Solaris. The result is a bunch of date/time > formatting test failures. Manually setting LC_CTYPE=C before running > 'make tests' fixes the problem. True. This situation could be improved. I found "LC_ALL=C; export LC_ALL" (or the equivalent) spread liberally throughout Makefiles and scripts. The only documentation I found mentioning locale was in a netbeans make README, which is buried pretty far down: http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/make/netbeans/README > It's on my list to fix... Good, thanks. Tim From david.holmes at oracle.com Fri Jul 22 07:01:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Jul 2016 17:01:33 +1000 Subject: hg: jdk9/dev: 8160873: (cs) JDK9 Build failure on Hindi locale In-Reply-To: <201607211647.u6LGlpj8004690@aojmv0008.oracle.com> References: <201607211647.u6LGlpj8004690@aojmv0008.oracle.com> Message-ID: <706d708a-f412-ecea-7bd4-4c36baca39a7@oracle.com> This change failed to regenerate and check-in the open (and closed) generated-configure.sh files! David On 22/07/2016 2:47 AM, naoto.sato at oracle.com wrote: > Changeset: a3f2a1723e75 > Author: naoto > Date: 2016-07-21 09:47 -0700 > URL: http://hg.openjdk.java.net/jdk9/dev/rev/a3f2a1723e75 > > 8160873: (cs) JDK9 Build failure on Hindi locale > Reviewed-by: tbell > > ! common/autoconf/boot-jdk.m4 > From tim.bell at oracle.com Fri Jul 22 15:37:45 2016 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 22 Jul 2016 08:37:45 -0700 Subject: hg: jdk9/dev: 8160873: (cs) JDK9 Build failure on Hindi locale In-Reply-To: <706d708a-f412-ecea-7bd4-4c36baca39a7@oracle.com> References: <201607211647.u6LGlpj8004690@aojmv0008.oracle.com> <706d708a-f412-ecea-7bd4-4c36baca39a7@oracle.com> Message-ID: <57923DC9.9000202@oracle.com> David: > This change failed to regenerate and check-in the open (and closed) > generated-configure.sh files! Good point - thanks. Naoto - sorry - I should have reminded you about this during code review > David > > On 22/07/2016 2:47 AM, naoto.sato at oracle.com wrote: >> Changeset: a3f2a1723e75 >> Author: naoto >> Date: 2016-07-21 09:47 -0700 >> URL: http://hg.openjdk.java.net/jdk9/dev/rev/a3f2a1723e75 >> >> 8160873: (cs) JDK9 Build failure on Hindi locale >> Reviewed-by: tbell >> >> ! common/autoconf/boot-jdk.m4 >> I am working on it. I will send out a RFR in a few minutes. I will also file a bug against the check in make/Init.gmk which is supposed to notice this. Tim From tim.bell at oracle.com Fri Jul 22 16:07:04 2016 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 22 Jul 2016 09:07:04 -0700 Subject: hg: jdk9/dev: 8160873: (cs) JDK9 Build failure on Hindi locale In-Reply-To: <57923DC9.9000202@oracle.com> References: <201607211647.u6LGlpj8004690@aojmv0008.oracle.com> <706d708a-f412-ecea-7bd4-4c36baca39a7@oracle.com> <57923DC9.9000202@oracle.com> Message-ID: <579244A8.7030403@oracle.com> On 07/22/16 08:37, Tim Bell wrote: > I will also file a bug against the check in make/Init.gmk which is > supposed to notice this. The generated-configure.sh files (open and closed) have been updated. I also filed JDK-8162413 "tighter safety check for .m4 files newer than generated-configure.sh" Tim From david.holmes at oracle.com Mon Jul 25 01:32:53 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Jul 2016 11:32:53 +1000 Subject: hg: jdk9/dev: 8160873: (cs) JDK9 Build failure on Hindi locale In-Reply-To: <579244A8.7030403@oracle.com> References: <201607211647.u6LGlpj8004690@aojmv0008.oracle.com> <706d708a-f412-ecea-7bd4-4c36baca39a7@oracle.com> <57923DC9.9000202@oracle.com> <579244A8.7030403@oracle.com> Message-ID: Thanks Tim! Much appreciated. David On 23/07/2016 2:07 AM, Tim Bell wrote: > On 07/22/16 08:37, Tim Bell wrote: >> I will also file a bug against the check in make/Init.gmk which is >> supposed to notice this. > > The generated-configure.sh files (open and closed) have been updated. > > I also filed JDK-8162413 "tighter safety check for .m4 files newer than > generated-configure.sh" > > Tim > From volker.simonis at gmail.com Tue Jul 26 12:20:11 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Jul 2016 14:20:11 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version Message-ID: Forwarding to build-dev in the hope to get a review there :) More details can be found in the bug description. Thank you and best regards, Volker ---------- Forwarded message ---------- From: Volker Simonis Date: Mon, Apr 4, 2016 at 6:47 PM Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version To: Java Core Libs Cc: verona-dev at openjdk.java.net Hi, can I please have a review for this small fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 https://bugs.openjdk.java.net/browse/JDK-8149519 Currently the value of the java.specification.version property comes from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is currently set to VERSION_NUMBER which is the same value which is also used for the java.version property. This is a bad idea, because VERSION_NUMBER is a dot separated sequence of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. for every build and/or update version). If we are configuring with "--with-version-patch=1" for example, VERSION_NUMBER and java.version will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION and java.specification.version have the same, dotted value. And it breaks a lot of legacy applications which parse java.specification.version as a float number. That code would still work if java.specification.version would be a concrete number (e.g. '9' or '10'). I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in common/autoconf/spec.gmk.in. This should be the "right value" until we get a specification change during a major release which hasn't happened for quite some time now. Regards, Volker From Alan.Bateman at oracle.com Tue Jul 26 12:26:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Jul 2016 13:26:45 +0100 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: This looks right but I'm curious why it was initially implemented to use VERSION_NUMBER. -Alan On 26/07/2016 13:20, Volker Simonis wrote: > Forwarding to build-dev in the hope to get a review there :) > More details can be found in the bug description. > > Thank you and best regards, > Volker > > > ---------- Forwarded message ---------- > From: Volker Simonis > Date: Mon, Apr 4, 2016 at 6:47 PM > Subject: RFR(XXS): 8149519: Investigate implementation of > java.specification.version > To: Java Core Libs > Cc: verona-dev at openjdk.java.net > > > Hi, > > can I please have a review for this small fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 > https://bugs.openjdk.java.net/browse/JDK-8149519 > > Currently the value of the java.specification.version property comes > from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is > currently set to VERSION_NUMBER which is the same value which is also > used for the java.version property. > > This is a bad idea, because VERSION_NUMBER is a dot separated sequence > of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. > for every build and/or update version). If we are configuring with > "--with-version-patch=1" for example, VERSION_NUMBER and java.version > will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION > and java.specification.version have the same, dotted value. And it > breaks a lot of legacy applications which parse > java.specification.version as a float number. That code would still > work if java.specification.version would be a concrete number (e.g. > '9' or '10'). > > I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in > common/autoconf/spec.gmk.in. This should be the "right value" until we > get a specification change during a major release which hasn't > happened for quite some time now. > > Regards, > Volker From volker.simonis at gmail.com Tue Jul 26 17:20:19 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Jul 2016 19:20:19 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: On Tue, Jul 26, 2016 at 2:26 PM, Alan Bateman wrote: > This looks right Thanks! > but I'm curious why it was initially implemented to use VERSION_NUMBER. Probably because until now VERSION_NUMBER == VERSION_MAJOR == 9? > > -Alan > > > > On 26/07/2016 13:20, Volker Simonis wrote: > >> Forwarding to build-dev in the hope to get a review there :) >> More details can be found in the bug description. >> >> Thank you and best regards, >> Volker >> >> >> ---------- Forwarded message ---------- >> From: Volker Simonis >> Date: Mon, Apr 4, 2016 at 6:47 PM >> Subject: RFR(XXS): 8149519: Investigate implementation of >> java.specification.version >> To: Java Core Libs >> Cc: verona-dev at openjdk.java.net >> >> >> Hi, >> >> can I please have a review for this small fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 >> https://bugs.openjdk.java.net/browse/JDK-8149519 >> >> Currently the value of the java.specification.version property comes >> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is >> currently set to VERSION_NUMBER which is the same value which is also >> used for the java.version property. >> >> This is a bad idea, because VERSION_NUMBER is a dot separated sequence >> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. >> for every build and/or update version). If we are configuring with >> "--with-version-patch=1" for example, VERSION_NUMBER and java.version >> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION >> and java.specification.version have the same, dotted value. And it >> breaks a lot of legacy applications which parse >> java.specification.version as a float number. That code would still >> work if java.specification.version would be a concrete number (e.g. >> '9' or '10'). >> >> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in >> common/autoconf/spec.gmk.in. This should be the "right value" until we >> get a specification change during a major release which hasn't >> happened for quite some time now. >> >> Regards, >> Volker > > From david.holmes at oracle.com Wed Jul 27 02:22:52 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jul 2016 12:22:52 +1000 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: +1 from me. Does the Verona JEP say anything about this? I certainly do not expect the specification version number of differ from the major release number. David On 26/07/2016 10:26 PM, Alan Bateman wrote: > This looks right but I'm curious why it was initially implemented to use > VERSION_NUMBER. > > -Alan > > > On 26/07/2016 13:20, Volker Simonis wrote: > >> Forwarding to build-dev in the hope to get a review there :) >> More details can be found in the bug description. >> >> Thank you and best regards, >> Volker >> >> >> ---------- Forwarded message ---------- >> From: Volker Simonis >> Date: Mon, Apr 4, 2016 at 6:47 PM >> Subject: RFR(XXS): 8149519: Investigate implementation of >> java.specification.version >> To: Java Core Libs >> Cc: verona-dev at openjdk.java.net >> >> >> Hi, >> >> can I please have a review for this small fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 >> https://bugs.openjdk.java.net/browse/JDK-8149519 >> >> Currently the value of the java.specification.version property comes >> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is >> currently set to VERSION_NUMBER which is the same value which is also >> used for the java.version property. >> >> This is a bad idea, because VERSION_NUMBER is a dot separated sequence >> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. >> for every build and/or update version). If we are configuring with >> "--with-version-patch=1" for example, VERSION_NUMBER and java.version >> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION >> and java.specification.version have the same, dotted value. And it >> breaks a lot of legacy applications which parse >> java.specification.version as a float number. That code would still >> work if java.specification.version would be a concrete number (e.g. >> '9' or '10'). >> >> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in >> common/autoconf/spec.gmk.in. This should be the "right value" until we >> get a specification change during a major release which hasn't >> happened for quite some time now. >> >> Regards, >> Volker > From weijun.wang at oracle.com Wed Jul 27 09:45:32 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 27 Jul 2016 17:45:32 +0800 Subject: conf vs. lib In-Reply-To: <48353291-ec70-6017-50f4-57ebf7cc2310@oracle.com> References: <444030c9-7f38-5f2f-d773-43c7da553439@oracle.com> <635309d3-20fa-537b-58e8-129961fef58d@oracle.com> <4e2b237f-b3fa-7b52-32f9-ed2e88c6f54c@oracle.com> <3b041b4d-d039-f18f-89d5-87fed5b18628@oracle.com> <1ca11b0c-3016-2a38-f5a0-fb46f9349d0e@oracle.com> <48353291-ec70-6017-50f4-57ebf7cc2310@oracle.com> Message-ID: > ? 2016?7?27??17:15?Alan Bateman ??? > > So have you decided one way or the other to have keytool support updating caceerts without needing to specify the file path? That would be consistent with leaving it in lib. If there are existing scripts that are specifying the location then they will continue to work. I suggest we create a new special -keystore value "<>" which acts like an alias of the cacerts file. Creating a new option means we have to document its relation with the existing -keystore option. The new name can also work with the -importkeystore command. Like this: keytool -list -keystore <> The name is inspired by <> in FilePermission. I'm open to other styles. Thanks Max From Alan.Bateman at oracle.com Wed Jul 27 11:13:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Jul 2016 12:13:13 +0100 Subject: conf vs. lib In-Reply-To: References: <444030c9-7f38-5f2f-d773-43c7da553439@oracle.com> <635309d3-20fa-537b-58e8-129961fef58d@oracle.com> <4e2b237f-b3fa-7b52-32f9-ed2e88c6f54c@oracle.com> <3b041b4d-d039-f18f-89d5-87fed5b18628@oracle.com> <1ca11b0c-3016-2a38-f5a0-fb46f9349d0e@oracle.com> <48353291-ec70-6017-50f4-57ebf7cc2310@oracle.com> Message-ID: <8ff431fc-a2ac-f29f-b9e6-afa7b4968df4@oracle.com> On 27/07/2016 10:45, Wang Weijun wrote: > : > I suggest we create a new special -keystore value "<>" which acts like an alias of the cacerts file. Creating a new option means we have to document its relation with the existing -keystore option. The new name can also work with the -importkeystore command. > > Like this: > > keytool -list -keystore <> > > The name is inspired by <> in FilePermission. I'm open to other styles. > I assume you mean to quote this as this will otherwise cause redirection when used on the command line or in scripts. In any case, it does seem a bit unusual to me. I would assume something like `keytool -list -cacerts` would be easier. I realize it would mean disallowing its usage with -keystore. -Alan From weijun.wang at oracle.com Wed Jul 27 11:38:46 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 27 Jul 2016 19:38:46 +0800 Subject: conf vs. lib In-Reply-To: <8ff431fc-a2ac-f29f-b9e6-afa7b4968df4@oracle.com> References: <444030c9-7f38-5f2f-d773-43c7da553439@oracle.com> <635309d3-20fa-537b-58e8-129961fef58d@oracle.com> <4e2b237f-b3fa-7b52-32f9-ed2e88c6f54c@oracle.com> <3b041b4d-d039-f18f-89d5-87fed5b18628@oracle.com> <1ca11b0c-3016-2a38-f5a0-fb46f9349d0e@oracle.com> <48353291-ec70-6017-50f4-57ebf7cc2310@oracle.com> <8ff431fc-a2ac-f29f-b9e6-afa7b4968df4@oracle.com> Message-ID: > On Jul 27, 2016, at 7:13 PM, Alan Bateman wrote: > > > > On 27/07/2016 10:45, Wang Weijun wrote: >> : >> I suggest we create a new special -keystore value "<>" which acts like an alias of the cacerts file. Creating a new option means we have to document its relation with the existing -keystore option. The new name can also work with the -importkeystore command. >> >> Like this: >> >> keytool -list -keystore <> >> >> The name is inspired by <> in FilePermission. I'm open to other styles. >> > I assume you mean to quote this as this will otherwise cause redirection when used on the command line or in scripts. Yes. Or just CACERTS? This will be ambiguous. > > In any case, it does seem a bit unusual to me. I would assume something like `keytool -list -cacerts` would be easier. I realize it would mean disallowing its usage with -keystore. How much is creating a new name or a new option worth? Do we plan to move cacerts again? Unless we backport it (I believe back porting a name is easier than an option), it is useless in writing a "cross-release" script. Another benefit is that we can invent new names later, say, user's own "cacerts" used by deployment. BTW, you said: > If there are existing scripts that are specifying the location then they will continue to work. What does this mean? If we change the location, it sure will not work, and they are recommended to use the new style, whether a new name or a new option. Anyway the script must be modified. In fact, most likely the script is importing a cert into cacerts, and importing one to an non-existent file will succeed silently! --Max > > -Alan From Alan.Bateman at oracle.com Wed Jul 27 12:13:11 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Jul 2016 13:13:11 +0100 Subject: conf vs. lib In-Reply-To: References: <444030c9-7f38-5f2f-d773-43c7da553439@oracle.com> <635309d3-20fa-537b-58e8-129961fef58d@oracle.com> <4e2b237f-b3fa-7b52-32f9-ed2e88c6f54c@oracle.com> <3b041b4d-d039-f18f-89d5-87fed5b18628@oracle.com> <1ca11b0c-3016-2a38-f5a0-fb46f9349d0e@oracle.com> <48353291-ec70-6017-50f4-57ebf7cc2310@oracle.com> <8ff431fc-a2ac-f29f-b9e6-afa7b4968df4@oracle.com> Message-ID: <7717800d-2a7d-51e2-9162-8cfa4abb1610@oracle.com> On 27/07/2016 12:38, Wang Weijun wrote: > : > Yes. Or just CACERTS? This will be ambiguous. It would be but do do you really want to use a token here? > : > How much is creating a new name or a new option worth? Do we plan to move cacerts again? Unless we backport it (I believe back porting a name is easier than an option), it is useless in writing a "cross-release" script. > > Another benefit is that we can invent new names later, say, user's own "cacerts" used by deployment. We have not touched cacerts. All I'm saying is that it shouldn't be hard to come up with a solution that doesn't require the user to know the internal location. As I see it, there are two cases to consider. One is using keytool to access the cacerts in the runtime that keytool is running on, the other is where you use keytool to update a remote cacerts (a bit like the cross compilation issue). javac uses `-system ` for example. -Alan From iris.clark at oracle.com Thu Jul 28 07:17:59 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 28 Jul 2016 00:17:59 -0700 (PDT) Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: <6f3a6c94-b9ba-4e7e-b36a-9331b2625c97@default> Hi, Volker. Thanks for your patience. I think that the solution that you've provided solves the immediate problem, the java.specification.version number is incorrectly set to be identical to java.version. The java.{vm.}?specification.version system properties should be independent of java.version and are determined by the JCP (either a JSR or an Maintenance Release). If there's ever an MR against JSR 379 (Java SE 9 Release Contents) the value may need to be updated to something besides $MAJOR. Let's go with what you've got now. Before you commit, I recommend that you update the title of 8149519 to describe either the problem or the solution. Something like "Set java.specification.version to $MAJOR" would be appropriate. I've filled the following two follow-on bugs: 8162686 is a Java SE 9 spec bug against myself to update the spec of java.{vm.}?specification.version system properties as described above. I'll also modify the Verona JEP to adjust the syntax of these system properties. I've also filed build bug (8162687) referencing 8145919 and 8162686. Regards, Iris For the build team's bug, I'll reference 8145919 and the spec bug. I suspect that they won't feel compelled to fix it for 9, but I leave it to them to determine how to best handle the issue. I think it would be reasonable for them to decline to add complexity to the build without any current need for such a feature. -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Tuesday, July 26, 2016 5:20 AM To: build-dev Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version Forwarding to build-dev in the hope to get a review there :) More details can be found in the bug description. Thank you and best regards, Volker ---------- Forwarded message ---------- From: Volker Simonis Date: Mon, Apr 4, 2016 at 6:47 PM Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version To: Java Core Libs Cc: verona-dev at openjdk.java.net Hi, can I please have a review for this small fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 https://bugs.openjdk.java.net/browse/JDK-8149519 Currently the value of the java.specification.version property comes from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is currently set to VERSION_NUMBER which is the same value which is also used for the java.version property. This is a bad idea, because VERSION_NUMBER is a dot separated sequence of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. for every build and/or update version). If we are configuring with "--with-version-patch=1" for example, VERSION_NUMBER and java.version will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION and java.specification.version have the same, dotted value. And it breaks a lot of legacy applications which parse java.specification.version as a float number. That code would still work if java.specification.version would be a concrete number (e.g. '9' or '10'). I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in common/autoconf/spec.gmk.in. This should be the "right value" until we get a specification change during a major release which hasn't happened for quite some time now. Regards, Volker From martin.walsh at oracle.com Thu Jul 28 09:58:57 2016 From: martin.walsh at oracle.com (Martin Walsh) Date: Thu, 28 Jul 2016 10:58:57 +0100 Subject: Creating IPS packages on Solaris Message-ID: <5799D761.10103@oracle.com> Hi, I am currently building the JVM on Solaris 11.3. I am trying to figure out how to build IPS packages from the SVR4 packages in my build directory. Could anyone provide any insight in how to do this? Thanks, Martin From sean.coffey at oracle.com Thu Jul 28 10:15:12 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 28 Jul 2016 11:15:12 +0100 Subject: Creating IPS packages on Solaris In-Reply-To: <5799D761.10103@oracle.com> References: <5799D761.10103@oracle.com> Message-ID: Hi Martin, such packages are not in the scope of the OpenJDK project. I'll ping you offline with some contacts. Regards, Sean. On 28/07/2016 10:58, Martin Walsh wrote: > Hi, > > I am currently building the JVM on Solaris 11.3. I am trying to > figure out how to build IPS packages from the SVR4 packages in my > build directory. Could anyone provide any insight in how to do this? > > Thanks, > > Martin From Alan.Burlison at oracle.com Thu Jul 28 15:53:12 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Thu, 28 Jul 2016 16:53:12 +0100 Subject: Creating IPS packages on Solaris In-Reply-To: References: <5799D761.10103@oracle.com> Message-ID: <579A2A68.4080205@oracle.com> On 28/07/2016 11:15, Se?n Coffey wrote: > such packages are not in the scope of the OpenJDK project. I'll ping you > offline with some contacts. Any reason why that's the case? All the tools needed to build IPS packages are available as standard on Solaris. -- Alan Burlison -- From adinn at redhat.com Thu Jul 28 16:58:33 2016 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 28 Jul 2016 17:58:33 +0100 Subject: Missing sources stepping through Jigsaw code? Message-ID: <579A39B9.1090607@redhat.com> n.b. I'm addressing this question to the Jigsaw list a sit appears to relate to the organization of the code base into modules but I have copied it to build-dev just in case it simply relates to the build config. While debugging my Jigsaw ModuleFinder implementation I noticed that the src.zip file distributed with early access release jigsaw-9ea+126 doesn't include any of the classes in the jdk package hierarchy. This was really inconvenient when trying to debug what is happening in the runtime underneath my implementation. 1) Is there a reason for excluding these sources from the zip? 2) More pertinently, is this merely a reflection of Oracle's policy regarding distribution of sources or is this also the policy adopted for OpenJDK builds? I ask the latter question because, as with most normal open source projects, it would seem to me to be more sensible to ensure that the sources used to build a release accompany the release where possible. So, I'd prefer for open code builds to be configured to include the jdk package sources -- unless, of course, there is a good reason not to include them. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Thu Jul 28 17:27:38 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Jul 2016 18:27:38 +0100 Subject: Missing sources stepping through Jigsaw code? In-Reply-To: <579A39B9.1090607@redhat.com> References: <579A39B9.1090607@redhat.com> Message-ID: On 28/07/2016 17:58, Andrew Dinn wrote: > : > > 2) More pertinently, is this merely a reflection of Oracle's policy > regarding distribution of sources or is this also the policy adopted for > OpenJDK builds? > Yes, it's a policy issue (outside of our control, and not specific to Jigsaw EA builds). If you do your own build then src.zip will contain all the java sources. -Alan From Alan.Bateman at oracle.com Thu Jul 28 18:11:19 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Jul 2016 19:11:19 +0100 Subject: Missing sources stepping through Jigsaw code? In-Reply-To: References: <579A39B9.1090607@redhat.com> Message-ID: <8cd0de20-46ac-61cd-9f2f-4ce9b3d3dfc7@oracle.com> On 28/07/2016 19:04, Jason T. Greene wrote: > : > Wow! That's very unfortunate. If there's no way to correlate a source snapshot to an OpenJDK binary; that's going to be a very strong motivator for using a thirdparty build. > The `release` file in the top-level directory has the hg tips used in the build, this has been the way to link it the sources for several years. -Alan From magnus.ihse.bursie at oracle.com Thu Jul 28 21:30:19 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 28 Jul 2016 23:30:19 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: Some background on this: I initially introduced VERSION_SPECIFICATION as VERSION_MAJOR but had to revert it in the Verona branch since I was told that the specification number should be identical to the release version. My initial reaction was the same as yours, that the specification would match only the major part. I see now that Iris support this change, so I hope the old rationale for having the specification in lockstep with the release is no longer valid. /Magnus > 26 juli 2016 kl. 14:26 skrev Alan Bateman : > > This looks right but I'm curious why it was initially implemented to use VERSION_NUMBER. > > -Alan > > >> On 26/07/2016 13:20, Volker Simonis wrote: >> >> Forwarding to build-dev in the hope to get a review there :) >> More details can be found in the bug description. >> >> Thank you and best regards, >> Volker >> >> >> ---------- Forwarded message ---------- >> From: Volker Simonis >> Date: Mon, Apr 4, 2016 at 6:47 PM >> Subject: RFR(XXS): 8149519: Investigate implementation of >> java.specification.version >> To: Java Core Libs >> Cc: verona-dev at openjdk.java.net >> >> >> Hi, >> >> can I please have a review for this small fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 >> https://bugs.openjdk.java.net/browse/JDK-8149519 >> >> Currently the value of the java.specification.version property comes >> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is >> currently set to VERSION_NUMBER which is the same value which is also >> used for the java.version property. >> >> This is a bad idea, because VERSION_NUMBER is a dot separated sequence >> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. >> for every build and/or update version). If we are configuring with >> "--with-version-patch=1" for example, VERSION_NUMBER and java.version >> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION >> and java.specification.version have the same, dotted value. And it >> breaks a lot of legacy applications which parse >> java.specification.version as a float number. That code would still >> work if java.specification.version would be a concrete number (e.g. >> '9' or '10'). >> >> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in >> common/autoconf/spec.gmk.in. This should be the "right value" until we >> get a specification change during a major release which hasn't >> happened for quite some time now. >> >> Regards, >> Volker > From samuelmarks at gmail.com Fri Jul 29 07:55:09 2016 From: samuelmarks at gmail.com (Samuel Marks) Date: Fri, 29 Jul 2016 17:55:09 +1000 Subject: kulla fails to configure with Java 9 ea (Early Access) Message-ID: Error: configure: Found potential Boot JDK using configure arguments configure: Potential Boot JDK found at /opt/Java/jdk-9 is incorrect JDK version (java version "9-ea"); ignoring configure: (Your Boot JDK must be version 8 or 9) configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK Here's a fix to the kulla repository (also attached, not sure what the protocol is): # HG changeset patch # User Samuel Marks # Date 1469777474 -36000 # Fri Jul 29 17:31:14 2016 +1000 # Node ID 9268348574206a8487901c8e8a1ea15987709521 # Parent 77a1e3986f77f6e9d1037f4de8296d927ef12ac4 New version check routine to handle Java 9 Early Access release diff -r 77a1e3986f77 -r 926834857420 common/autoconf/boot-jdk.m4 --- a/common/autoconf/boot-jdk.m4 Sat Aug 22 00:47:29 2015 -0700 +++ b/common/autoconf/boot-jdk.m4 Fri Jul 29 17:31:14 2016 +1000 @@ -74,11 +74,12 @@ BOOT_JDK_FOUND=no else # Oh, this is looking good! We probably have found a proper JDK. Is it the correct version? - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | head -n 1` + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | awk '/version/{print $NF}'` + BOOT_JDK_VERSION="${BOOT_JDK_VERSION:1:3}" + CORRECT_VERSIONS=(1.8 1.9 9 9-e) # Extra M4 quote needed to protect [] in grep expression. - [FOUND_CORRECT_VERSION=`echo $BOOT_JDK_VERSION | grep '\"1\.[89]\.'`] - if test "x$FOUND_CORRECT_VERSION" = x; then + if [[ ! " ${CORRECT_VERSIONS[*]} " == *" $BOOT_JDK_VERSION "* ]]; then AC_MSG_NOTICE([Potential Boot JDK found at $BOOT_JDK is incorrect JDK version ($BOOT_JDK_VERSION); ignoring]) AC_MSG_NOTICE([(Your Boot JDK must be version 8 or 9)]) BOOT_JDK_FOUND=no Samuel Marks http://linkedin.com/in/samuelmarks BTW: I posted in kulla-dev but they told me to post here - http://mail.openjdk.java.net/pipermail/kulla-dev/2016-July/001508.html -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.patch Type: text/x-patch Size: 1438 bytes Desc: not available URL: From bitterfoxc at gmail.com Fri Jul 29 08:12:46 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Fri, 29 Jul 2016 17:12:46 +0900 Subject: kulla fails to configure with Java 9 ea (Early Access) In-Reply-To: References: Message-ID: Hi Samuel, thank you for resending. Oops, let me confirm one thing please. You got this error on a repository hosted on kulla-dev, right? If so, unfortunately it isn't under maintaining because it already merged to jdk9-dev. Please confirm that you still get this error on jdk9-dev and your patch works well on it. Regards, shinyafox(Shinya Yoshida) 2016/07/29 ??4:55 "Samuel Marks" : > Error: > configure: Found potential Boot JDK using configure arguments > configure: Potential Boot JDK found at /opt/Java/jdk-9 is incorrect JDK > version (java version "9-ea"); ignoring > configure: (Your Boot JDK must be version 8 or 9) > configure: error: The path given by --with-boot-jdk does not contain a > valid Boot JDK > > Here's a fix to the kulla repository (also attached, not sure what the > protocol is): > > # HG changeset patch > # User Samuel Marks > # Date 1469777474 -36000 > # Fri Jul 29 17:31:14 2016 +1000 > # Node ID 9268348574206a8487901c8e8a1ea15987709521 > # Parent 77a1e3986f77f6e9d1037f4de8296d927ef12ac4 > New version check routine to handle Java 9 Early Access release > > diff -r 77a1e3986f77 -r 926834857420 common/autoconf/boot-jdk.m4 > --- a/common/autoconf/boot-jdk.m4 Sat Aug 22 00:47:29 2015 -0700 > +++ b/common/autoconf/boot-jdk.m4 Fri Jul 29 17:31:14 2016 +1000 > @@ -74,11 +74,12 @@ > BOOT_JDK_FOUND=no > else > # Oh, this is looking good! We probably have found a proper JDK. > Is it the correct version? > - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | head -n > 1` > + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | awk > '/version/{print $NF}'` > + BOOT_JDK_VERSION="${BOOT_JDK_VERSION:1:3}" > + CORRECT_VERSIONS=(1.8 1.9 9 9-e) > > # Extra M4 quote needed to protect [] in grep expression. > - [FOUND_CORRECT_VERSION=`echo $BOOT_JDK_VERSION | grep > '\"1\.[89]\.'`] > - if test "x$FOUND_CORRECT_VERSION" = x; then > + if [[ ! " ${CORRECT_VERSIONS[*]} " == *" $BOOT_JDK_VERSION "* > ]]; then > AC_MSG_NOTICE([Potential Boot JDK found at $BOOT_JDK is > incorrect JDK version ($BOOT_JDK_VERSION); ignoring]) > AC_MSG_NOTICE([(Your Boot JDK must be version 8 or 9)]) > BOOT_JDK_FOUND=no > > Samuel Marks > http://linkedin.com/in/samuelmarks > > BTW: I posted in kulla-dev but they told me to post here - > http://mail.openjdk.java.net/pipermail/kulla-dev/2016-July/001508.html > From adinn at redhat.com Fri Jul 29 09:43:40 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 29 Jul 2016 10:43:40 +0100 Subject: Missing sources stepping through Jigsaw code? In-Reply-To: <8cd0de20-46ac-61cd-9f2f-4ce9b3d3dfc7@oracle.com> References: <579A39B9.1090607@redhat.com> <8cd0de20-46ac-61cd-9f2f-4ce9b3d3dfc7@oracle.com> Message-ID: <579B254C.2040206@redhat.com> On 28/07/16 19:11, Alan Bateman wrote: > On 28/07/2016 19:04, Jason T. Greene wrote: >> Wow! That's very unfortunate. If there's no way to correlate a source >> snapshot to an OpenJDK binary; that's going to be a very strong >> motivator for using a thirdparty build. >> > The `release` file in the top-level directory has the hg tips used in > the build, this has been the way to link it the sources for several years. As Alan indicated, this is, of course, merely an artefact the EA Jigsaw releases being Oracle builds. The build system can be configured to include the missing sources in src.zip and seems to be so configured by default. I cannot see Red Hat being happy to follow Oracle's policy of omitting these sources from their OpenJDK releases. Obscurity has never been the a part of the Open Source way of doing things. I do think Oracle's policy -- at least wrt re these EA releases -- is rather self-defeating. It would actually be of great aid to those of us currently trying to help validate the proposed solutions to the outstanding Jigsaw issues if we could see what is going on inside the Jigsaw code from a debugger. Not everyone involved is in a position to build (and keep on rebuilding) a Jigsaw JDK9 release from scratch. Still, no doubt Oracle has its own reasons for adopting such a policy. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Fri Jul 29 10:06:29 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Jul 2016 11:06:29 +0100 Subject: Missing sources stepping through Jigsaw code? In-Reply-To: <579B254C.2040206@redhat.com> References: <579A39B9.1090607@redhat.com> <8cd0de20-46ac-61cd-9f2f-4ce9b3d3dfc7@oracle.com> <579B254C.2040206@redhat.com> Message-ID: On 29/07/2016 10:43, Andrew Dinn wrote: > : > As Alan indicated, this is, of course, merely an artefact the EA Jigsaw > releases being Oracle builds. The build system can be configured to > include the missing sources in src.zip and seems to be so configured by > default. I cannot see Red Hat being happy to follow Oracle's policy of > omitting these sources from their OpenJDK releases. Obscurity has never > been the a part of the Open Source way of doing things. > > I do think Oracle's policy -- at least wrt re these EA releases -- is > rather self-defeating. It would actually be of great aid to those of us > currently trying to help validate the proposed solutions to the > outstanding Jigsaw issues if we could see what is going on inside the > Jigsaw code from a debugger. Not everyone involved is in a position to > build (and keep on rebuilding) a Jigsaw JDK9 release from scratch. > Still, no doubt Oracle has its own reasons for adopting such a policy. I thought there was an FAQ on this but I can't find it. It comes up periodically but basically Oracle builds do have some code and modules that are not in OpenJDK, the deploy area (Java Web Start for example) mostly. Oracle builds have include the FX modules. They are in the OpenJFX project (in OpenJDK), just not in the JDK 9 forests so you typically don't have them in your own builds (needs a configure option when building). In any case, src.zip is just the .java sources. The IDEs/debuggers have historically used it. I don't know if it's used elsewhere but it has never been the complete source code. It has never include the hotspot code or any of the native code for example. The only thing about src.zip that is interesting to modules is whether to change the layout so that the contents are organized by module. We have been shy about changing it, mostly because it's not clear what might be depending on it. -Alan From adinn at redhat.com Fri Jul 29 10:54:26 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 29 Jul 2016 11:54:26 +0100 Subject: Missing sources stepping through Jigsaw code? In-Reply-To: References: <579A39B9.1090607@redhat.com> <8cd0de20-46ac-61cd-9f2f-4ce9b3d3dfc7@oracle.com> <579B254C.2040206@redhat.com> Message-ID: <579B35E2.9070807@redhat.com> On 29/07/16 11:06, Alan Bateman wrote: > I thought there was an FAQ on this but I can't find it. It comes up > periodically but basically Oracle builds do have some code and modules > that are not in OpenJDK, the deploy area (Java Web Start for example) > mostly. Oracle builds have include the FX modules. They are in the > OpenJFX project (in OpenJDK), just not in the JDK 9 forests so you > typically don't have them in your own builds (needs a configure option > when building). Well, that's very interesting but it wasn't this code that was missing, rather a significant swathe of the core JDK runtime classes. > In any case, src.zip is just the .java sources. The IDEs/debuggers have > historically used it. I don't know if it's used elsewhere but it has > never been the complete source code. It has never include the hotspot > code or any of the native code for example. No, indeed. And I wouldn't expect it to be anything other than Java sources since the purpose of src.zip is merely to provide a Java debugger with the sources of the Java bytecode included in the core JDK runtime (if we were ever to get to the point where gdb can debug Java and C++ well, I might then start clamouring for the hotspot sources to be included :-). But I did expect src.zip to contain all, or very nearly all, of the core JDK runtime sources. > The only thing about src.zip that is interesting to modules is whether > to change the layout so that the contents are organized by module. We > have been shy about changing it, mostly because it's not clear what > might be depending on it. I agree this is not really a module system issue which is why I posted to build-dev. I also posted to the Jigsaw dev list because it seemed to relate to the re-organization which resulted from introduction of the module system and thought you might be able to short-circuit the enquiry. Anyway, I'm quite happy so long as Red Hat can produce releases which allow the full core JDK runtime to be debugged from a Java debugger. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Fri Jul 29 11:23:18 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Jul 2016 12:23:18 +0100 Subject: Missing sources stepping through Jigsaw code? In-Reply-To: <579B35E2.9070807@redhat.com> References: <579A39B9.1090607@redhat.com> <8cd0de20-46ac-61cd-9f2f-4ce9b3d3dfc7@oracle.com> <579B254C.2040206@redhat.com> <579B35E2.9070807@redhat.com> Message-ID: <67cf2ecb-d00b-c286-bb81-846114313937@oracle.com> On 29/07/2016 11:54, Andrew Dinn wrote: > : > Well, that's very interesting but it wasn't this code that was missing, > rather a significant swathe of the core JDK runtime classes. From what I can tell then src.zip, going back to JDK 1.1 at least, didn't ever include all .java sources. Aside from a few exceptions, the sun.* classes were never included. We haven't changed anything in this project, I don't think anything has changed in JDK 9 either. When someone builds from the OpenJDK sources then there isn't any filtering, at least not with JDK 8 or JDK 9. -Alan From volker.simonis at gmail.com Fri Jul 29 17:40:13 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 29 Jul 2016 19:40:13 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: <6f3a6c94-b9ba-4e7e-b36a-9331b2625c97@default> References: <6f3a6c94-b9ba-4e7e-b36a-9331b2625c97@default> Message-ID: On Thu, Jul 28, 2016 at 9:17 AM, Iris Clark wrote: > Hi, Volker. > > Thanks for your patience. > > I think that the solution that you've provided solves the immediate problem, the java.specification.version number is incorrectly set to be identical to java.version. The java.{vm.}?specification.version system properties should be independent of java.version and are determined by the JCP (either a JSR or an Maintenance Release). If there's ever an MR against JSR 379 (Java SE 9 Release Contents) the value may need to be updated to something besides $MAJOR. > > Let's go with what you've got now. Before you commit, I recommend that you update the title of 8149519 to describe either the problem or the solution. Something like "Set java.specification.version to $MAJOR" would be appropriate. > Done. I've only left out the '$' as this my cause trouble on the command line. > I've filled the following two follow-on bugs: > > 8162686 is a Java SE 9 spec bug against myself to update the spec of java.{vm.}?specification.version system properties as described above. I'll also modify the Verona JEP to adjust the syntax of these system properties. > > I've also filed build bug (8162687) referencing 8145919 and 8162686. I suppose you wanted to refer to "java.vm.specification.version" in "8162687: ava.specification.version is always set to $MAJOR at build time" because "java.vm.specification.version" is actually being set in the code snippet you reference in the bug. Also, this is done at run-time, during HotSpot initialization and not at build time. Finally, I think this is more of a HotSpot issue and not a build issue. So I've changed the bug accordingly. If you think I've misunderstood something, please feel free to change it back. > > Regards, > Iris > > For the build team's bug, I'll reference 8145919 and the spec bug. I suspect that they won't feel compelled to fix it for 9, but I leave it to them to determine how to best handle the issue. I think it would be reasonable for them to decline to add complexity to the build without any current need for such a feature. See above. I think this is something the HotSpot team should care about because they should know which specification version their VM implements. Regards, Volker > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Tuesday, July 26, 2016 5:20 AM > To: build-dev > Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version > > Forwarding to build-dev in the hope to get a review there :) More details can be found in the bug description. > > Thank you and best regards, > Volker > > > ---------- Forwarded message ---------- > From: Volker Simonis > Date: Mon, Apr 4, 2016 at 6:47 PM > Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version > To: Java Core Libs > Cc: verona-dev at openjdk.java.net > > > Hi, > > can I please have a review for this small fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 > https://bugs.openjdk.java.net/browse/JDK-8149519 > > Currently the value of the java.specification.version property comes from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is currently set to VERSION_NUMBER which is the same value which is also used for the java.version property. > > This is a bad idea, because VERSION_NUMBER is a dot separated sequence of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. > for every build and/or update version). If we are configuring with "--with-version-patch=1" for example, VERSION_NUMBER and java.version will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION and java.specification.version have the same, dotted value. And it breaks a lot of legacy applications which parse java.specification.version as a float number. That code would still work if java.specification.version would be a concrete number (e.g. > '9' or '10'). > > I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in common/autoconf/spec.gmk.in. This should be the "right value" until we get a specification change during a major release which hasn't happened for quite some time now. > > Regards, > Volker From volker.simonis at gmail.com Fri Jul 29 17:42:12 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 29 Jul 2016 19:42:12 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: Hi Magnus, thanks for the background information! It's always the smallest issues which take the most time and the longest discussions. I'm just happy that we have no line-endings in the version string :) Regards, Volker On Thu, Jul 28, 2016 at 11:30 PM, Magnus Ihse Bursie wrote: > Some background on this: > > I initially introduced VERSION_SPECIFICATION as VERSION_MAJOR but had to revert it in the Verona branch since I was told that the specification number should be identical to the release version. My initial reaction was the same as yours, that the specification would match only the major part. > > I see now that Iris support this change, so I hope the old rationale for having the specification in lockstep with the release is no longer valid. > > /Magnus > >> 26 juli 2016 kl. 14:26 skrev Alan Bateman : >> >> This looks right but I'm curious why it was initially implemented to use VERSION_NUMBER. >> >> -Alan >> >> >>> On 26/07/2016 13:20, Volker Simonis wrote: >>> >>> Forwarding to build-dev in the hope to get a review there :) >>> More details can be found in the bug description. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> ---------- Forwarded message ---------- >>> From: Volker Simonis >>> Date: Mon, Apr 4, 2016 at 6:47 PM >>> Subject: RFR(XXS): 8149519: Investigate implementation of >>> java.specification.version >>> To: Java Core Libs >>> Cc: verona-dev at openjdk.java.net >>> >>> >>> Hi, >>> >>> can I please have a review for this small fix: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 >>> https://bugs.openjdk.java.net/browse/JDK-8149519 >>> >>> Currently the value of the java.specification.version property comes >>> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is >>> currently set to VERSION_NUMBER which is the same value which is also >>> used for the java.version property. >>> >>> This is a bad idea, because VERSION_NUMBER is a dot separated sequence >>> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. >>> for every build and/or update version). If we are configuring with >>> "--with-version-patch=1" for example, VERSION_NUMBER and java.version >>> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION >>> and java.specification.version have the same, dotted value. And it >>> breaks a lot of legacy applications which parse >>> java.specification.version as a float number. That code would still >>> work if java.specification.version would be a concrete number (e.g. >>> '9' or '10'). >>> >>> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in >>> common/autoconf/spec.gmk.in. This should be the "right value" until we >>> get a specification change during a major release which hasn't >>> happened for quite some time now. >>> >>> Regards, >>> Volker >> From volker.simonis at gmail.com Fri Jul 29 17:42:50 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 29 Jul 2016 19:42:50 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: Thanks, David! On Wed, Jul 27, 2016 at 4:22 AM, David Holmes wrote: > +1 from me. Does the Verona JEP say anything about this? I certainly do not > expect the specification version number of differ from the major release > number. > > David > > > On 26/07/2016 10:26 PM, Alan Bateman wrote: >> >> This looks right but I'm curious why it was initially implemented to use >> VERSION_NUMBER. >> >> -Alan >> >> >> On 26/07/2016 13:20, Volker Simonis wrote: >> >>> Forwarding to build-dev in the hope to get a review there :) >>> More details can be found in the bug description. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> ---------- Forwarded message ---------- >>> From: Volker Simonis >>> Date: Mon, Apr 4, 2016 at 6:47 PM >>> Subject: RFR(XXS): 8149519: Investigate implementation of >>> java.specification.version >>> To: Java Core Libs >>> Cc: verona-dev at openjdk.java.net >>> >>> >>> Hi, >>> >>> can I please have a review for this small fix: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 >>> https://bugs.openjdk.java.net/browse/JDK-8149519 >>> >>> Currently the value of the java.specification.version property comes >>> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is >>> currently set to VERSION_NUMBER which is the same value which is also >>> used for the java.version property. >>> >>> This is a bad idea, because VERSION_NUMBER is a dot separated sequence >>> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. >>> for every build and/or update version). If we are configuring with >>> "--with-version-patch=1" for example, VERSION_NUMBER and java.version >>> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION >>> and java.specification.version have the same, dotted value. And it >>> breaks a lot of legacy applications which parse >>> java.specification.version as a float number. That code would still >>> work if java.specification.version would be a concrete number (e.g. >>> '9' or '10'). >>> >>> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in >>> common/autoconf/spec.gmk.in. This should be the "right value" until we >>> get a specification change during a major release which hasn't >>> happened for quite some time now. >>> >>> Regards, >>> Volker >> >> > From iris.clark at oracle.com Fri Jul 29 17:57:33 2016 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 29 Jul 2016 10:57:33 -0700 (PDT) Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: <6f3a6c94-b9ba-4e7e-b36a-9331b2625c97@default> Message-ID: <971503bb-0148-462c-924e-186f8603b485@default> Hi, Volker. >> I've also filed build bug (8162687) referencing 8145919 and 8162686. > I suppose you wanted to refer to "java.vm.specification.version" in "8162687: ava.specification.version is always set to $MAJOR at build time" because "java.vm.specification.version" is actually being set in the code snippet you reference in the bug. Also, this is done at run-time, during HotSpot initialization and not at build time. > Finally, I think this is more of a HotSpot issue and not a build issue. > > So I've changed the bug accordingly. If you think I've misunderstood something, please feel free to change it back. The change needs to occur for both java.specification.version and java.vm.specification.version. I suspect that the VM code will depend on how the build change is made, as I've modified the bug to more clearly indicate this and moved it back to build because it's possible that the VM code may set their value from the build implementation. The build team may choose to file a separate bug to handle the VM issue, but ideally they should be handled at the same time. thanks, iris From samuelmarks at gmail.com Sat Jul 30 10:17:06 2016 From: samuelmarks at gmail.com (Samuel Marks) Date: Sat, 30 Jul 2016 20:17:06 +1000 Subject: kulla fails to configure with Java 9 ea (Early Access) In-Reply-To: References: Message-ID: Hmm, I could only find the one branch: http://hg.openjdk.java.net/kulla/dev/branches This is the file I edited: http://hg.openjdk.java.net/kulla/dev/file/77a1e3986f77/common/autoconf/boot-jdk.m4 Samuel Marks http://linkedin.com/in/samuelmarks On Fri, Jul 29, 2016 at 6:12 PM, ShinyaYoshida wrote: > Hi Samuel, thank you for resending. > > Oops, let me confirm one thing please. > You got this error on a repository hosted on kulla-dev, right? > > If so, unfortunately it isn't under maintaining because it already merged > to jdk9-dev. > Please confirm that you still get this error on jdk9-dev and your patch > works well on it. > > Regards, > shinyafox(Shinya Yoshida) > > 2016/07/29 ??4:55 "Samuel Marks" : > > Error: >> configure: Found potential Boot JDK using configure arguments >> configure: Potential Boot JDK found at /opt/Java/jdk-9 is incorrect JDK >> version (java version "9-ea"); ignoring >> configure: (Your Boot JDK must be version 8 or 9) >> configure: error: The path given by --with-boot-jdk does not contain a >> valid Boot JDK >> >> Here's a fix to the kulla repository (also attached, not sure what the >> protocol is): >> >> # HG changeset patch >> # User Samuel Marks >> # Date 1469777474 -36000 >> # Fri Jul 29 17:31:14 2016 +1000 >> # Node ID 9268348574206a8487901c8e8a1ea15987709521 >> # Parent 77a1e3986f77f6e9d1037f4de8296d927ef12ac4 >> New version check routine to handle Java 9 Early Access release >> >> diff -r 77a1e3986f77 -r 926834857420 common/autoconf/boot-jdk.m4 >> --- a/common/autoconf/boot-jdk.m4 Sat Aug 22 00:47:29 2015 -0700 >> +++ b/common/autoconf/boot-jdk.m4 Fri Jul 29 17:31:14 2016 +1000 >> @@ -74,11 +74,12 @@ >> BOOT_JDK_FOUND=no >> else >> # Oh, this is looking good! We probably have found a proper >> JDK. >> Is it the correct version? >> - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | head -n >> 1` >> + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | awk >> '/version/{print $NF}'` >> + BOOT_JDK_VERSION="${BOOT_JDK_VERSION:1:3}" >> + CORRECT_VERSIONS=(1.8 1.9 9 9-e) >> >> # Extra M4 quote needed to protect [] in grep expression. >> - [FOUND_CORRECT_VERSION=`echo $BOOT_JDK_VERSION | grep >> '\"1\.[89]\.'`] >> - if test "x$FOUND_CORRECT_VERSION" = x; then >> + if [[ ! " ${CORRECT_VERSIONS[*]} " == *" $BOOT_JDK_VERSION "* >> ]]; then >> AC_MSG_NOTICE([Potential Boot JDK found at $BOOT_JDK is >> incorrect JDK version ($BOOT_JDK_VERSION); ignoring]) >> AC_MSG_NOTICE([(Your Boot JDK must be version 8 or 9)]) >> BOOT_JDK_FOUND=no >> >> Samuel Marks >> http://linkedin.com/in/samuelmarks >> >> BTW: I posted in kulla-dev but they told me to post here - >> http://mail.openjdk.java.net/pipermail/kulla-dev/2016-July/001508.html >> >