From david.holmes at oracle.com Mon Jun 2 03:02:04 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Jun 2014 13:02:04 +1000 Subject: 8043753: Drop javax.transaction from compact2 In-Reply-To: <53887993.5000502@oracle.com> References: <53887993.5000502@oracle.com> Message-ID: <538BE92C.4030707@oracle.com> Hi Alan, This change looks okay to me. But the bug synopsis and description should clarify that it drops javax.transaction from compact2 and compact3, as you are moving it to the full JRE. Thanks, David On 30/05/2014 10:29 PM, Alan Bateman wrote: > > This is a proposed change to the set of API packages in the compact2 and > compact3 Profiles that we defined in Java SE 8 / JDK 8. > > The background to this is that compact2 includes the subset of the Java > Transaction API (JTA) that Java SE defines. JTA isn't usually > interesting for small devices but JDBC is and the JBDC API has API > dependencies on a number of XA types defined in javax.transaction.xa. > We've been looking at this again in the context of of moving to a truly > modular JDK. For a modular JDK it would be highly desirable to have a > JDBC module that has as few transitively dependencies as possible. The > problem with a dependence on JTA is that the 3 exceptions in > javax.transaction are RemoteException types and are only useful for > RMI-IIOP. So we'd like to split these so that javax.transaction can live > closer to CORBA and have javax.transaction.xa be closer to JDBC. In > order to get there then compact2 (and thus compact3) will need to > change. The compatibility impact of this is close is very low as it is > highly unlikely that applications running on embedded systems would be > making use of these 3 exceptions. > > The build changes are simple, it just changes > PROFILE_2_RTJAR_INCLUDE_PACKAGES to include the xa package and then > updates FULL_JRE_RTJAR_INCLUDE_TYPES to ensure that javax.transaction is > included in the full JRE/JDK builds. > > Thanks, > > -Alan. > > > diff --git a/make/profile-rtjar-includes.txt > b/make/profile-rtjar-includes.txt > --- a/make/profile-rtjar-includes.txt > +++ b/make/profile-rtjar-includes.txt > @@ -88,7 +88,7 @@ > java/sql \ > javax/rmi/ssl \ > javax/sql \ > - javax/transaction \ > + javax/transaction/xa \ > javax/xml \ > org/w3c \ > org/xml/sax \ > @@ -223,7 +223,8 @@ > javax/management/remote/rmi/_RMIConnection_Stub.class \ > javax/management/remote/rmi/_RMIServerImpl_Tie.class \ > javax/management/remote/rmi/_RMIServer_Stub.class \ > - javax/rmi/*.class > + javax/rmi/*.class \ > + javax/transaction/*.class > > FULL_JRE_RTJAR_EXCLUDE_TYPES := > > From Alan.Bateman at oracle.com Mon Jun 2 08:02:51 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 02 Jun 2014 09:02:51 +0100 Subject: 8043753: Drop javax.transaction from compact2 In-Reply-To: <538BE92C.4030707@oracle.com> References: <53887993.5000502@oracle.com> <538BE92C.4030707@oracle.com> Message-ID: <538C2FAB.8060702@oracle.com> On 02/06/2014 04:02, David Holmes wrote: > Hi Alan, > > This change looks okay to me. > > But the bug synopsis and description should clarify that it drops > javax.transaction from compact2 and compact3, as you are moving it to > the full JRE. > Thanks. I'll change the synopsis to "Drop javax.transaction from compact2 and compact3" to make it clearer. The full JRE is not impacted by this change. -Alan. From erik.joelsson at oracle.com Mon Jun 2 09:08:19 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 02 Jun 2014 11:08:19 +0200 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> Message-ID: <538C3F03.7020207@oracle.com> Hello David, Looks pretty good. A couple of questions still: * Where is the AC_SUBST for SDKROOT? * Could we get the "Checking for Xcode sdk name" output to only print on macosx? * Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still use this in some closed makefiles. Or is the idea that we instead will force the sdk name to 10.7? If so, then we need to still leave this in until every user (RE) has switched properly. /Erik On 2014-05-30 16:49, David DeHaven wrote: >> Here's the latest patch set: >> http://cr.openjdk.java.net/~ddehaven/8043340/v2/ > Just FYI, I ran a build only job on JPRT and it passed: > Build Stats: 14 pass, 0 fail, 0 killed, 0 working, 0 initializing, 0 not started > > -DrD- > From erik.joelsson at oracle.com Mon Jun 2 11:58:34 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 02 Jun 2014 13:58:34 +0200 Subject: RFR: JDK-8043160: JDK 9 Build failure in accessbridge In-Reply-To: <537F238E.8070802@oracle.com> References: <537F238E.8070802@oracle.com> Message-ID: <538C66EA.5080708@oracle.com> A friendly reminder that this still needs to be reviewed. /Erik On 2014-05-23 12:31, Erik Joelsson wrote: > Hello, > > This patch attempts to fix a build problem in accessbridge. Two > compile jobs are both trying to create the same header file. The fix > is to separate the output directories of these jobs so that they do > not interfere with each other. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8043160 > Webrev: http://cr.openjdk.java.net/~erikj/8043160/webrev.jdk.01/ > > /Erik From erik.joelsson at oracle.com Mon Jun 2 12:54:55 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 02 Jun 2014 14:54:55 +0200 Subject: RFR: JDK-8044480: JDK image target overwrites lib/server/libjsig.dylib symlink with a copy of lib/libjsig.dylib Message-ID: <538C741F.90107@oracle.com> Hello, Please review this small fix to images/bundle build on Macosx. In the macosx specific j2*-bundle, lib/server/libjsig.dylib is not a symlink to ../libjsig.dylib like on other platforms (or like in j2*-image). This behavior dates back to the original macosx port and was intentionally emulated in the new build in JDK 8. Bug: https://bugs.openjdk.java.net/browse/JDK-8044480 The fix in JDK 9 inline: diff --git a/make/Bundles.gmk b/make/Bundles.gmk --- a/make/Bundles.gmk +++ b/make/Bundles.gmk @@ -74,19 +74,16 @@ JDK_TARGET_LIST := $(subst $(JDK_IMAGE_DIR)/,$(JDK_BUNDLE_DIR)/Home/,$(JDK_FILE_LIST)) JRE_TARGET_LIST := $(subst $(JRE_IMAGE_DIR)/,$(JRE_BUNDLE_DIR)/Home/,$(JRE_FILE_LIST)) - # The old builds implementation of this did not preserve symlinks so - # make sure they are followed and the contents copied instead. - # To fix this, remove -L # Copy empty directories (jre/lib/applet). $(JDK_BUNDLE_DIR)/Home/%: $(JDK_IMAGE_DIR)/% $(ECHO) Copying $(patsubst $(OUTPUT_ROOT)/%,%,$@) $(MKDIR) -p $(@D) - if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -L '$<' '$@'; fi + if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -P '$<' '$@'; fi $(JRE_BUNDLE_DIR)/Home/%: $(JRE_IMAGE_DIR)/% $(ECHO) Copying $(patsubst $(OUTPUT_ROOT)/%,%,$@) $(MKDIR) -p $(@D) - if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -L '$<' '$@'; fi + if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -P '$<' '$@'; fi $(JDK_BUNDLE_DIR)/MacOS/libjli.dylib: $(ECHO) Creating link $(patsubst $(OUTPUT_ROOT)/%,%,$@) /Erik From daniel.daugherty at oracle.com Mon Jun 2 13:02:38 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 02 Jun 2014 07:02:38 -0600 Subject: RFR: JDK-8044480: JDK image target overwrites lib/server/libjsig.dylib symlink with a copy of lib/libjsig.dylib In-Reply-To: <538C741F.90107@oracle.com> References: <538C741F.90107@oracle.com> Message-ID: <538C75EE.4080205@oracle.com> Erik, Thanks for the very fast turn around on this. I could not think of a good way to test this for unexpected side effects other than to make the change and watch for fallout. I was not able to envision a scenario where replacing a regular file with a symlink to a copy of the same file would be functionally different. Thumbs up. Dan P.S. Ron is on vacation this week so please don't wait for a code review from him. On 6/2/14 6:54 AM, Erik Joelsson wrote: > Hello, > > Please review this small fix to images/bundle build on Macosx. In the > macosx specific j2*-bundle, lib/server/libjsig.dylib is not a symlink > to ../libjsig.dylib like on other platforms (or like in j2*-image). > This behavior dates back to the original macosx port and was > intentionally emulated in the new build in JDK 8. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044480 > The fix in JDK 9 inline: > > diff --git a/make/Bundles.gmk b/make/Bundles.gmk > --- a/make/Bundles.gmk > +++ b/make/Bundles.gmk > @@ -74,19 +74,16 @@ > JDK_TARGET_LIST := $(subst > $(JDK_IMAGE_DIR)/,$(JDK_BUNDLE_DIR)/Home/,$(JDK_FILE_LIST)) > JRE_TARGET_LIST := $(subst > $(JRE_IMAGE_DIR)/,$(JRE_BUNDLE_DIR)/Home/,$(JRE_FILE_LIST)) > > - # The old builds implementation of this did not preserve symlinks so > - # make sure they are followed and the contents copied instead. > - # To fix this, remove -L > # Copy empty directories (jre/lib/applet). > $(JDK_BUNDLE_DIR)/Home/%: $(JDK_IMAGE_DIR)/% > $(ECHO) Copying $(patsubst $(OUTPUT_ROOT)/%,%,$@) > $(MKDIR) -p $(@D) > - if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -L '$<' > '$@'; fi > + if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -P '$<' > '$@'; fi > > $(JRE_BUNDLE_DIR)/Home/%: $(JRE_IMAGE_DIR)/% > $(ECHO) Copying $(patsubst $(OUTPUT_ROOT)/%,%,$@) > $(MKDIR) -p $(@D) > - if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -L '$<' > '$@'; fi > + if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -P '$<' > '$@'; fi > > $(JDK_BUNDLE_DIR)/MacOS/libjli.dylib: > $(ECHO) Creating link $(patsubst $(OUTPUT_ROOT)/%,%,$@) > > > /Erik From erik.joelsson at oracle.com Mon Jun 2 14:09:04 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 02 Jun 2014 16:09:04 +0200 Subject: OpenJDK 8 compact profiles fail to build with make 4.0 In-Reply-To: <5389DA93.4080705@apache.org> References: <5389DA93.4080705@apache.org> Message-ID: <538C8580.8060102@oracle.com> Hello Emmanuel, I remember that piece of make logic being especially tricky to get working and it seems the weirdness in make has been fixed in make 4.0, or at least changed. Our dealing with escaping dollars is rather messy in JDK 8. I have recently worked on this in a JDK 9 project, where I have chosen a different approach that seems to work with both 3.8x and 4.0. The idea is based on defining this macro in make/common/MakeBase.gmk: ################################################################################ # This macro translates $ into \$ to protect the $ from expansion in the shell. # To make this macro resilient against already escaped strings, first remove # any present escapes before escaping so that no double escapes are added. EscapeDollar = $(subst $$,\$$,$(subst \$$,$$,$(strip $1))) And then instead of escaping dollars explicitly in make variable declarations, just call that macro before giving anything containing dollars to the shell. --- a/make/CreateJars.gmk +++ b/make/CreateJars.gmk @@ -302,17 +302,15 @@ # methods from classes that only go into the profile builds. BEANLESS_CLASSES = $(IMAGES_OUTPUTDIR)/beanless -# When there are $ characters in filenames we have some very subtle interactions between -# make expansion and shell expansion. In this particular case $< will contain a single $ while -# $@ will contain \$. So we have to pass $< in single-quotes to avoid shell expansion $(BEANLESS_CLASSES)/%: $(JDK_OUTPUTDIR)/classes/% $(MKDIR) -p $(@D) - $(TOOL_REMOVEMETHODS) '$<' $@ addPropertyChangeListener removePropertyChangeListener + $(TOOL_REMOVEMETHODS) $(call EscapeDollar, $<) $(call EscapeDollar, $@) \ + addPropertyChangeListener removePropertyChangeListener CLASSES_TO_DEBEAN = \ java/util/logging/LogManager.class \ - java/util/jar/Pack200\$$Packer.class \ - java/util/jar/Pack200\$$Unpacker.class \ + java/util/jar/Pack200$$Packer.class \ + java/util/jar/Pack200$$Unpacker.class \ com/sun/java/util/jar/pack/PackerImpl.class \ com/sun/java/util/jar/pack/UnpackerImpl.class @@ -345,7 +343,7 @@ $(CD) $(patsubst %$(VERSION_CLASS_PATH), %, $(CLASS_FILE)) && \ $(JAR) $(RT_JAR_UPDATE_OPTIONS) $@.tmp $(VERSION_CLASS_PATH); \ $(CD) $(BEANLESS_CLASSES) && \ - $(JAR) $(RT_JAR_UPDATE_OPTIONS) $@.tmp $(CLASSES_TO_DEBEAN); \ + $(JAR) $(RT_JAR_UPDATE_OPTIONS) $@.tmp $(call EscapeDollar, $(CLASSES_TO_DEBEAN)); \ fi $(MV) $@.tmp $@ The patch above works for me at least. /Erik On 2014-05-31 15:35, Emmanuel Bourg wrote: > Hi, > > I'd like to report an issue with the build for the OpenJDK 8 compact > profiles. On Debian the build fails when PropertyChangeListener is > removed from the pack200 classes: > > ## Starting profiles > /usr/bin/find: `/home/ebourg/jdk8u-dev/build/images/lib': No such file > or directory > make[2]: *** No rule to make target > '/home/ebourg/jdk8u-dev/build/images/beanless/java/util/jar/Pack200\$Packer.class', > needed by '/home/ebourg/jdk8u-dev/build/images/libprofile_1/rt.jar'. Stop. > make[2]: *** Waiting for unfinished jobs.... > Removed method > addPropertyChangeListener(java.beans.PropertyChangeListener) from > java/util/logging/LogManager > Removed method > removePropertyChangeListener(java.beans.PropertyChangeListener) from > java/util/logging/LogManager > BuildJdk.gmk:113: recipe for target 'profile_1' failed > make[1]: *** [profile_1] Error 2 > /home/ebourg/jdk8u-dev//make/Main.gmk:147: recipe for target > 'profiles-only' failed > make: *** [profiles-only] Error 2 > > > The same issue was reported last year on Arch Linux: > > http://mail.openjdk.java.net/pipermail/build-dev/2013-July/009557.html > > It looks like this error is caused by GNU Make 4.0 which is now the > default in Debian. I was able to build the compact profiles after > downgrading make to the version 3.81. > > OpenJDK 9 isn't affected by this issue because the > add/removePropertyChangeListener() methods are already removed. > > Make 4.0 caused another regression (JDK-8028407) which has been fixed > for OpenJDK 9. Could you also consider backporting it to OpenJDK 8 please? > > Thank you, > > Emmanuel Bourg From ebourg at apache.org Mon Jun 2 15:37:23 2014 From: ebourg at apache.org (Emmanuel Bourg) Date: Mon, 02 Jun 2014 17:37:23 +0200 Subject: OpenJDK 8 compact profiles fail to build with make 4.0 In-Reply-To: <538C8580.8060102@oracle.com> References: <5389DA93.4080705@apache.org> <538C8580.8060102@oracle.com> Message-ID: <538C9A33.6090405@apache.org> Le 02/06/2014 16:09, Erik Joelsson a ?crit : > The patch above works for me at least. Hi Eric, Thank you very much for the patch, I confirm it works on Debian. I was starting to lose my sanity with this dollar expansion stuff. Emmanuel Bourg From tim.bell at oracle.com Mon Jun 2 16:17:33 2014 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 02 Jun 2014 16:17:33 +0000 Subject: RFR: JDK-8043160: JDK 9 Build failure in accessbridge In-Reply-To: <538C66EA.5080708@oracle.com> References: <537F238E.8070802@oracle.com> <538C66EA.5080708@oracle.com> Message-ID: <538CA39D.2000004@oracle.com> Hi Erik: Looks good to me. Tim > A friendly reminder that this still needs to be reviewed. > > /Erik > > On 2014-05-23 12:31, Erik Joelsson wrote: >> Hello, >> >> This patch attempts to fix a build problem in accessbridge. Two >> compile jobs are both trying to create the same header file. The fix >> is to separate the output directories of these jobs so that they do >> not interfere with each other. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8043160 >> Webrev: http://cr.openjdk.java.net/~erikj/8043160/webrev.jdk.01/ >> >> /Erik > From david.dehaven at oracle.com Mon Jun 2 16:23:41 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 2 Jun 2014 09:23:41 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <538C3F03.7020207@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> Message-ID: > Hello David, > > Looks pretty good. A couple of questions still: > > * Where is the AC_SUBST for SDKROOT? Oops, that should've been after SDKROOT="$SYSROOT" in basics.m4. > * Could we get the "Checking for Xcode sdk name" output to only print on macosx? Can do. > * Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still use this in some closed makefiles. Or is the idea that we instead will force the sdk name to 10.7? If so, then we need to still leave this in until every user (RE) has switched properly. I moved all that to closed, it's in the internal review for those changes. The value is now set in custom-spec.gmk instead of spec.gmk. It was not used anywhere in OpenJDK that I could find. When deploy/install get revamped we can just remove it entirely, that'll be easier if it's in closed. It's referenced in make/bsd/makefiles/gcc.make, but that entire block is skipped if spec.gmk exists (confirmed by throwing garbage in there), and it defaults to 10.7.0 anyways. I have to do another iteration based on what Max found when only the command line tools are installed (no Xcode). Thankfully, it won't be too difficult to determine if Xcode is installed or not. The logic won't be terribly different. Basically XCODEBUILD might not be usable since if Xcode is not installed we will not be able to use it. The stub xcodebuild tool is installed with the OS and I can actually use the return code to detect if Xcode is present or not. Additionally, SYSROOT/SDKROOT will not be set as the CL tools install headers to the System frameworks directories. There are no SDKs installed so there is no other place to put them. -DrD- From tim.bell at oracle.com Mon Jun 2 16:28:53 2014 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 02 Jun 2014 16:28:53 +0000 Subject: RFR: JDK-8044480: JDK image target overwrites lib/server/libjsig.dylib symlink with a copy of lib/libjsig.dylib In-Reply-To: <538C75EE.4080205@oracle.com> References: <538C741F.90107@oracle.com> <538C75EE.4080205@oracle.com> Message-ID: <538CA645.6060508@oracle.com> Erik: Looks good to me as well. Tim On 06/02/14 13:02, Daniel D. Daugherty wrote: > Erik, > > Thanks for the very fast turn around on this. > > I could not think of a good way to test this for unexpected side > effects other than to make the change and watch for fallout. I was > not able to envision a scenario where replacing a regular file > with a symlink to a copy of the same file would be functionally > different. > > Thumbs up. > > Dan > > P.S. > Ron is on vacation this week so please don't wait for a code > review from him. > > > On 6/2/14 6:54 AM, Erik Joelsson wrote: >> Hello, >> >> Please review this small fix to images/bundle build on Macosx. In the >> macosx specific j2*-bundle, lib/server/libjsig.dylib is not a symlink >> to ../libjsig.dylib like on other platforms (or like in j2*-image). >> This behavior dates back to the original macosx port and was >> intentionally emulated in the new build in JDK 8. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8044480 >> The fix in JDK 9 inline: >> >> diff --git a/make/Bundles.gmk b/make/Bundles.gmk >> --- a/make/Bundles.gmk >> +++ b/make/Bundles.gmk >> @@ -74,19 +74,16 @@ >> JDK_TARGET_LIST := $(subst >> $(JDK_IMAGE_DIR)/,$(JDK_BUNDLE_DIR)/Home/,$(JDK_FILE_LIST)) >> JRE_TARGET_LIST := $(subst >> $(JRE_IMAGE_DIR)/,$(JRE_BUNDLE_DIR)/Home/,$(JRE_FILE_LIST)) >> >> - # The old builds implementation of this did not preserve symlinks so >> - # make sure they are followed and the contents copied instead. >> - # To fix this, remove -L >> # Copy empty directories (jre/lib/applet). >> $(JDK_BUNDLE_DIR)/Home/%: $(JDK_IMAGE_DIR)/% >> $(ECHO) Copying $(patsubst $(OUTPUT_ROOT)/%,%,$@) >> $(MKDIR) -p $(@D) >> - if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -L '$<' >> '$@'; fi >> + if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -P '$<' >> '$@'; fi >> >> $(JRE_BUNDLE_DIR)/Home/%: $(JRE_IMAGE_DIR)/% >> $(ECHO) Copying $(patsubst $(OUTPUT_ROOT)/%,%,$@) >> $(MKDIR) -p $(@D) >> - if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -L '$<' >> '$@'; fi >> + if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -P '$<' >> '$@'; fi >> >> $(JDK_BUNDLE_DIR)/MacOS/libjli.dylib: >> $(ECHO) Creating link $(patsubst $(OUTPUT_ROOT)/%,%,$@) >> >> >> /Erik > From mike.duigou at oracle.com Mon Jun 2 17:05:28 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 2 Jun 2014 10:05:28 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> Message-ID: <7F8690D6-9828-4722-9077-4B9E2326AE7C@oracle.com> On Jun 2 2014, at 09:23 , David DeHaven wrote: > * Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still use this in some closed makefiles. Or is the idea that we instead will force the sdk name to 10.7? If so, then we need to still leave this in until every user (RE) has switched properly. > > I moved all that to closed, it's in the internal review for those changes. The value is now set in custom-spec.gmk instead of spec.gmk. It was not used anywhere in OpenJDK that I could find. When deploy/install get revamped we can just remove it entirely, that'll be easier if it's in closed. > > It's referenced in make/bsd/makefiles/gcc.make, but that entire block is skipped if spec.gmk exists (confirmed by throwing garbage in there), and it defaults to 10.7.0 anyways. Many/most/some (?) Hotspot devs still typically build without configure so there is no spec.gmk for them. Mike From david.dehaven at oracle.com Mon Jun 2 17:21:12 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 2 Jun 2014 10:21:12 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <7F8690D6-9828-4722-9077-4B9E2326AE7C@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <7F8690D6-9828-4722-9077-4B9E2326AE7C@oracle.co! m> Message-ID: >> * Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still use this in some closed makefiles. Or is the idea that we instead will force the sdk name to 10.7? If so, then we need to still leave this in until every user (RE) has switched properly. >> >> I moved all that to closed, it's in the internal review for those changes. The value is now set in custom-spec.gmk instead of spec.gmk. It was not used anywhere in OpenJDK that I could find. When deploy/install get revamped we can just remove it entirely, that'll be easier if it's in closed. >> >> It's referenced in make/bsd/makefiles/gcc.make, but that entire block is skipped if spec.gmk exists (confirmed by throwing garbage in there), and it defaults to 10.7.0 anyways. > > Many/most/some (?) Hotspot devs still typically build without configure so there is no spec.gmk for them. So they weren't even using it, since MACOSX_VERSION_MIN was defined in spec.gmk. -DrD- From philip.race at oracle.com Mon Jun 2 17:38:06 2014 From: philip.race at oracle.com (Phil Race) Date: Mon, 02 Jun 2014 10:38:06 -0700 Subject: RFR: JDK-8043160: JDK 9 Build failure in accessbridge In-Reply-To: <538C66EA.5080708@oracle.com> References: <537F238E.8070802@oracle.com> <538C66EA.5080708@oracle.com> Message-ID: <538CB67E.6010809@oracle.com> Looks good to me. This has been a constant pain so I am very happy to see it fixed -phil. On 6/2/2014 4:58 AM, Erik Joelsson wrote: > A friendly reminder that this still needs to be reviewed. > > /Erik > > On 2014-05-23 12:31, Erik Joelsson wrote: >> Hello, >> >> This patch attempts to fix a build problem in accessbridge. Two >> compile jobs are both trying to create the same header file. The fix >> is to separate the output directories of these jobs so that they do >> not interfere with each other. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8043160 >> Webrev: http://cr.openjdk.java.net/~erikj/8043160/webrev.jdk.01/ >> >> /Erik > From david.dehaven at oracle.com Mon Jun 2 21:27:47 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 2 Jun 2014 14:27:47 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <538C3F03.7020207@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> Message-ID: <4BF27092-B09D-4473-84AA-AEFB74320F5D@oracle.com> > Looks pretty good. A couple of questions still: > > * Where is the AC_SUBST for SDKROOT? > > * Could we get the "Checking for Xcode sdk name" output to only print on macosx? Would this be OK instead? AC_MSG_CHECKING([for sdk name]) AC_MSG_RESULT([$SDKNAME]) Otherwise it might make sense to just move the whole arg into the macosx block too. -DrD- From tim.bell at oracle.com Tue Jun 3 01:01:32 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 03 Jun 2014 01:01:32 +0000 Subject: HSAIL unit tests fail when Okra library fails to load In-Reply-To: <5DA3C5F9-66BC-40A1-8FEE-0B57A6B061FC@oracle.com> References: <1EDCCD92-B001-4506-8C88-A8A46F67F677@oracle.com> <537E69FE.4020402@amd.com> <2B05CBCB-9C09-4C8B-95A9-4BEAFFC2CC8B@oracle.com> <06A794E4-AAAF-4BD4-8C7C-74F3CAA8ED12@oracle.com> <5DA3C5F9-66BC-40A1-8FEE-0B57A6B061FC@oracle.com> Message-ID: <538D1E6C.8080304@oracle.com> Hi - catching up on my email backlog: > Not sure what glibc version that is, though. For Linux builds, others on build-dev at openjdk.java.net are more knowledgeable about glibc used in different JDK releases. Hmmm - these README-builds.html files do not mention a specific glibc version: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/raw-file/tip/README-builds.html http://hg.openjdk.java.net/jdk7u/jdk7u-dev/raw-file/tip/README-builds.html I ran a little test on one of our Fedora 9 build/test systems: uname -a Linux sc11137352 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008 i686 i686 i386 GNU/Linux gcc -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux Thread model: posix gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) cat -n hw.c 1 #include 2 int main() { 3 printf("Hello world\n"); 4 } gcc -o hw hw.c ./hw Hello world ldd ./hw linux-gate.so.1 => (0x00110000) libc.so.6 => /lib/libc.so.6 (0x0080d000) /lib/ld-linux.so.2 (0x007ed000) Hope this helps- Tim On 05/23/14 00:13, Christian Thalinger wrote: > > On May 22, 2014, at 5:04 PM, Doug Simon > wrote: > >> >> On May 23, 2014, at 12:44 AM, Deneau, Tom > > wrote: >> >>> Doug -- >>> >>> What glibc does Hotspot build against? >> >> I?m not sure - Christian may know (or know who knows). > > Looking at some wiki pages JDK 8 is building on: > > Fedora 9 / GCC 4.3 > > Not sure what glibc version that is, though. Tim Bell is the right > guy to ask. > >> >> -Doug >> >>>> -----Original Message----- >>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>> Sent: Thursday, May 22, 2014 5:40 PM >>>> To: Caspole, Eric >>>> Cc: Deneau, Tom; Bernhard Urban >>>> Subject: Re: HSAIL unit tests fail when Okra library fails to load >>>> >>>> >>>> On May 22, 2014, at 11:19 PM, Eric Caspole >>> > wrote: >>>> >>>>> Hi Doug, >>>>> Do you think it is worth it to build the built in Okra simulator with >>>> an older glibc to help avoid this problem? What is the oldest >>>> distro you >>>> intend to support with Graal? >>>> >>>> In theory we should support whatever HotSpot does although in practice >>>> we only need it to work on OSes for which we build distributions. >>>> >>>> However, I think it's fine (for now at least) if we just cleanly >>>> ignore/short-circuit the HSAIL unit tests in question on platforms with >>>> an older glibc. >>>> >>>> -Doug >>>> >>>>> On 05/22/2014 07:33 AM, Doug Simon wrote: >>>>>> Hi Tom, Eric, >>>>>> >>>>>> We're in the process of making GraalVM binary builds that work on >>>> Oracle Linux 6.5 which has an old version of glibc (GLIBC 2.12). While >>>> testing this build, the HSAIL tests that use the Okra library fail >>>> because libokra_x86_64.so is built against a version of GLIBC later >>>> than >>>> 2.12. However, the failure message is very confusing. For example: >>>>>> >>>>>> $ mx --vm server unittest Vec3ObjStreamClassCastTest >>>>>> GraalJUnitCore >>>>>> JUnit version 4.11 >>>>>> .E >>>>>> Time: 0.77 >>>>>> There was 1 failure: >>>>>> 1) >>>> test(com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest) >>>>>> java.lang.NoClassDefFoundError: Could not initialize class >>>> com.amd.okra.OkraContext >>>>>> at >>>> com.oracle.graal.compiler.hsail.test.infra.KernelTester.(KernelTes >>>> ter.java:129) >>>>>> at >>>> com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.(Graa >>>> lKernelTester.java:63) >>>>>> at >>>> com.oracle.graal.compiler.hsail.test.SingleExceptionTestBase.(Sing >>>> leExceptionTestBase.java:32) >>>>>> at >>>> com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest.(V >>>> ec3ObjStreamClassCastTest.java:31) >>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>> Method) >>>>>> at >>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA >>>> ccessorImpl.java:62) >>>>>> at >>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons >>>> tructorAccessorImpl.java:45) >>>>>> at >>>> java.lang.reflect.Constructor.newInstance(Constructor.java:408) >>>>>> at >>>> org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunn >>>> er.java:195) >>>>>> at >>>> org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4 >>>> ClassRunner.java:244) >>>>>> >>>>>> Can you please make sure the HSAIL test harness recognizes a failure >>>> to load the Okra library (preferably issuing a message if it's for any >>>> other reason than the library not being available). One way to trigger >>>> this is to fake a bad library: >>>>>> >>>>>> $ mkdir -p resources/okra/Linux >>>>>> $ echo "bad" >resources/okra/Linux/libokra_x86_64.so >>>>>> $ jar uvf lib/okra-1.9-with-sim.jar >>>> resources/okra/Linux/libokra_x86_64.so >>>>>> $ mx --vm server unittest Vec3ObjStreamClassCastTest >>>>>> >>>>>> -Doug >>>>>> >>> >> > From david.holmes at oracle.com Tue Jun 3 02:23:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 03 Jun 2014 12:23:23 +1000 Subject: RFR: JDK-8044480: JDK image target overwrites lib/server/libjsig.dylib symlink with a copy of lib/libjsig.dylib In-Reply-To: <538C741F.90107@oracle.com> References: <538C741F.90107@oracle.com> Message-ID: <538D319B.2060108@oracle.com> Thumbs up from me too. David On 2/06/2014 10:54 PM, Erik Joelsson wrote: > Hello, > > Please review this small fix to images/bundle build on Macosx. In the > macosx specific j2*-bundle, lib/server/libjsig.dylib is not a symlink to > ../libjsig.dylib like on other platforms (or like in j2*-image). This > behavior dates back to the original macosx port and was intentionally > emulated in the new build in JDK 8. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044480 > The fix in JDK 9 inline: > > diff --git a/make/Bundles.gmk b/make/Bundles.gmk > --- a/make/Bundles.gmk > +++ b/make/Bundles.gmk > @@ -74,19 +74,16 @@ > JDK_TARGET_LIST := $(subst > $(JDK_IMAGE_DIR)/,$(JDK_BUNDLE_DIR)/Home/,$(JDK_FILE_LIST)) > JRE_TARGET_LIST := $(subst > $(JRE_IMAGE_DIR)/,$(JRE_BUNDLE_DIR)/Home/,$(JRE_FILE_LIST)) > > - # The old builds implementation of this did not preserve symlinks so > - # make sure they are followed and the contents copied instead. > - # To fix this, remove -L > # Copy empty directories (jre/lib/applet). > $(JDK_BUNDLE_DIR)/Home/%: $(JDK_IMAGE_DIR)/% > $(ECHO) Copying $(patsubst $(OUTPUT_ROOT)/%,%,$@) > $(MKDIR) -p $(@D) > - if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -L '$<' '$@'; fi > + if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -P '$<' '$@'; fi > > $(JRE_BUNDLE_DIR)/Home/%: $(JRE_IMAGE_DIR)/% > $(ECHO) Copying $(patsubst $(OUTPUT_ROOT)/%,%,$@) > $(MKDIR) -p $(@D) > - if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -L '$<' '$@'; fi > + if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -P '$<' '$@'; fi > > $(JDK_BUNDLE_DIR)/MacOS/libjli.dylib: > $(ECHO) Creating link $(patsubst $(OUTPUT_ROOT)/%,%,$@) > > > /Erik From david.holmes at oracle.com Tue Jun 3 02:41:04 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 03 Jun 2014 12:41:04 +1000 Subject: OpenJDK 8 compact profiles fail to build with make 4.0 In-Reply-To: <538C8580.8060102@oracle.com> References: <5389DA93.4080705@apache.org> <538C8580.8060102@oracle.com> Message-ID: <538D35C0.7030509@oracle.com> Hi Erik, This is great news! The dollar escaping stuff was a nightmare. Thanks, David On 3/06/2014 12:09 AM, Erik Joelsson wrote: > Hello Emmanuel, > > I remember that piece of make logic being especially tricky to get > working and it seems the weirdness in make has been fixed in make 4.0, > or at least changed. Our dealing with escaping dollars is rather messy > in JDK 8. I have recently worked on this in a JDK 9 project, where I > have chosen a different approach that seems to work with both 3.8x and > 4.0. The idea is based on defining this macro in make/common/MakeBase.gmk: > > ################################################################################ > > # This macro translates $ into \$ to protect the $ from expansion in the > shell. > # To make this macro resilient against already escaped strings, first > remove > # any present escapes before escaping so that no double escapes are added. > EscapeDollar = $(subst $$,\$$,$(subst \$$,$$,$(strip $1))) > > And then instead of escaping dollars explicitly in make variable > declarations, just call that macro before giving anything containing > dollars to the shell. > > --- a/make/CreateJars.gmk > +++ b/make/CreateJars.gmk > @@ -302,17 +302,15 @@ > # methods from classes that only go into the profile builds. > BEANLESS_CLASSES = $(IMAGES_OUTPUTDIR)/beanless > > -# When there are $ characters in filenames we have some very subtle > interactions between > -# make expansion and shell expansion. In this particular case $< will > contain a single $ while > -# $@ will contain \$. So we have to pass $< in single-quotes to avoid > shell expansion > $(BEANLESS_CLASSES)/%: $(JDK_OUTPUTDIR)/classes/% > $(MKDIR) -p $(@D) > - $(TOOL_REMOVEMETHODS) '$<' $@ addPropertyChangeListener > removePropertyChangeListener > + $(TOOL_REMOVEMETHODS) $(call EscapeDollar, $<) $(call EscapeDollar, > $@) \ > + addPropertyChangeListener removePropertyChangeListener > > CLASSES_TO_DEBEAN = \ > java/util/logging/LogManager.class \ > - java/util/jar/Pack200\$$Packer.class \ > - java/util/jar/Pack200\$$Unpacker.class \ > + java/util/jar/Pack200$$Packer.class \ > + java/util/jar/Pack200$$Unpacker.class \ > com/sun/java/util/jar/pack/PackerImpl.class \ > com/sun/java/util/jar/pack/UnpackerImpl.class > > @@ -345,7 +343,7 @@ > $(CD) $(patsubst %$(VERSION_CLASS_PATH), %, $(CLASS_FILE)) && \ > $(JAR) $(RT_JAR_UPDATE_OPTIONS) $@.tmp $(VERSION_CLASS_PATH); \ > $(CD) $(BEANLESS_CLASSES) && \ > - $(JAR) $(RT_JAR_UPDATE_OPTIONS) $@.tmp $(CLASSES_TO_DEBEAN); \ > + $(JAR) $(RT_JAR_UPDATE_OPTIONS) $@.tmp $(call EscapeDollar, > $(CLASSES_TO_DEBEAN)); \ > fi > $(MV) $@.tmp $@ > > The patch above works for me at least. > > /Erik > > On 2014-05-31 15:35, Emmanuel Bourg wrote: >> Hi, >> >> I'd like to report an issue with the build for the OpenJDK 8 compact >> profiles. On Debian the build fails when PropertyChangeListener is >> removed from the pack200 classes: >> >> ## Starting profiles >> /usr/bin/find: `/home/ebourg/jdk8u-dev/build/images/lib': No such file >> or directory >> make[2]: *** No rule to make target >> '/home/ebourg/jdk8u-dev/build/images/beanless/java/util/jar/Pack200\$Packer.class', >> >> needed by '/home/ebourg/jdk8u-dev/build/images/libprofile_1/rt.jar'. >> Stop. >> make[2]: *** Waiting for unfinished jobs.... >> Removed method >> addPropertyChangeListener(java.beans.PropertyChangeListener) from >> java/util/logging/LogManager >> Removed method >> removePropertyChangeListener(java.beans.PropertyChangeListener) from >> java/util/logging/LogManager >> BuildJdk.gmk:113: recipe for target 'profile_1' failed >> make[1]: *** [profile_1] Error 2 >> /home/ebourg/jdk8u-dev//make/Main.gmk:147: recipe for target >> 'profiles-only' failed >> make: *** [profiles-only] Error 2 >> >> >> The same issue was reported last year on Arch Linux: >> >> http://mail.openjdk.java.net/pipermail/build-dev/2013-July/009557.html >> >> It looks like this error is caused by GNU Make 4.0 which is now the >> default in Debian. I was able to build the compact profiles after >> downgrading make to the version 3.81. >> >> OpenJDK 9 isn't affected by this issue because the >> add/removePropertyChangeListener() methods are already removed. >> >> Make 4.0 caused another regression (JDK-8028407) which has been fixed >> for OpenJDK 9. Could you also consider backporting it to OpenJDK 8 >> please? >> >> Thank you, >> >> Emmanuel Bourg > From erik.joelsson at oracle.com Tue Jun 3 08:14:33 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 03 Jun 2014 10:14:33 +0200 Subject: HSAIL unit tests fail when Okra library fails to load In-Reply-To: <538D1E6C.8080304@oracle.com> References: <1EDCCD92-B001-4506-8C88-A8A46F67F677@oracle.com> <537E69FE.4020402@amd.com> <2B05CBCB-9C09-4C8B-95A9-4BEAFFC2CC8B@oracle.com> <06A794E4-AAAF-4BD4-8C7C-74F3CAA8ED12@oracle.com> <5DA3C5F9-66BC-40A1-8FEE-0B57A6B061FC@oracle.com> <538D1E6C.8080304@oracle.com> Message-ID: <538D83E9.5020808@oracle.com> And according to rpm, the version is: $ rpm -q glibc glibc-2.8-3.x86_64 /Erik On 2014-06-03 03:01, Tim Bell wrote: > Hi - catching up on my email backlog: > >> Not sure what glibc version that is, though. > > For Linux builds, others on build-dev at openjdk.java.net are more > knowledgeable about glibc used in different JDK releases. > > Hmmm - these README-builds.html files do not mention a specific glibc > version: > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/raw-file/tip/README-builds.html > > > http://hg.openjdk.java.net/jdk7u/jdk7u-dev/raw-file/tip/README-builds.html > > > I ran a little test on one of our Fedora 9 build/test systems: > > uname -a > Linux sc11137352 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008 > i686 i686 i386 GNU/Linux > > gcc -v > Using built-in specs. > Target: i386-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info > --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap > --enable-shared --enable-threads=posix --enable-checking=release > --with-system-zlib --enable-__cxa_atexit > --disable-libunwind-exceptions > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada > --enable-java-awt=gtk --disable-dssi --enable-plugin > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre > --enable-libgcj-multifile --enable-java-maintainer-mode > --with-ecj-jar=/usr/share/java/eclipse-ecj.jar > --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux > Thread model: posix > gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) > > cat -n hw.c > 1 #include > 2 int main() { > 3 printf("Hello world\n"); > 4 } > > gcc -o hw hw.c > > ./hw > Hello world > > ldd ./hw > linux-gate.so.1 => (0x00110000) > libc.so.6 => /lib/libc.so.6 (0x0080d000) > /lib/ld-linux.so.2 (0x007ed000) > > > Hope this helps- > > Tim > > > On 05/23/14 00:13, Christian Thalinger wrote: >> >> On May 22, 2014, at 5:04 PM, Doug Simon > > wrote: >> >>> >>> On May 23, 2014, at 12:44 AM, Deneau, Tom >> > wrote: >>> >>>> Doug -- >>>> >>>> What glibc does Hotspot build against? >>> >>> I?m not sure - Christian may know (or know who knows). >> >> Looking at some wiki pages JDK 8 is building on: >> >> Fedora 9 / GCC 4.3 >> >> Not sure what glibc version that is, though. Tim Bell is the right >> guy to ask. >> >>> >>> -Doug >>> >>>>> -----Original Message----- >>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>> Sent: Thursday, May 22, 2014 5:40 PM >>>>> To: Caspole, Eric >>>>> Cc: Deneau, Tom; Bernhard Urban >>>>> Subject: Re: HSAIL unit tests fail when Okra library fails to load >>>>> >>>>> >>>>> On May 22, 2014, at 11:19 PM, Eric Caspole >>>> > wrote: >>>>> >>>>>> Hi Doug, >>>>>> Do you think it is worth it to build the built in Okra simulator >>>>>> with >>>>> an older glibc to help avoid this problem? What is the oldest >>>>> distro you >>>>> intend to support with Graal? >>>>> >>>>> In theory we should support whatever HotSpot does although in >>>>> practice >>>>> we only need it to work on OSes for which we build distributions. >>>>> >>>>> However, I think it's fine (for now at least) if we just cleanly >>>>> ignore/short-circuit the HSAIL unit tests in question on platforms >>>>> with >>>>> an older glibc. >>>>> >>>>> -Doug >>>>> >>>>>> On 05/22/2014 07:33 AM, Doug Simon wrote: >>>>>>> Hi Tom, Eric, >>>>>>> >>>>>>> We're in the process of making GraalVM binary builds that work on >>>>> Oracle Linux 6.5 which has an old version of glibc (GLIBC 2.12). >>>>> While >>>>> testing this build, the HSAIL tests that use the Okra library fail >>>>> because libokra_x86_64.so is built against a version of GLIBC >>>>> later than >>>>> 2.12. However, the failure message is very confusing. For example: >>>>>>> >>>>>>> $ mx --vm server unittest Vec3ObjStreamClassCastTest >>>>>>> GraalJUnitCore >>>>>>> JUnit version 4.11 >>>>>>> .E >>>>>>> Time: 0.77 >>>>>>> There was 1 failure: >>>>>>> 1) >>>>> test(com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest) >>>>>>> java.lang.NoClassDefFoundError: Could not initialize class >>>>> com.amd.okra.OkraContext >>>>>>> at >>>>> com.oracle.graal.compiler.hsail.test.infra.KernelTester.(KernelTes >>>>> >>>>> ter.java:129) >>>>>>> at >>>>> com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.(Graa >>>>> >>>>> lKernelTester.java:63) >>>>>>> at >>>>> com.oracle.graal.compiler.hsail.test.SingleExceptionTestBase.(Sing >>>>> >>>>> leExceptionTestBase.java:32) >>>>>>> at >>>>> com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest.(V >>>>> >>>>> ec3ObjStreamClassCastTest.java:31) >>>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>>> Method) >>>>>>> at >>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA >>>>> >>>>> ccessorImpl.java:62) >>>>>>> at >>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons >>>>> >>>>> tructorAccessorImpl.java:45) >>>>>>> at >>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:408) >>>>>>> at >>>>> org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunn >>>>> >>>>> er.java:195) >>>>>>> at >>>>> org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4 >>>>> >>>>> ClassRunner.java:244) >>>>>>> >>>>>>> Can you please make sure the HSAIL test harness recognizes a >>>>>>> failure >>>>> to load the Okra library (preferably issuing a message if it's for >>>>> any >>>>> other reason than the library not being available). One way to >>>>> trigger >>>>> this is to fake a bad library: >>>>>>> >>>>>>> $ mkdir -p resources/okra/Linux >>>>>>> $ echo "bad" >resources/okra/Linux/libokra_x86_64.so >>>>>>> $ jar uvf lib/okra-1.9-with-sim.jar >>>>> resources/okra/Linux/libokra_x86_64.so >>>>>>> $ mx --vm server unittest Vec3ObjStreamClassCastTest >>>>>>> >>>>>>> -Doug >>>>>>> >>>> >>> >> > From erik.joelsson at oracle.com Tue Jun 3 08:18:28 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 03 Jun 2014 10:18:28 +0200 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <4BF27092-B09D-4473-84AA-AEFB74320F5D@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <4BF27092-B09D-4473-84AA-AEFB74320F5D@oracle.com> Message-ID: <538D84D4.9090603@oracle.com> On 2014-06-02 23:27, David DeHaven wrote: >> Looks pretty good. A couple of questions still: >> >> * Where is the AC_SUBST for SDKROOT? >> >> * Could we get the "Checking for Xcode sdk name" output to only print on macosx? > Would this be OK instead? > > AC_MSG_CHECKING([for sdk name]) > AC_MSG_RESULT([$SDKNAME]) > > Otherwise it might make sense to just move the whole arg into the macosx block too. As I understand it, the whole concept of an sdkname is only present on mac, so I would prefer it being in the macosx conditional block. /Erik From erik.joelsson at oracle.com Tue Jun 3 08:31:40 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 03 Jun 2014 10:31:40 +0200 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> Message-ID: <538D87EC.7080204@oracle.com> On 2014-06-02 18:23, David DeHaven wrote: >> * Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still use this in some closed makefiles. Or is the idea that we instead will force the sdk name to 10.7? If so, then we need to still leave this in until every user (RE) has switched properly. > I moved all that to closed, it's in the internal review for those changes. The value is now set in custom-spec.gmk instead of spec.gmk. It was not used anywhere in OpenJDK that I could find. When deploy/install get revamped we can just remove it entirely, that'll be easier if it's in closed. > > It's referenced in make/bsd/makefiles/gcc.make, but that entire block is skipped if spec.gmk exists (confirmed by throwing garbage in there), and it defaults to 10.7.0 anyways. > Actually, I thought on this some more (and read the closed review). I added that feature to be able to build on 10.8 and still have bits runnable on 10.7, and it's still used in the jdk through the CFLAGS_JDKLIB and friends. We cannot remove those until we can guarantee that all builds are done on macosx10.7 sdkroot (which I assume would also fix the issue). So at least for now, please leave those in the open. Also, by having these CFLAGS/LDFLAGS set, we are able to create compatible bits even if macosx10.7 isn't installed. If we want to move towards using a specific sdkroot rather than the -mmacosx-version-min flags to control compatibility, then we should also add a default for macosx10.7 in configure. It would probably be good to add a default regardless. > I have to do another iteration based on what Max found when only the command line tools are installed (no Xcode). Thankfully, it won't be too difficult to determine if Xcode is installed or not. The logic won't be terribly different. Basically XCODEBUILD might not be usable since if Xcode is not installed we will not be able to use it. The stub xcodebuild tool is installed with the OS and I can actually use the return code to detect if Xcode is present or not. Additionally, SYSROOT/SDKROOT will not be set as the CL tools install headers to the System frameworks directories. There are no SDKs installed so there is no other place to put them. Supporting this usecase makes it even more important to keep the -mmacosx-version-min flags. /Erik From tim.bell at oracle.com Tue Jun 3 14:52:50 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 03 Jun 2014 14:52:50 +0000 Subject: HSAIL unit tests fail when Okra library fails to load In-Reply-To: <538D83E9.5020808@oracle.com> References: <1EDCCD92-B001-4506-8C88-A8A46F67F677@oracle.com> <537E69FE.4020402@amd.com> <2B05CBCB-9C09-4C8B-95A9-4BEAFFC2CC8B@oracle.com> <06A794E4-AAAF-4BD4-8C7C-74F3CAA8ED12@oracle.com> <5DA3C5F9-66BC-40A1-8FEE-0B57A6B061FC@oracle.com> <538D1E6C.8080304@oracle.com> <538D83E9.5020808@oracle.com> Message-ID: <538DE142.1020104@oracle.com> That's puzzling - how does rpm square with what ldd is reporting? Is glibc loaded dynamically, in which case my experiments are missing the point... hostname sc11137352 /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) ldd /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/java linux-gate.so.1 => (0x00110000) libpthread.so.0 => /lib/libpthread.so.0 (0x009aa000) libjli.so => /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/../lib/i386/jli/libjli.so (0x00111000) libdl.so.2 => /lib/libdl.so.2 (0x009a3000) libc.so.6 => /lib/libc.so.6 (0x0080d000) /lib/ld-linux.so.2 (0x007ed000) Tim On 06/03/14 08:14, Erik Joelsson wrote: > And according to rpm, the version is: > > $ rpm -q glibc > glibc-2.8-3.x86_64 > > /Erik > > On 2014-06-03 03:01, Tim Bell wrote: >> Hi - catching up on my email backlog: >> >>> Not sure what glibc version that is, though. >> >> For Linux builds, others on build-dev at openjdk.java.net are more >> knowledgeable about glibc used in different JDK releases. >> >> Hmmm - these README-builds.html files do not mention a specific glibc >> version: >> >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/raw-file/tip/README-builds.html >> >> >> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/raw-file/tip/README-builds.html >> >> >> I ran a little test on one of our Fedora 9 build/test systems: >> >> uname -a >> Linux sc11137352 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT >> 2008 i686 i686 i386 GNU/Linux >> >> gcc -v >> Using built-in specs. >> Target: i386-redhat-linux >> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man >> --infodir=/usr/share/info >> --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap >> --enable-shared --enable-threads=posix --enable-checking=release >> --with-system-zlib --enable-__cxa_atexit >> --disable-libunwind-exceptions >> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada >> --enable-java-awt=gtk --disable-dssi --enable-plugin >> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre >> --enable-libgcj-multifile --enable-java-maintainer-mode >> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar >> --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux >> Thread model: posix >> gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) >> >> cat -n hw.c >> 1 #include >> 2 int main() { >> 3 printf("Hello world\n"); >> 4 } >> >> gcc -o hw hw.c >> >> ./hw >> Hello world >> >> ldd ./hw >> linux-gate.so.1 => (0x00110000) >> libc.so.6 => /lib/libc.so.6 (0x0080d000) >> /lib/ld-linux.so.2 (0x007ed000) >> >> >> Hope this helps- >> >> Tim >> >> >> On 05/23/14 00:13, Christian Thalinger wrote: >>> >>> On May 22, 2014, at 5:04 PM, Doug Simon >> > wrote: >>> >>>> >>>> On May 23, 2014, at 12:44 AM, Deneau, Tom >>> > wrote: >>>> >>>>> Doug -- >>>>> >>>>> What glibc does Hotspot build against? >>>> >>>> I?m not sure - Christian may know (or know who knows). >>> >>> Looking at some wiki pages JDK 8 is building on: >>> >>> Fedora 9 / GCC 4.3 >>> >>> Not sure what glibc version that is, though. Tim Bell is the right >>> guy to ask. >>> >>>> >>>> -Doug >>>> >>>>>> -----Original Message----- >>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>>> Sent: Thursday, May 22, 2014 5:40 PM >>>>>> To: Caspole, Eric >>>>>> Cc: Deneau, Tom; Bernhard Urban >>>>>> Subject: Re: HSAIL unit tests fail when Okra library fails to load >>>>>> >>>>>> >>>>>> On May 22, 2014, at 11:19 PM, Eric Caspole >>>>> > wrote: >>>>>> >>>>>>> Hi Doug, >>>>>>> Do you think it is worth it to build the built in Okra simulator >>>>>>> with >>>>>> an older glibc to help avoid this problem? What is the oldest >>>>>> distro you >>>>>> intend to support with Graal? >>>>>> >>>>>> In theory we should support whatever HotSpot does although in >>>>>> practice >>>>>> we only need it to work on OSes for which we build distributions. >>>>>> >>>>>> However, I think it's fine (for now at least) if we just cleanly >>>>>> ignore/short-circuit the HSAIL unit tests in question on >>>>>> platforms with >>>>>> an older glibc. >>>>>> >>>>>> -Doug >>>>>> >>>>>>> On 05/22/2014 07:33 AM, Doug Simon wrote: >>>>>>>> Hi Tom, Eric, >>>>>>>> >>>>>>>> We're in the process of making GraalVM binary builds that work on >>>>>> Oracle Linux 6.5 which has an old version of glibc (GLIBC 2.12). >>>>>> While >>>>>> testing this build, the HSAIL tests that use the Okra library fail >>>>>> because libokra_x86_64.so is built against a version of GLIBC >>>>>> later than >>>>>> 2.12. However, the failure message is very confusing. For example: >>>>>>>> >>>>>>>> $ mx --vm server unittest Vec3ObjStreamClassCastTest >>>>>>>> GraalJUnitCore >>>>>>>> JUnit version 4.11 >>>>>>>> .E >>>>>>>> Time: 0.77 >>>>>>>> There was 1 failure: >>>>>>>> 1) >>>>>> test(com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest) >>>>>> >>>>>>>> java.lang.NoClassDefFoundError: Could not initialize class >>>>>> com.amd.okra.OkraContext >>>>>>>> at >>>>>> com.oracle.graal.compiler.hsail.test.infra.KernelTester.(KernelTes >>>>>> >>>>>> ter.java:129) >>>>>>>> at >>>>>> com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.(Graa >>>>>> >>>>>> lKernelTester.java:63) >>>>>>>> at >>>>>> com.oracle.graal.compiler.hsail.test.SingleExceptionTestBase.(Sing >>>>>> >>>>>> leExceptionTestBase.java:32) >>>>>>>> at >>>>>> com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest.(V >>>>>> >>>>>> ec3ObjStreamClassCastTest.java:31) >>>>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>>>> Method) >>>>>>>> at >>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA >>>>>> >>>>>> ccessorImpl.java:62) >>>>>>>> at >>>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons >>>>>> >>>>>> tructorAccessorImpl.java:45) >>>>>>>> at >>>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:408) >>>>>>>> at >>>>>> org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunn >>>>>> >>>>>> er.java:195) >>>>>>>> at >>>>>> org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4 >>>>>> >>>>>> ClassRunner.java:244) >>>>>>>> >>>>>>>> Can you please make sure the HSAIL test harness recognizes a >>>>>>>> failure >>>>>> to load the Okra library (preferably issuing a message if it's >>>>>> for any >>>>>> other reason than the library not being available). One way to >>>>>> trigger >>>>>> this is to fake a bad library: >>>>>>>> >>>>>>>> $ mkdir -p resources/okra/Linux >>>>>>>> $ echo "bad" >resources/okra/Linux/libokra_x86_64.so >>>>>>>> $ jar uvf lib/okra-1.9-with-sim.jar >>>>>> resources/okra/Linux/libokra_x86_64.so >>>>>>>> $ mx --vm server unittest Vec3ObjStreamClassCastTest >>>>>>>> >>>>>>>> -Doug >>>>>>>> >>>>> >>>> >>> >> > From erik.joelsson at oracle.com Tue Jun 3 14:58:42 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 03 Jun 2014 16:58:42 +0200 Subject: HSAIL unit tests fail when Okra library fails to load In-Reply-To: <538DE142.1020104@oracle.com> References: <1EDCCD92-B001-4506-8C88-A8A46F67F677@oracle.com> <537E69FE.4020402@amd.com> <2B05CBCB-9C09-4C8B-95A9-4BEAFFC2CC8B@oracle.com> <06A794E4-AAAF-4BD4-8C7C-74F3CAA8ED12@oracle.com> <5DA3C5F9-66BC-40A1-8FEE-0B57A6B061FC@oracle.com> <538D1E6C.8080304@oracle.com> <538D83E9.5020808@oracle.com> <538DE142.1020104@oracle.com> Message-ID: <538DE2A2.8000401@oracle.com> I don't think they are conflicting. /lib/libc.so.6 is part of the package glibc-2.8-3. /Erik On 2014-06-03 16:52, Tim Bell wrote: > That's puzzling - how does rpm square with what ldd is reporting? Is > glibc loaded dynamically, in which case my experiments are missing the > point... > > hostname > sc11137352 > > /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build 1.8.0-b132) > Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) > > > ldd /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/java > linux-gate.so.1 => (0x00110000) > libpthread.so.0 => /lib/libpthread.so.0 (0x009aa000) > libjli.so => > /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/../lib/i386/jli/libjli.so > (0x00111000) > libdl.so.2 => /lib/libdl.so.2 (0x009a3000) > libc.so.6 => /lib/libc.so.6 (0x0080d000) > /lib/ld-linux.so.2 (0x007ed000) > > Tim > > On 06/03/14 08:14, Erik Joelsson wrote: >> And according to rpm, the version is: >> >> $ rpm -q glibc >> glibc-2.8-3.x86_64 >> >> /Erik >> >> On 2014-06-03 03:01, Tim Bell wrote: >>> Hi - catching up on my email backlog: >>> >>>> Not sure what glibc version that is, though. >>> >>> For Linux builds, others on build-dev at openjdk.java.net are more >>> knowledgeable about glibc used in different JDK releases. >>> >>> Hmmm - these README-builds.html files do not mention a specific >>> glibc version: >>> >>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/raw-file/tip/README-builds.html >>> >>> >>> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/raw-file/tip/README-builds.html >>> >>> >>> I ran a little test on one of our Fedora 9 build/test systems: >>> >>> uname -a >>> Linux sc11137352 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT >>> 2008 i686 i686 i386 GNU/Linux >>> >>> gcc -v >>> Using built-in specs. >>> Target: i386-redhat-linux >>> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man >>> --infodir=/usr/share/info >>> --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap >>> --enable-shared --enable-threads=posix --enable-checking=release >>> --with-system-zlib --enable-__cxa_atexit >>> --disable-libunwind-exceptions >>> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada >>> --enable-java-awt=gtk --disable-dssi --enable-plugin >>> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre >>> --enable-libgcj-multifile --enable-java-maintainer-mode >>> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar >>> --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux >>> Thread model: posix >>> gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) >>> >>> cat -n hw.c >>> 1 #include >>> 2 int main() { >>> 3 printf("Hello world\n"); >>> 4 } >>> >>> gcc -o hw hw.c >>> >>> ./hw >>> Hello world >>> >>> ldd ./hw >>> linux-gate.so.1 => (0x00110000) >>> libc.so.6 => /lib/libc.so.6 (0x0080d000) >>> /lib/ld-linux.so.2 (0x007ed000) >>> >>> >>> Hope this helps- >>> >>> Tim >>> >>> >>> On 05/23/14 00:13, Christian Thalinger wrote: >>>> >>>> On May 22, 2014, at 5:04 PM, Doug Simon >>> > wrote: >>>> >>>>> >>>>> On May 23, 2014, at 12:44 AM, Deneau, Tom >>>> > wrote: >>>>> >>>>>> Doug -- >>>>>> >>>>>> What glibc does Hotspot build against? >>>>> >>>>> I?m not sure - Christian may know (or know who knows). >>>> >>>> Looking at some wiki pages JDK 8 is building on: >>>> >>>> Fedora 9 / GCC 4.3 >>>> >>>> Not sure what glibc version that is, though. Tim Bell is the right >>>> guy to ask. >>>> >>>>> >>>>> -Doug >>>>> >>>>>>> -----Original Message----- >>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>>>> Sent: Thursday, May 22, 2014 5:40 PM >>>>>>> To: Caspole, Eric >>>>>>> Cc: Deneau, Tom; Bernhard Urban >>>>>>> Subject: Re: HSAIL unit tests fail when Okra library fails to load >>>>>>> >>>>>>> >>>>>>> On May 22, 2014, at 11:19 PM, Eric Caspole >>>>>> > wrote: >>>>>>> >>>>>>>> Hi Doug, >>>>>>>> Do you think it is worth it to build the built in Okra >>>>>>>> simulator with >>>>>>> an older glibc to help avoid this problem? What is the oldest >>>>>>> distro you >>>>>>> intend to support with Graal? >>>>>>> >>>>>>> In theory we should support whatever HotSpot does although in >>>>>>> practice >>>>>>> we only need it to work on OSes for which we build distributions. >>>>>>> >>>>>>> However, I think it's fine (for now at least) if we just cleanly >>>>>>> ignore/short-circuit the HSAIL unit tests in question on >>>>>>> platforms with >>>>>>> an older glibc. >>>>>>> >>>>>>> -Doug >>>>>>> >>>>>>>> On 05/22/2014 07:33 AM, Doug Simon wrote: >>>>>>>>> Hi Tom, Eric, >>>>>>>>> >>>>>>>>> We're in the process of making GraalVM binary builds that work on >>>>>>> Oracle Linux 6.5 which has an old version of glibc (GLIBC 2.12). >>>>>>> While >>>>>>> testing this build, the HSAIL tests that use the Okra library fail >>>>>>> because libokra_x86_64.so is built against a version of GLIBC >>>>>>> later than >>>>>>> 2.12. However, the failure message is very confusing. For example: >>>>>>>>> >>>>>>>>> $ mx --vm server unittest Vec3ObjStreamClassCastTest >>>>>>>>> GraalJUnitCore >>>>>>>>> JUnit version 4.11 >>>>>>>>> .E >>>>>>>>> Time: 0.77 >>>>>>>>> There was 1 failure: >>>>>>>>> 1) >>>>>>> test(com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest) >>>>>>> >>>>>>>>> java.lang.NoClassDefFoundError: Could not initialize class >>>>>>> com.amd.okra.OkraContext >>>>>>>>> at >>>>>>> com.oracle.graal.compiler.hsail.test.infra.KernelTester.(KernelTes >>>>>>> >>>>>>> ter.java:129) >>>>>>>>> at >>>>>>> com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.(Graa >>>>>>> >>>>>>> lKernelTester.java:63) >>>>>>>>> at >>>>>>> com.oracle.graal.compiler.hsail.test.SingleExceptionTestBase.(Sing >>>>>>> >>>>>>> leExceptionTestBase.java:32) >>>>>>>>> at >>>>>>> com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest.(V >>>>>>> >>>>>>> ec3ObjStreamClassCastTest.java:31) >>>>>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>>>>> Method) >>>>>>>>> at >>>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA >>>>>>> >>>>>>> ccessorImpl.java:62) >>>>>>>>> at >>>>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons >>>>>>> >>>>>>> tructorAccessorImpl.java:45) >>>>>>>>> at >>>>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:408) >>>>>>>>> at >>>>>>> org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunn >>>>>>> >>>>>>> er.java:195) >>>>>>>>> at >>>>>>> org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4 >>>>>>> >>>>>>> ClassRunner.java:244) >>>>>>>>> >>>>>>>>> Can you please make sure the HSAIL test harness recognizes a >>>>>>>>> failure >>>>>>> to load the Okra library (preferably issuing a message if it's >>>>>>> for any >>>>>>> other reason than the library not being available). One way to >>>>>>> trigger >>>>>>> this is to fake a bad library: >>>>>>>>> >>>>>>>>> $ mkdir -p resources/okra/Linux >>>>>>>>> $ echo "bad" >resources/okra/Linux/libokra_x86_64.so >>>>>>>>> $ jar uvf lib/okra-1.9-with-sim.jar >>>>>>> resources/okra/Linux/libokra_x86_64.so >>>>>>>>> $ mx --vm server unittest Vec3ObjStreamClassCastTest >>>>>>>>> >>>>>>>>> -Doug >>>>>>>>> >>>>>> >>>>> >>>> >>> >> > From tim.bell at oracle.com Tue Jun 3 15:31:13 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 03 Jun 2014 15:31:13 +0000 Subject: HSAIL unit tests fail when Okra library fails to load In-Reply-To: <538DE2A2.8000401@oracle.com> References: <1EDCCD92-B001-4506-8C88-A8A46F67F677@oracle.com> <537E69FE.4020402@amd.com> <2B05CBCB-9C09-4C8B-95A9-4BEAFFC2CC8B@oracle.com> <06A794E4-AAAF-4BD4-8C7C-74F3CAA8ED12@oracle.com> <5DA3C5F9-66BC-40A1-8FEE-0B57A6B061FC@oracle.com> <538D1E6C.8080304@oracle.com> <538D83E9.5020808@oracle.com> <538DE142.1020104@oracle.com> <538DE2A2.8000401@oracle.com> Message-ID: <538DEA41.1050308@oracle.com> Ah, I see. Thanks. So RPM (or equivalent) is the authority to consult on Linux, at least until we get to JDK 9 and start using your devkits to build. Tim On 06/03/14 14:58, Erik Joelsson wrote: > I don't think they are conflicting. /lib/libc.so.6 is part of the > package glibc-2.8-3. > > /Erik > > On 2014-06-03 16:52, Tim Bell wrote: >> That's puzzling - how does rpm square with what ldd is reporting? >> Is glibc loaded dynamically, in which case my experiments are missing >> the point... >> >> hostname >> sc11137352 >> >> /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/java -version >> java version "1.8.0" >> Java(TM) SE Runtime Environment (build 1.8.0-b132) >> Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) >> >> >> ldd /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/java >> linux-gate.so.1 => (0x00110000) >> libpthread.so.0 => /lib/libpthread.so.0 (0x009aa000) >> libjli.so => >> /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/../lib/i386/jli/libjli.so >> (0x00111000) >> libdl.so.2 => /lib/libdl.so.2 (0x009a3000) >> libc.so.6 => /lib/libc.so.6 (0x0080d000) >> /lib/ld-linux.so.2 (0x007ed000) >> >> Tim >> >> On 06/03/14 08:14, Erik Joelsson wrote: >>> And according to rpm, the version is: >>> >>> $ rpm -q glibc >>> glibc-2.8-3.x86_64 >>> >>> /Erik >>> >>> On 2014-06-03 03:01, Tim Bell wrote: >>>> Hi - catching up on my email backlog: >>>> >>>>> Not sure what glibc version that is, though. >>>> >>>> For Linux builds, others on build-dev at openjdk.java.net are more >>>> knowledgeable about glibc used in different JDK releases. >>>> >>>> Hmmm - these README-builds.html files do not mention a specific >>>> glibc version: >>>> >>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/raw-file/tip/README-builds.html >>>> >>>> >>>> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/raw-file/tip/README-builds.html >>>> >>>> >>>> I ran a little test on one of our Fedora 9 build/test systems: >>>> >>>> uname -a >>>> Linux sc11137352 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT >>>> 2008 i686 i686 i386 GNU/Linux >>>> >>>> gcc -v >>>> Using built-in specs. >>>> Target: i386-redhat-linux >>>> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man >>>> --infodir=/usr/share/info >>>> --with-bugurl=http://bugzilla.redhat.com/bugzilla >>>> --enable-bootstrap --enable-shared --enable-threads=posix >>>> --enable-checking=release --with-system-zlib --enable-__cxa_atexit >>>> --disable-libunwind-exceptions >>>> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada >>>> --enable-java-awt=gtk --disable-dssi --enable-plugin >>>> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre >>>> --enable-libgcj-multifile --enable-java-maintainer-mode >>>> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar >>>> --disable-libjava-multilib --with-cpu=generic >>>> --build=i386-redhat-linux >>>> Thread model: posix >>>> gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) >>>> >>>> cat -n hw.c >>>> 1 #include >>>> 2 int main() { >>>> 3 printf("Hello world\n"); >>>> 4 } >>>> >>>> gcc -o hw hw.c >>>> >>>> ./hw >>>> Hello world >>>> >>>> ldd ./hw >>>> linux-gate.so.1 => (0x00110000) >>>> libc.so.6 => /lib/libc.so.6 (0x0080d000) >>>> /lib/ld-linux.so.2 (0x007ed000) >>>> >>>> >>>> Hope this helps- >>>> >>>> Tim >>>> >>>> >>>> On 05/23/14 00:13, Christian Thalinger wrote: >>>>> >>>>> On May 22, 2014, at 5:04 PM, Doug Simon >>>> > wrote: >>>>> >>>>>> >>>>>> On May 23, 2014, at 12:44 AM, Deneau, Tom >>>>> > wrote: >>>>>> >>>>>>> Doug -- >>>>>>> >>>>>>> What glibc does Hotspot build against? >>>>>> >>>>>> I?m not sure - Christian may know (or know who knows). >>>>> >>>>> Looking at some wiki pages JDK 8 is building on: >>>>> >>>>> Fedora 9 / GCC 4.3 >>>>> >>>>> Not sure what glibc version that is, though. Tim Bell is the >>>>> right guy to ask. >>>>> >>>>>> >>>>>> -Doug >>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>>>>> Sent: Thursday, May 22, 2014 5:40 PM >>>>>>>> To: Caspole, Eric >>>>>>>> Cc: Deneau, Tom; Bernhard Urban >>>>>>>> Subject: Re: HSAIL unit tests fail when Okra library fails to load >>>>>>>> >>>>>>>> >>>>>>>> On May 22, 2014, at 11:19 PM, Eric Caspole >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hi Doug, >>>>>>>>> Do you think it is worth it to build the built in Okra >>>>>>>>> simulator with >>>>>>>> an older glibc to help avoid this problem? What is the oldest >>>>>>>> distro you >>>>>>>> intend to support with Graal? >>>>>>>> >>>>>>>> In theory we should support whatever HotSpot does although in >>>>>>>> practice >>>>>>>> we only need it to work on OSes for which we build distributions. >>>>>>>> >>>>>>>> However, I think it's fine (for now at least) if we just cleanly >>>>>>>> ignore/short-circuit the HSAIL unit tests in question on >>>>>>>> platforms with >>>>>>>> an older glibc. >>>>>>>> >>>>>>>> -Doug >>>>>>>> >>>>>>>>> On 05/22/2014 07:33 AM, Doug Simon wrote: >>>>>>>>>> Hi Tom, Eric, >>>>>>>>>> >>>>>>>>>> We're in the process of making GraalVM binary builds that >>>>>>>>>> work on >>>>>>>> Oracle Linux 6.5 which has an old version of glibc (GLIBC >>>>>>>> 2.12). While >>>>>>>> testing this build, the HSAIL tests that use the Okra library fail >>>>>>>> because libokra_x86_64.so is built against a version of GLIBC >>>>>>>> later than >>>>>>>> 2.12. However, the failure message is very confusing. For example: >>>>>>>>>> >>>>>>>>>> $ mx --vm server unittest Vec3ObjStreamClassCastTest >>>>>>>>>> GraalJUnitCore >>>>>>>>>> JUnit version 4.11 >>>>>>>>>> .E >>>>>>>>>> Time: 0.77 >>>>>>>>>> There was 1 failure: >>>>>>>>>> 1) >>>>>>>> test(com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest) >>>>>>>> >>>>>>>>>> java.lang.NoClassDefFoundError: Could not initialize class >>>>>>>> com.amd.okra.OkraContext >>>>>>>>>> at >>>>>>>> com.oracle.graal.compiler.hsail.test.infra.KernelTester.(KernelTes >>>>>>>> >>>>>>>> ter.java:129) >>>>>>>>>> at >>>>>>>> com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.(Graa >>>>>>>> >>>>>>>> lKernelTester.java:63) >>>>>>>>>> at >>>>>>>> com.oracle.graal.compiler.hsail.test.SingleExceptionTestBase.(Sing >>>>>>>> >>>>>>>> leExceptionTestBase.java:32) >>>>>>>>>> at >>>>>>>> com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest.(V >>>>>>>> >>>>>>>> ec3ObjStreamClassCastTest.java:31) >>>>>>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>>>>>> Method) >>>>>>>>>> at >>>>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA >>>>>>>> >>>>>>>> ccessorImpl.java:62) >>>>>>>>>> at >>>>>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons >>>>>>>> >>>>>>>> tructorAccessorImpl.java:45) >>>>>>>>>> at >>>>>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:408) >>>>>>>>>> at >>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunn >>>>>>>> >>>>>>>> er.java:195) >>>>>>>>>> at >>>>>>>> org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4 >>>>>>>> >>>>>>>> ClassRunner.java:244) >>>>>>>>>> >>>>>>>>>> Can you please make sure the HSAIL test harness recognizes a >>>>>>>>>> failure >>>>>>>> to load the Okra library (preferably issuing a message if it's >>>>>>>> for any >>>>>>>> other reason than the library not being available). One way to >>>>>>>> trigger >>>>>>>> this is to fake a bad library: >>>>>>>>>> >>>>>>>>>> $ mkdir -p resources/okra/Linux >>>>>>>>>> $ echo "bad" >resources/okra/Linux/libokra_x86_64.so >>>>>>>>>> $ jar uvf lib/okra-1.9-with-sim.jar >>>>>>>> resources/okra/Linux/libokra_x86_64.so >>>>>>>>>> $ mx --vm server unittest Vec3ObjStreamClassCastTest >>>>>>>>>> >>>>>>>>>> -Doug >>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From david.dehaven at oracle.com Tue Jun 3 18:04:23 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 3 Jun 2014 11:04:23 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <538D87EC.7080204@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <538D87EC.7080204@oracle.com> Message-ID: >>> * Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still use this in some closed makefiles. Or is the idea that we instead will force the sdk name to 10.7? If so, then we need to still leave this in until every user (RE) has switched properly. >> I moved all that to closed, it's in the internal review for those changes. The value is now set in custom-spec.gmk instead of spec.gmk. It was not used anywhere in OpenJDK that I could find. When deploy/install get revamped we can just remove it entirely, that'll be easier if it's in closed. >> >> It's referenced in make/bsd/makefiles/gcc.make, but that entire block is skipped if spec.gmk exists (confirmed by throwing garbage in there), and it defaults to 10.7.0 anyways. >> > Actually, I thought on this some more (and read the closed review). I added that feature to be able to build on 10.8 and still have bits runnable on 10.7, and it's still used in the jdk through the CFLAGS_JDKLIB and friends. We cannot remove those until we can guarantee that all builds are done on macosx10.7 sdkroot (which I assume would also fix the issue). So at least for now, please leave those in the open. Also, by having these CFLAGS/LDFLAGS set, we are able to create compatible bits even if macosx10.7 isn't installed. > > If we want to move towards using a specific sdkroot rather than the -mmacosx-version-min flags to control compatibility, then we should also add a default for macosx10.7 in configure. It would probably be good to add a default regardless. Like I said before, the -mmacosx-version-min argument is set in CFLAGS in JDK, it does not need the MACOSX_VERSION_MIN macro to be defined. That macro is *only* used by deploy and install (for the time being). Removing the macro has no effect on how any of the OpenJDK components are built. The minimum version is still set to 10.7. You're confusing SDK version with OS X supported version, the two are not the same. You can use a later SDK and set the minimum OS version to an earlier release. We cannot lock down a specific SDK because Apple changes which SDKs are available with each major release of Xcode (and there's really no point to doing so). The sdk name argument is to allow users to specify a particular SDK if it's needed, rather than assuming the default "macosx" sdk name which simply chooses the latest SDK available. Does that make sense? -DrD- From joe.darcy at oracle.com Tue Jun 3 18:07:13 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 03 Jun 2014 11:07:13 -0700 Subject: JDK 9 RFR of 8044715: Add finally lint warning to build of jdk repository Message-ID: <538E0ED1.8090804@oracle.com> Hello, I've started looking at clearing the javac "finally" lint category from the JDK sources. Once that is done, please review the corresponding makefile change to enable the warning the build: diff -r cb15bc14c26a make/Setup.gmk --- a/make/Setup.gmk Mon Jun 02 19:49:57 2014 +0400 +++ b/make/Setup.gmk Tue Jun 03 11:06:19 2014 -0700 @@ -27,7 +27,7 @@ # To build with all warnings enabled, do the following: # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" -JAVAC_WARNINGS := -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,overloads,serial,static,try,varargs -Werror +JAVAC_WARNINGS := -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,finally,overloads,serial,static,try,varargs -Werror # Any java code executed during a JDK build to build other parts of the JDK must be # executed by the bootstrap JDK (probably with -Xbootclasspath/p: ) and for this Thanks, -Joe From henry.jen at oracle.com Tue Jun 3 18:14:27 2014 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 03 Jun 2014 11:14:27 -0700 Subject: JDK 9 RFR of 8044715: Add finally lint warning to build of jdk repository In-Reply-To: <538E0ED1.8090804@oracle.com> References: <538E0ED1.8090804@oracle.com> Message-ID: <538E1083.7070500@oracle.com> +1. Not a "R"eviewer. Cheers, Henry On 06/03/2014 11:07 AM, Joe Darcy wrote: > Hello, > > I've started looking at clearing the javac "finally" lint category from > the JDK sources. Once that is done, please review the corresponding > makefile change to enable the warning the build: > > diff -r cb15bc14c26a make/Setup.gmk > --- a/make/Setup.gmk Mon Jun 02 19:49:57 2014 +0400 > +++ b/make/Setup.gmk Tue Jun 03 11:06:19 2014 -0700 > @@ -27,7 +27,7 @@ > > # To build with all warnings enabled, do the following: > # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" > -JAVAC_WARNINGS := > -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,overloads,serial,static,try,varargs > -Werror > +JAVAC_WARNINGS := > -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,finally,overloads,serial,static,try,varargs > -Werror > > # Any java code executed during a JDK build to build other parts of > the JDK must be > # executed by the bootstrap JDK (probably with -Xbootclasspath/p: ) > and for this > > Thanks, > > -Joe From tim.bell at oracle.com Tue Jun 3 18:45:35 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 03 Jun 2014 18:45:35 +0000 Subject: JDK 9 RFR of 8044715: Add finally lint warning to build of jdk repository In-Reply-To: <538E1083.7070500@oracle.com> References: <538E0ED1.8090804@oracle.com> <538E1083.7070500@oracle.com> Message-ID: <538E17CF.7030509@oracle.com> Looks good to me as well- Tim On 06/03/14 18:14, Henry Jen wrote: > +1. Not a "R"eviewer. > > Cheers, > Henry > > On 06/03/2014 11:07 AM, Joe Darcy wrote: >> Hello, >> >> I've started looking at clearing the javac "finally" lint category from >> the JDK sources. Once that is done, please review the corresponding >> makefile change to enable the warning the build: >> >> diff -r cb15bc14c26a make/Setup.gmk >> --- a/make/Setup.gmk Mon Jun 02 19:49:57 2014 +0400 >> +++ b/make/Setup.gmk Tue Jun 03 11:06:19 2014 -0700 >> @@ -27,7 +27,7 @@ >> >> # To build with all warnings enabled, do the following: >> # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" >> -JAVAC_WARNINGS := >> -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,overloads,serial,static,try,varargs >> >> -Werror >> +JAVAC_WARNINGS := >> -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,finally,overloads,serial,static,try,varargs >> >> -Werror >> >> # Any java code executed during a JDK build to build other parts of >> the JDK must be >> # executed by the bootstrap JDK (probably with -Xbootclasspath/p: ) >> and for this >> >> Thanks, >> >> -Joe From david.dehaven at oracle.com Tue Jun 3 20:57:01 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 3 Jun 2014 13:57:01 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <538D87EC.7080204@oracle.com> Message-ID: <0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com> >>>> * Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still use this in some closed makefiles. Or is the idea that we instead will force the sdk name to 10.7? If so, then we need to still leave this in until every user (RE) has switched properly. >>> I moved all that to closed, it's in the internal review for those changes. The value is now set in custom-spec.gmk instead of spec.gmk. It was not used anywhere in OpenJDK that I could find. When deploy/install get revamped we can just remove it entirely, that'll be easier if it's in closed. >>> >>> It's referenced in make/bsd/makefiles/gcc.make, but that entire block is skipped if spec.gmk exists (confirmed by throwing garbage in there), and it defaults to 10.7.0 anyways. >>> >> Actually, I thought on this some more (and read the closed review). I added that feature to be able to build on 10.8 and still have bits runnable on 10.7, and it's still used in the jdk through the CFLAGS_JDKLIB and friends. We cannot remove those until we can guarantee that all builds are done on macosx10.7 sdkroot (which I assume would also fix the issue). So at least for now, please leave those in the open. Also, by having these CFLAGS/LDFLAGS set, we are able to create compatible bits even if macosx10.7 isn't installed. >> >> If we want to move towards using a specific sdkroot rather than the -mmacosx-version-min flags to control compatibility, then we should also add a default for macosx10.7 in configure. It would probably be good to add a default regardless. Oops. Nevermind, I got overzealous in moving stuff around. I'll fix that. -DrD- From mikael.vidstedt at oracle.com Tue Jun 3 21:55:20 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 03 Jun 2014 14:55:20 -0700 Subject: Recognizing/translating cpu names Message-ID: <538E4448.9070705@oracle.com> All, On linux/SPARC the platform string returned from config.guess is "sparc64-unknown-linux-gnu", but the build system doesn't currently recognize "sparc64" as a valid cpu name. I'd like some feedback on how to address this. I can see two ways: 1. Add it to the list of recognized cpu names and map it to the "normal" sparc values, something like: http://cr.openjdk.java.net/~mikael/webrevs/top-sparc64/webrev.00/webrev/ 2. Massage/translate the string in config.guess to return something better (e.g. sparcv9-unknown-linux-gnu) I notice that we do the latter type of translation for some platforms/strings, but it's not clear to me what the pros and cons are of the respective approaches. Please advise. Thanks, Mikael From mike.duigou at oracle.com Tue Jun 3 22:36:43 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 3 Jun 2014 15:36:43 -0700 Subject: RFR: 8044733: (xs) common/autoconf/configure script doesn't properly detect missing tools Message-ID: <52DE10C0-E461-4040-B9F8-5F70850FC3C1@oracle.com> Hello all; This is a small changeset to fix a problem where on some platforms (Solaris and possibly others) the configure script doesn't properly detect the absence of autoconf or mercurial because which returns a string for the failure condition. The recipe used was previously in hgforest.sh for it's detection of the mercurial executable. issue: https://bugs.openjdk.java.net/browse/JDK-8044733 webrev: http://cr.openjdk.java.net/~mduigou/JDK-8044733/0/webrev Mike From erik.joelsson at oracle.com Wed Jun 4 08:16:11 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 04 Jun 2014 10:16:11 +0200 Subject: Recognizing/translating cpu names In-Reply-To: <538E4448.9070705@oracle.com> References: <538E4448.9070705@oracle.com> Message-ID: <538ED5CB.3070308@oracle.com> On 2014-06-03 23:55, Mikael Vidstedt wrote: > > All, > > On linux/SPARC the platform string returned from config.guess is > "sparc64-unknown-linux-gnu", but the build system doesn't currently > recognize "sparc64" as a valid cpu name. I'd like some feedback on how > to address this. I can see two ways: > > 1. Add it to the list of recognized cpu names and map it to the > "normal" sparc values, something like: > > http://cr.openjdk.java.net/~mikael/webrevs/top-sparc64/webrev.00/webrev/ > > 2. Massage/translate the string in config.guess to return something > better (e.g. sparcv9-unknown-linux-gnu) > > I notice that we do the latter type of translation for some > platforms/strings, but it's not clear to me what the pros and cons are > of the respective approaches. Please advise. > The reason we have a wrapper around config.guess is simply because we cannot edit the file (3rd party GPL) and we cannot update it to get the latest features (more legal reasons). So instead we have implemented support for newer architectures in the wrapper. I think for your case above, translating what config.guess says into our "standard" in platform.gmk is the right way to go. /Erik From erik.joelsson at oracle.com Wed Jun 4 08:17:54 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 04 Jun 2014 10:17:54 +0200 Subject: RFR: 8044733: (xs) common/autoconf/configure script doesn't properly detect missing tools In-Reply-To: <52DE10C0-E461-4040-B9F8-5F70850FC3C1@oracle.com> References: <52DE10C0-E461-4040-B9F8-5F70850FC3C1@oracle.com> Message-ID: <538ED632.1010400@oracle.com> Looks good. Using "which" is a pain. /Erik On 2014-06-04 00:36, Mike Duigou wrote: > Hello all; > > This is a small changeset to fix a problem where on some platforms (Solaris and possibly others) the configure script doesn't properly detect the absence of autoconf or mercurial because which returns a string for the failure condition. > > The recipe used was previously in hgforest.sh for it's detection of the mercurial executable. > > issue: https://bugs.openjdk.java.net/browse/JDK-8044733 > webrev: http://cr.openjdk.java.net/~mduigou/JDK-8044733/0/webrev > > Mike From pointo1d at gmail.com Wed Jun 4 18:22:06 2014 From: pointo1d at gmail.com (pointo1d) Date: Wed, 04 Jun 2014 19:22:06 +0100 Subject: RFR: 8044733: (xs) common/autoconf/configure script doesn't properly detect missing tools In-Reply-To: <52DE10C0-E461-4040-B9F8-5F70850FC3C1@oracle.com> References: <52DE10C0-E461-4040-B9F8-5F70850FC3C1@oracle.com> Message-ID: <538F63CE.7020706@gmail.com> Hiya Mike , On 03/06/14 23:36, Mike Duigou wrote: > Hello all; > > This is a small changeset to fix a problem where on some platforms (Solaris and possibly others) the configure script doesn't properly detect the absence of autoconf or mercurial because which returns a string for the failure condition. > > The recipe used was previously in hgforest.sh for it's detection of the mercurial executable. > > issue: https://bugs.openjdk.java.net/browse/JDK-8044733 > webrev: http://cr.openjdk.java.net/~mduigou/JDK-8044733/0/webrev > > Mike I thought '...because which...' was a grammatical mistake, then I realized that I should've read it as '...because which(1)...' :-) Anyway, would there be any mileage in... error() { echo "ERROR: $@ - aborting..." >&2 exit 1 } check_bin() { case x`which autoconf 2> /dev/null | grep -v "^no $1 in"` in x) return ;; *) return x ;; esac } run_autogen_or_fail() { if test "`check_bin autoconf`" = x; then error "Cannot locate autoconf, unable to correct situation. Please install autoconf and run 'bash autogen.sh' to update the generated files." else echo "Running autogen.sh to correct the situation" bash $conf_script_dir/autogen.sh fi } . . . check_hg_updates() { if test "x`check_bin hg`" != x; then conf_updated_autoconf_files=`cd $conf_script_dir && hg status -mard 2> /dev/null | grep autoconf` if test "x$conf_updated_autoconf_files" != x; then echo "Configure source code has been updated, checking time stamps" check_autoconf_timestamps fi . . else error "Cannot locate hg" fi . . . } Note that the above also corrects what appears to be the cargo cult of multiple echo statements c/w a single cat(1) using a here document. HTH , Best rgds , -- ?Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe From mike.duigou at oracle.com Wed Jun 4 18:25:12 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 4 Jun 2014 11:25:12 -0700 Subject: RFR: 8044733: (xs) common/autoconf/configure script doesn't properly detect missing tools In-Reply-To: <538F63CE.7020706@gmail.com> References: <52DE10C0-E461-4040-B9F8-5F70850FC3C1@oracle.com> <538F63CE.7020706@gmail.com> Message-ID: <22A4839F-9280-4879-A9FD-772BA754E1C4@oracle.com> I considered making the check a function but opted to do the minimal change instead. I do agree that it seems like something suitable for a function. Mike On Jun 4 2014, at 11:22 , pointo1d wrote: > Hiya Mike , > > On 03/06/14 23:36, Mike Duigou wrote: >> Hello all; >> >> This is a small changeset to fix a problem where on some platforms (Solaris and possibly others) the configure script doesn't properly detect the absence of autoconf or mercurial because which returns a string for the failure condition. >> >> The recipe used was previously in hgforest.sh for it's detection of the mercurial executable. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8044733 >> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8044733/0/webrev >> >> Mike > > I thought '...because which...' was a grammatical mistake, then I realized that I should've read it as '...because which(1)...' :-) > > Anyway, would there be any mileage in... > > error() { > echo "ERROR: $@ - aborting..." >&2 > exit 1 > } > > check_bin() { > case x`which autoconf 2> /dev/null | grep -v "^no $1 in"` in > x) return ;; > *) return x ;; > esac > } > > run_autogen_or_fail() { > if test "`check_bin autoconf`" = x; then > error "Cannot locate autoconf, unable to correct situation. > Please install autoconf and run 'bash autogen.sh' to update the generated files." > else > echo "Running autogen.sh to correct the situation" > bash $conf_script_dir/autogen.sh > fi > } > . > . > . > check_hg_updates() { > if test "x`check_bin hg`" != x; then > conf_updated_autoconf_files=`cd $conf_script_dir && hg status -mard 2> /dev/null | grep autoconf` > if test "x$conf_updated_autoconf_files" != x; then > echo "Configure source code has been updated, checking time stamps" > check_autoconf_timestamps > fi > . > . > else > error "Cannot locate hg" > fi > . > . > . > } > > Note that the above also corrects what appears to be the cargo cult of multiple echo statements c/w a single cat(1) using a here document. > > HTH , > Best rgds , > > -- > ?Dave Pointon FIAP MBCS > > Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe > From david.dehaven at oracle.com Wed Jun 4 23:01:29 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 4 Jun 2014 16:01:29 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <538D87EC.7080204@oracle.com> <0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com> Message-ID: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com> Next (hopefully last??) update: http://cr.openjdk.java.net/~ddehaven/8043340/v3 (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch) I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way. These comments in flags.m4 are a bit misleading and not really true: # FIXME: This needs to be exported in spec.gmk due to closed legacy code. # FIXME: clean this up, and/or move it elsewhere. So, I removed them... I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name. Testing: I now have two system configurations I'm testing with: 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk) 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else) System 1 tests: $ sudo xcode-select -switch /Applications/Xcode.app $ make clean; sh ./configure; make images ... 00:09:17 TOTAL ------------------------- Finished building Java(TM) for target 'images' $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images ... 00:13:37 TOTAL ------------------------- Finished building Java(TM) for target 'images' (Note that building with Xcode 5/clang is faster...) $ sudo xcode-select -switch /Applications/old/Xcode4.app $ make clean; sh ./configure; make images Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below) Hudson/JPRT should not be affected unless they also have Xcode 5 installed $ make clean; sh ./configure --with-toolchain-type=clang; make images ... 00:10:54 TOTAL ------------------------- Finished building Java(TM) for target 'images' System 2 tests: OpenJDK only (ignore the time, I had it pulling closed jdk while building): $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images ... 00:20:26 TOTAL ------------------------- Finished building OpenJDK for target 'images' Closed JDK (images only, deploy/install expected to fail) $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images ... 00:10:05 TOTAL ------------------------- Finished building Java(TM) for target 'images' -DrD- From erik.joelsson at oracle.com Thu Jun 5 08:04:19 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 05 Jun 2014 10:04:19 +0200 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <538D87EC.7080204@oracle.com> <0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com> <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracl! e.com> Message-ID: <53902483.1060208@oracle.com> Only thing I can think of now is that some of the error/warning messages do not start with a capital letter. Looks good and nice work! On 2014-06-05 01:01, David DeHaven wrote: > Next (hopefully last??) update: > http://cr.openjdk.java.net/~ddehaven/8043340/v3 > > (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch) > > I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way. > > > These comments in flags.m4 are a bit misleading and not really true: > # FIXME: This needs to be exported in spec.gmk due to closed legacy code. > # FIXME: clean this up, and/or move it elsewhere. > > So, I removed them... Good, that was indeed not true. > I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name. I think that's good too, I had some doubts about that. Is that environment variable set by the system in some way or is it something one sets manually? If it's something the system sets, then perhaps it's worth looking at (compare VS100COMNTOOLS on windows which points to visual studio). But since we can get the information from xcodebuild anyway, it really doesn't matter. Nice to see a speedup in building too. The broken case seems ok to me. Not much we can do there. Silently switching to clang would be bad too. /Erik > > > Testing: > > I now have two system configurations I'm testing with: > 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk) > 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else) > > System 1 tests: > $ sudo xcode-select -switch /Applications/Xcode.app > $ make clean; sh ./configure; make images > ... > 00:09:17 TOTAL > ------------------------- > Finished building Java(TM) for target 'images' > > > $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images > ... > 00:13:37 TOTAL > ------------------------- > Finished building Java(TM) for target 'images' > > (Note that building with Xcode 5/clang is faster...) > > > $ sudo xcode-select -switch /Applications/old/Xcode4.app > $ make clean; sh ./configure; make images > Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active > Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below) > Hudson/JPRT should not be affected unless they also have Xcode 5 installed > > > $ make clean; sh ./configure --with-toolchain-type=clang; make images > ... > 00:10:54 TOTAL > ------------------------- > Finished building Java(TM) for target 'images' > > > System 2 tests: > OpenJDK only (ignore the time, I had it pulling closed jdk while building): > $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images > ... > 00:20:26 TOTAL > ------------------------- > Finished building OpenJDK for target 'images' > > > Closed JDK (images only, deploy/install expected to fail) > $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images > ... > 00:10:05 TOTAL > ------------------------- > Finished building Java(TM) for target 'images' > > -DrD- > From david.dehaven at oracle.com Thu Jun 5 14:39:45 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 5 Jun 2014 07:39:45 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <53902483.1060208@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <538D87EC.7080204@oracle.com> <0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com> <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracl! e.com> <53902483.1060208@oracle.com> Message-ID: > Only thing I can think of now is that some of the error/warning messages do not start with a capital letter. Looks good and nice work! I'll fix those before pushing. >> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name. > I think that's good too, I had some doubts about that. Is that environment variable set by the system in some way or is it something one sets manually? If it's something the system sets, then perhaps it's worth looking at (compare VS100COMNTOOLS on windows which points to visual studio). But since we can get the information from xcodebuild anyway, it really doesn't matter. Right. SDKROOT is set when Xcode is building, so it would either be set by the user or if someone were building OpenJDK as part of an Xcode project. > Nice to see a speedup in building too. The broken case seems ok to me. Not much we can do there. Silently switching to clang would be bad too. Agreed! -DrD- From maurizio.cimadamore at oracle.com Thu Jun 5 17:37:18 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 05 Jun 2014 18:37:18 +0100 Subject: running compiler JCK tests from toplevel makefile Message-ID: <5390AACE.3060001@oracle.com> Hi, I've spent some time investigating why jck compiler tests could not be launched from toplevel make - i.e. using make test TEST=langtools_jck-compiler Turns out that langtools makefile expects certain variables, while the build provide others, and those are not correctly wired up. On top of that, manually setting an extra make variable (for JCK_HOME) would have no effect, as such variable would not be propagated by the make pipeline (toplevel make -> test/Makefile -> langtools/test/Makefile). The following patch seems to fix the issue - should I charge forward with it? diff -r 7d27dbb50d95 test/Makefile --- a/test/Makefile Wed Jun 04 10:03:17 2014 -0700 +++ b/test/Makefile Thu Jun 05 15:48:54 2014 +0100 @@ -58,7 +58,7 @@ # Test targets langtools_% : - @$(NO_STOPPING)$(call SUBDIR_TEST, $(LANGTOOLS_DIR), JT_JAVA=$(PRODUCT_HOME) JTREG_HOME=$(JT_HOME) TEST="$(subst langtools_,,$@)" $(subst langtools_,,$@)) + @$(NO_STOPPING)$(call SUBDIR_TEST, $(LANGTOOLS_DIR), JCK_HOME=$(JCK_HOME) TESTJAVA=$(PRODUCT_HOME) JT_JAVA=$(PRODUCT_HOME) JCK_CONCURRENCY=$(CONCURRENCY) JTREG_HOME=$(JT_HOME) TEST="$(subst langtools_,,$@)" $(subst langtools_,,$@)) jdk_% core_%s svc_%: @$(NO_STOPPING)$(call SUBDIR_TEST, $(JDK_DIR), TEST="$@" $@) Maurizio From mike.duigou at oracle.com Thu Jun 5 18:42:50 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 5 Jun 2014 11:42:50 -0700 Subject: running compiler JCK tests from toplevel makefile In-Reply-To: <5390AACE.3060001@oracle.com> References: <5390AACE.3060001@oracle.com> Message-ID: Seems reasonable. I personally have a preference for using the bootjdk for JT_JAVA but that's mostly a consequence of the bits that I work on--testing a HashMap change is more difficult when jtreg itself may not be working correctly. Mike On Jun 5 2014, at 10:37 , Maurizio Cimadamore wrote: > Hi, > I've spent some time investigating why jck compiler tests could not be launched from toplevel make - i.e. using > > make test TEST=langtools_jck-compiler > > Turns out that langtools makefile expects certain variables, while the build provide others, and those are not correctly wired up. On top of that, manually setting an extra make variable (for JCK_HOME) would have no effect, as such variable would not be propagated by the make pipeline (toplevel make -> test/Makefile -> langtools/test/Makefile). > > The following patch seems to fix the issue - should I charge forward with it? > > diff -r 7d27dbb50d95 test/Makefile > --- a/test/Makefile Wed Jun 04 10:03:17 2014 -0700 > +++ b/test/Makefile Thu Jun 05 15:48:54 2014 +0100 > @@ -58,7 +58,7 @@ > > # Test targets > langtools_% : > - @$(NO_STOPPING)$(call SUBDIR_TEST, $(LANGTOOLS_DIR), JT_JAVA=$(PRODUCT_HOME) JTREG_HOME=$(JT_HOME) TEST="$(subst langtools_,,$@)" $(subst langtools_,,$@)) > + @$(NO_STOPPING)$(call SUBDIR_TEST, $(LANGTOOLS_DIR), JCK_HOME=$(JCK_HOME) TESTJAVA=$(PRODUCT_HOME) JT_JAVA=$(PRODUCT_HOME) JCK_CONCURRENCY=$(CONCURRENCY) JTREG_HOME=$(JT_HOME) TEST="$(subst langtools_,,$@)" $(subst langtools_,,$@)) > > jdk_% core_%s svc_%: > @$(NO_STOPPING)$(call SUBDIR_TEST, $(JDK_DIR), TEST="$@" $@) > > > Maurizio From david.dehaven at oracle.com Thu Jun 5 21:51:57 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 5 Jun 2014 14:51:57 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <538D87EC.7080204@oracle.com> <0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com> <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracl! ! e.com> <53902483.1060208@oracle.com> Message-ID: <29CE59F0-689F-474F-882A-5063309E7D35@oracle.com> Will README-builds.html be updated as part of the compiler update? It (will be) outdated. I don't think it needs to be part of this patch since I'd like to backport this (and the other patches I've contributed recently) to 8u after it incubates for a while. -DrD- >> Only thing I can think of now is that some of the error/warning messages do not start with a capital letter. Looks good and nice work! > > I'll fix those before pushing. > > >>> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name. >> I think that's good too, I had some doubts about that. Is that environment variable set by the system in some way or is it something one sets manually? If it's something the system sets, then perhaps it's worth looking at (compare VS100COMNTOOLS on windows which points to visual studio). But since we can get the information from xcodebuild anyway, it really doesn't matter. > > Right. SDKROOT is set when Xcode is building, so it would either be set by the user or if someone were building OpenJDK as part of an Xcode project. > > >> Nice to see a speedup in building too. The broken case seems ok to me. Not much we can do there. Silently switching to clang would be bad too. > > Agreed! > > -DrD- > From maurizio.cimadamore at oracle.com Fri Jun 6 09:33:50 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 06 Jun 2014 10:33:50 +0100 Subject: running compiler JCK tests from toplevel makefile In-Reply-To: References: <5390AACE.3060001@oracle.com> Message-ID: <53918AFE.1000304@oracle.com> On 05/06/14 19:42, Mike Duigou wrote: > Seems reasonable. I personally have a preference for using the bootjdk for JT_JAVA but that's mostly a consequence of the bits that I work on--testing a HashMap change is more difficult when jtreg itself may not be working correctly. Definitively open to suggestions here - actually it's a pretty good idea. Ok - I will file an issue to keep track of this one and submit a review later on. Thanks for the comments Maurizio > > Mike > > On Jun 5 2014, at 10:37 , Maurizio Cimadamore wrote: > >> Hi, >> I've spent some time investigating why jck compiler tests could not be launched from toplevel make - i.e. using >> >> make test TEST=langtools_jck-compiler >> >> Turns out that langtools makefile expects certain variables, while the build provide others, and those are not correctly wired up. On top of that, manually setting an extra make variable (for JCK_HOME) would have no effect, as such variable would not be propagated by the make pipeline (toplevel make -> test/Makefile -> langtools/test/Makefile). >> >> The following patch seems to fix the issue - should I charge forward with it? >> >> diff -r 7d27dbb50d95 test/Makefile >> --- a/test/Makefile Wed Jun 04 10:03:17 2014 -0700 >> +++ b/test/Makefile Thu Jun 05 15:48:54 2014 +0100 >> @@ -58,7 +58,7 @@ >> >> # Test targets >> langtools_% : >> - @$(NO_STOPPING)$(call SUBDIR_TEST, $(LANGTOOLS_DIR), JT_JAVA=$(PRODUCT_HOME) JTREG_HOME=$(JT_HOME) TEST="$(subst langtools_,,$@)" $(subst langtools_,,$@)) >> + @$(NO_STOPPING)$(call SUBDIR_TEST, $(LANGTOOLS_DIR), JCK_HOME=$(JCK_HOME) TESTJAVA=$(PRODUCT_HOME) JT_JAVA=$(PRODUCT_HOME) JCK_CONCURRENCY=$(CONCURRENCY) JTREG_HOME=$(JT_HOME) TEST="$(subst langtools_,,$@)" $(subst langtools_,,$@)) >> >> jdk_% core_%s svc_%: >> @$(NO_STOPPING)$(call SUBDIR_TEST, $(JDK_DIR), TEST="$@" $@) >> >> >> Maurizio From joe.darcy at oracle.com Sat Jun 7 00:07:37 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 06 Jun 2014 17:07:37 -0700 Subject: JDK 9 RFR of JDK-8046273: Add overrides lint warning to build of jdk repository Message-ID: <539257C9.4080306@oracle.com> Hello, Another warnings-related build fix to review, this time for JDK-8046273: Add overrides lint warning to build of jdk repository once the few remaining overrides warnings are cleared. Thanks, -Joe diff -r 9e8cddf3312e make/Setup.gmk --- a/make/Setup.gmk Thu Jun 05 12:13:50 2014 +0100 +++ b/make/Setup.gmk Fri Jun 06 17:06:06 2014 -0700 @@ -27,7 +27,7 @@ # To build with all warnings enabled, do the following: # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" -JAVAC_WARNINGS := -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,overloads,serial,static,try,varargs -Werror +JAVAC_WARNINGS := -Xlint:-unchecked,-deprecation,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,overloads,overrides,serial,static,try,varargs -Werror # Any java code executed during a JDK build to build other parts of the JDK must be # executed by the bootstrap JDK (probably with -Xbootclasspath/p: ) and for this From tim.bell at oracle.com Sat Jun 7 00:31:44 2014 From: tim.bell at oracle.com (Tim Bell) Date: Sat, 07 Jun 2014 00:31:44 +0000 Subject: JDK 9 RFR of JDK-8046273: Add overrides lint warning to build of jdk repository In-Reply-To: <539257C9.4080306@oracle.com> References: <539257C9.4080306@oracle.com> Message-ID: <53925D70.3060204@oracle.com> Hi Joe: > Another warnings-related build fix to review, this time for > > JDK-8046273: Add overrides lint warning to build of jdk repository > > once the few remaining overrides warnings are cleared. > > Thanks, > > -Joe > > diff -r 9e8cddf3312e make/Setup.gmk > --- a/make/Setup.gmk Thu Jun 05 12:13:50 2014 +0100 > +++ b/make/Setup.gmk Fri Jun 06 17:06:06 2014 -0700 > @@ -27,7 +27,7 @@ > > # To build with all warnings enabled, do the following: > # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" > -JAVAC_WARNINGS := > -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,overloads,serial,static,try,varargs > -Werror > +JAVAC_WARNINGS := > -Xlint:-unchecked,-deprecation,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,overloads,overrides,serial,static,try,varargs > -Werror > Looks fine when the time comes. Approved. Tim From erik.joelsson at oracle.com Mon Jun 9 08:06:08 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 09 Jun 2014 10:06:08 +0200 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <29CE59F0-689F-474F-882A-5063309E7D35@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <538D87EC.7080204@oracle.com> <0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com> <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracl! e.com> <53902483.1060208@oracle.com> <29CE59F0-689F-474F-882A-5063309E7D35@ora! cle.com> Message-ID: <53956AF0.9080907@oracle.com> It certainly should be updated. /Erik On 2014-06-05 23:51, David DeHaven wrote: > Will README-builds.html be updated as part of the compiler update? It (will be) outdated. > > I don't think it needs to be part of this patch since I'd like to backport this (and the other patches I've contributed recently) to 8u after it incubates for a while. > > -DrD- > >>> Only thing I can think of now is that some of the error/warning messages do not start with a capital letter. Looks good and nice work! >> I'll fix those before pushing. >> >> >>>> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name. >>> I think that's good too, I had some doubts about that. Is that environment variable set by the system in some way or is it something one sets manually? If it's something the system sets, then perhaps it's worth looking at (compare VS100COMNTOOLS on windows which points to visual studio). But since we can get the information from xcodebuild anyway, it really doesn't matter. >> Right. SDKROOT is set when Xcode is building, so it would either be set by the user or if someone were building OpenJDK as part of an Xcode project. >> >> >>> Nice to see a speedup in building too. The broken case seems ok to me. Not much we can do there. Silently switching to clang would be bad too. >> Agreed! >> >> -DrD- >> From erik.joelsson at oracle.com Mon Jun 9 08:07:09 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 09 Jun 2014 10:07:09 +0200 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <53956AF0.9080907@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <538D87EC.7080204@oracle.com> <0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com> <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracl! e.com> <53902483.1060208@oracle.com> <29CE59F0-689F-474F-882A-5063309E7D35@oracle.com> <53956AF0.9080907@oracle.com> Message-ID: <53956B2D.8060603@oracle.com> At some point I mean. It's ok to not do it as part of this change. /Erik On 2014-06-09 10:06, Erik Joelsson wrote: > It certainly should be updated. > > /Erik > > On 2014-06-05 23:51, David DeHaven wrote: >> Will README-builds.html be updated as part of the compiler update? It >> (will be) outdated. >> >> I don't think it needs to be part of this patch since I'd like to >> backport this (and the other patches I've contributed recently) to 8u >> after it incubates for a while. >> >> -DrD- >> >>>> Only thing I can think of now is that some of the error/warning >>>> messages do not start with a capital letter. Looks good and nice work! >>> I'll fix those before pushing. >>> >>> >>>>> I also removed using SDKROOT from the env, since we ignore the >>>>> environment. Only two args affect SYSROOT now, --with-sysroot and >>>>> --with-sdk-name. >>>> I think that's good too, I had some doubts about that. Is that >>>> environment variable set by the system in some way or is it >>>> something one sets manually? If it's something the system sets, >>>> then perhaps it's worth looking at (compare VS100COMNTOOLS on >>>> windows which points to visual studio). But since we can get the >>>> information from xcodebuild anyway, it really doesn't matter. >>> Right. SDKROOT is set when Xcode is building, so it would either be >>> set by the user or if someone were building OpenJDK as part of an >>> Xcode project. >>> >>> >>>> Nice to see a speedup in building too. The broken case seems ok to >>>> me. Not much we can do there. Silently switching to clang would be >>>> bad too. >>> Agreed! >>> >>> -DrD- >>> > From david.dehaven at oracle.com Mon Jun 9 16:07:31 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 9 Jun 2014 09:07:31 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <53956B2D.8060603@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <538D87EC.7080204@oracle.com> <0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com> <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracl! e.com> <53902483.1060208@oracle.com> <29CE59F0-689F-474F-882A-5063309E7D35@oracle.com> <53956AF0.9080907@oracle.com> <53956B2D.8! 060603@oracle.com> Message-ID: <07520DFF-41CE-4E0B-8C95-F5D8439A3445@oracle.com> Ok, thanks. -DrD- > At some point I mean. It's ok to not do it as part of this change. > > /Erik > > On 2014-06-09 10:06, Erik Joelsson wrote: >> It certainly should be updated. >> >> /Erik >> >> On 2014-06-05 23:51, David DeHaven wrote: >>> Will README-builds.html be updated as part of the compiler update? It (will be) outdated. >>> >>> I don't think it needs to be part of this patch since I'd like to backport this (and the other patches I've contributed recently) to 8u after it incubates for a while. >>> >>> -DrD- >>> >>>>> Only thing I can think of now is that some of the error/warning messages do not start with a capital letter. Looks good and nice work! >>>> I'll fix those before pushing. >>>> >>>> >>>>>> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name. >>>>> I think that's good too, I had some doubts about that. Is that environment variable set by the system in some way or is it something one sets manually? If it's something the system sets, then perhaps it's worth looking at (compare VS100COMNTOOLS on windows which points to visual studio). But since we can get the information from xcodebuild anyway, it really doesn't matter. >>>> Right. SDKROOT is set when Xcode is building, so it would either be set by the user or if someone were building OpenJDK as part of an Xcode project. >>>> >>>> >>>>> Nice to see a speedup in building too. The broken case seems ok to me. Not much we can do there. Silently switching to clang would be bad too. >>>> Agreed! >>>> >>>> -DrD- >>>> >> > From david.dehaven at oracle.com Tue Jun 10 21:26:53 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 10 Jun 2014 14:26:53 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <538D87EC.7080204@oracle.com> <0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com> <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com> Message-ID: Can I get another Review on this? Also, since I don't think the servers have been updated to allow me to push yet, I may need someone to push for me. -DrD- > Next (hopefully last??) update: > http://cr.openjdk.java.net/~ddehaven/8043340/v3 > > (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch) > > I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way. > > > These comments in flags.m4 are a bit misleading and not really true: > # FIXME: This needs to be exported in spec.gmk due to closed legacy code. > # FIXME: clean this up, and/or move it elsewhere. > > So, I removed them... > > I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name. > > > > Testing: > > I now have two system configurations I'm testing with: > 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk) > 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else) > > System 1 tests: > $ sudo xcode-select -switch /Applications/Xcode.app > $ make clean; sh ./configure; make images > ... > 00:09:17 TOTAL > ------------------------- > Finished building Java(TM) for target 'images' > > > $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images > ... > 00:13:37 TOTAL > ------------------------- > Finished building Java(TM) for target 'images' > > (Note that building with Xcode 5/clang is faster...) > > > $ sudo xcode-select -switch /Applications/old/Xcode4.app > $ make clean; sh ./configure; make images > Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active > Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below) > Hudson/JPRT should not be affected unless they also have Xcode 5 installed > > > $ make clean; sh ./configure --with-toolchain-type=clang; make images > ... > 00:10:54 TOTAL > ------------------------- > Finished building Java(TM) for target 'images' > > > System 2 tests: > OpenJDK only (ignore the time, I had it pulling closed jdk while building): > $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images > ... > 00:20:26 TOTAL > ------------------------- > Finished building OpenJDK for target 'images' > > > Closed JDK (images only, deploy/install expected to fail) > $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images > ... > 00:10:05 TOTAL > ------------------------- > Finished building Java(TM) for target 'images' > > -DrD- > From mikael.vidstedt at oracle.com Wed Jun 11 00:11:03 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 10 Jun 2014 17:11:03 -0700 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH Message-ID: <53979E97.1040609@oracle.com> All, I need some feedback and comments on the below fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ Background: When configuring the hotspot build the build system sets up the ARCH variable to reflect the target cpu. Currently the value is initialized to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu name. For example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). The goal in the new (JDK) build system is to have the "legacy" value gradually removed in favor of the other variables. Discussion: The two candidate variables to base ARCH on are as far as I can tell OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together with ARCH_DATA_MODEL/LP64 that information should be enough for the Hotspot build system to do its thing. Note: ARCH is currently ignored on solaris and bsd - it's overridden at the top of the respective make//makefiles/defs.make files. Before I go too far with this though I'd like to get some feedback on whether or not this is the right approach and what the exact value should be. Depending on the outcome of that the Hotspot build system may have to be updated for some platforms to support the new value(s). Thanks, Mikael From david.holmes at oracle.com Wed Jun 11 02:45:58 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Jun 2014 12:45:58 +1000 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH In-Reply-To: <53979E97.1040609@oracle.com> References: <53979E97.1040609@oracle.com> Message-ID: <5397C2E6.6080603@oracle.com> Hi Mikael, This seems a reasonable proposal to me. We have an over-abundance of "arch" variables and values, so reducing that is a good aim. As you note the main flow-on effect here is that the hotspot makefiles have to be updated for the cases where OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think only x86 has that issue. Wouldn't it be nice if we could get rid of i386, i586, i686 etc both internally and in the build artifacts and bundles! Cheers, David On 11/06/2014 10:11 AM, Mikael Vidstedt wrote: > > All, > > I need some feedback and comments on the below fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ > > Background: > > When configuring the hotspot build the build system sets up the ARCH > variable to reflect the target cpu. Currently the value is initialized > to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu name. For > example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). The > goal in the new (JDK) build system is to have the "legacy" value > gradually removed in favor of the other variables. > > Discussion: > > The two candidate variables to base ARCH on are as far as I can tell > OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two > OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well > defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together > with ARCH_DATA_MODEL/LP64 that information should be enough for the > Hotspot build system to do its thing. Note: ARCH is currently ignored on > solaris and bsd - it's overridden at the top of the respective > make//makefiles/defs.make files. > > Before I go too far with this though I'd like to get some feedback on > whether or not this is the right approach and what the exact value > should be. Depending on the outcome of that the Hotspot build system may > have to be updated for some platforms to support the new value(s). > > Thanks, > Mikael > From tim.bell at oracle.com Wed Jun 11 05:39:04 2014 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 11 Jun 2014 05:39:04 +0000 Subject: RFR: JDK-8046474 Source changes needed to build JDK 9 with new platforms and compilers on Solaris and Linux Message-ID: <5397EB78.3010609@oracle.com> Please review in preparation for updating to new platforms and compilers on Solaris and Linux: This is a minor change to the make/jprt.properties and hotspot/make/jprt.properties files. Bug report: https://bugs.openjdk.java.net/browse/JDK-8046474 Webrev: http://cr.openjdk.java.net/~tbell/8046474/ Thank you- Tim From mikael.vidstedt at oracle.com Wed Jun 11 05:53:59 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 10 Jun 2014 22:53:59 -0700 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH In-Reply-To: <5397C2E6.6080603@oracle.com> References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com> Message-ID: <5397EEF7.5050006@oracle.com> David, Thanks for the feedback. Essentially the logic in the make//makefiles/defs.make files needs to recognize and deal with two different use cases: 1. ARCH being set by the JDK build system to the value of OPENJDK_TARGET_CPU_ARCH, or 2. no ARCH being set, in which case it needs to be populated - typically from uname Since Solaris and bsd both override ARCH they do not care about OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2. Linux/x86 is where most of the difference (and confusion) is, but I think aix/ppc64 will also change slightly since the ARCH value will go from ppc64 to ppc. I've tried to make the relevant changes, but I cannot verify that they actually work. cc:ing the ppc-aix list in the hope that somebody can help out with that. Summing it up, I have the following two webrevs: top: http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ With these changes I can build the normal platforms, but more verification is needed - esp. building hotspot only. Meanwhile feedback is much appreciated! Cheers, Mikael On 2014-06-10 19:45, David Holmes wrote: > Hi Mikael, > > This seems a reasonable proposal to me. We have an over-abundance of > "arch" variables and values, so reducing that is a good aim. > > As you note the main flow-on effect here is that the hotspot makefiles > have to be updated for the cases where OPENJDK_TARGET_CPU_ARCH and > OPENJDK_TARGET_CPU_LEGACY differ so that it still sets LIBARCH, > BUILDARCH, SRCARCH correctly. I think only x86 has that issue. > > Wouldn't it be nice if we could get rid of i386, i586, i686 etc both > internally and in the build artifacts and bundles! > > Cheers, > David > > On 11/06/2014 10:11 AM, Mikael Vidstedt wrote: >> >> All, >> >> I need some feedback and comments on the below fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ >> >> Background: >> >> When configuring the hotspot build the build system sets up the ARCH >> variable to reflect the target cpu. Currently the value is initialized >> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu name. For >> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). The >> goal in the new (JDK) build system is to have the "legacy" value >> gradually removed in favor of the other variables. >> >> Discussion: >> >> The two candidate variables to base ARCH on are as far as I can tell >> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two >> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well >> defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together >> with ARCH_DATA_MODEL/LP64 that information should be enough for the >> Hotspot build system to do its thing. Note: ARCH is currently ignored on >> solaris and bsd - it's overridden at the top of the respective >> make//makefiles/defs.make files. >> >> Before I go too far with this though I'd like to get some feedback on >> whether or not this is the right approach and what the exact value >> should be. Depending on the outcome of that the Hotspot build system may >> have to be updated for some platforms to support the new value(s). >> >> Thanks, >> Mikael >> From erik.joelsson at oracle.com Wed Jun 11 07:26:29 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 11 Jun 2014 09:26:29 +0200 Subject: RFR: JDK-8046474 Source changes needed to build JDK 9 with new platforms and compilers on Solaris and Linux In-Reply-To: <5397EB78.3010609@oracle.com> References: <5397EB78.3010609@oracle.com> Message-ID: <539804A5.6020603@oracle.com> Tim, looks good. /Erik On 2014-06-11 07:39, Tim Bell wrote: > Please review in preparation for updating to new platforms and > compilers on Solaris and Linux: > > This is a minor change to the make/jprt.properties and > hotspot/make/jprt.properties files. > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-8046474 > > Webrev: > > http://cr.openjdk.java.net/~tbell/8046474/ > > Thank you- > > Tim > From david.holmes at oracle.com Wed Jun 11 09:44:05 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Jun 2014 19:44:05 +1000 Subject: RFR: JDK-8046474 Source changes needed to build JDK 9 with new platforms and compilers on Solaris and Linux In-Reply-To: <5397EB78.3010609@oracle.com> References: <5397EB78.3010609@oracle.com> Message-ID: <539824E5.3010008@oracle.com> On 11/06/2014 3:39 PM, Tim Bell wrote: > Please review in preparation for updating to new platforms and compilers > on Solaris and Linux: Not so much preparation as once this is pushed JPRT will be using the new Solaris build platform. But in so much as this updated the Solaris platform used for JDK 9 in JPRT then it looks fine. David ----- > This is a minor change to the make/jprt.properties and > hotspot/make/jprt.properties files. > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-8046474 > > Webrev: > > http://cr.openjdk.java.net/~tbell/8046474/ > > Thank you- > > Tim > From henry.jen at oracle.com Wed Jun 11 16:24:24 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 11 Jun 2014 09:24:24 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <538D87EC.7080204@oracle.com> <0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com> <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com> Message-ID: <539882B8.3020301@oracle.com> On 06/10/2014 02:26 PM, David DeHaven wrote: > > Can I get another Review on this? > Looks good to me. >> >> $ sudo xcode-select -switch /Applications/old/Xcode4.app >> $ make clean; sh ./configure; make images >> Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active >> Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below) >> Hudson/JPRT should not be affected unless they also have Xcode 5 installed >> I assume this is because xcodebuild --version will report 4 in this case as 4 is set to active, but command line tools in /usr/bin are not updated accordingly? If --with-toolchain-path= work, perhaps we can set this based on version reported by xcodebuild? Cheers, Henry From david.dehaven at oracle.com Wed Jun 11 16:37:22 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 11 Jun 2014 09:37:22 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <539882B8.3020301@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <538D87EC.7080204@oracle.com> <0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com> <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com> <539882B8.3020301@oracle.com> Message-ID: <229438FB-F854-40E2-8E09-5878FADE20B0@oracle.com> >>> $ sudo xcode-select -switch /Applications/old/Xcode4.app >>> $ make clean; sh ./configure; make images >>> Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active >>> Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below) >>> Hudson/JPRT should not be affected unless they also have Xcode 5 installed >>> > > I assume this is because xcodebuild --version will report 4 in this case as 4 is set to active, but command line tools in /usr/bin are not updated accordingly? The stub tools seem to be hard wired to run clang, even if gcc really is there. This is only one of several problems with Apple's command line tools at the moment. Another more annoying issue is when you run lipo from /usr/bin with Xcode 4 active it will deadlock. > If --with-toolchain-path= work, perhaps we can set this based on version reported by xcodebuild? I thought about that, but the workaround should be good enough for our purposes. The goal is for everyone to be able to build on Xcode 5 with clang anyways :) -DrD- From gnu.andrew at redhat.com Wed Jun 11 17:03:39 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 11 Jun 2014 13:03:39 -0400 (EDT) Subject: URGENT RFR: 8041141: JDK9 emb build failure on PPC platform In-Reply-To: <5355AF58.6040809@oracle.com> References: <5355AF58.6040809@oracle.com> Message-ID: <1590192238.23041739.1402506219778.JavaMail.zimbra@redhat.com> ----- Original Message ----- > http://cr.openjdk.java.net/~dholmes/8041141/webrev/ > > The recent changes to convert warnings to errors didn't account for some > type-punning warnings in our Embedded PPC build due to the use of > strict-aliasing. Really we shouldn't be using strict-aliasing so this > change (which for some reason is in the open flags.m4 file) brings ppc > in-line with all other platforms and sets -fno-strict-aliasing > > I will be pushing this to jdk9/dev as we need this fixed immediately. > > Thanks, > David > Hi David, I just stumbled across this when trying to work out why we are seeing aliasing warnings in the demo code only on PPC builds. They get flagged by our build process. This exclusion of fno-strict-aliasing on PPC seems to date back to 7027910 in OpenJDK 7, where we are seeing the warnings, and there seems to be no explanation as to why it was added in either the code or reviews. Given -fno-strict-aliasing is now being used on all architectures in 9, do you think it's ok to do the same in 7? I could also turn it off on the individual files, but this would duplicate the flag on other architectures and we may then get more PPC-only warnings in future. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.dehaven at oracle.com Wed Jun 11 23:24:11 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 11 Jun 2014 16:24:11 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> <538C3F03.7020207@oracle.com> <538D87EC.7080204@oracle.com> <0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com> <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com> Message-ID: <75BA6A2F-9D22-4FB5-8FF1-6E936FC0B156@oracle.com> And just FYI, I got a mostly clean JPRT run: Four failures, a couple already tracked by the following issues: https://bugs.openjdk.java.net/browse/INTJDK-7609054 https://bugs.openjdk.java.net/browse/JDK-8043951 (reported to jprt_admin) This might be related to the latter as it happened only on the same Solaris 10 systems: TEST: sun/security/tools/keytool/default_options.sh JDK under test: (/tmp/jprt/P1/201308.ddehaven/testproduct/solaris_sparcv9_5.10-product) java version "1.9.0-internal" Java(TM) SE Runtime Environment (build 1.9.0-internal-201406112013.ddehaven.jdk9-dev-b00) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-201406112013.ddehaven.jdk9-dev-b00, mixed mode) ACTION: shell -- Failed. Execution failed: exit code 1 REASON: Assumed action based on file name: run shell default_options.sh TIME: 0.012 seconds messages: command: shell default_options.sh reason: Assumed action based on file name: run shell default_options.sh elapsed time (seconds): 0.012 STDOUT: STDERR: /tmp/jprt/P1/201308.ddehaven/s/jdk/test/sun/security/tools/keytool/default_options.sh: PASS=changeit: is not an identifier The last failure was due to an assertion failure in the test report generator (???), the tests themselves passed so I'm not concerned about it. -DrD- > Next (hopefully last??) update: > http://cr.openjdk.java.net/~ddehaven/8043340/v3 > > (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch) > > I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way. > > > These comments in flags.m4 are a bit misleading and not really true: > # FIXME: This needs to be exported in spec.gmk due to closed legacy code. > # FIXME: clean this up, and/or move it elsewhere. > > So, I removed them... > > I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name. > > > > Testing: > > I now have two system configurations I'm testing with: > 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk) > 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else) > > System 1 tests: > $ sudo xcode-select -switch /Applications/Xcode.app > $ make clean; sh ./configure; make images > ... > 00:09:17 TOTAL > ------------------------- > Finished building Java(TM) for target 'images' > > > $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images > ... > 00:13:37 TOTAL > ------------------------- > Finished building Java(TM) for target 'images' > > (Note that building with Xcode 5/clang is faster...) > > > $ sudo xcode-select -switch /Applications/old/Xcode4.app > $ make clean; sh ./configure; make images > Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active > Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below) > Hudson/JPRT should not be affected unless they also have Xcode 5 installed > > > $ make clean; sh ./configure --with-toolchain-type=clang; make images > ... > 00:10:54 TOTAL > ------------------------- > Finished building Java(TM) for target 'images' > > > System 2 tests: > OpenJDK only (ignore the time, I had it pulling closed jdk while building): > $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images > ... > 00:20:26 TOTAL > ------------------------- > Finished building OpenJDK for target 'images' > > > Closed JDK (images only, deploy/install expected to fail) > $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images > ... > 00:10:05 TOTAL > ------------------------- > Finished building Java(TM) for target 'images' > > -DrD- > From david.holmes at oracle.com Thu Jun 12 01:29:53 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Jun 2014 11:29:53 +1000 Subject: URGENT RFR: 8041141: JDK9 emb build failure on PPC platform In-Reply-To: <1590192238.23041739.1402506219778.JavaMail.zimbra@redhat.com> References: <5355AF58.6040809@oracle.com> <1590192238.23041739.1402506219778.JavaMail.zimbra@redhat.com> Message-ID: <53990291.6030507@oracle.com> Hi Andrew, On 12/06/2014 3:03 AM, Andrew Hughes wrote: > ----- Original Message ----- >> http://cr.openjdk.java.net/~dholmes/8041141/webrev/ >> >> The recent changes to convert warnings to errors didn't account for some >> type-punning warnings in our Embedded PPC build due to the use of >> strict-aliasing. Really we shouldn't be using strict-aliasing so this >> change (which for some reason is in the open flags.m4 file) brings ppc >> in-line with all other platforms and sets -fno-strict-aliasing >> >> I will be pushing this to jdk9/dev as we need this fixed immediately. >> >> Thanks, >> David >> > > Hi David, > > I just stumbled across this when trying to work out why we are seeing aliasing > warnings in the demo code only on PPC builds. They get flagged by our build process. > This exclusion of fno-strict-aliasing on PPC seems to date back to 7027910 in OpenJDK > 7, where we are seeing the warnings, and there seems to be no explanation as to why > it was added in either the code or reviews. It was copied from our internal build instructions. The new build unfortunately required it to be exposed in flags.m4. > Given -fno-strict-aliasing is now being used on all architectures in 9, do you think > it's ok to do the same in 7? I could also turn it off on the individual files, but > this would duplicate the flag on other architectures and we may then get more PPC-only > warnings in future. I think it should be fine in principle. I'm not sure what the actual change in 7 would be. David ----- > Thanks, > From aph at redhat.com Thu Jun 12 13:53:44 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 Jun 2014 14:53:44 +0100 Subject: URGENT RFR: 8041141: JDK9 emb build failure on PPC platform In-Reply-To: <1590192238.23041739.1402506219778.JavaMail.zimbra@redhat.com> References: <5355AF58.6040809@oracle.com> <1590192238.23041739.1402506219778.JavaMail.zimbra@redhat.com> Message-ID: <5399B0E8.8050107@redhat.com> Hi, On 06/11/2014 06:03 PM, Andrew Hughes wrote: > > I just stumbled across this when trying to work out why we are seeing aliasing > warnings in the demo code only on PPC builds. They get flagged by our build process. > This exclusion of fno-strict-aliasing on PPC seems to date back to 7027910 in OpenJDK > 7, where we are seeing the warnings, and there seems to be no explanation as to why > it was added in either the code or reviews. > > Given -fno-strict-aliasing is now being used on all architectures in 9, do you think > it's ok to do the same in 7? I could also turn it off on the individual files, but > this would duplicate the flag on other architectures and we may then get more PPC-only > warnings in future. Never mind the warnings, -fno-strict-aliasing is essential for correctness. Andrew. From mikael.vidstedt at oracle.com Thu Jun 12 21:18:49 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 12 Jun 2014 14:18:49 -0700 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH In-Reply-To: <5397EEF7.5050006@oracle.com> References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com> Message-ID: <539A1939.80103@oracle.com> I have now verified that the changes work just fine for the platforms we build and test - both from the top level and when building hotspot only. Taking suggestions on other tests to perform. And it would be great if somebody could test the changes on on aix/ppc. So, kindly asking for "real"/final reviews of the changes: top: http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ Cheers, Mikael On 2014-06-10 22:53, Mikael Vidstedt wrote: > > David, > > Thanks for the feedback. Essentially the logic in the > make//makefiles/defs.make files needs to recognize and deal with > two different use cases: > > 1. ARCH being set by the JDK build system to the value of > OPENJDK_TARGET_CPU_ARCH, or > 2. no ARCH being set, in which case it needs to be populated - > typically from uname > > Since Solaris and bsd both override ARCH they do not care about > OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2. > > Linux/x86 is where most of the difference (and confusion) is, but I > think aix/ppc64 will also change slightly since the ARCH value will go > from ppc64 to ppc. I've tried to make the relevant changes, but I > cannot verify that they actually work. cc:ing the ppc-aix list in the > hope that somebody can help out with that. > > > Summing it up, I have the following two webrevs: > > top: > http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ > hotspot: > http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ > > With these changes I can build the normal platforms, but more > verification is needed - esp. building hotspot only. Meanwhile > feedback is much appreciated! > > Cheers, > Mikael > > On 2014-06-10 19:45, David Holmes wrote: >> Hi Mikael, >> >> This seems a reasonable proposal to me. We have an over-abundance of >> "arch" variables and values, so reducing that is a good aim. >> >> As you note the main flow-on effect here is that the hotspot >> makefiles have to be updated for the cases where >> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so that >> it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think only x86 >> has that issue. >> >> Wouldn't it be nice if we could get rid of i386, i586, i686 etc both >> internally and in the build artifacts and bundles! >> >> Cheers, >> David >> >> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote: >>> >>> All, >>> >>> I need some feedback and comments on the below fix: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 >>> Webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ >>> >>> Background: >>> >>> When configuring the hotspot build the build system sets up the ARCH >>> variable to reflect the target cpu. Currently the value is initialized >>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu name. >>> For >>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). The >>> goal in the new (JDK) build system is to have the "legacy" value >>> gradually removed in favor of the other variables. >>> >>> Discussion: >>> >>> The two candidate variables to base ARCH on are as far as I can tell >>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two >>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well >>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together >>> with ARCH_DATA_MODEL/LP64 that information should be enough for the >>> Hotspot build system to do its thing. Note: ARCH is currently >>> ignored on >>> solaris and bsd - it's overridden at the top of the respective >>> make//makefiles/defs.make files. >>> >>> Before I go too far with this though I'd like to get some feedback on >>> whether or not this is the right approach and what the exact value >>> should be. Depending on the outcome of that the Hotspot build system >>> may >>> have to be updated for some platforms to support the new value(s). >>> >>> Thanks, >>> Mikael >>> > From erik.joelsson at oracle.com Fri Jun 13 06:56:44 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 13 Jun 2014 08:56:44 +0200 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH In-Reply-To: <539A1939.80103@oracle.com> References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com> <539A1939.80103@oracle.com> Message-ID: <539AA0AC.6090202@oracle.com> Looks fine to me. /Erik On 2014-06-12 23:18, Mikael Vidstedt wrote: > > I have now verified that the changes work just fine for the platforms > we build and test - both from the top level and when building hotspot > only. Taking suggestions on other tests to perform. And it would be > great if somebody could test the changes on on aix/ppc. > > So, kindly asking for "real"/final reviews of the changes: > > top: > http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ > hotspot: > http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ > > Cheers, > Mikael > > On 2014-06-10 22:53, Mikael Vidstedt wrote: >> >> David, >> >> Thanks for the feedback. Essentially the logic in the >> make//makefiles/defs.make files needs to recognize and deal with >> two different use cases: >> >> 1. ARCH being set by the JDK build system to the value of >> OPENJDK_TARGET_CPU_ARCH, or >> 2. no ARCH being set, in which case it needs to be populated - >> typically from uname >> >> Since Solaris and bsd both override ARCH they do not care about >> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2. >> >> Linux/x86 is where most of the difference (and confusion) is, but I >> think aix/ppc64 will also change slightly since the ARCH value will >> go from ppc64 to ppc. I've tried to make the relevant changes, but I >> cannot verify that they actually work. cc:ing the ppc-aix list in the >> hope that somebody can help out with that. >> >> >> Summing it up, I have the following two webrevs: >> >> top: >> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >> hotspot: >> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >> >> With these changes I can build the normal platforms, but more >> verification is needed - esp. building hotspot only. Meanwhile >> feedback is much appreciated! >> >> Cheers, >> Mikael >> >> On 2014-06-10 19:45, David Holmes wrote: >>> Hi Mikael, >>> >>> This seems a reasonable proposal to me. We have an over-abundance of >>> "arch" variables and values, so reducing that is a good aim. >>> >>> As you note the main flow-on effect here is that the hotspot >>> makefiles have to be updated for the cases where >>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so that >>> it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think only >>> x86 has that issue. >>> >>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc both >>> internally and in the build artifacts and bundles! >>> >>> Cheers, >>> David >>> >>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote: >>>> >>>> All, >>>> >>>> I need some feedback and comments on the below fix: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 >>>> Webrev: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ >>>> >>>> Background: >>>> >>>> When configuring the hotspot build the build system sets up the ARCH >>>> variable to reflect the target cpu. Currently the value is initialized >>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu >>>> name. For >>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). The >>>> goal in the new (JDK) build system is to have the "legacy" value >>>> gradually removed in favor of the other variables. >>>> >>>> Discussion: >>>> >>>> The two candidate variables to base ARCH on are as far as I can tell >>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two >>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well >>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together >>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the >>>> Hotspot build system to do its thing. Note: ARCH is currently >>>> ignored on >>>> solaris and bsd - it's overridden at the top of the respective >>>> make//makefiles/defs.make files. >>>> >>>> Before I go too far with this though I'd like to get some feedback on >>>> whether or not this is the right approach and what the exact value >>>> should be. Depending on the outcome of that the Hotspot build >>>> system may >>>> have to be updated for some platforms to support the new value(s). >>>> >>>> Thanks, >>>> Mikael >>>> >> > From david.dehaven at oracle.com Fri Jun 13 21:44:27 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 13 Jun 2014 14:44:27 -0700 Subject: [8u20] RFR: 8038027: DTDBuilder should be run in headless mode In-Reply-To: References: Message-ID: <7B80EEDA-26C8-4A73-9EBF-77D37D280FF0@oracle.com> And now actually including build-dev... Please review this slightly different backport of JDK-8038027 to 8u. -DrD- > > Please review my trivial backport of JDK-8038027. The actual change is identical to 9, the difference is the surrounding $(JAVA) is $(JAVA_SMALL) in JDK 9. > > JBS Issue: > https://bugs.openjdk.java.net/browse/JDK-8038027 > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0eab6c63201d > > JDK 9 review: > http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012182.html > > 8u patch: > --- cut here --- > diff --git a/make/Tools.gmk b/make/Tools.gmk > --- a/make/Tools.gmk > +++ b/make/Tools.gmk > @@ -80,6 +80,7 @@ > build.tools.generatecharacter.CharacterName > > TOOL_DTDBUILDER = $(JAVA) -Ddtd_home=$(JDK_TOPDIR)/make/data/dtdbuilder \ > + -Djava.awt.headless=true \ > -cp $(JDK_OUTPUTDIR)/btclasses build.tools.dtdbuilder.DTDBuilder > > TOOL_GENERATEBREAKITERATORDATA = $(JAVA) \ > --- cut here --- > > -DrD- > From david.dehaven at oracle.com Sat Jun 14 01:09:38 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 13 Jun 2014 18:09:38 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: References: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com> <173AECD0-7B32-4F00-BE8B-20003C6E0990@oracle.com> <539905F1.7060509@oracle.com> Message-ID: Updated. I kicked off a JPRT -bo run to be sure it doesn't break something else. http://cr.openjdk.java.net/~ddehaven/8043340/v4/ Only change from previous is in make/bsd/makefiles/saproc.make, I added SA_SYSROOT_FLAGS which is set to SYSROOT_CFLAGS. I didn't want to add SYSROOT_CFLAGS to the compile command in case $(CC) expands to something that includes the same args on non-Mac platforms, this seems safer. -DrD- > > Yes, I was going for convenience and minimizing disturbance. I'll change how the flags are passed. > > If SDKROOT is unset then the paths point at the existing hard-coded paths in /System/Library/Frameworks, all SDKROOT does is prepend the SDK path and it's only set under certain conditions. JPRT has been perfectly happy with this change so far. > > Note that this ugliness can go away when we remove the dependencies on the JavaNativeFoundation and JavaRuntimeSupport frameworks. > > -DrD- > >> Hi David, >> >> In saproc.make: >> >> Hijacking SAARCH seems wrong - convenient perhaps, but wrong. What you are adding is nothing to do with the ARCH setting. If none of the existing variables are suitable perhaps just add SA_CFLAGS? >> >> If SDKROOT is not set is the path one that would normally exist? In particular does it exist on all our JPRT clients? >> >> Thanks, >> David H. >> >> On 12/06/2014 6:06 AM, David DeHaven wrote: >>> >>> Can I get hotspot signoff on the (fairly trivial) hotspot changes for this? >>> >>> The hotspot specific changes are here: >>> http://cr.openjdk.java.net/~ddehaven/8043340/v3/hotspot/ >>> >>> Also, is there a problem if I push these through jdk9/build instead of going through hotspot? >>> >>> I'm re-submitting a JPRT run, now that JDK-8045998 has been fixed I should actually get valid results. >>> >>> -DrD- >>> >>>> From: David DeHaven >>>> Subject: Re: RFR: [9] 8043340 & 8043591: [macosx] Build system issues >>>> Date: June 4, 2014 16:01:29 PDT >>>> To: build-dev build-dev >>>> >>>> >>>> Next (hopefully last??) update: >>>> http://cr.openjdk.java.net/~ddehaven/8043340/v3 >>>> >>>> (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch) >>>> >>>> I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way. >>>> >>>> >>>> These comments in flags.m4 are a bit misleading and not really true: >>>> # FIXME: This needs to be exported in spec.gmk due to closed legacy code. >>>> # FIXME: clean this up, and/or move it elsewhere. >>>> >>>> So, I removed them... >>>> >>>> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name. >>>> >>>> >>>> >>>> Testing: >>>> >>>> I now have two system configurations I'm testing with: >>>> 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk) >>>> 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else) >>>> >>>> System 1 tests: >>>> $ sudo xcode-select -switch /Applications/Xcode.app >>>> $ make clean; sh ./configure; make images >>>> ... >>>> 00:09:17 TOTAL >>>> ------------------------- >>>> Finished building Java(TM) for target 'images' >>>> >>>> >>>> $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images >>>> ... >>>> 00:13:37 TOTAL >>>> ------------------------- >>>> Finished building Java(TM) for target 'images' >>>> >>>> (Note that building with Xcode 5/clang is faster...) >>>> >>>> >>>> $ sudo xcode-select -switch /Applications/old/Xcode4.app >>>> $ make clean; sh ./configure; make images >>>> Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active >>>> Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below) >>>> Hudson/JPRT should not be affected unless they also have Xcode 5 installed >>>> >>>> >>>> $ make clean; sh ./configure --with-toolchain-type=clang; make images >>>> ... >>>> 00:10:54 TOTAL >>>> ------------------------- >>>> Finished building Java(TM) for target 'images' >>>> >>>> >>>> System 2 tests: >>>> OpenJDK only (ignore the time, I had it pulling closed jdk while building): >>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images >>>> ... >>>> 00:20:26 TOTAL >>>> ------------------------- >>>> Finished building OpenJDK for target 'images' >>>> >>>> >>>> Closed JDK (images only, deploy/install expected to fail) >>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images >>>> ... >>>> 00:10:05 TOTAL >>>> ------------------------- >>>> Finished building Java(TM) for target 'images' >>>> >>>> -DrD- >>>> >>> > From jin.phd at gmail.com Mon Jun 16 03:53:49 2014 From: jin.phd at gmail.com (Jin Mingjian) Date: Mon, 16 Jun 2014 11:53:49 +0800 Subject: OpenJDK 8 compact profiles fail to build with make 4.0 In-Reply-To: <538D35C0.7030509@oracle.com> References: <5389DA93.4080705@apache.org> <538C8580.8060102@oracle.com> <538D35C0.7030509@oracle.com> Message-ID: Too long to go back:) Erik, great to find it is the dollar escaping problem of make finally:) thanks, Jin On Tue, Jun 3, 2014 at 10:41 AM, David Holmes wrote: > Hi Erik, > > This is great news! The dollar escaping stuff was a nightmare. > > Thanks, > David > > > On 3/06/2014 12:09 AM, Erik Joelsson wrote: > >> Hello Emmanuel, >> >> I remember that piece of make logic being especially tricky to get >> working and it seems the weirdness in make has been fixed in make 4.0, >> or at least changed. Our dealing with escaping dollars is rather messy >> in JDK 8. I have recently worked on this in a JDK 9 project, where I >> have chosen a different approach that seems to work with both 3.8x and >> 4.0. The idea is based on defining this macro in make/common/MakeBase.gmk: >> >> ############################################################ >> #################### >> >> # This macro translates $ into \$ to protect the $ from expansion in the >> shell. >> # To make this macro resilient against already escaped strings, first >> remove >> # any present escapes before escaping so that no double escapes are added. >> EscapeDollar = $(subst $$,\$$,$(subst \$$,$$,$(strip $1))) >> >> And then instead of escaping dollars explicitly in make variable >> declarations, just call that macro before giving anything containing >> dollars to the shell. >> >> --- a/make/CreateJars.gmk >> +++ b/make/CreateJars.gmk >> @@ -302,17 +302,15 @@ >> # methods from classes that only go into the profile builds. >> BEANLESS_CLASSES = $(IMAGES_OUTPUTDIR)/beanless >> >> -# When there are $ characters in filenames we have some very subtle >> interactions between >> -# make expansion and shell expansion. In this particular case $< will >> contain a single $ while >> -# $@ will contain \$. So we have to pass $< in single-quotes to avoid >> shell expansion >> $(BEANLESS_CLASSES)/%: $(JDK_OUTPUTDIR)/classes/% >> $(MKDIR) -p $(@D) >> - $(TOOL_REMOVEMETHODS) '$<' $@ addPropertyChangeListener >> removePropertyChangeListener >> + $(TOOL_REMOVEMETHODS) $(call EscapeDollar, $<) $(call EscapeDollar, >> $@) \ >> + addPropertyChangeListener removePropertyChangeListener >> >> CLASSES_TO_DEBEAN = \ >> java/util/logging/LogManager.class \ >> - java/util/jar/Pack200\$$Packer.class \ >> - java/util/jar/Pack200\$$Unpacker.class \ >> + java/util/jar/Pack200$$Packer.class \ >> + java/util/jar/Pack200$$Unpacker.class \ >> com/sun/java/util/jar/pack/PackerImpl.class \ >> com/sun/java/util/jar/pack/UnpackerImpl.class >> >> @@ -345,7 +343,7 @@ >> $(CD) $(patsubst %$(VERSION_CLASS_PATH), %, $(CLASS_FILE)) && \ >> $(JAR) $(RT_JAR_UPDATE_OPTIONS) $@.tmp $(VERSION_CLASS_PATH); \ >> $(CD) $(BEANLESS_CLASSES) && \ >> - $(JAR) $(RT_JAR_UPDATE_OPTIONS) $@.tmp $(CLASSES_TO_DEBEAN); \ >> + $(JAR) $(RT_JAR_UPDATE_OPTIONS) $@.tmp $(call EscapeDollar, >> $(CLASSES_TO_DEBEAN)); \ >> fi >> $(MV) $@.tmp $@ >> >> The patch above works for me at least. >> >> /Erik >> >> On 2014-05-31 15:35, Emmanuel Bourg wrote: >> >>> Hi, >>> >>> I'd like to report an issue with the build for the OpenJDK 8 compact >>> profiles. On Debian the build fails when PropertyChangeListener is >>> removed from the pack200 classes: >>> >>> ## Starting profiles >>> /usr/bin/find: `/home/ebourg/jdk8u-dev/build/images/lib': No such file >>> or directory >>> make[2]: *** No rule to make target >>> '/home/ebourg/jdk8u-dev/build/images/beanless/java/util/jar/ >>> Pack200\$Packer.class', >>> >>> needed by '/home/ebourg/jdk8u-dev/build/images/libprofile_1/rt.jar'. >>> Stop. >>> make[2]: *** Waiting for unfinished jobs.... >>> Removed method >>> addPropertyChangeListener(java.beans.PropertyChangeListener) from >>> java/util/logging/LogManager >>> Removed method >>> removePropertyChangeListener(java.beans.PropertyChangeListener) from >>> java/util/logging/LogManager >>> BuildJdk.gmk:113: recipe for target 'profile_1' failed >>> make[1]: *** [profile_1] Error 2 >>> /home/ebourg/jdk8u-dev//make/Main.gmk:147: recipe for target >>> 'profiles-only' failed >>> make: *** [profiles-only] Error 2 >>> >>> >>> The same issue was reported last year on Arch Linux: >>> >>> http://mail.openjdk.java.net/pipermail/build-dev/2013-July/009557.html >>> >>> It looks like this error is caused by GNU Make 4.0 which is now the >>> default in Debian. I was able to build the compact profiles after >>> downgrading make to the version 3.81. >>> >>> OpenJDK 9 isn't affected by this issue because the >>> add/removePropertyChangeListener() methods are already removed. >>> >>> Make 4.0 caused another regression (JDK-8028407) which has been fixed >>> for OpenJDK 9. Could you also consider backporting it to OpenJDK 8 >>> please? >>> >>> Thank you, >>> >>> Emmanuel Bourg >>> >> >> From erik.joelsson at oracle.com Mon Jun 16 07:46:43 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Jun 2014 09:46:43 +0200 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: References: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com> <173AECD0-7B32-4F00-BE8B-20003C6E0990@oracle.com> <539905F1.7060509@oracle.com> Message-ID: <539EA0E3.4020005@oracle.com> Looks good to me. /Erik On 2014-06-14 03:09, David DeHaven wrote: > Updated. I kicked off a JPRT -bo run to be sure it doesn't break something else. > > http://cr.openjdk.java.net/~ddehaven/8043340/v4/ > > Only change from previous is in make/bsd/makefiles/saproc.make, I added SA_SYSROOT_FLAGS which is set to SYSROOT_CFLAGS. I didn't want to add SYSROOT_CFLAGS to the compile command in case $(CC) expands to something that includes the same args on non-Mac platforms, this seems safer. > > -DrD- > > >> Yes, I was going for convenience and minimizing disturbance. I'll change how the flags are passed. >> >> If SDKROOT is unset then the paths point at the existing hard-coded paths in /System/Library/Frameworks, all SDKROOT does is prepend the SDK path and it's only set under certain conditions. JPRT has been perfectly happy with this change so far. >> >> Note that this ugliness can go away when we remove the dependencies on the JavaNativeFoundation and JavaRuntimeSupport frameworks. >> >> -DrD- >> >>> Hi David, >>> >>> In saproc.make: >>> >>> Hijacking SAARCH seems wrong - convenient perhaps, but wrong. What you are adding is nothing to do with the ARCH setting. If none of the existing variables are suitable perhaps just add SA_CFLAGS? >>> >>> If SDKROOT is not set is the path one that would normally exist? In particular does it exist on all our JPRT clients? >>> >>> Thanks, >>> David H. >>> >>> On 12/06/2014 6:06 AM, David DeHaven wrote: >>>> Can I get hotspot signoff on the (fairly trivial) hotspot changes for this? >>>> >>>> The hotspot specific changes are here: >>>> http://cr.openjdk.java.net/~ddehaven/8043340/v3/hotspot/ >>>> >>>> Also, is there a problem if I push these through jdk9/build instead of going through hotspot? >>>> >>>> I'm re-submitting a JPRT run, now that JDK-8045998 has been fixed I should actually get valid results. >>>> >>>> -DrD- >>>> >>>>> From: David DeHaven >>>>> Subject: Re: RFR: [9] 8043340 & 8043591: [macosx] Build system issues >>>>> Date: June 4, 2014 16:01:29 PDT >>>>> To: build-dev build-dev >>>>> >>>>> >>>>> Next (hopefully last??) update: >>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v3 >>>>> >>>>> (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch) >>>>> >>>>> I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way. >>>>> >>>>> >>>>> These comments in flags.m4 are a bit misleading and not really true: >>>>> # FIXME: This needs to be exported in spec.gmk due to closed legacy code. >>>>> # FIXME: clean this up, and/or move it elsewhere. >>>>> >>>>> So, I removed them... >>>>> >>>>> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name. >>>>> >>>>> >>>>> >>>>> Testing: >>>>> >>>>> I now have two system configurations I'm testing with: >>>>> 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk) >>>>> 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else) >>>>> >>>>> System 1 tests: >>>>> $ sudo xcode-select -switch /Applications/Xcode.app >>>>> $ make clean; sh ./configure; make images >>>>> ... >>>>> 00:09:17 TOTAL >>>>> ------------------------- >>>>> Finished building Java(TM) for target 'images' >>>>> >>>>> >>>>> $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images >>>>> ... >>>>> 00:13:37 TOTAL >>>>> ------------------------- >>>>> Finished building Java(TM) for target 'images' >>>>> >>>>> (Note that building with Xcode 5/clang is faster...) >>>>> >>>>> >>>>> $ sudo xcode-select -switch /Applications/old/Xcode4.app >>>>> $ make clean; sh ./configure; make images >>>>> Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active >>>>> Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below) >>>>> Hudson/JPRT should not be affected unless they also have Xcode 5 installed >>>>> >>>>> >>>>> $ make clean; sh ./configure --with-toolchain-type=clang; make images >>>>> ... >>>>> 00:10:54 TOTAL >>>>> ------------------------- >>>>> Finished building Java(TM) for target 'images' >>>>> >>>>> >>>>> System 2 tests: >>>>> OpenJDK only (ignore the time, I had it pulling closed jdk while building): >>>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images >>>>> ... >>>>> 00:20:26 TOTAL >>>>> ------------------------- >>>>> Finished building OpenJDK for target 'images' >>>>> >>>>> >>>>> Closed JDK (images only, deploy/install expected to fail) >>>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images >>>>> ... >>>>> 00:10:05 TOTAL >>>>> ------------------------- >>>>> Finished building Java(TM) for target 'images' >>>>> >>>>> -DrD- >>>>> From mikael.vidstedt at oracle.com Mon Jun 16 20:17:37 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 16 Jun 2014 13:17:37 -0700 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH In-Reply-To: <539AA0AC.6090202@oracle.com> References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com> <539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com> Message-ID: <539F50E1.7090300@oracle.com> Thanks Erik. Another review please? Cheers, Mikael On 2014-06-12 23:56, Erik Joelsson wrote: > Looks fine to me. > > /Erik > > On 2014-06-12 23:18, Mikael Vidstedt wrote: >> >> I have now verified that the changes work just fine for the platforms >> we build and test - both from the top level and when building hotspot >> only. Taking suggestions on other tests to perform. And it would be >> great if somebody could test the changes on on aix/ppc. >> >> So, kindly asking for "real"/final reviews of the changes: >> >> top: >> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >> hotspot: >> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >> >> Cheers, >> Mikael >> >> On 2014-06-10 22:53, Mikael Vidstedt wrote: >>> >>> David, >>> >>> Thanks for the feedback. Essentially the logic in the >>> make//makefiles/defs.make files needs to recognize and deal with >>> two different use cases: >>> >>> 1. ARCH being set by the JDK build system to the value of >>> OPENJDK_TARGET_CPU_ARCH, or >>> 2. no ARCH being set, in which case it needs to be populated - >>> typically from uname >>> >>> Since Solaris and bsd both override ARCH they do not care about >>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2. >>> >>> Linux/x86 is where most of the difference (and confusion) is, but I >>> think aix/ppc64 will also change slightly since the ARCH value will >>> go from ppc64 to ppc. I've tried to make the relevant changes, but I >>> cannot verify that they actually work. cc:ing the ppc-aix list in >>> the hope that somebody can help out with that. >>> >>> >>> Summing it up, I have the following two webrevs: >>> >>> top: >>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>> >>> hotspot: >>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>> >>> With these changes I can build the normal platforms, but more >>> verification is needed - esp. building hotspot only. Meanwhile >>> feedback is much appreciated! >>> >>> Cheers, >>> Mikael >>> >>> On 2014-06-10 19:45, David Holmes wrote: >>>> Hi Mikael, >>>> >>>> This seems a reasonable proposal to me. We have an over-abundance >>>> of "arch" variables and values, so reducing that is a good aim. >>>> >>>> As you note the main flow-on effect here is that the hotspot >>>> makefiles have to be updated for the cases where >>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so >>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think >>>> only x86 has that issue. >>>> >>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc >>>> both internally and in the build artifacts and bundles! >>>> >>>> Cheers, >>>> David >>>> >>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote: >>>>> >>>>> All, >>>>> >>>>> I need some feedback and comments on the below fix: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ >>>>> >>>>> Background: >>>>> >>>>> When configuring the hotspot build the build system sets up the ARCH >>>>> variable to reflect the target cpu. Currently the value is >>>>> initialized >>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu >>>>> name. For >>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). >>>>> The >>>>> goal in the new (JDK) build system is to have the "legacy" value >>>>> gradually removed in favor of the other variables. >>>>> >>>>> Discussion: >>>>> >>>>> The two candidate variables to base ARCH on are as far as I can tell >>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two >>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well >>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together >>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the >>>>> Hotspot build system to do its thing. Note: ARCH is currently >>>>> ignored on >>>>> solaris and bsd - it's overridden at the top of the respective >>>>> make//makefiles/defs.make files. >>>>> >>>>> Before I go too far with this though I'd like to get some feedback on >>>>> whether or not this is the right approach and what the exact value >>>>> should be. Depending on the outcome of that the Hotspot build >>>>> system may >>>>> have to be updated for some platforms to support the new value(s). >>>>> >>>>> Thanks, >>>>> Mikael >>>>> >>> >> > From david.holmes at oracle.com Tue Jun 17 02:49:22 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Jun 2014 12:49:22 +1000 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH In-Reply-To: <539F50E1.7090300@oracle.com> References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com> <539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com> <539F50E1.7090300@oracle.com> Message-ID: <539FACB2.2050508@oracle.com> Hi Mikael, Sorry for the delay ... make/aix/makefiles/defs.make: This change doesn't make sense to me: 48 ifneq (,$(findstring $(ARCH), ppc)) given that the logic immediately preceding this sets ARCH to either ppc or ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow for both 32-bit and 64-bit cross-builds but the earlier logic is really precluding this. So it seems to me that the changes in this file are completely unnecessary (or else the earlier logic also needs changing). --- make/linux/makefiles/defs.make This block: 86 # i686/i586 and amd64/x86_64 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586)) 88 ifeq ($(ARCH_DATA_MODEL), 64) 89 ARCH_DATA_MODEL = 64 90 MAKE_ARGS += LP64=1 91 PLATFORM = linux-amd64 92 VM_PLATFORM = linux_amd64 93 HS_ARCH = x86 94 else 95 ARCH_DATA_MODEL = 32 96 PLATFORM = linux-i586 97 VM_PLATFORM = linux_i486 98 HS_ARCH = x86 99 # We have to reset ARCH to i686 since SRCARCH relies on it 100 ARCH = i686 101 endif 102 endif seems to allow the user to try and do a 64-bit build on a 32-bit build machine. Not sure if that would get caught in an earlier sanity check? (Same is true for the sparc block). Also I don't think the following is actually true: # We have to reset ARCH to i686 since SRCARCH relies on it ARCH = i686 As long as ARCH is not amd64 and not x86_64 any 32-bit x86 architecture designator will simply map to a SRCARCH of x86, as per defs.make: SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc zero,$(ARCH))) ARCH/ = x86 ARCH/sparc = sparc ARCH/sparc64= sparc ARCH/ia64 = ia64 ARCH/amd64 = x86 ARCH/x86_64 = x86 ARCH/ppc64 = ppc ARCH/ppc = ppc ARCH/arm = arm ARCH/zero = zero Cheers, David On 17/06/2014 6:17 AM, Mikael Vidstedt wrote: > > Thanks Erik. Another review please? > > Cheers, > Mikael > > On 2014-06-12 23:56, Erik Joelsson wrote: >> Looks fine to me. >> >> /Erik >> >> On 2014-06-12 23:18, Mikael Vidstedt wrote: >>> >>> I have now verified that the changes work just fine for the platforms >>> we build and test - both from the top level and when building hotspot >>> only. Taking suggestions on other tests to perform. And it would be >>> great if somebody could test the changes on on aix/ppc. >>> >>> So, kindly asking for "real"/final reviews of the changes: >>> >>> top: >>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>> hotspot: >>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>> >>> >>> Cheers, >>> Mikael >>> >>> On 2014-06-10 22:53, Mikael Vidstedt wrote: >>>> >>>> David, >>>> >>>> Thanks for the feedback. Essentially the logic in the >>>> make//makefiles/defs.make files needs to recognize and deal with >>>> two different use cases: >>>> >>>> 1. ARCH being set by the JDK build system to the value of >>>> OPENJDK_TARGET_CPU_ARCH, or >>>> 2. no ARCH being set, in which case it needs to be populated - >>>> typically from uname >>>> >>>> Since Solaris and bsd both override ARCH they do not care about >>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2. >>>> >>>> Linux/x86 is where most of the difference (and confusion) is, but I >>>> think aix/ppc64 will also change slightly since the ARCH value will >>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I >>>> cannot verify that they actually work. cc:ing the ppc-aix list in >>>> the hope that somebody can help out with that. >>>> >>>> >>>> Summing it up, I have the following two webrevs: >>>> >>>> top: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>> >>>> hotspot: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>> >>>> >>>> With these changes I can build the normal platforms, but more >>>> verification is needed - esp. building hotspot only. Meanwhile >>>> feedback is much appreciated! >>>> >>>> Cheers, >>>> Mikael >>>> >>>> On 2014-06-10 19:45, David Holmes wrote: >>>>> Hi Mikael, >>>>> >>>>> This seems a reasonable proposal to me. We have an over-abundance >>>>> of "arch" variables and values, so reducing that is a good aim. >>>>> >>>>> As you note the main flow-on effect here is that the hotspot >>>>> makefiles have to be updated for the cases where >>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so >>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think >>>>> only x86 has that issue. >>>>> >>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc >>>>> both internally and in the build artifacts and bundles! >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote: >>>>>> >>>>>> All, >>>>>> >>>>>> I need some feedback and comments on the below fix: >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ >>>>>> >>>>>> Background: >>>>>> >>>>>> When configuring the hotspot build the build system sets up the ARCH >>>>>> variable to reflect the target cpu. Currently the value is >>>>>> initialized >>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu >>>>>> name. For >>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). >>>>>> The >>>>>> goal in the new (JDK) build system is to have the "legacy" value >>>>>> gradually removed in favor of the other variables. >>>>>> >>>>>> Discussion: >>>>>> >>>>>> The two candidate variables to base ARCH on are as far as I can tell >>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two >>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well >>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together >>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the >>>>>> Hotspot build system to do its thing. Note: ARCH is currently >>>>>> ignored on >>>>>> solaris and bsd - it's overridden at the top of the respective >>>>>> make//makefiles/defs.make files. >>>>>> >>>>>> Before I go too far with this though I'd like to get some feedback on >>>>>> whether or not this is the right approach and what the exact value >>>>>> should be. Depending on the outcome of that the Hotspot build >>>>>> system may >>>>>> have to be updated for some platforms to support the new value(s). >>>>>> >>>>>> Thanks, >>>>>> Mikael >>>>>> >>>> >>> >> > From david.holmes at oracle.com Tue Jun 17 02:52:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Jun 2014 12:52:42 +1000 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: References: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com> <173AECD0-7B32-4F00-BE8B-20003C6E0990@oracle.com> <539905F1.7060509@oracle.com> Message-ID: <539FAD7A.1040909@oracle.com> On 14/06/2014 11:09 AM, David DeHaven wrote: > > Updated. I kicked off a JPRT -bo run to be sure it doesn't break something else. > > http://cr.openjdk.java.net/~ddehaven/8043340/v4/ > > Only change from previous is in make/bsd/makefiles/saproc.make, I added SA_SYSROOT_FLAGS which is set to SYSROOT_CFLAGS. I didn't want to add SYSROOT_CFLAGS to the compile command in case $(CC) expands to something that includes the same args on non-Mac platforms, this seems safer. Thanks David. That change looks okay to me. David H. > -DrD- > > >> >> Yes, I was going for convenience and minimizing disturbance. I'll change how the flags are passed. >> >> If SDKROOT is unset then the paths point at the existing hard-coded paths in /System/Library/Frameworks, all SDKROOT does is prepend the SDK path and it's only set under certain conditions. JPRT has been perfectly happy with this change so far. >> >> Note that this ugliness can go away when we remove the dependencies on the JavaNativeFoundation and JavaRuntimeSupport frameworks. >> >> -DrD- >> >>> Hi David, >>> >>> In saproc.make: >>> >>> Hijacking SAARCH seems wrong - convenient perhaps, but wrong. What you are adding is nothing to do with the ARCH setting. If none of the existing variables are suitable perhaps just add SA_CFLAGS? >>> >>> If SDKROOT is not set is the path one that would normally exist? In particular does it exist on all our JPRT clients? >>> >>> Thanks, >>> David H. >>> >>> On 12/06/2014 6:06 AM, David DeHaven wrote: >>>> >>>> Can I get hotspot signoff on the (fairly trivial) hotspot changes for this? >>>> >>>> The hotspot specific changes are here: >>>> http://cr.openjdk.java.net/~ddehaven/8043340/v3/hotspot/ >>>> >>>> Also, is there a problem if I push these through jdk9/build instead of going through hotspot? >>>> >>>> I'm re-submitting a JPRT run, now that JDK-8045998 has been fixed I should actually get valid results. >>>> >>>> -DrD- >>>> >>>>> From: David DeHaven >>>>> Subject: Re: RFR: [9] 8043340 & 8043591: [macosx] Build system issues >>>>> Date: June 4, 2014 16:01:29 PDT >>>>> To: build-dev build-dev >>>>> >>>>> >>>>> Next (hopefully last??) update: >>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v3 >>>>> >>>>> (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch) >>>>> >>>>> I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way. >>>>> >>>>> >>>>> These comments in flags.m4 are a bit misleading and not really true: >>>>> # FIXME: This needs to be exported in spec.gmk due to closed legacy code. >>>>> # FIXME: clean this up, and/or move it elsewhere. >>>>> >>>>> So, I removed them... >>>>> >>>>> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name. >>>>> >>>>> >>>>> >>>>> Testing: >>>>> >>>>> I now have two system configurations I'm testing with: >>>>> 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk) >>>>> 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else) >>>>> >>>>> System 1 tests: >>>>> $ sudo xcode-select -switch /Applications/Xcode.app >>>>> $ make clean; sh ./configure; make images >>>>> ... >>>>> 00:09:17 TOTAL >>>>> ------------------------- >>>>> Finished building Java(TM) for target 'images' >>>>> >>>>> >>>>> $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images >>>>> ... >>>>> 00:13:37 TOTAL >>>>> ------------------------- >>>>> Finished building Java(TM) for target 'images' >>>>> >>>>> (Note that building with Xcode 5/clang is faster...) >>>>> >>>>> >>>>> $ sudo xcode-select -switch /Applications/old/Xcode4.app >>>>> $ make clean; sh ./configure; make images >>>>> Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active >>>>> Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below) >>>>> Hudson/JPRT should not be affected unless they also have Xcode 5 installed >>>>> >>>>> >>>>> $ make clean; sh ./configure --with-toolchain-type=clang; make images >>>>> ... >>>>> 00:10:54 TOTAL >>>>> ------------------------- >>>>> Finished building Java(TM) for target 'images' >>>>> >>>>> >>>>> System 2 tests: >>>>> OpenJDK only (ignore the time, I had it pulling closed jdk while building): >>>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images >>>>> ... >>>>> 00:20:26 TOTAL >>>>> ------------------------- >>>>> Finished building OpenJDK for target 'images' >>>>> >>>>> >>>>> Closed JDK (images only, deploy/install expected to fail) >>>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images >>>>> ... >>>>> 00:10:05 TOTAL >>>>> ------------------------- >>>>> Finished building Java(TM) for target 'images' >>>>> >>>>> -DrD- >>>>> >>>> >> > From mikael.vidstedt at oracle.com Tue Jun 17 19:11:16 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 17 Jun 2014 12:11:16 -0700 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH In-Reply-To: <539FACB2.2050508@oracle.com> References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com> <539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com> <539F50E1.7090300@oracle.com> <539FACB2.2050508@oracle.com> Message-ID: <53A092D4.3060100@oracle.com> New webrev here (only the hotspot part, the webrev for top hasn't changed): http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/ Comments inline. On 2014-06-16 19:49, David Holmes wrote: > Hi Mikael, > > Sorry for the delay ... > > make/aix/makefiles/defs.make: > > This change doesn't make sense to me: > > 48 ifneq (,$(findstring $(ARCH), ppc)) > > given that the logic immediately preceding this sets ARCH to either > ppc or ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow > for both 32-bit and 64-bit cross-builds but the earlier logic is > really precluding this. So it seems to me that the changes in this > file are completely unnecessary (or else the earlier logic also needs > changing). Indeed, that is correct - I missed the fact that ARCH is always overriden to be either ppc or ppc64. The old logic is unnecessarily hard to follow, but I guess that's in line with our hotspot Makefiles in general ;) I'll revert the changes to the file and add a mental note to self and others that linux appears to be the only platform where the incoming value of ARCH is actually honored - it's ignored/overridden on Solaris, BSD and AIX. > make/linux/makefiles/defs.make > > This block: > > 86 # i686/i586 and amd64/x86_64 > 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586)) > 88 ifeq ($(ARCH_DATA_MODEL), 64) > 89 ARCH_DATA_MODEL = 64 > 90 MAKE_ARGS += LP64=1 > 91 PLATFORM = linux-amd64 > 92 VM_PLATFORM = linux_amd64 > 93 HS_ARCH = x86 > 94 else > 95 ARCH_DATA_MODEL = 32 > 96 PLATFORM = linux-i586 > 97 VM_PLATFORM = linux_i486 > 98 HS_ARCH = x86 > 99 # We have to reset ARCH to i686 since SRCARCH relies on it > 100 ARCH = i686 > 101 endif > 102 endif > > seems to allow the user to try and do a 64-bit build on a 32-bit build > machine. Not sure if that would get caught in an earlier sanity check? > (Same is true for the sparc block). While the changes are primarily just intended to cut down on the duplication I don't immediately see the reason why we wouldn't want to allow compiling a 64-bit VM from a 32-bit machine? We're cross compiling all sorts of platforms, so why not allow this if the compiler supports it? I'd prefer to keep it this way. > Also I don't think the following is actually true: > > # We have to reset ARCH to i686 since SRCARCH relies on it > ARCH = i686 > > As long as ARCH is not amd64 and not x86_64 any 32-bit x86 > architecture designator will simply map to a SRCARCH of x86, as per > defs.make: > > SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm > ppc zero,$(ARCH))) > ARCH/ = x86 > ARCH/sparc = sparc > ARCH/sparc64= sparc > ARCH/ia64 = ia64 > ARCH/amd64 = x86 > ARCH/x86_64 = x86 > ARCH/ppc64 = ppc > ARCH/ppc = ppc > ARCH/arm = arm > ARCH/zero = zero Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64, ppc64, ppc, arm, zero } it will map to x86 anyway. I thought about cleaning that up before I sent out the first webrev, but soon found myself doing way more cleanup than was healthy for this specific change. However, since I had to update this change anyway I removed the ARCH reset part. Cheers, Mikael > > > Cheers, > David > > On 17/06/2014 6:17 AM, Mikael Vidstedt wrote: >> >> Thanks Erik. Another review please? >> >> Cheers, >> Mikael >> >> On 2014-06-12 23:56, Erik Joelsson wrote: >>> Looks fine to me. >>> >>> /Erik >>> >>> On 2014-06-12 23:18, Mikael Vidstedt wrote: >>>> >>>> I have now verified that the changes work just fine for the platforms >>>> we build and test - both from the top level and when building hotspot >>>> only. Taking suggestions on other tests to perform. And it would be >>>> great if somebody could test the changes on on aix/ppc. >>>> >>>> So, kindly asking for "real"/final reviews of the changes: >>>> >>>> top: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>> >>>> hotspot: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>> >>>> >>>> >>>> Cheers, >>>> Mikael >>>> >>>> On 2014-06-10 22:53, Mikael Vidstedt wrote: >>>>> >>>>> David, >>>>> >>>>> Thanks for the feedback. Essentially the logic in the >>>>> make//makefiles/defs.make files needs to recognize and deal with >>>>> two different use cases: >>>>> >>>>> 1. ARCH being set by the JDK build system to the value of >>>>> OPENJDK_TARGET_CPU_ARCH, or >>>>> 2. no ARCH being set, in which case it needs to be populated - >>>>> typically from uname >>>>> >>>>> Since Solaris and bsd both override ARCH they do not care about >>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2. >>>>> >>>>> Linux/x86 is where most of the difference (and confusion) is, but I >>>>> think aix/ppc64 will also change slightly since the ARCH value will >>>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I >>>>> cannot verify that they actually work. cc:ing the ppc-aix list in >>>>> the hope that somebody can help out with that. >>>>> >>>>> >>>>> Summing it up, I have the following two webrevs: >>>>> >>>>> top: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>>> >>>>> >>>>> hotspot: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>>> >>>>> >>>>> >>>>> With these changes I can build the normal platforms, but more >>>>> verification is needed - esp. building hotspot only. Meanwhile >>>>> feedback is much appreciated! >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>> On 2014-06-10 19:45, David Holmes wrote: >>>>>> Hi Mikael, >>>>>> >>>>>> This seems a reasonable proposal to me. We have an over-abundance >>>>>> of "arch" variables and values, so reducing that is a good aim. >>>>>> >>>>>> As you note the main flow-on effect here is that the hotspot >>>>>> makefiles have to be updated for the cases where >>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so >>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think >>>>>> only x86 has that issue. >>>>>> >>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc >>>>>> both internally and in the build artifacts and bundles! >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote: >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> I need some feedback and comments on the below fix: >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ >>>>>>> >>>>>>> >>>>>>> Background: >>>>>>> >>>>>>> When configuring the hotspot build the build system sets up the >>>>>>> ARCH >>>>>>> variable to reflect the target cpu. Currently the value is >>>>>>> initialized >>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu >>>>>>> name. For >>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). >>>>>>> The >>>>>>> goal in the new (JDK) build system is to have the "legacy" value >>>>>>> gradually removed in favor of the other variables. >>>>>>> >>>>>>> Discussion: >>>>>>> >>>>>>> The two candidate variables to base ARCH on are as far as I can >>>>>>> tell >>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two >>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, >>>>>>> well >>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. >>>>>>> Together >>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the >>>>>>> Hotspot build system to do its thing. Note: ARCH is currently >>>>>>> ignored on >>>>>>> solaris and bsd - it's overridden at the top of the respective >>>>>>> make//makefiles/defs.make files. >>>>>>> >>>>>>> Before I go too far with this though I'd like to get some >>>>>>> feedback on >>>>>>> whether or not this is the right approach and what the exact value >>>>>>> should be. Depending on the outcome of that the Hotspot build >>>>>>> system may >>>>>>> have to be updated for some platforms to support the new value(s). >>>>>>> >>>>>>> Thanks, >>>>>>> Mikael >>>>>>> >>>>> >>>> >>> >> From mike.duigou at oracle.com Tue Jun 17 21:35:31 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 17 Jun 2014 14:35:31 -0700 Subject: Adding hg version check to get_source.sh? Message-ID: With the upgrade of the hg.openjdk.java.net servers very old mercurial clients can no longer be used (0.9.5) and there have been persistent reports of more frequent connection failures. The older your mercurial client the more likely the failures are. jdk: hg clone http://hg.openjdk.java.net/jdk9/dev/jdk jdk jdk: requesting all changes jdk: adding changesets jdk: adding manifests jdk: transaction abort! jdk: rollback completed jdk: abort: stream ended unexpectedly (got 8372 bytes, expected 10932) I would like to add a version check to get_source.sh which will require mercurial 1.5 or later and warn for clients older than 1.9. Seem reasonable? Mike From kellyohair at gmail.com Tue Jun 17 21:50:58 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Tue, 17 Jun 2014 14:50:58 -0700 Subject: Adding hg version check to get_source.sh? In-Reply-To: References: Message-ID: Seems reasonable to me. -kto On Jun 17, 2014, at 2:35 PM, Mike Duigou wrote: > With the upgrade of the hg.openjdk.java.net servers very old mercurial clients can no longer be used (0.9.5) and there have been persistent reports of more frequent connection failures. The older your mercurial client the more likely the failures are. > > jdk: hg clone http://hg.openjdk.java.net/jdk9/dev/jdk jdk > jdk: requesting all changes > jdk: adding changesets > jdk: adding manifests > jdk: transaction abort! > jdk: rollback completed > jdk: abort: stream ended unexpectedly (got 8372 bytes, expected 10932) > > I would like to add a version check to get_source.sh which will require mercurial 1.5 or later and warn for clients older than 1.9. > > Seem reasonable? > > Mike From standbyme946 at gmail.com Wed Jun 18 00:56:14 2014 From: standbyme946 at gmail.com (Su) Date: Tue, 17 Jun 2014 17:56:14 -0700 Subject: contains for TreeSet Message-ID: May I ask why "contains" method of TreeSet uses the comparator to decide if two objects are equals, but not the equals method of the object? Thank you. From david.holmes at oracle.com Wed Jun 18 01:39:20 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jun 2014 11:39:20 +1000 Subject: contains for TreeSet In-Reply-To: References: Message-ID: <53A0EDC8.1040109@oracle.com> Moving your question to core-libs-dev, please drop build-dev from all future responses. David On 18/06/2014 10:56 AM, Su wrote: > May I ask why "contains" method of TreeSet uses the comparator to decide if > two objects are equals, but not the equals method of the object? > > Thank you. > From david.holmes at oracle.com Wed Jun 18 01:55:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jun 2014 11:55:46 +1000 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH In-Reply-To: <53A092D4.3060100@oracle.com> References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com> <539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com> <539F50E1.7090300@oracle.com> <539FACB2.2050508@oracle.com> <53A092D4.3060100@oracle.com> Message-ID: <53A0F1A2.8000604@oracle.com> On 18/06/2014 5:11 AM, Mikael Vidstedt wrote: > > New webrev here (only the hotspot part, the webrev for top hasn't changed): > > http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/ Looks okay to me. > > Comments inline. Ditto > On 2014-06-16 19:49, David Holmes wrote: >> Hi Mikael, >> >> Sorry for the delay ... >> >> make/aix/makefiles/defs.make: >> >> This change doesn't make sense to me: >> >> 48 ifneq (,$(findstring $(ARCH), ppc)) >> >> given that the logic immediately preceding this sets ARCH to either >> ppc or ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow >> for both 32-bit and 64-bit cross-builds but the earlier logic is >> really precluding this. So it seems to me that the changes in this >> file are completely unnecessary (or else the earlier logic also needs >> changing). > > Indeed, that is correct - I missed the fact that ARCH is always > overriden to be either ppc or ppc64. The old logic is unnecessarily hard > to follow, but I guess that's in line with our hotspot Makefiles in > general ;) > > I'll revert the changes to the file and add a mental note to self and > others that linux appears to be the only platform where the incoming > value of ARCH is actually honored - it's ignored/overridden on Solaris, > BSD and AIX. Note that it is honored on linux because that is the only platform which currently supports true cross-compilation. If we supported cross-compilation on the other platforms then they would need to honor the incoming ARCH as meaning the ARCH for the target platform to build. >> make/linux/makefiles/defs.make >> >> This block: >> >> 86 # i686/i586 and amd64/x86_64 >> 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586)) >> 88 ifeq ($(ARCH_DATA_MODEL), 64) >> 89 ARCH_DATA_MODEL = 64 >> 90 MAKE_ARGS += LP64=1 >> 91 PLATFORM = linux-amd64 >> 92 VM_PLATFORM = linux_amd64 >> 93 HS_ARCH = x86 >> 94 else >> 95 ARCH_DATA_MODEL = 32 >> 96 PLATFORM = linux-i586 >> 97 VM_PLATFORM = linux_i486 >> 98 HS_ARCH = x86 >> 99 # We have to reset ARCH to i686 since SRCARCH relies on it >> 100 ARCH = i686 >> 101 endif >> 102 endif >> >> seems to allow the user to try and do a 64-bit build on a 32-bit build >> machine. Not sure if that would get caught in an earlier sanity check? >> (Same is true for the sparc block). > > While the changes are primarily just intended to cut down on the > duplication I don't immediately see the reason why we wouldn't want to > allow compiling a 64-bit VM from a 32-bit machine? We're cross compiling > all sorts of platforms, so why not allow this if the compiler supports > it? I'd prefer to keep it this way. Ok. It is in theory at least possible to do this. Cheers, David ------ >> Also I don't think the following is actually true: >> >> # We have to reset ARCH to i686 since SRCARCH relies on it >> ARCH = i686 >> >> As long as ARCH is not amd64 and not x86_64 any 32-bit x86 >> architecture designator will simply map to a SRCARCH of x86, as per >> defs.make: >> >> SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm >> ppc zero,$(ARCH))) >> ARCH/ = x86 >> ARCH/sparc = sparc >> ARCH/sparc64= sparc >> ARCH/ia64 = ia64 >> ARCH/amd64 = x86 >> ARCH/x86_64 = x86 >> ARCH/ppc64 = ppc >> ARCH/ppc = ppc >> ARCH/arm = arm >> ARCH/zero = zero > > Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64, > ppc64, ppc, arm, zero } it will map to x86 anyway. I thought about > cleaning that up before I sent out the first webrev, but soon found > myself doing way more cleanup than was healthy for this specific change. > However, since I had to update this change anyway I removed the ARCH > reset part. > > Cheers, > Mikael > >> >> >> Cheers, >> David >> >> On 17/06/2014 6:17 AM, Mikael Vidstedt wrote: >>> >>> Thanks Erik. Another review please? >>> >>> Cheers, >>> Mikael >>> >>> On 2014-06-12 23:56, Erik Joelsson wrote: >>>> Looks fine to me. >>>> >>>> /Erik >>>> >>>> On 2014-06-12 23:18, Mikael Vidstedt wrote: >>>>> >>>>> I have now verified that the changes work just fine for the platforms >>>>> we build and test - both from the top level and when building hotspot >>>>> only. Taking suggestions on other tests to perform. And it would be >>>>> great if somebody could test the changes on on aix/ppc. >>>>> >>>>> So, kindly asking for "real"/final reviews of the changes: >>>>> >>>>> top: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>>> >>>>> hotspot: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>> On 2014-06-10 22:53, Mikael Vidstedt wrote: >>>>>> >>>>>> David, >>>>>> >>>>>> Thanks for the feedback. Essentially the logic in the >>>>>> make//makefiles/defs.make files needs to recognize and deal with >>>>>> two different use cases: >>>>>> >>>>>> 1. ARCH being set by the JDK build system to the value of >>>>>> OPENJDK_TARGET_CPU_ARCH, or >>>>>> 2. no ARCH being set, in which case it needs to be populated - >>>>>> typically from uname >>>>>> >>>>>> Since Solaris and bsd both override ARCH they do not care about >>>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2. >>>>>> >>>>>> Linux/x86 is where most of the difference (and confusion) is, but I >>>>>> think aix/ppc64 will also change slightly since the ARCH value will >>>>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I >>>>>> cannot verify that they actually work. cc:ing the ppc-aix list in >>>>>> the hope that somebody can help out with that. >>>>>> >>>>>> >>>>>> Summing it up, I have the following two webrevs: >>>>>> >>>>>> top: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>>>> >>>>>> >>>>>> hotspot: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>>>> >>>>>> >>>>>> >>>>>> With these changes I can build the normal platforms, but more >>>>>> verification is needed - esp. building hotspot only. Meanwhile >>>>>> feedback is much appreciated! >>>>>> >>>>>> Cheers, >>>>>> Mikael >>>>>> >>>>>> On 2014-06-10 19:45, David Holmes wrote: >>>>>>> Hi Mikael, >>>>>>> >>>>>>> This seems a reasonable proposal to me. We have an over-abundance >>>>>>> of "arch" variables and values, so reducing that is a good aim. >>>>>>> >>>>>>> As you note the main flow-on effect here is that the hotspot >>>>>>> makefiles have to be updated for the cases where >>>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so >>>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think >>>>>>> only x86 has that issue. >>>>>>> >>>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc >>>>>>> both internally and in the build artifacts and bundles! >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote: >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> I need some feedback and comments on the below fix: >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ >>>>>>>> >>>>>>>> >>>>>>>> Background: >>>>>>>> >>>>>>>> When configuring the hotspot build the build system sets up the >>>>>>>> ARCH >>>>>>>> variable to reflect the target cpu. Currently the value is >>>>>>>> initialized >>>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu >>>>>>>> name. For >>>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). >>>>>>>> The >>>>>>>> goal in the new (JDK) build system is to have the "legacy" value >>>>>>>> gradually removed in favor of the other variables. >>>>>>>> >>>>>>>> Discussion: >>>>>>>> >>>>>>>> The two candidate variables to base ARCH on are as far as I can >>>>>>>> tell >>>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two >>>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, >>>>>>>> well >>>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. >>>>>>>> Together >>>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the >>>>>>>> Hotspot build system to do its thing. Note: ARCH is currently >>>>>>>> ignored on >>>>>>>> solaris and bsd - it's overridden at the top of the respective >>>>>>>> make//makefiles/defs.make files. >>>>>>>> >>>>>>>> Before I go too far with this though I'd like to get some >>>>>>>> feedback on >>>>>>>> whether or not this is the right approach and what the exact value >>>>>>>> should be. Depending on the outcome of that the Hotspot build >>>>>>>> system may >>>>>>>> have to be updated for some platforms to support the new value(s). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Mikael >>>>>>>> >>>>>> >>>>> >>>> >>> > From erik.joelsson at oracle.com Wed Jun 18 08:08:51 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 18 Jun 2014 10:08:51 +0200 Subject: Adding hg version check to get_source.sh? In-Reply-To: References: Message-ID: <53A14913.9030905@oracle.com> +1 /Erik On 2014-06-17 23:50, Kelly O'Hair wrote: > Seems reasonable to me. > > -kto > > On Jun 17, 2014, at 2:35 PM, Mike Duigou wrote: > >> With the upgrade of the hg.openjdk.java.net servers very old mercurial clients can no longer be used (0.9.5) and there have been persistent reports of more frequent connection failures. The older your mercurial client the more likely the failures are. >> >> jdk: hg clone http://hg.openjdk.java.net/jdk9/dev/jdk jdk >> jdk: requesting all changes >> jdk: adding changesets >> jdk: adding manifests >> jdk: transaction abort! >> jdk: rollback completed >> jdk: abort: stream ended unexpectedly (got 8372 bytes, expected 10932) >> >> I would like to add a version check to get_source.sh which will require mercurial 1.5 or later and warn for clients older than 1.9. >> >> Seem reasonable? >> >> Mike From erik.joelsson at oracle.com Wed Jun 18 08:14:02 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 18 Jun 2014 10:14:02 +0200 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH In-Reply-To: <53A092D4.3060100@oracle.com> References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com> <539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com> <539F50E1.7090300@oracle.com> <539FACB2.2050508@oracle.com> <53A092D4.3060100@oracle.com> Message-ID: <53A14A4A.5090208@oracle.com> Looks ok to me. /Erik On 2014-06-17 21:11, Mikael Vidstedt wrote: > > New webrev here (only the hotspot part, the webrev for top hasn't > changed): > > http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/ > > > Comments inline. > > On 2014-06-16 19:49, David Holmes wrote: >> Hi Mikael, >> >> Sorry for the delay ... >> >> make/aix/makefiles/defs.make: >> >> This change doesn't make sense to me: >> >> 48 ifneq (,$(findstring $(ARCH), ppc)) >> >> given that the logic immediately preceding this sets ARCH to either >> ppc or ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow >> for both 32-bit and 64-bit cross-builds but the earlier logic is >> really precluding this. So it seems to me that the changes in this >> file are completely unnecessary (or else the earlier logic also needs >> changing). > > Indeed, that is correct - I missed the fact that ARCH is always > overriden to be either ppc or ppc64. The old logic is unnecessarily > hard to follow, but I guess that's in line with our hotspot Makefiles > in general ;) > > I'll revert the changes to the file and add a mental note to self and > others that linux appears to be the only platform where the incoming > value of ARCH is actually honored - it's ignored/overridden on > Solaris, BSD and AIX. > >> make/linux/makefiles/defs.make >> >> This block: >> >> 86 # i686/i586 and amd64/x86_64 >> 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586)) >> 88 ifeq ($(ARCH_DATA_MODEL), 64) >> 89 ARCH_DATA_MODEL = 64 >> 90 MAKE_ARGS += LP64=1 >> 91 PLATFORM = linux-amd64 >> 92 VM_PLATFORM = linux_amd64 >> 93 HS_ARCH = x86 >> 94 else >> 95 ARCH_DATA_MODEL = 32 >> 96 PLATFORM = linux-i586 >> 97 VM_PLATFORM = linux_i486 >> 98 HS_ARCH = x86 >> 99 # We have to reset ARCH to i686 since SRCARCH relies on it >> 100 ARCH = i686 >> 101 endif >> 102 endif >> >> seems to allow the user to try and do a 64-bit build on a 32-bit >> build machine. Not sure if that would get caught in an earlier sanity >> check? (Same is true for the sparc block). > > While the changes are primarily just intended to cut down on the > duplication I don't immediately see the reason why we wouldn't want to > allow compiling a 64-bit VM from a 32-bit machine? We're cross > compiling all sorts of platforms, so why not allow this if the > compiler supports it? I'd prefer to keep it this way. > >> Also I don't think the following is actually true: >> >> # We have to reset ARCH to i686 since SRCARCH relies on it >> ARCH = i686 >> >> As long as ARCH is not amd64 and not x86_64 any 32-bit x86 >> architecture designator will simply map to a SRCARCH of x86, as per >> defs.make: >> >> SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm >> ppc zero,$(ARCH))) >> ARCH/ = x86 >> ARCH/sparc = sparc >> ARCH/sparc64= sparc >> ARCH/ia64 = ia64 >> ARCH/amd64 = x86 >> ARCH/x86_64 = x86 >> ARCH/ppc64 = ppc >> ARCH/ppc = ppc >> ARCH/arm = arm >> ARCH/zero = zero > > Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64, > ppc64, ppc, arm, zero } it will map to x86 anyway. I thought about > cleaning that up before I sent out the first webrev, but soon found > myself doing way more cleanup than was healthy for this specific > change. However, since I had to update this change anyway I removed > the ARCH reset part. > > Cheers, > Mikael > >> >> >> Cheers, >> David >> >> On 17/06/2014 6:17 AM, Mikael Vidstedt wrote: >>> >>> Thanks Erik. Another review please? >>> >>> Cheers, >>> Mikael >>> >>> On 2014-06-12 23:56, Erik Joelsson wrote: >>>> Looks fine to me. >>>> >>>> /Erik >>>> >>>> On 2014-06-12 23:18, Mikael Vidstedt wrote: >>>>> >>>>> I have now verified that the changes work just fine for the platforms >>>>> we build and test - both from the top level and when building hotspot >>>>> only. Taking suggestions on other tests to perform. And it would be >>>>> great if somebody could test the changes on on aix/ppc. >>>>> >>>>> So, kindly asking for "real"/final reviews of the changes: >>>>> >>>>> top: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>>> >>>>> hotspot: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>> On 2014-06-10 22:53, Mikael Vidstedt wrote: >>>>>> >>>>>> David, >>>>>> >>>>>> Thanks for the feedback. Essentially the logic in the >>>>>> make//makefiles/defs.make files needs to recognize and deal with >>>>>> two different use cases: >>>>>> >>>>>> 1. ARCH being set by the JDK build system to the value of >>>>>> OPENJDK_TARGET_CPU_ARCH, or >>>>>> 2. no ARCH being set, in which case it needs to be populated - >>>>>> typically from uname >>>>>> >>>>>> Since Solaris and bsd both override ARCH they do not care about >>>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2. >>>>>> >>>>>> Linux/x86 is where most of the difference (and confusion) is, but I >>>>>> think aix/ppc64 will also change slightly since the ARCH value will >>>>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I >>>>>> cannot verify that they actually work. cc:ing the ppc-aix list in >>>>>> the hope that somebody can help out with that. >>>>>> >>>>>> >>>>>> Summing it up, I have the following two webrevs: >>>>>> >>>>>> top: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>>>> >>>>>> >>>>>> hotspot: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>>>> >>>>>> >>>>>> >>>>>> With these changes I can build the normal platforms, but more >>>>>> verification is needed - esp. building hotspot only. Meanwhile >>>>>> feedback is much appreciated! >>>>>> >>>>>> Cheers, >>>>>> Mikael >>>>>> >>>>>> On 2014-06-10 19:45, David Holmes wrote: >>>>>>> Hi Mikael, >>>>>>> >>>>>>> This seems a reasonable proposal to me. We have an over-abundance >>>>>>> of "arch" variables and values, so reducing that is a good aim. >>>>>>> >>>>>>> As you note the main flow-on effect here is that the hotspot >>>>>>> makefiles have to be updated for the cases where >>>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so >>>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think >>>>>>> only x86 has that issue. >>>>>>> >>>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc >>>>>>> both internally and in the build artifacts and bundles! >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote: >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> I need some feedback and comments on the below fix: >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ >>>>>>>> >>>>>>>> >>>>>>>> Background: >>>>>>>> >>>>>>>> When configuring the hotspot build the build system sets up the >>>>>>>> ARCH >>>>>>>> variable to reflect the target cpu. Currently the value is >>>>>>>> initialized >>>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu >>>>>>>> name. For >>>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). >>>>>>>> The >>>>>>>> goal in the new (JDK) build system is to have the "legacy" value >>>>>>>> gradually removed in favor of the other variables. >>>>>>>> >>>>>>>> Discussion: >>>>>>>> >>>>>>>> The two candidate variables to base ARCH on are as far as I can >>>>>>>> tell >>>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two >>>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a >>>>>>>> single, well >>>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. >>>>>>>> Together >>>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for >>>>>>>> the >>>>>>>> Hotspot build system to do its thing. Note: ARCH is currently >>>>>>>> ignored on >>>>>>>> solaris and bsd - it's overridden at the top of the respective >>>>>>>> make//makefiles/defs.make files. >>>>>>>> >>>>>>>> Before I go too far with this though I'd like to get some >>>>>>>> feedback on >>>>>>>> whether or not this is the right approach and what the exact value >>>>>>>> should be. Depending on the outcome of that the Hotspot build >>>>>>>> system may >>>>>>>> have to be updated for some platforms to support the new value(s). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Mikael >>>>>>>> >>>>>> >>>>> >>>> >>> > From pointo1d at gmail.com Wed Jun 18 11:35:12 2014 From: pointo1d at gmail.com (pointo1d) Date: Wed, 18 Jun 2014 12:35:12 +0100 Subject: Adding hg version check to get_source.sh? In-Reply-To: References: Message-ID: <53A17970.4030901@gmail.com> Hiya Mike , On 17/06/14 22:35, Mike Duigou wrote: > With the upgrade of the hg.openjdk.java.net servers very old mercurial clients can no longer be used (0.9.5) and there have been persistent reports of more frequent connection failures. The older your mercurial client the more likely the failures are. > > jdk: hg clone http://hg.openjdk.java.net/jdk9/dev/jdk jdk > jdk: requesting all changes > jdk: adding changesets > jdk: adding manifests > jdk: transaction abort! > jdk: rollback completed > jdk: abort: stream ended unexpectedly (got 8372 bytes, expected 10932) > > I would like to add a version check to get_source.sh which will require mercurial 1.5 or later and warn for clients older than 1.9. > > Seem reasonable? > > Mike It [your suggestion] sounds eminently sensible. Best rgds , -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe From pointo1d at gmail.com Wed Jun 18 11:35:35 2014 From: pointo1d at gmail.com (pointo1d) Date: Wed, 18 Jun 2014 12:35:35 +0100 Subject: Adding hg version check to get_source.sh? In-Reply-To: References: Message-ID: <53A17987.2090709@gmail.com> Hiya Mike , On 17/06/14 22:35, Mike Duigou wrote: > With the upgrade of the hg.openjdk.java.net servers very old mercurial clients can no longer be used (0.9.5) and there have been persistent reports of more frequent connection failures. The older your mercurial client the more likely the failures are. > > jdk: hg clone http://hg.openjdk.java.net/jdk9/dev/jdk jdk > jdk: requesting all changes > jdk: adding changesets > jdk: adding manifests > jdk: transaction abort! > jdk: rollback completed > jdk: abort: stream ended unexpectedly (got 8372 bytes, expected 10932) > > I would like to add a version check to get_source.sh which will require mercurial 1.5 or later and warn for clients older than 1.9. > > Seem reasonable? > > Mike It [your suggestion] sounds eminently sensible. Best rgds , -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe From iris.clark at oracle.com Wed Jun 18 16:12:49 2014 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 18 Jun 2014 09:12:49 -0700 (PDT) Subject: Adding hg version check to get_source.sh? In-Reply-To: References: Message-ID: Hi, Mike. The minimum recommended version of Hg on the client side is 2.6.3 [1, 2]. I'd recommend a warning for anything older than that. Thanks, iris [1]: http://mail.openjdk.java.net/pipermail/announce/2014-March/000164.html [2]: http://openjdk.java.net/guide/repositories.html#installConfig -----Original Message----- From: Mike Duigou Sent: Tuesday, June 17, 2014 2:36 PM To: build-dev build-dev Subject: Adding hg version check to get_source.sh? With the upgrade of the hg.openjdk.java.net servers very old mercurial clients can no longer be used (0.9.5) and there have been persistent reports of more frequent connection failures. The older your mercurial client the more likely the failures are. jdk: hg clone http://hg.openjdk.java.net/jdk9/dev/jdk jdk jdk: requesting all changes jdk: adding changesets jdk: adding manifests jdk: transaction abort! jdk: rollback completed jdk: abort: stream ended unexpectedly (got 8372 bytes, expected 10932) I would like to add a version check to get_source.sh which will require mercurial 1.5 or later and warn for clients older than 1.9. Seem reasonable? Mike From mikael.vidstedt at oracle.com Wed Jun 18 19:32:54 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 18 Jun 2014 12:32:54 -0700 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH In-Reply-To: <53A14A4A.5090208@oracle.com> References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com> <539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com> <539F50E1.7090300@oracle.com> <539FACB2.2050508@oracle.com> <53A092D4.3060100@oracle.com> <53A14A4A.5090208@oracle.com> Message-ID: <53A1E966.1050808@oracle.com> Erik/David - thanks for the reviews! Cheers, Mikael On 2014-06-18 01:14, Erik Joelsson wrote: > Looks ok to me. > > /Erik > > On 2014-06-17 21:11, Mikael Vidstedt wrote: >> >> New webrev here (only the hotspot part, the webrev for top hasn't >> changed): >> >> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/ >> >> >> Comments inline. >> >> On 2014-06-16 19:49, David Holmes wrote: >>> Hi Mikael, >>> >>> Sorry for the delay ... >>> >>> make/aix/makefiles/defs.make: >>> >>> This change doesn't make sense to me: >>> >>> 48 ifneq (,$(findstring $(ARCH), ppc)) >>> >>> given that the logic immediately preceding this sets ARCH to either >>> ppc or ppc64 based on ARCH_DATA_MODEL. You seem to be trying to >>> allow for both 32-bit and 64-bit cross-builds but the earlier logic >>> is really precluding this. So it seems to me that the changes in >>> this file are completely unnecessary (or else the earlier logic also >>> needs changing). >> >> Indeed, that is correct - I missed the fact that ARCH is always >> overriden to be either ppc or ppc64. The old logic is unnecessarily >> hard to follow, but I guess that's in line with our hotspot Makefiles >> in general ;) >> >> I'll revert the changes to the file and add a mental note to self and >> others that linux appears to be the only platform where the incoming >> value of ARCH is actually honored - it's ignored/overridden on >> Solaris, BSD and AIX. >> >>> make/linux/makefiles/defs.make >>> >>> This block: >>> >>> 86 # i686/i586 and amd64/x86_64 >>> 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586)) >>> 88 ifeq ($(ARCH_DATA_MODEL), 64) >>> 89 ARCH_DATA_MODEL = 64 >>> 90 MAKE_ARGS += LP64=1 >>> 91 PLATFORM = linux-amd64 >>> 92 VM_PLATFORM = linux_amd64 >>> 93 HS_ARCH = x86 >>> 94 else >>> 95 ARCH_DATA_MODEL = 32 >>> 96 PLATFORM = linux-i586 >>> 97 VM_PLATFORM = linux_i486 >>> 98 HS_ARCH = x86 >>> 99 # We have to reset ARCH to i686 since SRCARCH relies on it >>> 100 ARCH = i686 >>> 101 endif >>> 102 endif >>> >>> seems to allow the user to try and do a 64-bit build on a 32-bit >>> build machine. Not sure if that would get caught in an earlier >>> sanity check? (Same is true for the sparc block). >> >> While the changes are primarily just intended to cut down on the >> duplication I don't immediately see the reason why we wouldn't want >> to allow compiling a 64-bit VM from a 32-bit machine? We're cross >> compiling all sorts of platforms, so why not allow this if the >> compiler supports it? I'd prefer to keep it this way. >> >>> Also I don't think the following is actually true: >>> >>> # We have to reset ARCH to i686 since SRCARCH relies on it >>> ARCH = i686 >>> >>> As long as ARCH is not amd64 and not x86_64 any 32-bit x86 >>> architecture designator will simply map to a SRCARCH of x86, as per >>> defs.make: >>> >>> SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm >>> ppc zero,$(ARCH))) >>> ARCH/ = x86 >>> ARCH/sparc = sparc >>> ARCH/sparc64= sparc >>> ARCH/ia64 = ia64 >>> ARCH/amd64 = x86 >>> ARCH/x86_64 = x86 >>> ARCH/ppc64 = ppc >>> ARCH/ppc = ppc >>> ARCH/arm = arm >>> ARCH/zero = zero >> >> Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64, >> ppc64, ppc, arm, zero } it will map to x86 anyway. I thought about >> cleaning that up before I sent out the first webrev, but soon found >> myself doing way more cleanup than was healthy for this specific >> change. However, since I had to update this change anyway I removed >> the ARCH reset part. >> >> Cheers, >> Mikael >> >>> >>> >>> Cheers, >>> David >>> >>> On 17/06/2014 6:17 AM, Mikael Vidstedt wrote: >>>> >>>> Thanks Erik. Another review please? >>>> >>>> Cheers, >>>> Mikael >>>> >>>> On 2014-06-12 23:56, Erik Joelsson wrote: >>>>> Looks fine to me. >>>>> >>>>> /Erik >>>>> >>>>> On 2014-06-12 23:18, Mikael Vidstedt wrote: >>>>>> >>>>>> I have now verified that the changes work just fine for the >>>>>> platforms >>>>>> we build and test - both from the top level and when building >>>>>> hotspot >>>>>> only. Taking suggestions on other tests to perform. And it would be >>>>>> great if somebody could test the changes on on aix/ppc. >>>>>> >>>>>> So, kindly asking for "real"/final reviews of the changes: >>>>>> >>>>>> top: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>>>> >>>>>> hotspot: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> Mikael >>>>>> >>>>>> On 2014-06-10 22:53, Mikael Vidstedt wrote: >>>>>>> >>>>>>> David, >>>>>>> >>>>>>> Thanks for the feedback. Essentially the logic in the >>>>>>> make//makefiles/defs.make files needs to recognize and deal >>>>>>> with >>>>>>> two different use cases: >>>>>>> >>>>>>> 1. ARCH being set by the JDK build system to the value of >>>>>>> OPENJDK_TARGET_CPU_ARCH, or >>>>>>> 2. no ARCH being set, in which case it needs to be populated - >>>>>>> typically from uname >>>>>>> >>>>>>> Since Solaris and bsd both override ARCH they do not care about >>>>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2. >>>>>>> >>>>>>> Linux/x86 is where most of the difference (and confusion) is, but I >>>>>>> think aix/ppc64 will also change slightly since the ARCH value will >>>>>>> go from ppc64 to ppc. I've tried to make the relevant changes, >>>>>>> but I >>>>>>> cannot verify that they actually work. cc:ing the ppc-aix list in >>>>>>> the hope that somebody can help out with that. >>>>>>> >>>>>>> >>>>>>> Summing it up, I have the following two webrevs: >>>>>>> >>>>>>> top: >>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>>>>> >>>>>>> >>>>>>> hotspot: >>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> With these changes I can build the normal platforms, but more >>>>>>> verification is needed - esp. building hotspot only. Meanwhile >>>>>>> feedback is much appreciated! >>>>>>> >>>>>>> Cheers, >>>>>>> Mikael >>>>>>> >>>>>>> On 2014-06-10 19:45, David Holmes wrote: >>>>>>>> Hi Mikael, >>>>>>>> >>>>>>>> This seems a reasonable proposal to me. We have an over-abundance >>>>>>>> of "arch" variables and values, so reducing that is a good aim. >>>>>>>> >>>>>>>> As you note the main flow-on effect here is that the hotspot >>>>>>>> makefiles have to be updated for the cases where >>>>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so >>>>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think >>>>>>>> only x86 has that issue. >>>>>>>> >>>>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc >>>>>>>> both internally and in the build artifacts and bundles! >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote: >>>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> I need some feedback and comments on the below fix: >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Background: >>>>>>>>> >>>>>>>>> When configuring the hotspot build the build system sets up >>>>>>>>> the ARCH >>>>>>>>> variable to reflect the target cpu. Currently the value is >>>>>>>>> initialized >>>>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu >>>>>>>>> name. For >>>>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on >>>>>>>>> mac). >>>>>>>>> The >>>>>>>>> goal in the new (JDK) build system is to have the "legacy" value >>>>>>>>> gradually removed in favor of the other variables. >>>>>>>>> >>>>>>>>> Discussion: >>>>>>>>> >>>>>>>>> The two candidate variables to base ARCH on are as far as I >>>>>>>>> can tell >>>>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two >>>>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a >>>>>>>>> single, well >>>>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. >>>>>>>>> Together >>>>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough >>>>>>>>> for the >>>>>>>>> Hotspot build system to do its thing. Note: ARCH is currently >>>>>>>>> ignored on >>>>>>>>> solaris and bsd - it's overridden at the top of the respective >>>>>>>>> make//makefiles/defs.make files. >>>>>>>>> >>>>>>>>> Before I go too far with this though I'd like to get some >>>>>>>>> feedback on >>>>>>>>> whether or not this is the right approach and what the exact >>>>>>>>> value >>>>>>>>> should be. Depending on the outcome of that the Hotspot build >>>>>>>>> system may >>>>>>>>> have to be updated for some platforms to support the new >>>>>>>>> value(s). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Mikael >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From Alan.Bateman at oracle.com Thu Jun 19 12:13:14 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Jun 2014 13:13:14 +0100 Subject: [9] Review Request: 8047336 Read flavormap.properties as resource In-Reply-To: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com> References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com> Message-ID: <53A2D3DA.4030503@oracle.com> On 19/06/2014 12:17, Petr Pchelko wrote: > Hello, > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8047336 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/ > > This is another step in datatransfer modularization work. This part of the work needs a CCC, so I've moved it out to a separate fix. The CCC will be filed once the fix is settled. > > Multiple changes are happening here: > 1. After http://ccc.us.oracle.com/8005250 the flavormap.properties and AWT.DnD.flavorMapFileURL Toolkit property was removed from the public API. However one mention was forgotten and I'm removing it now, see changes in Toolkit.java > 2. For modules we need to move flavormap.properties out of the jre/lib. I'm not sure about the new location. Can I add properties to the java.awt.datatransfer package? Wouldn't they be considered public in this case? > 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by the user and it's not used by us. So I'm removing it. > 4. As flavormap.properties is not editable by the user any more, I'm changing it's format to get significant simplification of the parsing code. > > There's no way left to change the default mappings now, but we have public supported API to create new mappings in the Java code. System property could be added to provide alternative properties location, but I don't think it's required. > The dropping of the reference to flavormap.properties from java.awt.Toolkit looks okay to me. I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap (not a detailed review) and it looks okay. I cannot comment on the changes to format as I don't know the history in this area to understand the issues around duplicates. On your question about introducing a system property to allow the configuration be picked up from some other (non-JDK) location then it doesn't sound like there is a strong case. Do we know if anyone has been editing the file in ${java.home}/lib? I assume that if there is a strong need then it could be possible to introducing it in the future without conflicting with anything that you are doing here. -Alan. From petr.pchelko at oracle.com Thu Jun 19 11:17:41 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 19 Jun 2014 15:17:41 +0400 Subject: [9] Review Request: 8047336 Read flavormap.properties as resource Message-ID: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com> Hello, Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8047336 The fix is available at: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/ This is another step in datatransfer modularization work. This part of the work needs a CCC, so I've moved it out to a separate fix. The CCC will be filed once the fix is settled. Multiple changes are happening here: 1. After http://ccc.us.oracle.com/8005250 the flavormap.properties and AWT.DnD.flavorMapFileURL Toolkit property was removed from the public API. However one mention was forgotten and I'm removing it now, see changes in Toolkit.java 2. For modules we need to move flavormap.properties out of the jre/lib. I'm not sure about the new location. Can I add properties to the java.awt.datatransfer package? Wouldn't they be considered public in this case? 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by the user and it's not used by us. So I'm removing it. 4. As flavormap.properties is not editable by the user any more, I'm changing it's format to get significant simplification of the parsing code. There's no way left to change the default mappings now, but we have public supported API to create new mappings in the Java code. System property could be added to provide alternative properties location, but I don't think it's required. The fix was tested on Windows, Linux and Mac with JCK and all regression tests related to datatransfer, dnd and clipboard. The JPRT build succeeds. A question for the build team: as you see I'm creating an explicit rule for the properties file. The problem's that if I add flavormap.properties to the COPY_PATTERNS, the solaris version is used on Mac for some reason. Is that a bug and is there any way to avoid it? Thank you. With best regards. Petr. From petr.pchelko at oracle.com Thu Jun 19 12:24:28 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 19 Jun 2014 16:24:28 +0400 Subject: [9] Review Request: 8047336 Read flavormap.properties as resource In-Reply-To: <53A2D3DA.4030503@oracle.com> References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com> <53A2D3DA.4030503@oracle.com> Message-ID: Hello, Alan. Thank you for the review. > Do we know if anyone has been editing the file in ${java.home}/lib? I couldn't find any examples on the internet although I've done a very extensive search, so I we could add a property later if someone would request it. With best regards. Petr. On 19 ???? 2014 ?., at 16:13, Alan Bateman wrote: > On 19/06/2014 12:17, Petr Pchelko wrote: >> Hello, >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8047336 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/ >> >> This is another step in datatransfer modularization work. This part of the work needs a CCC, so I've moved it out to a separate fix. The CCC will be filed once the fix is settled. >> >> Multiple changes are happening here: >> 1. After http://ccc.us.oracle.com/8005250 the flavormap.properties and AWT.DnD.flavorMapFileURL Toolkit property was removed from the public API. However one mention was forgotten and I'm removing it now, see changes in Toolkit.java >> 2. For modules we need to move flavormap.properties out of the jre/lib. I'm not sure about the new location. Can I add properties to the java.awt.datatransfer package? Wouldn't they be considered public in this case? >> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by the user and it's not used by us. So I'm removing it. >> 4. As flavormap.properties is not editable by the user any more, I'm changing it's format to get significant simplification of the parsing code. >> >> There's no way left to change the default mappings now, but we have public supported API to create new mappings in the Java code. System property could be added to provide alternative properties location, but I don't think it's required. >> > The dropping of the reference to flavormap.properties from java.awt.Toolkit looks okay to me. > > I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap (not a detailed review) and it looks okay. I cannot comment on the changes to format as I don't know the history in this area to understand the issues around duplicates. > > On your question about introducing a system property to allow the configuration be picked up from some other (non-JDK) location then it doesn't sound like there is a strong case. Do we know if anyone has been editing the file in ${java.home}/lib? I assume that if there is a strong need then it could be possible to introducing it in the future without conflicting with anything that you are doing here. > > -Alan. From david.dehaven at oracle.com Thu Jun 19 17:25:32 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 19 Jun 2014 10:25:32 -0700 Subject: OS X configure ignores --with-tools-dir In-Reply-To: <3AD40696-3F26-4D58-8C27-870798406DA9@oracle.com> References: <3AD40696-3F26-4D58-8C27-870798406DA9@oracle.com> Message-ID: There's some changes in 9 that should be backported to 8u so developers on 10.9 will be able to build. JDK-8043340 (that I just pushed to 9) is one, but it's dependent on at least one other change. -DrD- > Attempting to build JDK 8 on Mavericks I found the same problem: > > $ sh configure --with-debug-level=fastdebug --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin > [?] > checking for gcc... /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc > configure: Resolving CC (as /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc) failed, using /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc directly. > checking resolved symbolic links for CC... /Applications/Xcode4.app/Contents/Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 > checking if CC is disguised ccache... no, keeping CC > configure: Using i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build) C compiler version 2336.11.00) (located at /Applications/Xcode4.app/Contents/Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2) > checking whether the C compiler works... no > configure: error: in `/Users/bpb/Work/CoreLibs/jdk/jdk8u-dev': > configure: error: C compiler cannot create executables > See `config.log' for more details > configure exiting with result code 77 > > Thanks, > > Brina >> On 04/30/2014 12:42 AM, Erik Joelsson wrote: >>> >>> On 2014-04-30 00:51, Dan Smith wrote: >>>> Thanks Henry, that will force it to choose my referenced compiler. >>>> >>>> Still not clear whether this is intended behavior or not: is the >>>> default toolchain-type (clang, apparently) supposed to trump an >>>> explicit tools-dir? I.e., is this a bug, or just surprising but >>>> intentional? >>> I think this is intentional, but it could certainly still be discussed. >>> I'm surprised clang is already picked as default however. Perhaps there >>> is something else that's not working as intended causing this. >> >> We use 'xcodebuild -version' to determine xcode version, and choose >> clang as default after 5.0. >> >> http://hg.openjdk.java.net/jdk9/jdk9/rev/77c150b417d8 >> >> --with-tools-dir specify where to find the toolchain, in this case, we >> would hope it can correctly identify it's xcode 4, but it's not. >> >> Cheers, >> Henry > From mandy.chung at oracle.com Thu Jun 19 17:47:32 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Jun 2014 10:47:32 -0700 Subject: Review request: 8047387: Generate different version of java.policy file for windows 32-bit and 64-bit Message-ID: <53A32234.4030306@oracle.com> The jar files for access bridge are different on windows-i586 and windows-amd64. Need to be able to generate different version of java.policy for windows-i586 and windows-amd64 JDK. This patch copies different copy according to its target OS/CPU. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8047387/webrev.00/ thanks Mandy From tim.bell at oracle.com Thu Jun 19 19:02:59 2014 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 19 Jun 2014 19:02:59 +0000 Subject: Review request: 8047387: Generate different version of java.policy file for windows 32-bit and 64-bit In-Reply-To: <53A32234.4030306@oracle.com> References: <53A32234.4030306@oracle.com> Message-ID: <53A333E3.5050506@oracle.com> Hi Mandy: > The jar files for access bridge are different on windows-i586 and > windows-amd64. Need to be able to generate different version of > java.policy for windows-i586 and windows-amd64 JDK. > > This patch copies different copy according to its target OS/CPU. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8047387/webrev.00/ Looks good to me. Tim From mandy.chung at oracle.com Thu Jun 19 20:39:49 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Jun 2014 13:39:49 -0700 Subject: Review request: 8047387: Generate different version of java.policy file for windows 32-bit and 64-bit In-Reply-To: <53A333E3.5050506@oracle.com> References: <53A32234.4030306@oracle.com> <53A333E3.5050506@oracle.com> Message-ID: <53A34A95.3080103@oracle.com> On 6/19/14 12:02 PM, Tim Bell wrote: > Hi Mandy: > >> The jar files for access bridge are different on windows-i586 and >> windows-amd64. Need to be able to generate different version of >> java.policy for windows-i586 and windows-amd64 JDK. >> >> This patch copies different copy according to its target OS/CPU. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8047387/webrev.00/ > > Looks good to me. > Thanks Tim. Erik has also reviewed it earlier before he went on vacation. Mandy From anthony.petrov at oracle.com Fri Jun 20 11:19:21 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 20 Jun 2014 15:19:21 +0400 Subject: [9] Review Request: 8047336 Read flavormap.properties as resource In-Reply-To: References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com> <53A2D3DA.4030503@oracle.com> Message-ID: <53A418B9.6080500@oracle.com> Hi Petr, I ran the following query: https://www.google.com/#q=custom+flavormap.properties and the search yielded the following forum thread: https://community.oracle.com/thread/1293314?start=0&tstart=0 where developers seem to suggest they do edit the $JDKHOME/jre/lib/flavormap.properties file sometimes. Do we officially declare that we drop support for this possibility? -- best regards, Anthony On 6/19/2014 4:24 PM, Petr Pchelko wrote: > Hello, Alan. > > Thank you for the review. > >> Do we know if anyone has been editing the file in ${java.home}/lib? > I couldn't find any examples on the internet although I've done a very > extensive search, so I we could add a property later if someone would > request it. > > With best regards. Petr. > > On 19 ???? 2014 ?., at 16:13, Alan Bateman > wrote: > >> On 19/06/2014 12:17, Petr Pchelko wrote: >>> Hello, >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8047336 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/ >>> >>> This is another step in datatransfer modularization work. This part of the work needs a CCC, so I've moved it out to a separate fix. The CCC will be filed once the fix is settled. >>> >>> Multiple changes are happening here: >>> 1. Afterhttp://ccc.us.oracle.com/8005250 the flavormap.properties and AWT.DnD.flavorMapFileURL Toolkit property was removed from the public API. However one mention was forgotten and I'm removing it now, see changes in Toolkit.java >>> 2. For modules we need to move flavormap.properties out of the jre/lib. I'm not sure about the new location. Can I add properties to the java.awt.datatransfer package? Wouldn't they be considered public in this case? >>> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by the user and it's not used by us. So I'm removing it. >>> 4. As flavormap.properties is not editable by the user any more, I'm changing it's format to get significant simplification of the parsing code. >>> >>> There's no way left to change the default mappings now, but we have public supported API to create new mappings in the Java code. System property could be added to provide alternative properties location, but I don't think it's required. >>> >> The dropping of the reference to flavormap.properties from >> java.awt.Toolkit looks okay to me. >> >> I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap >> (not a detailed review) and it looks okay. I cannot comment on the >> changes to format as I don't know the history in this area to >> understand the issues around duplicates. >> >> On your question about introducing a system property to allow the >> configuration be picked up from some other (non-JDK) location then it >> doesn't sound like there is a strong case. Do we know if anyone has >> been editing the file in ${java.home}/lib? I assume that if there is a >> strong need then it could be possible to introducing it in the future >> without conflicting with anything that you are doing here. >> >> -Alan. > From artem.ananiev at oracle.com Fri Jun 20 11:29:26 2014 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 20 Jun 2014 15:29:26 +0400 Subject: [9] Review Request: 8047336 Read flavormap.properties as resource In-Reply-To: <53A418B9.6080500@oracle.com> References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com> <53A2D3DA.4030503@oracle.com> <53A418B9.6080500@oracle.com> Message-ID: <53A41B16.9020404@oracle.com> On 6/20/2014 3:19 PM, Anthony Petrov wrote: > Hi Petr, > > I ran the following query: > > https://www.google.com/#q=custom+flavormap.properties > > and the search yielded the following forum thread: > > https://community.oracle.com/thread/1293314?start=0&tstart=0 > > where developers seem to suggest they do edit the > $JDKHOME/jre/lib/flavormap.properties file sometimes. > > Do we officially declare that we drop support for this possibility? This possibility will be dropped regardless of the current Petr's fix, since there will be no single "jre" folder in jigsaw world. Probably, some other mechanism to customize files like flavormap.properties or logging.properties will be introduced. BTW, the current fix is not about flavormap.properties on its own, but about removing AWT.DnD.flavorMapFileURL toolkit property. I would suggest to push this change as a separate bug fix, not as a part of 8047336. Thanks, Artem > -- > best regards, > Anthony > > On 6/19/2014 4:24 PM, Petr Pchelko wrote: >> Hello, Alan. >> >> Thank you for the review. >> >>> Do we know if anyone has been editing the file in ${java.home}/lib? >> I couldn't find any examples on the internet although I've done a very >> extensive search, so I we could add a property later if someone would >> request it. >> >> With best regards. Petr. >> >> On 19 ???? 2014 ?., at 16:13, Alan Bateman > > wrote: >> >>> On 19/06/2014 12:17, Petr Pchelko wrote: >>>> Hello, >>>> >>>> Please review the fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8047336 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/ >>>> >>>> This is another step in datatransfer modularization work. This part >>>> of the work needs a CCC, so I've moved it out to a separate fix. The >>>> CCC will be filed once the fix is settled. >>>> >>>> Multiple changes are happening here: >>>> 1. Afterhttp://ccc.us.oracle.com/8005250 the flavormap.properties >>>> and AWT.DnD.flavorMapFileURL Toolkit property was removed from the >>>> public API. However one mention was forgotten and I'm removing it >>>> now, see changes in Toolkit.java >>>> 2. For modules we need to move flavormap.properties out of the >>>> jre/lib. I'm not sure about the new location. Can I add properties >>>> to the java.awt.datatransfer package? Wouldn't they be considered >>>> public in this case? >>>> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by >>>> the user and it's not used by us. So I'm removing it. >>>> 4. As flavormap.properties is not editable by the user any more, I'm >>>> changing it's format to get significant simplification of the >>>> parsing code. >>>> >>>> There's no way left to change the default mappings now, but we have >>>> public supported API to create new mappings in the Java code. System >>>> property could be added to provide alternative properties location, >>>> but I don't think it's required. >>>> >>> The dropping of the reference to flavormap.properties from >>> java.awt.Toolkit looks okay to me. >>> >>> I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap >>> (not a detailed review) and it looks okay. I cannot comment on the >>> changes to format as I don't know the history in this area to >>> understand the issues around duplicates. >>> >>> On your question about introducing a system property to allow the >>> configuration be picked up from some other (non-JDK) location then it >>> doesn't sound like there is a strong case. Do we know if anyone has >>> been editing the file in ${java.home}/lib? I assume that if there is a >>> strong need then it could be possible to introducing it in the future >>> without conflicting with anything that you are doing here. >>> >>> -Alan. >> From anthony.petrov at oracle.com Fri Jun 20 11:37:16 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 20 Jun 2014 15:37:16 +0400 Subject: [9] Review Request: 8047336 Read flavormap.properties as resource In-Reply-To: <53A41B16.9020404@oracle.com> References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com> <53A2D3DA.4030503@oracle.com> <53A418B9.6080500@oracle.com> <53A41B16.9020404@oracle.com> Message-ID: <53A41CEC.3060102@oracle.com> On 6/20/2014 3:29 PM, Artem Ananiev wrote: > On 6/20/2014 3:19 PM, Anthony Petrov wrote: >> I ran the following query: >> >> https://www.google.com/#q=custom+flavormap.properties >> >> and the search yielded the following forum thread: >> >> https://community.oracle.com/thread/1293314?start=0&tstart=0 >> >> where developers seem to suggest they do edit the >> $JDKHOME/jre/lib/flavormap.properties file sometimes. >> >> Do we officially declare that we drop support for this possibility? > > This possibility will be dropped regardless of the current Petr's fix, > since there will be no single "jre" folder in jigsaw world. Probably, > some other mechanism to customize files like flavormap.properties or > logging.properties will be introduced. Can we file an RFE for this feature now please? > BTW, the current fix is not about flavormap.properties on its own, but > about removing AWT.DnD.flavorMapFileURL toolkit property. I would > suggest to push this change as a separate bug fix, not as a part of > 8047336. +1 -- best regards, Anthony > > Thanks, > > Artem > >> -- >> best regards, >> Anthony >> >> On 6/19/2014 4:24 PM, Petr Pchelko wrote: >>> Hello, Alan. >>> >>> Thank you for the review. >>> >>>> Do we know if anyone has been editing the file in ${java.home}/lib? >>> I couldn't find any examples on the internet although I've done a very >>> extensive search, so I we could add a property later if someone would >>> request it. >>> >>> With best regards. Petr. >>> >>> On 19 ???? 2014 ?., at 16:13, Alan Bateman >> > wrote: >>> >>>> On 19/06/2014 12:17, Petr Pchelko wrote: >>>>> Hello, >>>>> >>>>> Please review the fix for the issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8047336 >>>>> The fix is available at: >>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/ >>>>> >>>>> This is another step in datatransfer modularization work. This part >>>>> of the work needs a CCC, so I've moved it out to a separate fix. The >>>>> CCC will be filed once the fix is settled. >>>>> >>>>> Multiple changes are happening here: >>>>> 1. Afterhttp://ccc.us.oracle.com/8005250 the flavormap.properties >>>>> and AWT.DnD.flavorMapFileURL Toolkit property was removed from the >>>>> public API. However one mention was forgotten and I'm removing it >>>>> now, see changes in Toolkit.java >>>>> 2. For modules we need to move flavormap.properties out of the >>>>> jre/lib. I'm not sure about the new location. Can I add properties >>>>> to the java.awt.datatransfer package? Wouldn't they be considered >>>>> public in this case? >>>>> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by >>>>> the user and it's not used by us. So I'm removing it. >>>>> 4. As flavormap.properties is not editable by the user any more, I'm >>>>> changing it's format to get significant simplification of the >>>>> parsing code. >>>>> >>>>> There's no way left to change the default mappings now, but we have >>>>> public supported API to create new mappings in the Java code. System >>>>> property could be added to provide alternative properties location, >>>>> but I don't think it's required. >>>>> >>>> The dropping of the reference to flavormap.properties from >>>> java.awt.Toolkit looks okay to me. >>>> >>>> I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap >>>> (not a detailed review) and it looks okay. I cannot comment on the >>>> changes to format as I don't know the history in this area to >>>> understand the issues around duplicates. >>>> >>>> On your question about introducing a system property to allow the >>>> configuration be picked up from some other (non-JDK) location then it >>>> doesn't sound like there is a strong case. Do we know if anyone has >>>> been editing the file in ${java.home}/lib? I assume that if there is a >>>> strong need then it could be possible to introducing it in the future >>>> without conflicting with anything that you are doing here. >>>> >>>> -Alan. >>> From petr.pchelko at oracle.com Fri Jun 20 11:41:18 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 20 Jun 2014 15:41:18 +0400 Subject: [9] Review Request: 8047336 Read flavormap.properties as resource In-Reply-To: <53A41B16.9020404@oracle.com> References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com> <53A2D3DA.4030503@oracle.com> <53A418B9.6080500@oracle.com> <53A41B16.9020404@oracle.com> Message-ID: <18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com> Hello, Anthony, Artem. >> Do we officially declare that we drop support for this possibility? > This possibility will be dropped regardless of the current Petr's fix, since there will be no single "jre" folder in jigsaw world. Probably, some other mechanism to customize files like flavormap.properties or logging.properties will be introduced. And we can add a system property to set an alternative flavormap.properties file later if someone would request such a feature. > BTW, the current fix is not about flavormap.properties on its own, but about removing AWT.DnD.flavorMapFileURL toolkit property. I would suggest to push this change as a separate bug fix, not as a part of 8047336. And also about changing flavormap.properties format) The current fix is all the work in datatransfer modularization that needs a CCC. All changes seem related, so I would prefer no to split it further, because it would make it harder to track when all the peaces are integrated to jake repository to continue the work. And it would need more CCC requests which consume time. Thank you. With best regards. Petr. On 20 ???? 2014 ?., at 15:29, Artem Ananiev wrote: > > On 6/20/2014 3:19 PM, Anthony Petrov wrote: >> Hi Petr, >> >> I ran the following query: >> >> https://www.google.com/#q=custom+flavormap.properties >> >> and the search yielded the following forum thread: >> >> https://community.oracle.com/thread/1293314?start=0&tstart=0 >> >> where developers seem to suggest they do edit the >> $JDKHOME/jre/lib/flavormap.properties file sometimes. >> >> Do we officially declare that we drop support for this possibility? > > This possibility will be dropped regardless of the current Petr's fix, since there will be no single "jre" folder in jigsaw world. Probably, some other mechanism to customize files like flavormap.properties or logging.properties will be introduced. > > BTW, the current fix is not about flavormap.properties on its own, but about removing AWT.DnD.flavorMapFileURL toolkit property. I would suggest to push this change as a separate bug fix, not as a part of 8047336. > > Thanks, > > Artem > >> -- >> best regards, >> Anthony >> >> On 6/19/2014 4:24 PM, Petr Pchelko wrote: >>> Hello, Alan. >>> >>> Thank you for the review. >>> >>>> Do we know if anyone has been editing the file in ${java.home}/lib? >>> I couldn't find any examples on the internet although I've done a very >>> extensive search, so I we could add a property later if someone would >>> request it. >>> >>> With best regards. Petr. >>> >>> On 19 ???? 2014 ?., at 16:13, Alan Bateman >> > wrote: >>> >>>> On 19/06/2014 12:17, Petr Pchelko wrote: >>>>> Hello, >>>>> >>>>> Please review the fix for the issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8047336 >>>>> The fix is available at: >>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/ >>>>> >>>>> This is another step in datatransfer modularization work. This part >>>>> of the work needs a CCC, so I've moved it out to a separate fix. The >>>>> CCC will be filed once the fix is settled. >>>>> >>>>> Multiple changes are happening here: >>>>> 1. Afterhttp://ccc.us.oracle.com/8005250 the flavormap.properties >>>>> and AWT.DnD.flavorMapFileURL Toolkit property was removed from the >>>>> public API. However one mention was forgotten and I'm removing it >>>>> now, see changes in Toolkit.java >>>>> 2. For modules we need to move flavormap.properties out of the >>>>> jre/lib. I'm not sure about the new location. Can I add properties >>>>> to the java.awt.datatransfer package? Wouldn't they be considered >>>>> public in this case? >>>>> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by >>>>> the user and it's not used by us. So I'm removing it. >>>>> 4. As flavormap.properties is not editable by the user any more, I'm >>>>> changing it's format to get significant simplification of the >>>>> parsing code. >>>>> >>>>> There's no way left to change the default mappings now, but we have >>>>> public supported API to create new mappings in the Java code. System >>>>> property could be added to provide alternative properties location, >>>>> but I don't think it's required. >>>>> >>>> The dropping of the reference to flavormap.properties from >>>> java.awt.Toolkit looks okay to me. >>>> >>>> I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap >>>> (not a detailed review) and it looks okay. I cannot comment on the >>>> changes to format as I don't know the history in this area to >>>> understand the issues around duplicates. >>>> >>>> On your question about introducing a system property to allow the >>>> configuration be picked up from some other (non-JDK) location then it >>>> doesn't sound like there is a strong case. Do we know if anyone has >>>> been editing the file in ${java.home}/lib? I assume that if there is a >>>> strong need then it could be possible to introducing it in the future >>>> without conflicting with anything that you are doing here. >>>> >>>> -Alan. >>> From anthony.petrov at oracle.com Fri Jun 20 11:43:13 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 20 Jun 2014 15:43:13 +0400 Subject: [9] Review Request: 8047336 Read flavormap.properties as resource In-Reply-To: <18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com> References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com> <53A2D3DA.4030503@oracle.com> <53A418B9.6080500@oracle.com> <53A41B16.9020404@oracle.com> <18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com> Message-ID: <53A41E51.1060205@oracle.com> I see. OK then. But this looks like something that needs to be release-noted. -- best regards, Anthony On 6/20/2014 3:41 PM, Petr Pchelko wrote: > Hello, Anthony, Artem. > >>> Do we officially declare that we drop support for this possibility? >> This possibility will be dropped regardless of the current Petr's fix, since there will be no single "jre" folder in jigsaw world. Probably, some other mechanism to customize files like flavormap.properties or logging.properties will be introduced. > And we can add a system property to set an alternative flavormap.properties file later if someone would request such a feature. > >> BTW, the current fix is not about flavormap.properties on its own, but about removing AWT.DnD.flavorMapFileURL toolkit property. I would suggest to push this change as a separate bug fix, not as a part of 8047336. > And also about changing flavormap.properties format) The current fix is all the work in datatransfer modularization that needs a CCC. All changes seem related, so I would prefer no to split it further, > because it would make it harder to track when all the peaces are integrated to jake repository to continue the work. And it would need more CCC requests which consume time. > > Thank you. > With best regards. Petr. > > On 20 ???? 2014 ?., at 15:29, Artem Ananiev wrote: > >> >> On 6/20/2014 3:19 PM, Anthony Petrov wrote: >>> Hi Petr, >>> >>> I ran the following query: >>> >>> https://www.google.com/#q=custom+flavormap.properties >>> >>> and the search yielded the following forum thread: >>> >>> https://community.oracle.com/thread/1293314?start=0&tstart=0 >>> >>> where developers seem to suggest they do edit the >>> $JDKHOME/jre/lib/flavormap.properties file sometimes. >>> >>> Do we officially declare that we drop support for this possibility? >> >> This possibility will be dropped regardless of the current Petr's fix, since there will be no single "jre" folder in jigsaw world. Probably, some other mechanism to customize files like flavormap.properties or logging.properties will be introduced. >> >> BTW, the current fix is not about flavormap.properties on its own, but about removing AWT.DnD.flavorMapFileURL toolkit property. I would suggest to push this change as a separate bug fix, not as a part of 8047336. >> >> Thanks, >> >> Artem >> >>> -- >>> best regards, >>> Anthony >>> >>> On 6/19/2014 4:24 PM, Petr Pchelko wrote: >>>> Hello, Alan. >>>> >>>> Thank you for the review. >>>> >>>>> Do we know if anyone has been editing the file in ${java.home}/lib? >>>> I couldn't find any examples on the internet although I've done a very >>>> extensive search, so I we could add a property later if someone would >>>> request it. >>>> >>>> With best regards. Petr. >>>> >>>> On 19 ???? 2014 ?., at 16:13, Alan Bateman >>> > wrote: >>>> >>>>> On 19/06/2014 12:17, Petr Pchelko wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the fix for the issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8047336 >>>>>> The fix is available at: >>>>>> http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/ >>>>>> >>>>>> This is another step in datatransfer modularization work. This part >>>>>> of the work needs a CCC, so I've moved it out to a separate fix. The >>>>>> CCC will be filed once the fix is settled. >>>>>> >>>>>> Multiple changes are happening here: >>>>>> 1. Afterhttp://ccc.us.oracle.com/8005250 the flavormap.properties >>>>>> and AWT.DnD.flavorMapFileURL Toolkit property was removed from the >>>>>> public API. However one mention was forgotten and I'm removing it >>>>>> now, see changes in Toolkit.java >>>>>> 2. For modules we need to move flavormap.properties out of the >>>>>> jre/lib. I'm not sure about the new location. Can I add properties >>>>>> to the java.awt.datatransfer package? Wouldn't they be considered >>>>>> public in this case? >>>>>> 3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by >>>>>> the user and it's not used by us. So I'm removing it. >>>>>> 4. As flavormap.properties is not editable by the user any more, I'm >>>>>> changing it's format to get significant simplification of the >>>>>> parsing code. >>>>>> >>>>>> There's no way left to change the default mappings now, but we have >>>>>> public supported API to create new mappings in the Java code. System >>>>>> property could be added to provide alternative properties location, >>>>>> but I don't think it's required. >>>>>> >>>>> The dropping of the reference to flavormap.properties from >>>>> java.awt.Toolkit looks okay to me. >>>>> >>>>> I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap >>>>> (not a detailed review) and it looks okay. I cannot comment on the >>>>> changes to format as I don't know the history in this area to >>>>> understand the issues around duplicates. >>>>> >>>>> On your question about introducing a system property to allow the >>>>> configuration be picked up from some other (non-JDK) location then it >>>>> doesn't sound like there is a strong case. Do we know if anyone has >>>>> been editing the file in ${java.home}/lib? I assume that if there is a >>>>> strong need then it could be possible to introducing it in the future >>>>> without conflicting with anything that you are doing here. >>>>> >>>>> -Alan. >>>> > From Alan.Bateman at oracle.com Fri Jun 20 11:50:10 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Jun 2014 12:50:10 +0100 Subject: [9] Review Request: 8047336 Read flavormap.properties as resource In-Reply-To: <18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com> References: <59786637-036B-49C3-AB92-0D5742C87AC2@oracle.com> <53A2D3DA.4030503@oracle.com> <53A418B9.6080500@oracle.com> <53A41B16.9020404@oracle.com> <18DA96EE-B90D-4BAD-8990-6D4972446019@oracle.com> Message-ID: <53A41FF2.8050705@oracle.com> On 20/06/2014 12:41, Petr Pchelko wrote: > Hello, Anthony, Artem. > >>> Do we officially declare that we drop support for this possibility? >> This possibility will be dropped regardless of the current Petr's fix, since there will be no single "jre" folder in jigsaw world. Probably, some other mechanism to customize files like flavormap.properties or logging.properties will be introduced. > And we can add a system property to set an alternative flavormap.properties file later if someone would request such a feature. > >> BTW, the current fix is not about flavormap.properties on its own, but about removing AWT.DnD.flavorMapFileURL toolkit property. I would suggest to push this change as a separate bug fix, not as a part of 8047336. > And also about changing flavormap.properties format) The current fix is all the work in datatransfer modularization that needs a CCC. All changes seem related, so I would prefer no to split it further, > because it would make it harder to track when all the peaces are integrated to jake repository to continue the work. And it would need more CCC requests which consume time. > The forum post looks like is from 2001. If there doesn't appear that many developers have resorted to editing that file then I would suggest just going with what you have. If it really becomes necessary to support having configuration elsewhere (not in the JDK image) then I don't think anything that you have now precludes that. -Alan. From mikael.vidstedt at oracle.com Sat Jun 21 05:35:52 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 20 Jun 2014 22:35:52 -0700 Subject: RFR (XS): 8047763: Recognize sparc64 as a sparc platform Message-ID: <53A519B8.9030003@oracle.com> Please review the following change which adds code to recognize "sparc64" as a 64-bit sparc platform. sparc64 is what uname returns on linux/sparc, and is the value which trickles up to the platform.m4 switch. (I've excluded the generated-configure.sh scripts in the webrev). Bug: https://bugs.openjdk.java.net/browse/JDK-8047763 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8047763/webrev.00/webrev/ Thanks, Mikae From Alan.Bateman at oracle.com Sat Jun 21 09:30:45 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 21 Jun 2014 10:30:45 +0100 Subject: Can jdk/src/macosx/native/jobjc be deleted? Message-ID: <53A550C5.6020400@oracle.com> JObjC was dropped from the build in JDK 8, it was dropped in a JDK 7 update too. The remnants of it were removed from the build via JDK-8033111 in jdk9-b03 but the dead code in the jdk/src/macosx/native/jobjc was not removed. Is there any reason to keep it around in the JDK 9 forest? -Alan. From david.holmes at oracle.com Mon Jun 23 07:19:51 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Jun 2014 17:19:51 +1000 Subject: RFR (XS): 8047763: Recognize sparc64 as a sparc platform In-Reply-To: <53A519B8.9030003@oracle.com> References: <53A519B8.9030003@oracle.com> Message-ID: <53A7D517.1000905@oracle.com> Looks okay to me. David On 21/06/2014 3:35 PM, Mikael Vidstedt wrote: > > Please review the following change which adds code to recognize > "sparc64" as a 64-bit sparc platform. sparc64 is what uname returns on > linux/sparc, and is the value which trickles up to the platform.m4 switch. > > (I've excluded the generated-configure.sh scripts in the webrev). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8047763 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8047763/webrev.00/webrev/ > > Thanks, > Mikae From volker.simonis at gmail.com Mon Jun 23 16:42:29 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 23 Jun 2014 18:42:29 +0200 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH In-Reply-To: <53A092D4.3060100@oracle.com> References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com> <539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com> <539F50E1.7090300@oracle.com> <539FACB2.2050508@oracle.com> <53A092D4.3060100@oracle.com> Message-ID: Hi Mikael, sorry for the delayed answer - the PPC/AIX team was on holiday:) I've tested your changes on AIX and Linux/PPC64. On AIX everything works fine. For Linux/PPC64 there's a single occurrence of a test against $ARCH which you've missed: diff -r 116e9b1bf477 make/linux/Makefile --- a/make/linux/Makefile Mon Jun 23 17:43:30 2014 +0200 +++ b/make/linux/Makefile Mon Jun 23 18:15:20 2014 +0200 @@ -67,8 +67,10 @@ endif endif # C1 is not ported on ppc64, so we cannot build a tiered VM: -ifeq ($(ARCH),ppc64) - FORCE_TIERED=0 +ifeq ($(ARCH),ppc) + ifeq ($(ARCH_DATA_MODEL), 64) + FORCE_TIERED=0 + endif endif ifdef LP64 With this change I could successfully build on AIX and Linux/PPC64 (I've only tested complete builds). Thank you and best regards, Volker On Tue, Jun 17, 2014 at 9:11 PM, Mikael Vidstedt wrote: > > New webrev here (only the hotspot part, the webrev for top hasn't changed): > > http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/ > > Comments inline. > > > On 2014-06-16 19:49, David Holmes wrote: >> >> Hi Mikael, >> >> Sorry for the delay ... >> >> make/aix/makefiles/defs.make: >> >> This change doesn't make sense to me: >> >> 48 ifneq (,$(findstring $(ARCH), ppc)) >> >> given that the logic immediately preceding this sets ARCH to either ppc or >> ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow for both >> 32-bit and 64-bit cross-builds but the earlier logic is really precluding >> this. So it seems to me that the changes in this file are completely >> unnecessary (or else the earlier logic also needs changing). > > > Indeed, that is correct - I missed the fact that ARCH is always overriden to > be either ppc or ppc64. The old logic is unnecessarily hard to follow, but I > guess that's in line with our hotspot Makefiles in general ;) > > I'll revert the changes to the file and add a mental note to self and others > that linux appears to be the only platform where the incoming value of ARCH > is actually honored - it's ignored/overridden on Solaris, BSD and AIX. > > >> make/linux/makefiles/defs.make >> >> This block: >> >> 86 # i686/i586 and amd64/x86_64 >> 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586)) >> 88 ifeq ($(ARCH_DATA_MODEL), 64) >> 89 ARCH_DATA_MODEL = 64 >> 90 MAKE_ARGS += LP64=1 >> 91 PLATFORM = linux-amd64 >> 92 VM_PLATFORM = linux_amd64 >> 93 HS_ARCH = x86 >> 94 else >> 95 ARCH_DATA_MODEL = 32 >> 96 PLATFORM = linux-i586 >> 97 VM_PLATFORM = linux_i486 >> 98 HS_ARCH = x86 >> 99 # We have to reset ARCH to i686 since SRCARCH relies on it >> 100 ARCH = i686 >> 101 endif >> 102 endif >> >> seems to allow the user to try and do a 64-bit build on a 32-bit build >> machine. Not sure if that would get caught in an earlier sanity check? (Same >> is true for the sparc block). > > > While the changes are primarily just intended to cut down on the duplication > I don't immediately see the reason why we wouldn't want to allow compiling a > 64-bit VM from a 32-bit machine? We're cross compiling all sorts of > platforms, so why not allow this if the compiler supports it? I'd prefer to > keep it this way. > > >> Also I don't think the following is actually true: >> >> # We have to reset ARCH to i686 since SRCARCH relies on it >> ARCH = i686 >> >> As long as ARCH is not amd64 and not x86_64 any 32-bit x86 architecture >> designator will simply map to a SRCARCH of x86, as per defs.make: >> >> SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc >> zero,$(ARCH))) >> ARCH/ = x86 >> ARCH/sparc = sparc >> ARCH/sparc64= sparc >> ARCH/ia64 = ia64 >> ARCH/amd64 = x86 >> ARCH/x86_64 = x86 >> ARCH/ppc64 = ppc >> ARCH/ppc = ppc >> ARCH/arm = arm >> ARCH/zero = zero > > > Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64, ppc64, > ppc, arm, zero } it will map to x86 anyway. I thought about cleaning that up > before I sent out the first webrev, but soon found myself doing way more > cleanup than was healthy for this specific change. However, since I had to > update this change anyway I removed the ARCH reset part. > > Cheers, > Mikael > > >> >> >> Cheers, >> David >> >> On 17/06/2014 6:17 AM, Mikael Vidstedt wrote: >>> >>> >>> Thanks Erik. Another review please? >>> >>> Cheers, >>> Mikael >>> >>> On 2014-06-12 23:56, Erik Joelsson wrote: >>>> >>>> Looks fine to me. >>>> >>>> /Erik >>>> >>>> On 2014-06-12 23:18, Mikael Vidstedt wrote: >>>>> >>>>> >>>>> I have now verified that the changes work just fine for the platforms >>>>> we build and test - both from the top level and when building hotspot >>>>> only. Taking suggestions on other tests to perform. And it would be >>>>> great if somebody could test the changes on on aix/ppc. >>>>> >>>>> So, kindly asking for "real"/final reviews of the changes: >>>>> >>>>> top: >>>>> >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>>> hotspot: >>>>> >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>>> >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>> On 2014-06-10 22:53, Mikael Vidstedt wrote: >>>>>> >>>>>> >>>>>> David, >>>>>> >>>>>> Thanks for the feedback. Essentially the logic in the >>>>>> make//makefiles/defs.make files needs to recognize and deal with >>>>>> two different use cases: >>>>>> >>>>>> 1. ARCH being set by the JDK build system to the value of >>>>>> OPENJDK_TARGET_CPU_ARCH, or >>>>>> 2. no ARCH being set, in which case it needs to be populated - >>>>>> typically from uname >>>>>> >>>>>> Since Solaris and bsd both override ARCH they do not care about >>>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2. >>>>>> >>>>>> Linux/x86 is where most of the difference (and confusion) is, but I >>>>>> think aix/ppc64 will also change slightly since the ARCH value will >>>>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I >>>>>> cannot verify that they actually work. cc:ing the ppc-aix list in >>>>>> the hope that somebody can help out with that. >>>>>> >>>>>> >>>>>> Summing it up, I have the following two webrevs: >>>>>> >>>>>> top: >>>>>> >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>>>> >>>>>> hotspot: >>>>>> >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>>>> >>>>>> >>>>>> With these changes I can build the normal platforms, but more >>>>>> verification is needed - esp. building hotspot only. Meanwhile >>>>>> feedback is much appreciated! >>>>>> >>>>>> Cheers, >>>>>> Mikael >>>>>> >>>>>> On 2014-06-10 19:45, David Holmes wrote: >>>>>>> >>>>>>> Hi Mikael, >>>>>>> >>>>>>> This seems a reasonable proposal to me. We have an over-abundance >>>>>>> of "arch" variables and values, so reducing that is a good aim. >>>>>>> >>>>>>> As you note the main flow-on effect here is that the hotspot >>>>>>> makefiles have to be updated for the cases where >>>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so >>>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think >>>>>>> only x86 has that issue. >>>>>>> >>>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc >>>>>>> both internally and in the build artifacts and bundles! >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote: >>>>>>>> >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> I need some feedback and comments on the below fix: >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ >>>>>>>> >>>>>>>> Background: >>>>>>>> >>>>>>>> When configuring the hotspot build the build system sets up the ARCH >>>>>>>> variable to reflect the target cpu. Currently the value is >>>>>>>> initialized >>>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu >>>>>>>> name. For >>>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). >>>>>>>> The >>>>>>>> goal in the new (JDK) build system is to have the "legacy" value >>>>>>>> gradually removed in favor of the other variables. >>>>>>>> >>>>>>>> Discussion: >>>>>>>> >>>>>>>> The two candidate variables to base ARCH on are as far as I can tell >>>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two >>>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, >>>>>>>> well >>>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. >>>>>>>> Together >>>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the >>>>>>>> Hotspot build system to do its thing. Note: ARCH is currently >>>>>>>> ignored on >>>>>>>> solaris and bsd - it's overridden at the top of the respective >>>>>>>> make//makefiles/defs.make files. >>>>>>>> >>>>>>>> Before I go too far with this though I'd like to get some feedback >>>>>>>> on >>>>>>>> whether or not this is the right approach and what the exact value >>>>>>>> should be. Depending on the outcome of that the Hotspot build >>>>>>>> system may >>>>>>>> have to be updated for some platforms to support the new value(s). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Mikael >>>>>>>> >>>>>> >>>>> >>>> >>> > From mike.duigou at oracle.com Mon Jun 23 21:50:41 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 23 Jun 2014 14:50:41 -0700 Subject: Add version check to get_source.sh Message-ID: <57A0035C-C08A-452F-A3B5-9ED27D9AE518@oracle.com> Hello all; This is the changeset for the enhancement proposed last week. It adds version checks to get_source.sh script. Currently the script will abort if the Mercurial client is not found or is older than 1.5.0. If Mercurial client is older than 2.6.3 then a warning will be issued but the script will attempt to continue. webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047925/0/webrev/ jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047925 Mike From tim.bell at oracle.com Tue Jun 24 00:00:50 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 24 Jun 2014 00:00:50 +0000 Subject: Add version check to get_source.sh In-Reply-To: <57A0035C-C08A-452F-A3B5-9ED27D9AE518@oracle.com> References: <57A0035C-C08A-452F-A3B5-9ED27D9AE518@oracle.com> Message-ID: <53A8BFB2.9080105@oracle.com> Hi Mike: > This is the changeset for the enhancement proposed last week. It adds version checks to get_source.sh script. Currently the script will abort if the Mercurial client is not found or is older than 1.5.0. If Mercurial client is older than 2.6.3 then a warning will be issued but the script will attempt to continue. > > webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047925/0/webrev/ > jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047925 Looks good to me. Tim From mikael.vidstedt at oracle.com Tue Jun 24 04:38:05 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 23 Jun 2014 21:38:05 -0700 Subject: Add version check to get_source.sh In-Reply-To: <57A0035C-C08A-452F-A3B5-9ED27D9AE518@oracle.com> References: <57A0035C-C08A-452F-A3B5-9ED27D9AE518@oracle.com> Message-ID: Minor typo: + echo "WARNING: Mercurial version $rqstmajor.$rqstminor.$rqstrev or later is recommended. $hgwhere is version version $hgversion" >&2 "...version version..." Otherwise fine! Cheers, Mikael > On Jun 23, 2014, at 14:50, Mike Duigou wrote: > > Hello all; > > This is the changeset for the enhancement proposed last week. It adds version checks to get_source.sh script. Currently the script will abort if the Mercurial client is not found or is older than 1.5.0. If Mercurial client is older than 2.6.3 then a warning will be issued but the script will attempt to continue. > > webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047925/0/webrev/ > jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047925 > > Mike From omajid at redhat.com Tue Jun 24 20:22:46 2014 From: omajid at redhat.com (Omair Majid) Date: Tue, 24 Jun 2014 16:22:46 -0400 Subject: RFR: 8044733: (xs) common/autoconf/configure script doesn't properly detect missing tools In-Reply-To: <538ED632.1010400@oracle.com> References: <52DE10C0-E461-4040-B9F8-5F70850FC3C1@oracle.com> <538ED632.1010400@oracle.com> Message-ID: <20140624202245.GE11390@redhat.com> * Erik Joelsson [2014-06-04 04:18]: > Looks good. Using "which" is a pain. Have you considered switching away from `which`? A number of other alternatives, with better behaviour, are possible: http://stackoverflow.com/questions/592620/ Cheers, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From mike.duigou at oracle.com Tue Jun 24 21:58:26 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 24 Jun 2014 14:58:26 -0700 Subject: RFR: 8044733: (xs) common/autoconf/configure script doesn't properly detect missing tools In-Reply-To: <20140624202245.GE11390@redhat.com> References: <52DE10C0-E461-4040-B9F8-5F70850FC3C1@oracle.com> <538ED632.1010400@oracle.com> <20140624202245.GE11390@redhat.com> Message-ID: "command -v foo" looks like a much better option. Thanks! Mike On Jun 24 2014, at 13:22 , Omair Majid wrote: > * Erik Joelsson [2014-06-04 04:18]: >> Looks good. Using "which" is a pain. > > Have you considered switching away from `which`? > > A number of other alternatives, with better behaviour, are possible: > http://stackoverflow.com/questions/592620/ > > Cheers, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From mike.duigou at oracle.com Tue Jun 24 22:20:56 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 24 Jun 2014 15:20:56 -0700 Subject: Add version check to get_source.sh In-Reply-To: References: <57A0035C-C08A-452F-A3B5-9ED27D9AE518@oracle.com> Message-ID: <4E35D583-484A-495C-996E-F2A2015FEB4E@oracle.com> On Jun 23 2014, at 21:38 , Mikael Vidstedt wrote: > > Minor typo: > > + echo "WARNING: Mercurial version $rqstmajor.$rqstminor.$rqstrev or later is recommended. $hgwhere is version version $hgversion" >&2 > "...version version..." > Otherwise fine! Thank you. Corrected. > > Cheers, > Mikael > > On Jun 23, 2014, at 14:50, Mike Duigou wrote: > >> Hello all; >> >> This is the changeset for the enhancement proposed last week. It adds version checks to get_source.sh script. Currently the script will abort if the Mercurial client is not found or is older than 1.5.0. If Mercurial client is older than 2.6.3 then a warning will be issued but the script will attempt to continue. >> >> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047925/0/webrev/ >> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047925 >> >> Mike From joe.darcy at oracle.com Wed Jun 25 01:02:42 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 24 Jun 2014 18:02:42 -0700 Subject: JDK 9 RFR of changing sense of lint warning in the jdk makefile Message-ID: <53AA1FB2.9050800@oracle.com> Hello, In the makefile for the jdk repo, the current options list to javac's warning is a bit awkward since it lists all the options that are enabled as opposed to the ones which are disabled. Nearly all the options are enabled now (yay!) and I think it would be cleaner to reverse the sense of the list: diff -r 07eb3be7e64b make/Setup.gmk --- a/make/Setup.gmk Tue Jun 24 10:46:08 2014 -0700 +++ b/make/Setup.gmk Tue Jun 24 17:58:15 2014 -0700 @@ -27,7 +27,7 @@ # To build with all warnings enabled, do the following: # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" -JAVAC_WARNINGS := -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,finally,overloads,serial,static,try,varargs -Werror +JAVAC_WARNINGS := -Xlint:all,-deprecation,-rawtypes,-unchecked -Werror # Any java code executed during a JDK build to build other parts of the JDK must be # executed by the bootstrap JDK (probably with -Xbootclasspath/p: ) and for this If there is agreement this is an improvement, I'll file a bug and have the change pushed via jprt. (This change works for an OpenJDK build on linux, but there is a possibility closed or platform-specific code triggers some warning not related to source code, like options handling, in which case a few additional "-foo" clauses might be needed.) Thanks, -Joe From mikael.vidstedt at oracle.com Wed Jun 25 03:05:07 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 24 Jun 2014 20:05:07 -0700 Subject: JDK 9 RFR of changing sense of lint warning in the jdk makefile In-Reply-To: <53AA1FB2.9050800@oracle.com> References: <53AA1FB2.9050800@oracle.com> Message-ID: <7A3561B4-DE06-4297-BF95-E9E458A90127@oracle.com> Sounds like a very reasonable thing to do. Congrats on getting all the warnings addressed! Cheers, Mikael > On Jun 24, 2014, at 18:02, Joe Darcy wrote: > > Hello, > > In the makefile for the jdk repo, the current options list to javac's warning is a bit awkward since it lists all the options that are enabled as opposed to the ones which are disabled. Nearly all the options are enabled now (yay!) and I think it would be cleaner to reverse the sense of the list: > > diff -r 07eb3be7e64b make/Setup.gmk > --- a/make/Setup.gmk Tue Jun 24 10:46:08 2014 -0700 > +++ b/make/Setup.gmk Tue Jun 24 17:58:15 2014 -0700 > @@ -27,7 +27,7 @@ > > # To build with all warnings enabled, do the following: > # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" > -JAVAC_WARNINGS := -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,finally,overloads,serial,static,try,varargs -Werror > +JAVAC_WARNINGS := -Xlint:all,-deprecation,-rawtypes,-unchecked -Werror > > # Any java code executed during a JDK build to build other parts of the JDK must be > # executed by the bootstrap JDK (probably with -Xbootclasspath/p: ) and for this > > If there is agreement this is an improvement, I'll file a bug and have the change pushed via jprt. (This change works for an OpenJDK build on linux, but there is a possibility closed or platform-specific code triggers some warning not related to source code, like options handling, in which case a few additional "-foo" clauses might be needed.) > > Thanks, > > -Joe From pointo1d at gmail.com Wed Jun 25 09:51:34 2014 From: pointo1d at gmail.com (pointo1d) Date: Wed, 25 Jun 2014 10:51:34 +0100 Subject: Add version check to get_source.sh In-Reply-To: <57A0035C-C08A-452F-A3B5-9ED27D9AE518@oracle.com> References: <57A0035C-C08A-452F-A3B5-9ED27D9AE518@oracle.com> Message-ID: <53AA9BA6.6040707@gmail.com> Hiya Mike , On 23/06/14 22:50, Mike Duigou wrote: > Hello all; > > This is the changeset for the enhancement proposed last week. It adds version checks to get_source.sh script. Currently the script will abort if the Mercurial client is not found or is older than 1.5.0. If Mercurial client is older than 2.6.3 then a warning will be issued but the script will attempt to continue. > > webrev:http://cr.openjdk.java.net/~mduigou/JDK-8047925/0/webrev/ > jbsbug:https://bugs.openjdk.java.net/browse/JDK-8047925 > > Mike Would the following (or similar) not help by way of improving readability (also incorporating the typo identified by Mikael)... to_stderr() { echo "$@" >&2 } error() { to_stderr "ERROR: $1" exit ${2:-126} } error "Could not locate Mercurial command" . . . error"Could not determine Mercurial version" . . . to_stderr "WARNING: Mercurial version $rqstmajor.$rqstminor.$rqstrev or later is recommended. $hgwhere is version $hgversion" Best rgds , -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe From gnu.andrew at redhat.com Wed Jun 25 14:44:04 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 25 Jun 2014 10:44:04 -0400 (EDT) Subject: URGENT RFR: 8041141: JDK9 emb build failure on PPC platform In-Reply-To: <53990291.6030507@oracle.com> References: <5355AF58.6040809@oracle.com> <1590192238.23041739.1402506219778.JavaMail.zimbra@redhat.com> <53990291.6030507@oracle.com> Message-ID: <723284019.30326403.1403707444234.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Andrew, > > On 12/06/2014 3:03 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> http://cr.openjdk.java.net/~dholmes/8041141/webrev/ > >> > >> The recent changes to convert warnings to errors didn't account for some > >> type-punning warnings in our Embedded PPC build due to the use of > >> strict-aliasing. Really we shouldn't be using strict-aliasing so this > >> change (which for some reason is in the open flags.m4 file) brings ppc > >> in-line with all other platforms and sets -fno-strict-aliasing > >> > >> I will be pushing this to jdk9/dev as we need this fixed immediately. > >> > >> Thanks, > >> David > >> > > > > Hi David, > > > > I just stumbled across this when trying to work out why we are seeing > > aliasing > > warnings in the demo code only on PPC builds. They get flagged by our build > > process. > > This exclusion of fno-strict-aliasing on PPC seems to date back to 7027910 > > in OpenJDK > > 7, where we are seeing the warnings, and there seems to be no explanation > > as to why > > it was added in either the code or reviews. > > It was copied from our internal build instructions. The new build > unfortunately required it to be exposed in flags.m4. Ah, ok. > > > Given -fno-strict-aliasing is now being used on all architectures in 9, do > > you think > > it's ok to do the same in 7? I could also turn it off on the individual > > files, but > > this would duplicate the flag on other architectures and we may then get > > more PPC-only > > warnings in future. > > I think it should be fine in principle. I'm not sure what the actual > change in 7 would be. Just this: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.5/jdk/rev/925c4ace5635 I'll look at getting the change backported to 7 & 8 then. > > David > ----- > > > Thanks, > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From volker.simonis at gmail.com Wed Jun 25 16:05:38 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 25 Jun 2014 18:05:38 +0200 Subject: URGENT RFR: 8041141: JDK9 emb build failure on PPC platform In-Reply-To: <5399B0E8.8050107@redhat.com> References: <5355AF58.6040809@oracle.com> <1590192238.23041739.1402506219778.JavaMail.zimbra@redhat.com> <5399B0E8.8050107@redhat.com> Message-ID: On Thu, Jun 12, 2014 at 3:53 PM, Andrew Haley wrote: > Hi, > > On 06/11/2014 06:03 PM, Andrew Hughes wrote: >> >> I just stumbled across this when trying to work out why we are seeing aliasing >> warnings in the demo code only on PPC builds. They get flagged by our build process. >> This exclusion of fno-strict-aliasing on PPC seems to date back to 7027910 in OpenJDK >> 7, where we are seeing the warnings, and there seems to be no explanation as to why >> it was added in either the code or reviews. >> >> Given -fno-strict-aliasing is now being used on all architectures in 9, do you think >> it's ok to do the same in 7? I could also turn it off on the individual files, but >> this would duplicate the flag on other architectures and we may then get more PPC-only >> warnings in future. > > Never mind the warnings, -fno-strict-aliasing is essential for correctness. > I agree that we should set this just to be on the safe side. Notice that for the HotSpot build this is set unconditionally for all GCC platfoms in make/{bsd,linux,solaris}/makefiles/gcc.make from jdk 7 through 9. There's also a bug in GCC < 4.4.1 which incorrectly prints this waring even in cases where it shouldn't (see "Bug 41874 - Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning", https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874) I just realized that we did all our internal OpenJDK 8/9 Linux/PPC64 builds with "--with-extra-cflags=-Wno-strict-aliasing" because of that bug. So I'd appreciate if you'd downport your fix to 7 and 8. Notice that for OpenJDK 7 this issue only affects 32-bit builds, because it checks for "($(ARCH),ppc)" and ARCH is 'ppc' for 32-bit builds and ppc64 for 64-bit builds. In 8 this affects both, 32- and 64-bit ppc because it checks for $OPENJDK_TARGET_CPU_ARCH which is 'ppc' for both, the 32- and the 64-bit variant. Thank you and best regards, Volker > Andrew. > From volker.simonis at gmail.com Thu Jun 26 12:51:18 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 26 Jun 2014 14:51:18 +0200 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH In-Reply-To: References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com> <539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com> <539F50E1.7090300@oracle.com> <539FACB2.2050508@oracle.com> <53A092D4.3060100@oracle.com> Message-ID: OK, I've just realized that my comments were a little too late and the change was submitted shortly after I sent the mail. I'll try to put this tiny fix into the patch for 8048169 then which already contains some other PPC64 related stuff anyway. Regards, Volker On Mon, Jun 23, 2014 at 6:42 PM, Volker Simonis wrote: > Hi Mikael, > > sorry for the delayed answer - the PPC/AIX team was on holiday:) > > I've tested your changes on AIX and Linux/PPC64. On AIX everything works fine. > > For Linux/PPC64 there's a single occurrence of a test against $ARCH > which you've missed: > > diff -r 116e9b1bf477 make/linux/Makefile > --- a/make/linux/Makefile Mon Jun 23 17:43:30 2014 +0200 > +++ b/make/linux/Makefile Mon Jun 23 18:15:20 2014 +0200 > @@ -67,8 +67,10 @@ > endif > endif > # C1 is not ported on ppc64, so we cannot build a tiered VM: > -ifeq ($(ARCH),ppc64) > - FORCE_TIERED=0 > +ifeq ($(ARCH),ppc) > + ifeq ($(ARCH_DATA_MODEL), 64) > + FORCE_TIERED=0 > + endif > endif > > ifdef LP64 > > With this change I could successfully build on AIX and Linux/PPC64 > (I've only tested complete builds). > > Thank you and best regards, > Volker > > > On Tue, Jun 17, 2014 at 9:11 PM, Mikael Vidstedt > wrote: >> >> New webrev here (only the hotspot part, the webrev for top hasn't changed): >> >> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/ >> >> Comments inline. >> >> >> On 2014-06-16 19:49, David Holmes wrote: >>> >>> Hi Mikael, >>> >>> Sorry for the delay ... >>> >>> make/aix/makefiles/defs.make: >>> >>> This change doesn't make sense to me: >>> >>> 48 ifneq (,$(findstring $(ARCH), ppc)) >>> >>> given that the logic immediately preceding this sets ARCH to either ppc or >>> ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow for both >>> 32-bit and 64-bit cross-builds but the earlier logic is really precluding >>> this. So it seems to me that the changes in this file are completely >>> unnecessary (or else the earlier logic also needs changing). >> >> >> Indeed, that is correct - I missed the fact that ARCH is always overriden to >> be either ppc or ppc64. The old logic is unnecessarily hard to follow, but I >> guess that's in line with our hotspot Makefiles in general ;) >> >> I'll revert the changes to the file and add a mental note to self and others >> that linux appears to be the only platform where the incoming value of ARCH >> is actually honored - it's ignored/overridden on Solaris, BSD and AIX. >> >> >>> make/linux/makefiles/defs.make >>> >>> This block: >>> >>> 86 # i686/i586 and amd64/x86_64 >>> 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586)) >>> 88 ifeq ($(ARCH_DATA_MODEL), 64) >>> 89 ARCH_DATA_MODEL = 64 >>> 90 MAKE_ARGS += LP64=1 >>> 91 PLATFORM = linux-amd64 >>> 92 VM_PLATFORM = linux_amd64 >>> 93 HS_ARCH = x86 >>> 94 else >>> 95 ARCH_DATA_MODEL = 32 >>> 96 PLATFORM = linux-i586 >>> 97 VM_PLATFORM = linux_i486 >>> 98 HS_ARCH = x86 >>> 99 # We have to reset ARCH to i686 since SRCARCH relies on it >>> 100 ARCH = i686 >>> 101 endif >>> 102 endif >>> >>> seems to allow the user to try and do a 64-bit build on a 32-bit build >>> machine. Not sure if that would get caught in an earlier sanity check? (Same >>> is true for the sparc block). >> >> >> While the changes are primarily just intended to cut down on the duplication >> I don't immediately see the reason why we wouldn't want to allow compiling a >> 64-bit VM from a 32-bit machine? We're cross compiling all sorts of >> platforms, so why not allow this if the compiler supports it? I'd prefer to >> keep it this way. >> >> >>> Also I don't think the following is actually true: >>> >>> # We have to reset ARCH to i686 since SRCARCH relies on it >>> ARCH = i686 >>> >>> As long as ARCH is not amd64 and not x86_64 any 32-bit x86 architecture >>> designator will simply map to a SRCARCH of x86, as per defs.make: >>> >>> SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc >>> zero,$(ARCH))) >>> ARCH/ = x86 >>> ARCH/sparc = sparc >>> ARCH/sparc64= sparc >>> ARCH/ia64 = ia64 >>> ARCH/amd64 = x86 >>> ARCH/x86_64 = x86 >>> ARCH/ppc64 = ppc >>> ARCH/ppc = ppc >>> ARCH/arm = arm >>> ARCH/zero = zero >> >> >> Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64, ppc64, >> ppc, arm, zero } it will map to x86 anyway. I thought about cleaning that up >> before I sent out the first webrev, but soon found myself doing way more >> cleanup than was healthy for this specific change. However, since I had to >> update this change anyway I removed the ARCH reset part. >> >> Cheers, >> Mikael >> >> >>> >>> >>> Cheers, >>> David >>> >>> On 17/06/2014 6:17 AM, Mikael Vidstedt wrote: >>>> >>>> >>>> Thanks Erik. Another review please? >>>> >>>> Cheers, >>>> Mikael >>>> >>>> On 2014-06-12 23:56, Erik Joelsson wrote: >>>>> >>>>> Looks fine to me. >>>>> >>>>> /Erik >>>>> >>>>> On 2014-06-12 23:18, Mikael Vidstedt wrote: >>>>>> >>>>>> >>>>>> I have now verified that the changes work just fine for the platforms >>>>>> we build and test - both from the top level and when building hotspot >>>>>> only. Taking suggestions on other tests to perform. And it would be >>>>>> great if somebody could test the changes on on aix/ppc. >>>>>> >>>>>> So, kindly asking for "real"/final reviews of the changes: >>>>>> >>>>>> top: >>>>>> >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>>>> hotspot: >>>>>> >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>>>> >>>>>> >>>>>> Cheers, >>>>>> Mikael >>>>>> >>>>>> On 2014-06-10 22:53, Mikael Vidstedt wrote: >>>>>>> >>>>>>> >>>>>>> David, >>>>>>> >>>>>>> Thanks for the feedback. Essentially the logic in the >>>>>>> make//makefiles/defs.make files needs to recognize and deal with >>>>>>> two different use cases: >>>>>>> >>>>>>> 1. ARCH being set by the JDK build system to the value of >>>>>>> OPENJDK_TARGET_CPU_ARCH, or >>>>>>> 2. no ARCH being set, in which case it needs to be populated - >>>>>>> typically from uname >>>>>>> >>>>>>> Since Solaris and bsd both override ARCH they do not care about >>>>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2. >>>>>>> >>>>>>> Linux/x86 is where most of the difference (and confusion) is, but I >>>>>>> think aix/ppc64 will also change slightly since the ARCH value will >>>>>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I >>>>>>> cannot verify that they actually work. cc:ing the ppc-aix list in >>>>>>> the hope that somebody can help out with that. >>>>>>> >>>>>>> >>>>>>> Summing it up, I have the following two webrevs: >>>>>>> >>>>>>> top: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>>>>> >>>>>>> hotspot: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>>>>> >>>>>>> >>>>>>> With these changes I can build the normal platforms, but more >>>>>>> verification is needed - esp. building hotspot only. Meanwhile >>>>>>> feedback is much appreciated! >>>>>>> >>>>>>> Cheers, >>>>>>> Mikael >>>>>>> >>>>>>> On 2014-06-10 19:45, David Holmes wrote: >>>>>>>> >>>>>>>> Hi Mikael, >>>>>>>> >>>>>>>> This seems a reasonable proposal to me. We have an over-abundance >>>>>>>> of "arch" variables and values, so reducing that is a good aim. >>>>>>>> >>>>>>>> As you note the main flow-on effect here is that the hotspot >>>>>>>> makefiles have to be updated for the cases where >>>>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so >>>>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think >>>>>>>> only x86 has that issue. >>>>>>>> >>>>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc >>>>>>>> both internally and in the build artifacts and bundles! >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> I need some feedback and comments on the below fix: >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ >>>>>>>>> >>>>>>>>> Background: >>>>>>>>> >>>>>>>>> When configuring the hotspot build the build system sets up the ARCH >>>>>>>>> variable to reflect the target cpu. Currently the value is >>>>>>>>> initialized >>>>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu >>>>>>>>> name. For >>>>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). >>>>>>>>> The >>>>>>>>> goal in the new (JDK) build system is to have the "legacy" value >>>>>>>>> gradually removed in favor of the other variables. >>>>>>>>> >>>>>>>>> Discussion: >>>>>>>>> >>>>>>>>> The two candidate variables to base ARCH on are as far as I can tell >>>>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two >>>>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, >>>>>>>>> well >>>>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. >>>>>>>>> Together >>>>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the >>>>>>>>> Hotspot build system to do its thing. Note: ARCH is currently >>>>>>>>> ignored on >>>>>>>>> solaris and bsd - it's overridden at the top of the respective >>>>>>>>> make//makefiles/defs.make files. >>>>>>>>> >>>>>>>>> Before I go too far with this though I'd like to get some feedback >>>>>>>>> on >>>>>>>>> whether or not this is the right approach and what the exact value >>>>>>>>> should be. Depending on the outcome of that the Hotspot build >>>>>>>>> system may >>>>>>>>> have to be updated for some platforms to support the new value(s). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Mikael >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From volker.simonis at gmail.com Thu Jun 26 13:17:28 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 26 Jun 2014 15:17:28 +0200 Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH In-Reply-To: References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com> <539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com> <539F50E1.7090300@oracle.com> <539FACB2.2050508@oracle.com> <53A092D4.3060100@oracle.com> Message-ID: On Thu, Jun 26, 2014 at 2:51 PM, Volker Simonis wrote: > OK, I've just realized that my comments were a little too late and the > change was submitted shortly after I sent the mail. > > I'll try to put this tiny fix into the patch for 8048169 then which > already contains some other PPC64 related stuff anyway. > I've decided to better create an own bug for this issue (https://bugs.openjdk.java.net/browse/JDK-8048232) because 8048169 needs to be down-ported to jdk8 while this change doesn't. Regards, Volker > Regards, > Volker > > > On Mon, Jun 23, 2014 at 6:42 PM, Volker Simonis > wrote: >> Hi Mikael, >> >> sorry for the delayed answer - the PPC/AIX team was on holiday:) >> >> I've tested your changes on AIX and Linux/PPC64. On AIX everything works fine. >> >> For Linux/PPC64 there's a single occurrence of a test against $ARCH >> which you've missed: >> >> diff -r 116e9b1bf477 make/linux/Makefile >> --- a/make/linux/Makefile Mon Jun 23 17:43:30 2014 +0200 >> +++ b/make/linux/Makefile Mon Jun 23 18:15:20 2014 +0200 >> @@ -67,8 +67,10 @@ >> endif >> endif >> # C1 is not ported on ppc64, so we cannot build a tiered VM: >> -ifeq ($(ARCH),ppc64) >> - FORCE_TIERED=0 >> +ifeq ($(ARCH),ppc) >> + ifeq ($(ARCH_DATA_MODEL), 64) >> + FORCE_TIERED=0 >> + endif >> endif >> >> ifdef LP64 >> >> With this change I could successfully build on AIX and Linux/PPC64 >> (I've only tested complete builds). >> >> Thank you and best regards, >> Volker >> >> >> On Tue, Jun 17, 2014 at 9:11 PM, Mikael Vidstedt >> wrote: >>> >>> New webrev here (only the hotspot part, the webrev for top hasn't changed): >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/ >>> >>> Comments inline. >>> >>> >>> On 2014-06-16 19:49, David Holmes wrote: >>>> >>>> Hi Mikael, >>>> >>>> Sorry for the delay ... >>>> >>>> make/aix/makefiles/defs.make: >>>> >>>> This change doesn't make sense to me: >>>> >>>> 48 ifneq (,$(findstring $(ARCH), ppc)) >>>> >>>> given that the logic immediately preceding this sets ARCH to either ppc or >>>> ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow for both >>>> 32-bit and 64-bit cross-builds but the earlier logic is really precluding >>>> this. So it seems to me that the changes in this file are completely >>>> unnecessary (or else the earlier logic also needs changing). >>> >>> >>> Indeed, that is correct - I missed the fact that ARCH is always overriden to >>> be either ppc or ppc64. The old logic is unnecessarily hard to follow, but I >>> guess that's in line with our hotspot Makefiles in general ;) >>> >>> I'll revert the changes to the file and add a mental note to self and others >>> that linux appears to be the only platform where the incoming value of ARCH >>> is actually honored - it's ignored/overridden on Solaris, BSD and AIX. >>> >>> >>>> make/linux/makefiles/defs.make >>>> >>>> This block: >>>> >>>> 86 # i686/i586 and amd64/x86_64 >>>> 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586)) >>>> 88 ifeq ($(ARCH_DATA_MODEL), 64) >>>> 89 ARCH_DATA_MODEL = 64 >>>> 90 MAKE_ARGS += LP64=1 >>>> 91 PLATFORM = linux-amd64 >>>> 92 VM_PLATFORM = linux_amd64 >>>> 93 HS_ARCH = x86 >>>> 94 else >>>> 95 ARCH_DATA_MODEL = 32 >>>> 96 PLATFORM = linux-i586 >>>> 97 VM_PLATFORM = linux_i486 >>>> 98 HS_ARCH = x86 >>>> 99 # We have to reset ARCH to i686 since SRCARCH relies on it >>>> 100 ARCH = i686 >>>> 101 endif >>>> 102 endif >>>> >>>> seems to allow the user to try and do a 64-bit build on a 32-bit build >>>> machine. Not sure if that would get caught in an earlier sanity check? (Same >>>> is true for the sparc block). >>> >>> >>> While the changes are primarily just intended to cut down on the duplication >>> I don't immediately see the reason why we wouldn't want to allow compiling a >>> 64-bit VM from a 32-bit machine? We're cross compiling all sorts of >>> platforms, so why not allow this if the compiler supports it? I'd prefer to >>> keep it this way. >>> >>> >>>> Also I don't think the following is actually true: >>>> >>>> # We have to reset ARCH to i686 since SRCARCH relies on it >>>> ARCH = i686 >>>> >>>> As long as ARCH is not amd64 and not x86_64 any 32-bit x86 architecture >>>> designator will simply map to a SRCARCH of x86, as per defs.make: >>>> >>>> SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc >>>> zero,$(ARCH))) >>>> ARCH/ = x86 >>>> ARCH/sparc = sparc >>>> ARCH/sparc64= sparc >>>> ARCH/ia64 = ia64 >>>> ARCH/amd64 = x86 >>>> ARCH/x86_64 = x86 >>>> ARCH/ppc64 = ppc >>>> ARCH/ppc = ppc >>>> ARCH/arm = arm >>>> ARCH/zero = zero >>> >>> >>> Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64, ppc64, >>> ppc, arm, zero } it will map to x86 anyway. I thought about cleaning that up >>> before I sent out the first webrev, but soon found myself doing way more >>> cleanup than was healthy for this specific change. However, since I had to >>> update this change anyway I removed the ARCH reset part. >>> >>> Cheers, >>> Mikael >>> >>> >>>> >>>> >>>> Cheers, >>>> David >>>> >>>> On 17/06/2014 6:17 AM, Mikael Vidstedt wrote: >>>>> >>>>> >>>>> Thanks Erik. Another review please? >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>> On 2014-06-12 23:56, Erik Joelsson wrote: >>>>>> >>>>>> Looks fine to me. >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2014-06-12 23:18, Mikael Vidstedt wrote: >>>>>>> >>>>>>> >>>>>>> I have now verified that the changes work just fine for the platforms >>>>>>> we build and test - both from the top level and when building hotspot >>>>>>> only. Taking suggestions on other tests to perform. And it would be >>>>>>> great if somebody could test the changes on on aix/ppc. >>>>>>> >>>>>>> So, kindly asking for "real"/final reviews of the changes: >>>>>>> >>>>>>> top: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>>>>> hotspot: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Mikael >>>>>>> >>>>>>> On 2014-06-10 22:53, Mikael Vidstedt wrote: >>>>>>>> >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> Thanks for the feedback. Essentially the logic in the >>>>>>>> make//makefiles/defs.make files needs to recognize and deal with >>>>>>>> two different use cases: >>>>>>>> >>>>>>>> 1. ARCH being set by the JDK build system to the value of >>>>>>>> OPENJDK_TARGET_CPU_ARCH, or >>>>>>>> 2. no ARCH being set, in which case it needs to be populated - >>>>>>>> typically from uname >>>>>>>> >>>>>>>> Since Solaris and bsd both override ARCH they do not care about >>>>>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2. >>>>>>>> >>>>>>>> Linux/x86 is where most of the difference (and confusion) is, but I >>>>>>>> think aix/ppc64 will also change slightly since the ARCH value will >>>>>>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I >>>>>>>> cannot verify that they actually work. cc:ing the ppc-aix list in >>>>>>>> the hope that somebody can help out with that. >>>>>>>> >>>>>>>> >>>>>>>> Summing it up, I have the following two webrevs: >>>>>>>> >>>>>>>> top: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/ >>>>>>>> >>>>>>>> hotspot: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/ >>>>>>>> >>>>>>>> >>>>>>>> With these changes I can build the normal platforms, but more >>>>>>>> verification is needed - esp. building hotspot only. Meanwhile >>>>>>>> feedback is much appreciated! >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Mikael >>>>>>>> >>>>>>>> On 2014-06-10 19:45, David Holmes wrote: >>>>>>>>> >>>>>>>>> Hi Mikael, >>>>>>>>> >>>>>>>>> This seems a reasonable proposal to me. We have an over-abundance >>>>>>>>> of "arch" variables and values, so reducing that is a good aim. >>>>>>>>> >>>>>>>>> As you note the main flow-on effect here is that the hotspot >>>>>>>>> makefiles have to be updated for the cases where >>>>>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so >>>>>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think >>>>>>>>> only x86 has that issue. >>>>>>>>> >>>>>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc >>>>>>>>> both internally and in the build artifacts and bundles! >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> All, >>>>>>>>>> >>>>>>>>>> I need some feedback and comments on the below fix: >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471 >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/ >>>>>>>>>> >>>>>>>>>> Background: >>>>>>>>>> >>>>>>>>>> When configuring the hotspot build the build system sets up the ARCH >>>>>>>>>> variable to reflect the target cpu. Currently the value is >>>>>>>>>> initialized >>>>>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu >>>>>>>>>> name. For >>>>>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). >>>>>>>>>> The >>>>>>>>>> goal in the new (JDK) build system is to have the "legacy" value >>>>>>>>>> gradually removed in favor of the other variables. >>>>>>>>>> >>>>>>>>>> Discussion: >>>>>>>>>> >>>>>>>>>> The two candidate variables to base ARCH on are as far as I can tell >>>>>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two >>>>>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, >>>>>>>>>> well >>>>>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. >>>>>>>>>> Together >>>>>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the >>>>>>>>>> Hotspot build system to do its thing. Note: ARCH is currently >>>>>>>>>> ignored on >>>>>>>>>> solaris and bsd - it's overridden at the top of the respective >>>>>>>>>> make//makefiles/defs.make files. >>>>>>>>>> >>>>>>>>>> Before I go too far with this though I'd like to get some feedback >>>>>>>>>> on >>>>>>>>>> whether or not this is the right approach and what the exact value >>>>>>>>>> should be. Depending on the outcome of that the Hotspot build >>>>>>>>>> system may >>>>>>>>>> have to be updated for some platforms to support the new value(s). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Mikael >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> From mike.duigou at oracle.com Thu Jun 26 18:24:52 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 26 Jun 2014 11:24:52 -0700 Subject: Add version check to get_source.sh In-Reply-To: <53AA9BA6.6040707@gmail.com> References: <57A0035C-C08A-452F-A3B5-9ED27D9AE518@oracle.com> <53AA9BA6.6040707@gmail.com> Message-ID: Yes, a reasonable suggestion. I have to update the script to fix the parsing of the dev build version format, ie. X.Y.Z+ISO8601 and will include this cleanup with that change. Mike On Jun 25 2014, at 02:51 , pointo1d wrote: > Hiya Mike , > > On 23/06/14 22:50, Mike Duigou wrote: >> Hello all; >> >> This is the changeset for the enhancement proposed last week. It adds version checks to get_source.sh script. Currently the script will abort if the Mercurial client is not found or is older than 1.5.0. If Mercurial client is older than 2.6.3 then a warning will be issued but the script will attempt to continue. >> >> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047925/0/webrev/ >> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047925 >> >> Mike > > Would the following (or similar) not help by way of improving readability (also incorporating the typo identified by Mikael)... > > to_stderr() { > echo "$@" >&2 > } > > error() { > to_stderr "ERROR: $1" > exit ${2:-126} > } > > error "Could not locate Mercurial command" > . > . > . > error "Could not determine Mercurial version" > . > . > . > to_stderr "WARNING: Mercurial version $rqstmajor.$rqstminor.$rqstrev or later is recommended. $hgwhere is version $hgversion" > > Best rgds , > -- > ?Dave Pointon FIAP MBCS > Now I saw, tho' too late, the folly of beginning a work before we count the > cost and before we we judge rightly of our strength to go thro' with it > - Robinson Crusoe From mike.duigou at oracle.com Thu Jun 26 19:01:06 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 26 Jun 2014 12:01:06 -0700 Subject: RFR: 8048184 : (s) handle mercurial dev build version string Message-ID: Hello all; After pushing JDK-8047925 it was discovered that unofficial development builds of Mercurial use a different version string format and get_source.sh needs an enhancement to correctly parse this version string. I have also incorporated some cleanup suggested by Dave Pointon, made the script more defensive in it's handling of numeric values and replaced the use of 'which' with the more reliable 'command -v' jbsbug: https://bugs.openjdk.java.net/browse/JDK-8048184 webrev: http://cr.openjdk.java.net/~mduigou/JDK-8048184/0/webrev/ Mike From joe.darcy at oracle.com Thu Jun 26 21:57:18 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 26 Jun 2014 14:57:18 -0700 Subject: JDK 9 RFR of two fixes to make/Javadoc.gmk Message-ID: <53AC973E.7030108@oracle.com> Hello, Two JDK 9 fixes to make/Javadoc.gmk for review: JDK-8048302: Update bug reporting URL in make/Javadoc.gmk JDK-8048321: Enabled doclint warnings in docs build http://cr.openjdk.java.net/~darcy/8048302.0/ The two portions of the patch below should be clear. The old sun.com URL for reporting bugs was retired and replaced with a java.com URL. After some recent fixes in langtools, the langtools API sources are doclint clean, meaning the doclet, taglet, and tree API doc command should enforce that property using the doclint option. The core API build is doclint clean on a few properties and those are also enabled by this change. I verified a docs build succeeds with this changes. Thanks, -Joe diff -r 9f96a36ef77c make/Javadoc.gmk --- a/make/Javadoc.gmk Tue Jun 24 20:29:52 2014 -0700 +++ b/make/Javadoc.gmk Thu Jun 26 14:53:57 2014 -0700 @@ -118,7 +118,7 @@ COPYRIGHT_URL = $(DOCSDIR_URL)/legal/cpyr.html # Url to bug filing site -BUG_SUBMIT_URL = http://bugreport.sun.com/bugreport/ +BUG_SUBMIT_URL = http://bugreport.java.com/bugreport/ # Common line for how to submit a bug or rfe BUG_SUBMIT_LINE = Submit a bug or feature @@ -366,7 +366,7 @@ $(COREAPI_OPTIONS_FILE): $(COREAPI_OVERVIEW) $(prep-target) @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ - $(call OptionOnly,-Xdoclint:none) ; \ + $(call OptionOnly,-Xdoclint:html,reference,syntax) ; \ $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ $(call OptionPair,-encoding,ISO-8859-1) ; \ $(call OptionPair,-tag,beaninfo:X) ; \ @@ -442,7 +442,7 @@ $(DOCLETAPI_OPTIONS_FILE): $(prep-target) @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ - $(call OptionOnly,-Xdoclint:none) ; \ + $(call OptionOnly,-Xdoclint:all) ; \ $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ $(call OptionPair,-encoding,ascii) ; \ $(call OptionOnly,-breakiterator) ; \ @@ -499,7 +499,7 @@ $(TAGLETAPI_OPTIONS_FILE): $(prep-target) @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ - $(call OptionOnly,-Xdoclint:none) ; \ + $(call OptionOnly,-Xdoclint:all) ; \ $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ $(call OptionPair,-encoding,ascii) ; \ $(call OptionOnly,-nonavbar) ; \ @@ -1074,7 +1074,7 @@ $(TREEAPI_OPTIONS_FILE): $(prep-target) @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ - $(call OptionOnly,-Xdoclint:none) ; \ + $(call OptionOnly,-Xdoclint:all) ; \ $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ $(call OptionPair,-encoding,ascii) ; \ $(call OptionPair,-doctitle,$(TREEAPI_DOCTITLE)) ; \ From tim.bell at oracle.com Sat Jun 28 02:03:25 2014 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 27 Jun 2014 19:03:25 -0700 Subject: JDK 9 RFR of changing sense of lint warning in the jdk makefile In-Reply-To: <7A3561B4-DE06-4297-BF95-E9E458A90127@oracle.com> References: <53AA1FB2.9050800@oracle.com> <7A3561B4-DE06-4297-BF95-E9E458A90127@oracle.com> Message-ID: <53AE226D.8090507@oracle.com> Sounds like a good idea to me as well. Tim On 06/24/14 08:05 PM, Mikael Vidstedt wrote: > Sounds like a very reasonable thing to do. > > Congrats on getting all the warnings addressed! > > Cheers, > Mikael > >> On Jun 24, 2014, at 18:02, Joe Darcy wrote: >> >> Hello, >> >> In the makefile for the jdk repo, the current options list to javac's warning is a bit awkward since it lists all the options that are enabled as opposed to the ones which are disabled. Nearly all the options are enabled now (yay!) and I think it would be cleaner to reverse the sense of the list: >> >> diff -r 07eb3be7e64b make/Setup.gmk >> --- a/make/Setup.gmk Tue Jun 24 10:46:08 2014 -0700 >> +++ b/make/Setup.gmk Tue Jun 24 17:58:15 2014 -0700 >> @@ -27,7 +27,7 @@ >> >> # To build with all warnings enabled, do the following: >> # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" >> -JAVAC_WARNINGS := -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,finally,overloads,serial,static,try,varargs -Werror >> +JAVAC_WARNINGS := -Xlint:all,-deprecation,-rawtypes,-unchecked -Werror >> >> # Any java code executed during a JDK build to build other parts of the JDK must be >> # executed by the bootstrap JDK (probably with -Xbootclasspath/p: ) and for this >> >> If there is agreement this is an improvement, I'll file a bug and have the change pushed via jprt. (This change works for an OpenJDK build on linux, but there is a possibility closed or platform-specific code triggers some warning not related to source code, like options handling, in which case a few additional "-foo" clauses might be needed.) >> >> Thanks, >> >> -Joe From joe.darcy at oracle.com Sun Jun 29 22:37:37 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 29 Jun 2014 15:37:37 -0700 Subject: JDK 9 RFR of two fixes to make/Javadoc.gmk In-Reply-To: <53AC973E.7030108@oracle.com> References: <53AC973E.7030108@oracle.com> Message-ID: <53B09531.1010702@oracle.com> Hello, Just re-asserting the "please review" interrupt -- I'd prefer to get this pushed soon, before the good javadoc properties get perturbed by accident! Thanks, -Joe On 06/26/2014 02:57 PM, Joe Darcy wrote: > Hello, > > Two JDK 9 fixes to make/Javadoc.gmk for review: > > JDK-8048302: Update bug reporting URL in make/Javadoc.gmk > JDK-8048321: Enabled doclint warnings in docs build > http://cr.openjdk.java.net/~darcy/8048302.0/ > > The two portions of the patch below should be clear. > > The old sun.com URL for reporting bugs was retired and replaced with a > java.com URL. > > After some recent fixes in langtools, the langtools API sources are > doclint clean, meaning the doclet, taglet, and tree API doc command > should enforce that property using the doclint option. > > The core API build is doclint clean on a few properties and those are > also enabled by this change. > > I verified a docs build succeeds with this changes. > > Thanks, > > -Joe > > diff -r 9f96a36ef77c make/Javadoc.gmk > --- a/make/Javadoc.gmk Tue Jun 24 20:29:52 2014 -0700 > +++ b/make/Javadoc.gmk Thu Jun 26 14:53:57 2014 -0700 > @@ -118,7 +118,7 @@ > COPYRIGHT_URL = $(DOCSDIR_URL)/legal/cpyr.html > > # Url to bug filing site > -BUG_SUBMIT_URL = http://bugreport.sun.com/bugreport/ > +BUG_SUBMIT_URL = http://bugreport.java.com/bugreport/ > > # Common line for how to submit a bug or rfe > BUG_SUBMIT_LINE = Submit a bug or > feature > @@ -366,7 +366,7 @@ > $(COREAPI_OPTIONS_FILE): $(COREAPI_OVERVIEW) > $(prep-target) > @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ > - $(call OptionOnly,-Xdoclint:none) ; \ > + $(call OptionOnly,-Xdoclint:html,reference,syntax) ; \ > $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ > $(call OptionPair,-encoding,ISO-8859-1) ; \ > $(call OptionPair,-tag,beaninfo:X) ; \ > @@ -442,7 +442,7 @@ > $(DOCLETAPI_OPTIONS_FILE): > $(prep-target) > @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ > - $(call OptionOnly,-Xdoclint:none) ; \ > + $(call OptionOnly,-Xdoclint:all) ; \ > $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ > $(call OptionPair,-encoding,ascii) ; \ > $(call OptionOnly,-breakiterator) ; \ > @@ -499,7 +499,7 @@ > $(TAGLETAPI_OPTIONS_FILE): > $(prep-target) > @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ > - $(call OptionOnly,-Xdoclint:none) ; \ > + $(call OptionOnly,-Xdoclint:all) ; \ > $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ > $(call OptionPair,-encoding,ascii) ; \ > $(call OptionOnly,-nonavbar) ; \ > @@ -1074,7 +1074,7 @@ > $(TREEAPI_OPTIONS_FILE): > $(prep-target) > @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ > - $(call OptionOnly,-Xdoclint:none) ; \ > + $(call OptionOnly,-Xdoclint:all) ; \ > $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ > $(call OptionPair,-encoding,ascii) ; \ > $(call OptionPair,-doctitle,$(TREEAPI_DOCTITLE)) ; \ > From tim.bell at oracle.com Mon Jun 30 04:17:55 2014 From: tim.bell at oracle.com (Tim Bell) Date: Sun, 29 Jun 2014 21:17:55 -0700 Subject: JDK 9 RFR of two fixes to make/Javadoc.gmk In-Reply-To: <53B09531.1010702@oracle.com> References: <53AC973E.7030108@oracle.com> <53B09531.1010702@oracle.com> Message-ID: <53B0E4F3.1030507@oracle.com> Hi Joe: > Just re-asserting the "please review" interrupt -- I'd prefer to get > this pushed soon, before the good javadoc properties get perturbed by > accident! > Looks good to me. Approved. Tim > Thanks, > > -Joe > > On 06/26/2014 02:57 PM, Joe Darcy wrote: >> Hello, >> >> Two JDK 9 fixes to make/Javadoc.gmk for review: >> >> JDK-8048302: Update bug reporting URL in make/Javadoc.gmk >> JDK-8048321: Enabled doclint warnings in docs build >> http://cr.openjdk.java.net/~darcy/8048302.0/ >> >> The two portions of the patch below should be clear. >> >> The old sun.com URL for reporting bugs was retired and replaced with >> a java.com URL. >> >> After some recent fixes in langtools, the langtools API sources are >> doclint clean, meaning the doclet, taglet, and tree API doc command >> should enforce that property using the doclint option. >> >> The core API build is doclint clean on a few properties and those are >> also enabled by this change. >> >> I verified a docs build succeeds with this changes. >> >> Thanks, >> >> -Joe >> >> diff -r 9f96a36ef77c make/Javadoc.gmk >> --- a/make/Javadoc.gmk Tue Jun 24 20:29:52 2014 -0700 >> +++ b/make/Javadoc.gmk Thu Jun 26 14:53:57 2014 -0700 >> @@ -118,7 +118,7 @@ >> COPYRIGHT_URL = $(DOCSDIR_URL)/legal/cpyr.html >> >> # Url to bug filing site >> -BUG_SUBMIT_URL = http://bugreport.sun.com/bugreport/ >> +BUG_SUBMIT_URL = http://bugreport.java.com/bugreport/ >> >> # Common line for how to submit a bug or rfe >> BUG_SUBMIT_LINE = Submit a bug or >> feature >> @@ -366,7 +366,7 @@ >> $(COREAPI_OPTIONS_FILE): $(COREAPI_OVERVIEW) >> $(prep-target) >> @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ >> - $(call OptionOnly,-Xdoclint:none) ; \ >> + $(call OptionOnly,-Xdoclint:html,reference,syntax) ; \ >> $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ >> $(call OptionPair,-encoding,ISO-8859-1) ; \ >> $(call OptionPair,-tag,beaninfo:X) ; \ >> @@ -442,7 +442,7 @@ >> $(DOCLETAPI_OPTIONS_FILE): >> $(prep-target) >> @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ >> - $(call OptionOnly,-Xdoclint:none) ; \ >> + $(call OptionOnly,-Xdoclint:all) ; \ >> $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ >> $(call OptionPair,-encoding,ascii) ; \ >> $(call OptionOnly,-breakiterator) ; \ >> @@ -499,7 +499,7 @@ >> $(TAGLETAPI_OPTIONS_FILE): >> $(prep-target) >> @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ >> - $(call OptionOnly,-Xdoclint:none) ; \ >> + $(call OptionOnly,-Xdoclint:all) ; \ >> $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ >> $(call OptionPair,-encoding,ascii) ; \ >> $(call OptionOnly,-nonavbar) ; \ >> @@ -1074,7 +1074,7 @@ >> $(TREEAPI_OPTIONS_FILE): >> $(prep-target) >> @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ >> - $(call OptionOnly,-Xdoclint:none) ; \ >> + $(call OptionOnly,-Xdoclint:all) ; \ >> $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ >> $(call OptionPair,-encoding,ascii) ; \ >> $(call OptionPair,-doctitle,$(TREEAPI_DOCTITLE)) ; \ >> > From joe.darcy at oracle.com Mon Jun 30 21:30:40 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 30 Jun 2014 14:30:40 -0700 Subject: JDK 9 RFR of two fixes to make/Javadoc.gmk In-Reply-To: <53B0E4F3.1030507@oracle.com> References: <53AC973E.7030108@oracle.com> <53B09531.1010702@oracle.com> <53B0E4F3.1030507@oracle.com> Message-ID: <53B1D700.3040503@oracle.com> Hello, Upon closer inspection, the change to the core API doclint didn't work with the imported sources so I pushed the fix without updating the core API command. In other words, only the docs components which come from the langtools repo were updated. Thanks, -Joe On 06/29/2014 09:17 PM, Tim Bell wrote: > Hi Joe: > >> Just re-asserting the "please review" interrupt -- I'd prefer to get >> this pushed soon, before the good javadoc properties get perturbed by >> accident! >> > > Looks good to me. Approved. > > Tim > >> Thanks, >> >> -Joe >> >> On 06/26/2014 02:57 PM, Joe Darcy wrote: >>> Hello, >>> >>> Two JDK 9 fixes to make/Javadoc.gmk for review: >>> >>> JDK-8048302: Update bug reporting URL in make/Javadoc.gmk >>> JDK-8048321: Enabled doclint warnings in docs build >>> http://cr.openjdk.java.net/~darcy/8048302.0/ >>> >>> The two portions of the patch below should be clear. >>> >>> The old sun.com URL for reporting bugs was retired and replaced with >>> a java.com URL. >>> >>> After some recent fixes in langtools, the langtools API sources are >>> doclint clean, meaning the doclet, taglet, and tree API doc command >>> should enforce that property using the doclint option. >>> >>> The core API build is doclint clean on a few properties and those >>> are also enabled by this change. >>> >>> I verified a docs build succeeds with this changes. >>> >>> Thanks, >>> >>> -Joe >>> >>> diff -r 9f96a36ef77c make/Javadoc.gmk >>> --- a/make/Javadoc.gmk Tue Jun 24 20:29:52 2014 -0700 >>> +++ b/make/Javadoc.gmk Thu Jun 26 14:53:57 2014 -0700 >>> @@ -118,7 +118,7 @@ >>> COPYRIGHT_URL = $(DOCSDIR_URL)/legal/cpyr.html >>> >>> # Url to bug filing site >>> -BUG_SUBMIT_URL = http://bugreport.sun.com/bugreport/ >>> +BUG_SUBMIT_URL = http://bugreport.java.com/bugreport/ >>> >>> # Common line for how to submit a bug or rfe >>> BUG_SUBMIT_LINE = Submit a bug or >>> feature >>> @@ -366,7 +366,7 @@ >>> $(COREAPI_OPTIONS_FILE): $(COREAPI_OVERVIEW) >>> $(prep-target) >>> @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ >>> - $(call OptionOnly,-Xdoclint:none) ; \ >>> + $(call OptionOnly,-Xdoclint:html,reference,syntax) ; \ >>> $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ >>> $(call OptionPair,-encoding,ISO-8859-1) ; \ >>> $(call OptionPair,-tag,beaninfo:X) ; \ >>> @@ -442,7 +442,7 @@ >>> $(DOCLETAPI_OPTIONS_FILE): >>> $(prep-target) >>> @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ >>> - $(call OptionOnly,-Xdoclint:none) ; \ >>> + $(call OptionOnly,-Xdoclint:all) ; \ >>> $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ >>> $(call OptionPair,-encoding,ascii) ; \ >>> $(call OptionOnly,-breakiterator) ; \ >>> @@ -499,7 +499,7 @@ >>> $(TAGLETAPI_OPTIONS_FILE): >>> $(prep-target) >>> @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ >>> - $(call OptionOnly,-Xdoclint:none) ; \ >>> + $(call OptionOnly,-Xdoclint:all) ; \ >>> $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ >>> $(call OptionPair,-encoding,ascii) ; \ >>> $(call OptionOnly,-nonavbar) ; \ >>> @@ -1074,7 +1074,7 @@ >>> $(TREEAPI_OPTIONS_FILE): >>> $(prep-target) >>> @($(call OptionOnly,$(COMMON_JAVADOCFLAGS)) ; \ >>> - $(call OptionOnly,-Xdoclint:none) ; \ >>> + $(call OptionOnly,-Xdoclint:all) ; \ >>> $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ >>> $(call OptionPair,-encoding,ascii) ; \ >>> $(call OptionPair,-doctitle,$(TREEAPI_DOCTITLE)) ; \ >>> >> >