From staffan.larsen at oracle.com Mon May 4 06:52:26 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 4 May 2015 08:52:26 +0200 Subject: RFR: JDK-8079248 JDK fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" Message-ID: <480D0346-4F6B-492F-B243-6A045FC40193@oracle.com> This is a P1 bug that surfaced when changes from jdk9/dev and jdk9/hs-rt met in jdk9/hs. In this case the windows compiler upgrades in jdk9/dev met changes in jdk9/hs-rt that moved a call to GetProcessMemoryInfo from management.dll to management_ext.dll. With the compiler upgrades PSAPI_VERSION=1 is needed when compiling the library calling GetProcessMemoryInfo. This fix simply moves that patch from make/lib/Lib-java.management.gmk to make/lib/Lib-jdk.management.gmk. The patch was introduced in JDK-8076557. I will push the change below directly to jdk9/hs. Thanks, /Staffan diff --git a/make/lib/Lib-java.management.gmk b/make/lib/Lib-java.management.gmk --- a/make/lib/Lib-java.management.gmk +++ b/make/lib/Lib-java.management.gmk @@ -38,11 +38,6 @@ $(LIBJAVA_HEADER_FLAGS) \ # -# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate -# a binary that is compatible with windows versions older than 7/2008R2. -# See MSDN documentation for GetProcessMemoryInfo for more information. -BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1 - LIBMANAGEMENT_OPTIMIZATION := HIGH ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) ifeq ($(ENABLE_DEBUG_SYMBOLS), true) diff --git a/make/lib/Lib-jdk.management.gmk b/make/lib/Lib-jdk.management.gmk --- a/make/lib/Lib-jdk.management.gmk +++ b/make/lib/Lib-jdk.management.gmk @@ -39,6 +39,11 @@ $(LIBJAVA_HEADER_FLAGS) \ # +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate +# a binary that is compatible with windows versions older than 7/2008R2. +# See MSDN documentation for GetProcessMemoryInfo for more information. +BUILD_LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1 + LIBMANAGEMENT_EXT_OPTIMIZATION := HIGH ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) ifeq ($(ENABLE_DEBUG_SYMBOLS), true) From david.holmes at oracle.com Mon May 4 07:27:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 May 2015 17:27:16 +1000 Subject: RFR: JDK-8079248 JDK fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" In-Reply-To: <480D0346-4F6B-492F-B243-6A045FC40193@oracle.com> References: <480D0346-4F6B-492F-B243-6A045FC40193@oracle.com> Message-ID: <55471F54.6090804@oracle.com> Hi Staffan, Seems fine as a spot fix but I'm wondering if this shouldn't be a common option for all the dlls now we are building with VS2013? Thanks, David On 4/05/2015 4:52 PM, Staffan Larsen wrote: > This is a P1 bug that surfaced when changes from jdk9/dev and jdk9/hs-rt met in jdk9/hs. In this case the windows compiler upgrades in jdk9/dev met changes in jdk9/hs-rt that moved a call to GetProcessMemoryInfo from management.dll to management_ext.dll. With the compiler upgrades PSAPI_VERSION=1 is needed when compiling the library calling GetProcessMemoryInfo. This fix simply moves that patch from make/lib/Lib-java.management.gmk to make/lib/Lib-jdk.management.gmk. The patch was introduced in JDK-8076557. > > I will push the change below directly to jdk9/hs. > > Thanks, > /Staffan > > > diff --git a/make/lib/Lib-java.management.gmk b/make/lib/Lib-java.management.gmk > --- a/make/lib/Lib-java.management.gmk > +++ b/make/lib/Lib-java.management.gmk > @@ -38,11 +38,6 @@ > $(LIBJAVA_HEADER_FLAGS) \ > # > > -# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate > -# a binary that is compatible with windows versions older than 7/2008R2. > -# See MSDN documentation for GetProcessMemoryInfo for more information. > -BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1 > - > LIBMANAGEMENT_OPTIMIZATION := HIGH > ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) > ifeq ($(ENABLE_DEBUG_SYMBOLS), true) > diff --git a/make/lib/Lib-jdk.management.gmk b/make/lib/Lib-jdk.management.gmk > --- a/make/lib/Lib-jdk.management.gmk > +++ b/make/lib/Lib-jdk.management.gmk > @@ -39,6 +39,11 @@ > $(LIBJAVA_HEADER_FLAGS) \ > # > > +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate > +# a binary that is compatible with windows versions older than 7/2008R2. > +# See MSDN documentation for GetProcessMemoryInfo for more information. > +BUILD_LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1 > + > LIBMANAGEMENT_EXT_OPTIMIZATION := HIGH > ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) > ifeq ($(ENABLE_DEBUG_SYMBOLS), true) > From staffan.larsen at oracle.com Mon May 4 07:33:18 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 4 May 2015 09:33:18 +0200 Subject: RFR: JDK-8079248 JDK fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" In-Reply-To: <55471F54.6090804@oracle.com> References: <480D0346-4F6B-492F-B243-6A045FC40193@oracle.com> <55471F54.6090804@oracle.com> Message-ID: <2108C368-9023-4AFA-B35C-C954A63C391A@oracle.com> > On 4 maj 2015, at 09:27, David Holmes wrote: > > Hi Staffan, > > Seems fine as a spot fix but I'm wondering if this shouldn't be a common option for all the dlls now we are building with VS2013? I?ll let the build team comment on that. /Staffan > > Thanks, > David > > On 4/05/2015 4:52 PM, Staffan Larsen wrote: >> This is a P1 bug that surfaced when changes from jdk9/dev and jdk9/hs-rt met in jdk9/hs. In this case the windows compiler upgrades in jdk9/dev met changes in jdk9/hs-rt that moved a call to GetProcessMemoryInfo from management.dll to management_ext.dll. With the compiler upgrades PSAPI_VERSION=1 is needed when compiling the library calling GetProcessMemoryInfo. This fix simply moves that patch from make/lib/Lib-java.management.gmk to make/lib/Lib-jdk.management.gmk. The patch was introduced in JDK-8076557. >> >> I will push the change below directly to jdk9/hs. >> >> Thanks, >> /Staffan >> >> >> diff --git a/make/lib/Lib-java.management.gmk b/make/lib/Lib-java.management.gmk >> --- a/make/lib/Lib-java.management.gmk >> +++ b/make/lib/Lib-java.management.gmk >> @@ -38,11 +38,6 @@ >> $(LIBJAVA_HEADER_FLAGS) \ >> # >> >> -# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate >> -# a binary that is compatible with windows versions older than 7/2008R2. >> -# See MSDN documentation for GetProcessMemoryInfo for more information. >> -BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1 >> - >> LIBMANAGEMENT_OPTIMIZATION := HIGH >> ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) >> ifeq ($(ENABLE_DEBUG_SYMBOLS), true) >> diff --git a/make/lib/Lib-jdk.management.gmk b/make/lib/Lib-jdk.management.gmk >> --- a/make/lib/Lib-jdk.management.gmk >> +++ b/make/lib/Lib-jdk.management.gmk >> @@ -39,6 +39,11 @@ >> $(LIBJAVA_HEADER_FLAGS) \ >> # >> >> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate >> +# a binary that is compatible with windows versions older than 7/2008R2. >> +# See MSDN documentation for GetProcessMemoryInfo for more information. >> +BUILD_LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1 >> + >> LIBMANAGEMENT_EXT_OPTIMIZATION := HIGH >> ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) >> ifeq ($(ENABLE_DEBUG_SYMBOLS), true) >> From magnus.ihse.bursie at oracle.com Mon May 4 07:54:38 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 May 2015 09:54:38 +0200 Subject: RFR: JDK-8079248 JDK fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" In-Reply-To: <55471F54.6090804@oracle.com> References: <480D0346-4F6B-492F-B243-6A045FC40193@oracle.com> <55471F54.6090804@oracle.com> Message-ID: > 4 maj 2015 kl. 09:27 skrev David Holmes : > > Hi Staffan, > > Seems fine as a spot fix but I'm wondering if this shouldn't be a common option for all the dlls now we are building with VS2013? Or maybe as a define in the source code before the include section for the specific source code that needs a legacy version of GetProcessMemoryInfo? That seems more prudent to me. /Magnus > > Thanks, > David > >> On 4/05/2015 4:52 PM, Staffan Larsen wrote: >> This is a P1 bug that surfaced when changes from jdk9/dev and jdk9/hs-rt met in jdk9/hs. In this case the windows compiler upgrades in jdk9/dev met changes in jdk9/hs-rt that moved a call to GetProcessMemoryInfo from management.dll to management_ext.dll. With the compiler upgrades PSAPI_VERSION=1 is needed when compiling the library calling GetProcessMemoryInfo. This fix simply moves that patch from make/lib/Lib-java.management.gmk to make/lib/Lib-jdk.management.gmk. The patch was introduced in JDK-8076557. >> >> I will push the change below directly to jdk9/hs. >> >> Thanks, >> /Staffan >> >> >> diff --git a/make/lib/Lib-java.management.gmk b/make/lib/Lib-java.management.gmk >> --- a/make/lib/Lib-java.management.gmk >> +++ b/make/lib/Lib-java.management.gmk >> @@ -38,11 +38,6 @@ >> $(LIBJAVA_HEADER_FLAGS) \ >> # >> >> -# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate >> -# a binary that is compatible with windows versions older than 7/2008R2. >> -# See MSDN documentation for GetProcessMemoryInfo for more information. >> -BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1 >> - >> LIBMANAGEMENT_OPTIMIZATION := HIGH >> ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) >> ifeq ($(ENABLE_DEBUG_SYMBOLS), true) >> diff --git a/make/lib/Lib-jdk.management.gmk b/make/lib/Lib-jdk.management.gmk >> --- a/make/lib/Lib-jdk.management.gmk >> +++ b/make/lib/Lib-jdk.management.gmk >> @@ -39,6 +39,11 @@ >> $(LIBJAVA_HEADER_FLAGS) \ >> # >> >> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate >> +# a binary that is compatible with windows versions older than 7/2008R2. >> +# See MSDN documentation for GetProcessMemoryInfo for more information. >> +BUILD_LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1 >> + >> LIBMANAGEMENT_EXT_OPTIMIZATION := HIGH >> ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) >> ifeq ($(ENABLE_DEBUG_SYMBOLS), true) >> From staffan.larsen at oracle.com Mon May 4 08:25:05 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 4 May 2015 10:25:05 +0200 Subject: RFR: JDK-8079248 JDK fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" In-Reply-To: References: <480D0346-4F6B-492F-B243-6A045FC40193@oracle.com> <55471F54.6090804@oracle.com> Message-ID: > On 4 maj 2015, at 09:54, Magnus Ihse Bursie wrote: > > >> 4 maj 2015 kl. 09:27 skrev David Holmes : >> >> Hi Staffan, >> >> Seems fine as a spot fix but I'm wondering if this shouldn't be a common option for all the dlls now we are building with VS2013? > > Or maybe as a define in the source code before the include section for the specific source code that needs a legacy version of GetProcessMemoryInfo? That seems more prudent to me. In this case the function is called the same and works the same in all versions of Windows (there is no ?legacy version?). What differs is that it is linked against different names in different libs for different versions of Windows. So from a source code perspective there is no difference, but from a build perspective there is. /Staffan > > /Magnus > >> >> Thanks, >> David >> >>> On 4/05/2015 4:52 PM, Staffan Larsen wrote: >>> This is a P1 bug that surfaced when changes from jdk9/dev and jdk9/hs-rt met in jdk9/hs. In this case the windows compiler upgrades in jdk9/dev met changes in jdk9/hs-rt that moved a call to GetProcessMemoryInfo from management.dll to management_ext.dll. With the compiler upgrades PSAPI_VERSION=1 is needed when compiling the library calling GetProcessMemoryInfo. This fix simply moves that patch from make/lib/Lib-java.management.gmk to make/lib/Lib-jdk.management.gmk. The patch was introduced in JDK-8076557. >>> >>> I will push the change below directly to jdk9/hs. >>> >>> Thanks, >>> /Staffan >>> >>> >>> diff --git a/make/lib/Lib-java.management.gmk b/make/lib/Lib-java.management.gmk >>> --- a/make/lib/Lib-java.management.gmk >>> +++ b/make/lib/Lib-java.management.gmk >>> @@ -38,11 +38,6 @@ >>> $(LIBJAVA_HEADER_FLAGS) \ >>> # >>> >>> -# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate >>> -# a binary that is compatible with windows versions older than 7/2008R2. >>> -# See MSDN documentation for GetProcessMemoryInfo for more information. >>> -BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1 >>> - >>> LIBMANAGEMENT_OPTIMIZATION := HIGH >>> ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) >>> ifeq ($(ENABLE_DEBUG_SYMBOLS), true) >>> diff --git a/make/lib/Lib-jdk.management.gmk b/make/lib/Lib-jdk.management.gmk >>> --- a/make/lib/Lib-jdk.management.gmk >>> +++ b/make/lib/Lib-jdk.management.gmk >>> @@ -39,6 +39,11 @@ >>> $(LIBJAVA_HEADER_FLAGS) \ >>> # >>> >>> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate >>> +# a binary that is compatible with windows versions older than 7/2008R2. >>> +# See MSDN documentation for GetProcessMemoryInfo for more information. >>> +BUILD_LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1 >>> + >>> LIBMANAGEMENT_EXT_OPTIMIZATION := HIGH >>> ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) >>> ifeq ($(ENABLE_DEBUG_SYMBOLS), true) >>> From erik.joelsson at oracle.com Mon May 4 09:05:35 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 May 2015 11:05:35 +0200 Subject: aarch64: jdk9: 8078245: fails to build from source In-Reply-To: <5541BD0A.3090305@oracle.com> References: <1429607797.4116.11.camel@mylittlepony.linaroharston> <5539EC8E.1060507@oracle.com> <1430304750.8394.56.camel@mylittlepony.linaroharston> <5541BD0A.3090305@oracle.com> Message-ID: <5547365F.1020105@oracle.com> Hello, I think this looks good enough. The flags handling is still a big mess so even if there were a better place for this, I couldn't say where. /Erik On 2015-04-30 07:26, David Holmes wrote: > Hi Nevill, > > Just realized this was sent to hotspot-dev (attempting bcc) but is not > a hotspot issue. With your new approach this is a build issue so > cc'ing build-dev. > > The new approach seems better to me but build folk need to confirm the > placement. > > Thanks, > David > > On 29/04/2015 8:52 PM, Edward Nevill wrote: >> On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote: >>> Hi Ed, >>> >>> On 21/04/2015 7:16 PM, Edward Nevill wrote: >>>> Hi, >>>> >>>> The current jdk9 tip fails to build from source on aarch64 with the >>>> following error message >>>> >>>> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: >>>> In function `png_init_filter_functions': >>>> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: >>>> undefined reference to `png_init_filter_functions_neon' >>>> collect2: error: ld returned 1 exit status >>>> >>>> The following webrev gets it building again. >>>> >>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/ >>> >>> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm >>> also wondering how we would get __ARM_NEON defined but not __arm__? >> >> On arm 32 bit gcc defines the symbol __ARM_NEON if the flag >> -mfpu=neon is specified. Since this is not specified as part of the >> OpenJDK build the symbol is not defined and the build succeeds. >> >> On aarch64 the symbol __ARM_NEON is always defined (the theory being >> that aarch64 always supports Neon). Personally I think this is borken >> as it causes builds to fail (and not just OpenJDK, several other >> projects have had the same build failure - try googling the above >> error message). But we are stuck with gcc as it is. >> >> However, I don't like the above fix because it not only modifies the >> jdk, it modifies an external component which is pulled into jdk, >> which means every time a new revision of linpng is pulled in, the >> patch will have to be applied again. >> >> A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0 >> in the build (only if aarch64). >> >> The failing code in pngpriv.h reads >> >> #ifndef PNG_ARM_NEON_OPT >> >> ... >> >> # if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \ >> defined(PNG_ALIGNED_MEMORY_SUPPORTED) >> # define PNG_ARM_NEON_OPT 2 >> # else >> # define PNG_ARM_NEON_OPT 0 >> # endif >> #endif >> >> So, if we just predefine PNG_ARM_NEON=0 in the build this will have >> the same effect as adding defined(__arm__) or !defined(__aarch64__) >> above. >> >> The following patch webrev does this:- >> >> http://cr.openjdk.java.net/~enevill/8078245/webrev.01/ >> >> If you are happy with this and if I could have another reviewer I >> will push this. >> >> All the best, >> Ed. >> >> From erik.joelsson at oracle.com Mon May 4 09:11:12 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 May 2015 11:11:12 +0200 Subject: RFR: JDK-8079248 JDK fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" In-Reply-To: References: <480D0346-4F6B-492F-B243-6A045FC40193@oracle.com> <55471F54.6090804@oracle.com> Message-ID: <554737B0.7030507@oracle.com> On 2015-05-04 10:25, Staffan Larsen wrote: >> On 4 maj 2015, at 09:54, Magnus Ihse Bursie wrote: >> >> >>> 4 maj 2015 kl. 09:27 skrev David Holmes : >>> >>> Hi Staffan, >>> >>> Seems fine as a spot fix but I'm wondering if this shouldn't be a common option for all the dlls now we are building with VS2013? >> Or maybe as a define in the source code before the include section for the specific source code that needs a legacy version of GetProcessMemoryInfo? That seems more prudent to me. > In this case the function is called the same and works the same in all versions of Windows (there is no ?legacy version?). What differs is that it is linked against different names in different libs for different versions of Windows. So from a source code perspective there is no difference, but from a build perspective there is. I think the placement suggested here is fine. It could be moved to configure for global application, but I doubt it will ever be needed. As soon as we drop support for Windows versions older than 7, we can remove this option. /Erik > /Staffan > >> /Magnus >> >>> Thanks, >>> David >>> >>>> On 4/05/2015 4:52 PM, Staffan Larsen wrote: >>>> This is a P1 bug that surfaced when changes from jdk9/dev and jdk9/hs-rt met in jdk9/hs. In this case the windows compiler upgrades in jdk9/dev met changes in jdk9/hs-rt that moved a call to GetProcessMemoryInfo from management.dll to management_ext.dll. With the compiler upgrades PSAPI_VERSION=1 is needed when compiling the library calling GetProcessMemoryInfo. This fix simply moves that patch from make/lib/Lib-java.management.gmk to make/lib/Lib-jdk.management.gmk. The patch was introduced in JDK-8076557. >>>> >>>> I will push the change below directly to jdk9/hs. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> diff --git a/make/lib/Lib-java.management.gmk b/make/lib/Lib-java.management.gmk >>>> --- a/make/lib/Lib-java.management.gmk >>>> +++ b/make/lib/Lib-java.management.gmk >>>> @@ -38,11 +38,6 @@ >>>> $(LIBJAVA_HEADER_FLAGS) \ >>>> # >>>> >>>> -# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate >>>> -# a binary that is compatible with windows versions older than 7/2008R2. >>>> -# See MSDN documentation for GetProcessMemoryInfo for more information. >>>> -BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1 >>>> - >>>> LIBMANAGEMENT_OPTIMIZATION := HIGH >>>> ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) >>>> ifeq ($(ENABLE_DEBUG_SYMBOLS), true) >>>> diff --git a/make/lib/Lib-jdk.management.gmk b/make/lib/Lib-jdk.management.gmk >>>> --- a/make/lib/Lib-jdk.management.gmk >>>> +++ b/make/lib/Lib-jdk.management.gmk >>>> @@ -39,6 +39,11 @@ >>>> $(LIBJAVA_HEADER_FLAGS) \ >>>> # >>>> >>>> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate >>>> +# a binary that is compatible with windows versions older than 7/2008R2. >>>> +# See MSDN documentation for GetProcessMemoryInfo for more information. >>>> +BUILD_LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1 >>>> + >>>> LIBMANAGEMENT_EXT_OPTIMIZATION := HIGH >>>> ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) >>>> ifeq ($(ENABLE_DEBUG_SYMBOLS), true) >>>> From staffan.larsen at oracle.com Mon May 4 09:43:42 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 4 May 2015 11:43:42 +0200 Subject: RFR: JDK-8079248 JDK fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" In-Reply-To: <554737B0.7030507@oracle.com> References: <480D0346-4F6B-492F-B243-6A045FC40193@oracle.com> <55471F54.6090804@oracle.com> <554737B0.7030507@oracle.com> Message-ID: <1B30D60F-7C14-4BB3-875D-181DC47B85BE@oracle.com> Thanks for the reviews - the fix is now in the JPRT queue. /Staffan > On 4 maj 2015, at 11:11, Erik Joelsson wrote: > > > On 2015-05-04 10:25, Staffan Larsen wrote: >>> On 4 maj 2015, at 09:54, Magnus Ihse Bursie wrote: >>> >>> >>>> 4 maj 2015 kl. 09:27 skrev David Holmes : >>>> >>>> Hi Staffan, >>>> >>>> Seems fine as a spot fix but I'm wondering if this shouldn't be a common option for all the dlls now we are building with VS2013? >>> Or maybe as a define in the source code before the include section for the specific source code that needs a legacy version of GetProcessMemoryInfo? That seems more prudent to me. >> In this case the function is called the same and works the same in all versions of Windows (there is no ?legacy version?). What differs is that it is linked against different names in different libs for different versions of Windows. So from a source code perspective there is no difference, but from a build perspective there is. > I think the placement suggested here is fine. It could be moved to configure for global application, but I doubt it will ever be needed. As soon as we drop support for Windows versions older than 7, we can remove this option. > > /Erik >> /Staffan >> >>> /Magnus >>> >>>> Thanks, >>>> David >>>> >>>>> On 4/05/2015 4:52 PM, Staffan Larsen wrote: >>>>> This is a P1 bug that surfaced when changes from jdk9/dev and jdk9/hs-rt met in jdk9/hs. In this case the windows compiler upgrades in jdk9/dev met changes in jdk9/hs-rt that moved a call to GetProcessMemoryInfo from management.dll to management_ext.dll. With the compiler upgrades PSAPI_VERSION=1 is needed when compiling the library calling GetProcessMemoryInfo. This fix simply moves that patch from make/lib/Lib-java.management.gmk to make/lib/Lib-jdk.management.gmk. The patch was introduced in JDK-8076557. >>>>> >>>>> I will push the change below directly to jdk9/hs. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>> diff --git a/make/lib/Lib-java.management.gmk b/make/lib/Lib-java.management.gmk >>>>> --- a/make/lib/Lib-java.management.gmk >>>>> +++ b/make/lib/Lib-java.management.gmk >>>>> @@ -38,11 +38,6 @@ >>>>> $(LIBJAVA_HEADER_FLAGS) \ >>>>> # >>>>> >>>>> -# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate >>>>> -# a binary that is compatible with windows versions older than 7/2008R2. >>>>> -# See MSDN documentation for GetProcessMemoryInfo for more information. >>>>> -BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1 >>>>> - >>>>> LIBMANAGEMENT_OPTIMIZATION := HIGH >>>>> ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) >>>>> ifeq ($(ENABLE_DEBUG_SYMBOLS), true) >>>>> diff --git a/make/lib/Lib-jdk.management.gmk b/make/lib/Lib-jdk.management.gmk >>>>> --- a/make/lib/Lib-jdk.management.gmk >>>>> +++ b/make/lib/Lib-jdk.management.gmk >>>>> @@ -39,6 +39,11 @@ >>>>> $(LIBJAVA_HEADER_FLAGS) \ >>>>> # >>>>> >>>>> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate >>>>> +# a binary that is compatible with windows versions older than 7/2008R2. >>>>> +# See MSDN documentation for GetProcessMemoryInfo for more information. >>>>> +BUILD_LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1 >>>>> + >>>>> LIBMANAGEMENT_EXT_OPTIMIZATION := HIGH >>>>> ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) >>>>> ifeq ($(ENABLE_DEBUG_SYMBOLS), true) From erik.joelsson at oracle.com Mon May 4 13:38:52 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 May 2015 15:38:52 +0200 Subject: RFR: JDK-8079087: Add support for Cygwin 2.0 Message-ID: <5547766C.5000308@oracle.com> Hello, Please review this small patch to configure which enables building on Cygwin 2.0 and newer. Instead of explicitly testing for all versions we know work, I inverted the check to exclude the ones we know won't work. Hitting a known bad Cygwin version should be very rare anyway since 1.7 has been around for a long time now and Cygwin is so aggresive with keeping people updated. Bug: https://bugs.openjdk.java.net/browse/JDK-8079087 Patch: diff -r bc02cff96b92 common/autoconf/basics_windows.m4 --- a/common/autoconf/basics_windows.m4 +++ b/common/autoconf/basics_windows.m4 @@ -320,8 +320,8 @@ WINDOWS_ENV_VENDOR='cygwin' WINDOWS_ENV_VERSION="$CYGWIN_VERSION" - CYGWIN_VERSION_OK=`$ECHO $CYGWIN_VERSION | $GREP ^1.7.` - if test "x$CYGWIN_VERSION_OK" = x; then + CYGWIN_VERSION_OLD=`$ECHO $CYGWIN_VERSION | $GREP -e '^1\.[0-6]'` + if test "x$CYGWIN_VERSION_OLD" != x; then AC_MSG_NOTICE([Your cygwin is too old. You are running $CYGWIN_VERSION, but at least cygwin 1.7 is required. Please upgrade.]) AC_MSG_ERROR([Cannot continue]) fi /Erik From erik.joelsson at oracle.com Mon May 4 13:46:19 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 May 2015 15:46:19 +0200 Subject: RFR: JDK-8077422: hprof agent: Build failed with VS2013 Update 4 In-Reply-To: <55381A5D.1020900@oracle.com> References: <55380D4E.7080700@oracle.com> <55380EA4.7030901@oracle.com> <55381A5D.1020900@oracle.com> Message-ID: <5547782B.2040804@oracle.com> Hello, This bug has been marked as won't fix since the code it affects is going to be removed. However, until that removal happens, we can't build using VS2013 SP4. I'm in the process of updating the compilers used internally at Oracle to that specific version and to be able to continue that work, I need this to be buildable now. For this reason I propose Peter Brunet's suggested solution to the problem, just adding a C macro definition that makes it compile. I slightly adjusted his initial proposal. Bug: https://bugs.openjdk.java.net/browse/JDK-8077422 Patch: diff -r 83ff0dedf9e1 make/lib/Lib-jdk.hprof.agent.gmk --- a/make/lib/Lib-jdk.hprof.agent.gmk +++ b/make/lib/Lib-jdk.hprof.agent.gmk @@ -31,7 +31,7 @@ BUILD_LIBHPROF_CFLAGS := $(addprefix -I, $(BUILD_LIBHPROF_SRC)) \ -I$(JDK_TOPDIR)/src/demo/share/jvmti/java_crw_demo BUILD_LIBHPROF_LDFLAGS := LIBHPROF_OPTIMIZATION := HIGHEST @@ -49,6 +49,7 @@ CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \ $(BUILD_LIBHPROF_CFLAGS), \ CFLAGS_debug := -DHPROF_LOGGING, \ + CFLAGS_windows := -D_WINSOCK_DEPRECATED_NO_WARNINGS, \ MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \ LDFLAGS := $(LDFLAGS_JDKLIB) \ $(call SET_SHARED_LIBRARY_ORIGIN), \ /Erik On 2015-04-23 00:02, Pete Brunet wrote: > This hack to jdk/make/lib/Lib-jdk.hprof.agent.gmk works for now: > > LANG := C, \ > OPTIMIZATION := $(LIBHPROF_OPTIMIZATION), \ > CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \ > + -D_WINSOCK_DEPRECATED_NO_WARNINGS \ > $(BUILD_LIBHPROF_CFLAGS), \ > CFLAGS_debug := -DHPROF_LOGGING, \ > MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \ > > Pete > > On 4/22/15 4:12 PM, Pete Brunet wrote: >> p.s. I also had done a make reconfigure and make clean. I'll try make >> clean and reconfigure from bash. >> >> On 4/22/15 4:06 PM, Pete Brunet wrote: >>> I was able to build 9 OK then I switched from VS2010 to VS2013 and now >>> get the following. I tried hg tpull -u but that didn't help. >>> >>> Is there something I need to do besides installing VS Pro 2013 with >>> Update 4? >>> >>> $ make images 2>&1 | tee make-64.log >>> Building target 'images' in configuration >>> 'windows-x86_64-normal-server-release' >>> >>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86) >>> : error C2220: warning treated as error - no 'object' file generated >>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86) >>> : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() >>> instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated >>> API warnings >>> c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see >>> declaration of 'gethostbyname' >>> Lib-jdk.hprof.agent.gmk:44: recipe for target >>> '/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h >>> prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: *** >>> [/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj] >>> Error 2 >>> make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed >>> make[2]: *** [jdk.hprof.agent-libs] Error 1 >>> make[2]: *** Waiting for unfinished jobs.... >>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255: >>> recipe for target 'main' failed >>> make[1]: *** [main] Error 1 >>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171: >>> recipe for target 'images' failed >>> make: *** [images] Error 2 From magnus.ihse.bursie at oracle.com Mon May 4 14:43:43 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 May 2015 16:43:43 +0200 Subject: [aarch64-port-dev ] aarch64: jdk9: 8078245: fails to build from source In-Reply-To: <5547365F.1020105@oracle.com> References: <1429607797.4116.11.camel@mylittlepony.linaroharston> <5539EC8E.1060507@oracle.com> <1430304750.8394.56.camel@mylittlepony.linaroharston> <5541BD0A.3090305@oracle.com> <5547365F.1020105@oracle.com> Message-ID: Why not just for the library that needs it? /Magnus > 4 maj 2015 kl. 11:05 skrev Erik Joelsson : > > Hello, > > I think this looks good enough. The flags handling is still a big mess so even if there were a better place for this, I couldn't say where. > > /Erik > >> On 2015-04-30 07:26, David Holmes wrote: >> Hi Nevill, >> >> Just realized this was sent to hotspot-dev (attempting bcc) but is not a hotspot issue. With your new approach this is a build issue so cc'ing build-dev. >> >> The new approach seems better to me but build folk need to confirm the placement. >> >> Thanks, >> David >> >>> On 29/04/2015 8:52 PM, Edward Nevill wrote: >>>> On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote: >>>> Hi Ed, >>>> >>>>> On 21/04/2015 7:16 PM, Edward Nevill wrote: >>>>> Hi, >>>>> >>>>> The current jdk9 tip fails to build from source on aarch64 with the following error message >>>>> >>>>> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': >>>>> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon' >>>>> collect2: error: ld returned 1 exit status >>>>> >>>>> The following webrev gets it building again. >>>>> >>>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/ >>>> >>>> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm >>>> also wondering how we would get __ARM_NEON defined but not __arm__? >>> >>> On arm 32 bit gcc defines the symbol __ARM_NEON if the flag -mfpu=neon is specified. Since this is not specified as part of the OpenJDK build the symbol is not defined and the build succeeds. >>> >>> On aarch64 the symbol __ARM_NEON is always defined (the theory being that aarch64 always supports Neon). Personally I think this is borken as it causes builds to fail (and not just OpenJDK, several other projects have had the same build failure - try googling the above error message). But we are stuck with gcc as it is. >>> >>> However, I don't like the above fix because it not only modifies the jdk, it modifies an external component which is pulled into jdk, which means every time a new revision of linpng is pulled in, the patch will have to be applied again. >>> >>> A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0 in the build (only if aarch64). >>> >>> The failing code in pngpriv.h reads >>> >>> #ifndef PNG_ARM_NEON_OPT >>> >>> ... >>> >>> # if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \ >>> defined(PNG_ALIGNED_MEMORY_SUPPORTED) >>> # define PNG_ARM_NEON_OPT 2 >>> # else >>> # define PNG_ARM_NEON_OPT 0 >>> # endif >>> #endif >>> >>> So, if we just predefine PNG_ARM_NEON=0 in the build this will have the same effect as adding defined(__arm__) or !defined(__aarch64__) above. >>> >>> The following patch webrev does this:- >>> >>> http://cr.openjdk.java.net/~enevill/8078245/webrev.01/ >>> >>> If you are happy with this and if I could have another reviewer I will push this. >>> >>> All the best, >>> Ed. > From erik.joelsson at oracle.com Mon May 4 15:03:38 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 May 2015 17:03:38 +0200 Subject: [aarch64-port-dev ] aarch64: jdk9: 8078245: fails to build from source In-Reply-To: References: <1429607797.4116.11.camel@mylittlepony.linaroharston> <5539EC8E.1060507@oracle.com> <1430304750.8394.56.camel@mylittlepony.linaroharston> <5541BD0A.3090305@oracle.com> <5547365F.1020105@oracle.com> Message-ID: <55478A4A.90301@oracle.com> Right, that does make sense. This isn't a toolchain global flag like some others we've had to deal with lately, but rather seems pretty specific to the png code, or am I missing something? If that's the case, then it's better added for the specific library. /Erik On 2015-05-04 16:43, Magnus Ihse Bursie wrote: > Why not just for the library that needs it? > > /Magnus > >> 4 maj 2015 kl. 11:05 skrev Erik Joelsson : >> >> Hello, >> >> I think this looks good enough. The flags handling is still a big mess so even if there were a better place for this, I couldn't say where. >> >> /Erik >> >>> On 2015-04-30 07:26, David Holmes wrote: >>> Hi Nevill, >>> >>> Just realized this was sent to hotspot-dev (attempting bcc) but is not a hotspot issue. With your new approach this is a build issue so cc'ing build-dev. >>> >>> The new approach seems better to me but build folk need to confirm the placement. >>> >>> Thanks, >>> David >>> >>>> On 29/04/2015 8:52 PM, Edward Nevill wrote: >>>>> On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote: >>>>> Hi Ed, >>>>> >>>>>> On 21/04/2015 7:16 PM, Edward Nevill wrote: >>>>>> Hi, >>>>>> >>>>>> The current jdk9 tip fails to build from source on aarch64 with the following error message >>>>>> >>>>>> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': >>>>>> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon' >>>>>> collect2: error: ld returned 1 exit status >>>>>> >>>>>> The following webrev gets it building again. >>>>>> >>>>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/ >>>>> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm >>>>> also wondering how we would get __ARM_NEON defined but not __arm__? >>>> On arm 32 bit gcc defines the symbol __ARM_NEON if the flag -mfpu=neon is specified. Since this is not specified as part of the OpenJDK build the symbol is not defined and the build succeeds. >>>> >>>> On aarch64 the symbol __ARM_NEON is always defined (the theory being that aarch64 always supports Neon). Personally I think this is borken as it causes builds to fail (and not just OpenJDK, several other projects have had the same build failure - try googling the above error message). But we are stuck with gcc as it is. >>>> >>>> However, I don't like the above fix because it not only modifies the jdk, it modifies an external component which is pulled into jdk, which means every time a new revision of linpng is pulled in, the patch will have to be applied again. >>>> >>>> A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0 in the build (only if aarch64). >>>> >>>> The failing code in pngpriv.h reads >>>> >>>> #ifndef PNG_ARM_NEON_OPT >>>> >>>> ... >>>> >>>> # if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \ >>>> defined(PNG_ALIGNED_MEMORY_SUPPORTED) >>>> # define PNG_ARM_NEON_OPT 2 >>>> # else >>>> # define PNG_ARM_NEON_OPT 0 >>>> # endif >>>> #endif >>>> >>>> So, if we just predefine PNG_ARM_NEON=0 in the build this will have the same effect as adding defined(__arm__) or !defined(__aarch64__) above. >>>> >>>> The following patch webrev does this:- >>>> >>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.01/ >>>> >>>> If you are happy with this and if I could have another reviewer I will push this. >>>> >>>> All the best, >>>> Ed. From staffan.larsen at oracle.com Mon May 4 15:13:22 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 4 May 2015 17:13:22 +0200 Subject: RFR: JDK-8077422: hprof agent: Build failed with VS2013 Update 4 In-Reply-To: <5547782B.2040804@oracle.com> References: <55380D4E.7080700@oracle.com> <55380EA4.7030901@oracle.com> <55381A5D.1020900@oracle.com> <5547782B.2040804@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 4 maj 2015, at 15:46, Erik Joelsson wrote: > > Hello, > > This bug has been marked as won't fix since the code it affects is going to be removed. However, until that removal happens, we can't build using VS2013 SP4. I'm in the process of updating the compilers used internally at Oracle to that specific version and to be able to continue that work, I need this to be buildable now. For this reason I propose Peter Brunet's suggested solution to the problem, just adding a C macro definition that makes it compile. I slightly adjusted his initial proposal. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8077422 > Patch: > diff -r 83ff0dedf9e1 make/lib/Lib-jdk.hprof.agent.gmk > --- a/make/lib/Lib-jdk.hprof.agent.gmk > +++ b/make/lib/Lib-jdk.hprof.agent.gmk > @@ -31,7 +31,7 @@ > > BUILD_LIBHPROF_CFLAGS := $(addprefix -I, $(BUILD_LIBHPROF_SRC)) \ > -I$(JDK_TOPDIR)/src/demo/share/jvmti/java_crw_demo > > BUILD_LIBHPROF_LDFLAGS := > > LIBHPROF_OPTIMIZATION := HIGHEST > @@ -49,6 +49,7 @@ > CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \ > $(BUILD_LIBHPROF_CFLAGS), \ > CFLAGS_debug := -DHPROF_LOGGING, \ > + CFLAGS_windows := -D_WINSOCK_DEPRECATED_NO_WARNINGS, \ > MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \ > LDFLAGS := $(LDFLAGS_JDKLIB) \ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > /Erik > > On 2015-04-23 00:02, Pete Brunet wrote: >> This hack to jdk/make/lib/Lib-jdk.hprof.agent.gmk works for now: >> >> LANG := C, \ >> OPTIMIZATION := $(LIBHPROF_OPTIMIZATION), \ >> CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \ >> + -D_WINSOCK_DEPRECATED_NO_WARNINGS \ >> $(BUILD_LIBHPROF_CFLAGS), \ >> CFLAGS_debug := -DHPROF_LOGGING, \ >> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \ >> >> Pete >> >> On 4/22/15 4:12 PM, Pete Brunet wrote: >>> p.s. I also had done a make reconfigure and make clean. I'll try make >>> clean and reconfigure from bash. >>> >>> On 4/22/15 4:06 PM, Pete Brunet wrote: >>>> I was able to build 9 OK then I switched from VS2010 to VS2013 and now >>>> get the following. I tried hg tpull -u but that didn't help. >>>> >>>> Is there something I need to do besides installing VS Pro 2013 with >>>> Update 4? >>>> >>>> $ make images 2>&1 | tee make-64.log >>>> Building target 'images' in configuration >>>> 'windows-x86_64-normal-server-release' >>>> >>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86) >>>> : error C2220: warning treated as error - no 'object' file generated >>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86) >>>> : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() >>>> instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated >>>> API warnings >>>> c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see >>>> declaration of 'gethostbyname' >>>> Lib-jdk.hprof.agent.gmk:44: recipe for target >>>> '/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h >>>> prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: *** >>>> [/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj] >>>> Error 2 >>>> make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed >>>> make[2]: *** [jdk.hprof.agent-libs] Error 1 >>>> make[2]: *** Waiting for unfinished jobs.... >>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255: >>>> recipe for target 'main' failed >>>> make[1]: *** [main] Error 1 >>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171: >>>> recipe for target 'images' failed >>>> make: *** [images] Error 2 > From tim.bell at oracle.com Mon May 4 15:15:02 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 04 May 2015 08:15:02 -0700 Subject: RFR: JDK-8079087: Add support for Cygwin 2.0 In-Reply-To: <5547766C.5000308@oracle.com> References: <5547766C.5000308@oracle.com> Message-ID: <55478CF6.9020107@oracle.com> Erik: Looks good to me. Tim > Please review this small patch to configure which enables building on > Cygwin 2.0 and newer. Instead of explicitly testing for all versions > we know work, I inverted the check to exclude the ones we know won't > work. Hitting a known bad Cygwin version should be very rare anyway > since 1.7 has been around for a long time now and Cygwin is so > aggresive with keeping people updated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079087 > > Patch: > > diff -r bc02cff96b92 common/autoconf/basics_windows.m4 > --- a/common/autoconf/basics_windows.m4 > +++ b/common/autoconf/basics_windows.m4 > @@ -320,8 +320,8 @@ > WINDOWS_ENV_VENDOR='cygwin' > WINDOWS_ENV_VERSION="$CYGWIN_VERSION" > > - CYGWIN_VERSION_OK=`$ECHO $CYGWIN_VERSION | $GREP ^1.7.` > - if test "x$CYGWIN_VERSION_OK" = x; then > + CYGWIN_VERSION_OLD=`$ECHO $CYGWIN_VERSION | $GREP -e '^1\.[0-6]'` > + if test "x$CYGWIN_VERSION_OLD" != x; then > AC_MSG_NOTICE([Your cygwin is too old. You are running > $CYGWIN_VERSION, but at least cygwin 1.7 is required. Please upgrade.]) > AC_MSG_ERROR([Cannot continue]) > fi > > > /Erik From tim.bell at oracle.com Mon May 4 15:17:29 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 04 May 2015 08:17:29 -0700 Subject: RFR: JDK-8077422: hprof agent: Build failed with VS2013 Update 4 In-Reply-To: References: <55380D4E.7080700@oracle.com> <55380EA4.7030901@oracle.com> <55381A5D.1020900@oracle.com> <5547782B.2040804@oracle.com> Message-ID: <55478D89.70708@oracle.com> Erik: Looks good to me as well. Tim On 05/04/15 08:13, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 4 maj 2015, at 15:46, Erik Joelsson wrote: >> >> Hello, >> >> This bug has been marked as won't fix since the code it affects is going to be removed. However, until that removal happens, we can't build using VS2013 SP4. I'm in the process of updating the compilers used internally at Oracle to that specific version and to be able to continue that work, I need this to be buildable now. For this reason I propose Peter Brunet's suggested solution to the problem, just adding a C macro definition that makes it compile. I slightly adjusted his initial proposal. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8077422 >> Patch: >> diff -r 83ff0dedf9e1 make/lib/Lib-jdk.hprof.agent.gmk >> --- a/make/lib/Lib-jdk.hprof.agent.gmk >> +++ b/make/lib/Lib-jdk.hprof.agent.gmk >> @@ -31,7 +31,7 @@ >> >> BUILD_LIBHPROF_CFLAGS := $(addprefix -I, $(BUILD_LIBHPROF_SRC)) \ >> -I$(JDK_TOPDIR)/src/demo/share/jvmti/java_crw_demo >> >> BUILD_LIBHPROF_LDFLAGS := >> >> LIBHPROF_OPTIMIZATION := HIGHEST >> @@ -49,6 +49,7 @@ >> CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \ >> $(BUILD_LIBHPROF_CFLAGS), \ >> CFLAGS_debug := -DHPROF_LOGGING, \ >> + CFLAGS_windows := -D_WINSOCK_DEPRECATED_NO_WARNINGS, \ >> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \ >> LDFLAGS := $(LDFLAGS_JDKLIB) \ >> $(call SET_SHARED_LIBRARY_ORIGIN), \ >> >> /Erik >> >> On 2015-04-23 00:02, Pete Brunet wrote: >>> This hack to jdk/make/lib/Lib-jdk.hprof.agent.gmk works for now: >>> >>> LANG := C, \ >>> OPTIMIZATION := $(LIBHPROF_OPTIMIZATION), \ >>> CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \ >>> + -D_WINSOCK_DEPRECATED_NO_WARNINGS \ >>> $(BUILD_LIBHPROF_CFLAGS), \ >>> CFLAGS_debug := -DHPROF_LOGGING, \ >>> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \ >>> >>> Pete >>> >>> On 4/22/15 4:12 PM, Pete Brunet wrote: >>>> p.s. I also had done a make reconfigure and make clean. I'll try make >>>> clean and reconfigure from bash. >>>> >>>> On 4/22/15 4:06 PM, Pete Brunet wrote: >>>>> I was able to build 9 OK then I switched from VS2010 to VS2013 and now >>>>> get the following. I tried hg tpull -u but that didn't help. >>>>> >>>>> Is there something I need to do besides installing VS Pro 2013 with >>>>> Update 4? >>>>> >>>>> $ make images 2>&1 | tee make-64.log >>>>> Building target 'images' in configuration >>>>> 'windows-x86_64-normal-server-release' >>>>> >>>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86) >>>>> : error C2220: warning treated as error - no 'object' file generated >>>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86) >>>>> : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() >>>>> instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated >>>>> API warnings >>>>> c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see >>>>> declaration of 'gethostbyname' >>>>> Lib-jdk.hprof.agent.gmk:44: recipe for target >>>>> '/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h >>>>> prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: *** >>>>> [/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj] >>>>> Error 2 >>>>> make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed >>>>> make[2]: *** [jdk.hprof.agent-libs] Error 1 >>>>> make[2]: *** Waiting for unfinished jobs.... >>>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255: >>>>> recipe for target 'main' failed >>>>> make[1]: *** [main] Error 1 >>>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171: >>>>> recipe for target 'images' failed >>>>> make: *** [images] Error 2 From edward.nevill at linaro.org Tue May 5 09:23:42 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Tue, 05 May 2015 10:23:42 +0100 Subject: [aarch64-port-dev ] aarch64: jdk9: 8078245: fails to build from source In-Reply-To: <55478A4A.90301@oracle.com> References: <1429607797.4116.11.camel@mylittlepony.linaroharston> <5539EC8E.1060507@oracle.com> <1430304750.8394.56.camel@mylittlepony.linaroharston> <5541BD0A.3090305@oracle.com> <5547365F.1020105@oracle.com> <55478A4A.90301@oracle.com> Message-ID: <1430817822.14347.8.camel@mylittlepony.linaroharston> Hi, You are right, there is a better place for this, in make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk is the line LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE \ so, someone has already done this here for x86, so I just need to add the equivalent for aarch64 LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \ Note: I have not conditionalised this on OPENJDK_TARGET_CPU_ARCH as the corresponding x86 code is not conditionalised and I really don't think the symbol PNG_ARM_NEON_OPT will have any effect on any other architectures. Erik, Magnus & David, I have listed you as reviewers in the following webrev. If you are happy with this please let me know and I will push. http://cr.openjdk.java.net/~enevill/8078245/webrev.02/ All the best, Ed. On Mon, 2015-05-04 at 17:03 +0200, Erik Joelsson wrote: > Right, that does make sense. This isn't a toolchain global flag like > some others we've had to deal with lately, but rather seems pretty > specific to the png code, or am I missing something? If that's the case, > then it's better added for the specific library. > > /Erik > > On 2015-05-04 16:43, Magnus Ihse Bursie wrote: > > Why not just for the library that needs it? > > > > /Magnus > > > >> 4 maj 2015 kl. 11:05 skrev Erik Joelsson : > >> > >> Hello, > >> > >> I think this looks good enough. The flags handling is still a big mess so even if there were a better place for this, I couldn't say where. > >> > >> /Erik > >> > >>> On 2015-04-30 07:26, David Holmes wrote: > >>> Hi Nevill, > >>> > >>> Just realized this was sent to hotspot-dev (attempting bcc) but is not a hotspot issue. With your new approach this is a build issue so cc'ing build-dev. > >>> > >>> The new approach seems better to me but build folk need to confirm the placement. > >>> > >>> Thanks, > >>> David > >>> > >>>> On 29/04/2015 8:52 PM, Edward Nevill wrote: > >>>>> On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote: > >>>>> Hi Ed, > >>>>> > >>>>>> On 21/04/2015 7:16 PM, Edward Nevill wrote: > >>>>>> Hi, > >>>>>> > >>>>>> The current jdk9 tip fails to build from source on aarch64 with the following error message > >>>>>> > >>>>>> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': > >>>>>> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon' > >>>>>> collect2: error: ld returned 1 exit status > >>>>>> > >>>>>> The following webrev gets it building again. > >>>>>> > >>>>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/ > >>>>> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm > >>>>> also wondering how we would get __ARM_NEON defined but not __arm__? > >>>> On arm 32 bit gcc defines the symbol __ARM_NEON if the flag -mfpu=neon is specified. Since this is not specified as part of the OpenJDK build the symbol is not defined and the build succeeds. > >>>> > >>>> On aarch64 the symbol __ARM_NEON is always defined (the theory being that aarch64 always supports Neon). Personally I think this is borken as it causes builds to fail (and not just OpenJDK, several other projects have had the same build failure - try googling the above error message). But we are stuck with gcc as it is. > >>>> > >>>> However, I don't like the above fix because it not only modifies the jdk, it modifies an external component which is pulled into jdk, which means every time a new revision of linpng is pulled in, the patch will have to be applied again. > >>>> > >>>> A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0 in the build (only if aarch64). > >>>> > >>>> The failing code in pngpriv.h reads > >>>> > >>>> #ifndef PNG_ARM_NEON_OPT > >>>> > >>>> ... > >>>> > >>>> # if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \ > >>>> defined(PNG_ALIGNED_MEMORY_SUPPORTED) > >>>> # define PNG_ARM_NEON_OPT 2 > >>>> # else > >>>> # define PNG_ARM_NEON_OPT 0 > >>>> # endif > >>>> #endif > >>>> > >>>> So, if we just predefine PNG_ARM_NEON=0 in the build this will have the same effect as adding defined(__arm__) or !defined(__aarch64__) above. > >>>> > >>>> The following patch webrev does this:- > >>>> > >>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.01/ > >>>> > >>>> If you are happy with this and if I could have another reviewer I will push this. > >>>> > >>>> All the best, > >>>> Ed. > From erik.joelsson at oracle.com Tue May 5 10:16:14 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 05 May 2015 12:16:14 +0200 Subject: [aarch64-port-dev ] aarch64: jdk9: 8078245: fails to build from source In-Reply-To: <1430817822.14347.8.camel@mylittlepony.linaroharston> References: <1429607797.4116.11.camel@mylittlepony.linaroharston> <5539EC8E.1060507@oracle.com> <1430304750.8394.56.camel@mylittlepony.linaroharston> <5541BD0A.3090305@oracle.com> <5547365F.1020105@oracle.com> <55478A4A.90301@oracle.com> <1430817822.14347.8.camel@mylittlepony.linaroharston> Message-ID: <5548986E.9060901@oracle.com> Hello Ed, I'm happy with this. /Erik On 2015-05-05 11:23, Edward Nevill wrote: > Hi, > > You are right, there is a better place for this, > > in make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > > is the line > > LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE \ > > so, someone has already done this here for x86, so I just need to add the equivalent for aarch64 > > LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \ > > Note: I have not conditionalised this on OPENJDK_TARGET_CPU_ARCH as the corresponding x86 code is not conditionalised and I really don't think the symbol PNG_ARM_NEON_OPT will have any effect on any other architectures. > > Erik, Magnus & David, I have listed you as reviewers in the following webrev. If you are happy with this please let me know and I will push. > > http://cr.openjdk.java.net/~enevill/8078245/webrev.02/ > > All the best, > Ed. > > On Mon, 2015-05-04 at 17:03 +0200, Erik Joelsson wrote: >> Right, that does make sense. This isn't a toolchain global flag like >> some others we've had to deal with lately, but rather seems pretty >> specific to the png code, or am I missing something? If that's the case, >> then it's better added for the specific library. >> >> /Erik >> >> On 2015-05-04 16:43, Magnus Ihse Bursie wrote: >>> Why not just for the library that needs it? >>> >>> /Magnus >>> >>>> 4 maj 2015 kl. 11:05 skrev Erik Joelsson : >>>> >>>> Hello, >>>> >>>> I think this looks good enough. The flags handling is still a big mess so even if there were a better place for this, I couldn't say where. >>>> >>>> /Erik >>>> >>>>> On 2015-04-30 07:26, David Holmes wrote: >>>>> Hi Nevill, >>>>> >>>>> Just realized this was sent to hotspot-dev (attempting bcc) but is not a hotspot issue. With your new approach this is a build issue so cc'ing build-dev. >>>>> >>>>> The new approach seems better to me but build folk need to confirm the placement. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> On 29/04/2015 8:52 PM, Edward Nevill wrote: >>>>>>> On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote: >>>>>>> Hi Ed, >>>>>>> >>>>>>>> On 21/04/2015 7:16 PM, Edward Nevill wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> The current jdk9 tip fails to build from source on aarch64 with the following error message >>>>>>>> >>>>>>>> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': >>>>>>>> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon' >>>>>>>> collect2: error: ld returned 1 exit status >>>>>>>> >>>>>>>> The following webrev gets it building again. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/ >>>>>>> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm >>>>>>> also wondering how we would get __ARM_NEON defined but not __arm__? >>>>>> On arm 32 bit gcc defines the symbol __ARM_NEON if the flag -mfpu=neon is specified. Since this is not specified as part of the OpenJDK build the symbol is not defined and the build succeeds. >>>>>> >>>>>> On aarch64 the symbol __ARM_NEON is always defined (the theory being that aarch64 always supports Neon). Personally I think this is borken as it causes builds to fail (and not just OpenJDK, several other projects have had the same build failure - try googling the above error message). But we are stuck with gcc as it is. >>>>>> >>>>>> However, I don't like the above fix because it not only modifies the jdk, it modifies an external component which is pulled into jdk, which means every time a new revision of linpng is pulled in, the patch will have to be applied again. >>>>>> >>>>>> A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0 in the build (only if aarch64). >>>>>> >>>>>> The failing code in pngpriv.h reads >>>>>> >>>>>> #ifndef PNG_ARM_NEON_OPT >>>>>> >>>>>> ... >>>>>> >>>>>> # if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \ >>>>>> defined(PNG_ALIGNED_MEMORY_SUPPORTED) >>>>>> # define PNG_ARM_NEON_OPT 2 >>>>>> # else >>>>>> # define PNG_ARM_NEON_OPT 0 >>>>>> # endif >>>>>> #endif >>>>>> >>>>>> So, if we just predefine PNG_ARM_NEON=0 in the build this will have the same effect as adding defined(__arm__) or !defined(__aarch64__) above. >>>>>> >>>>>> The following patch webrev does this:- >>>>>> >>>>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.01/ >>>>>> >>>>>> If you are happy with this and if I could have another reviewer I will push this. >>>>>> >>>>>> All the best, >>>>>> Ed. > From david.holmes at oracle.com Tue May 5 10:23:00 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 May 2015 20:23:00 +1000 Subject: [aarch64-port-dev ] aarch64: jdk9: 8078245: fails to build from source In-Reply-To: <1430817822.14347.8.camel@mylittlepony.linaroharston> References: <1429607797.4116.11.camel@mylittlepony.linaroharston> <5539EC8E.1060507@oracle.com> <1430304750.8394.56.camel@mylittlepony.linaroharston> <5541BD0A.3090305@oracle.com> <5547365F.1020105@oracle.com> <55478A4A.90301@oracle.com> <1430817822.14347.8.camel@mylittlepony.linaroharston> Message-ID: <55489A04.6010404@oracle.com> On 5/05/2015 7:23 PM, Edward Nevill wrote: > Hi, > > You are right, there is a better place for this, > > in make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > > is the line > > LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE \ > > so, someone has already done this here for x86, so I just need to add the equivalent for aarch64 > > LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \ > > Note: I have not conditionalised this on OPENJDK_TARGET_CPU_ARCH as the corresponding x86 code is not conditionalised and I really don't think the symbol PNG_ARM_NEON_OPT will have any effect on any other architectures. > > Erik, Magnus & David, I have listed you as reviewers in the following webrev. If you are happy with this please let me know and I will push. I defer to the build folk. Thanks, David > http://cr.openjdk.java.net/~enevill/8078245/webrev.02/ > > All the best, > Ed. > > On Mon, 2015-05-04 at 17:03 +0200, Erik Joelsson wrote: >> Right, that does make sense. This isn't a toolchain global flag like >> some others we've had to deal with lately, but rather seems pretty >> specific to the png code, or am I missing something? If that's the case, >> then it's better added for the specific library. >> >> /Erik >> >> On 2015-05-04 16:43, Magnus Ihse Bursie wrote: >>> Why not just for the library that needs it? >>> >>> /Magnus >>> >>>> 4 maj 2015 kl. 11:05 skrev Erik Joelsson : >>>> >>>> Hello, >>>> >>>> I think this looks good enough. The flags handling is still a big mess so even if there were a better place for this, I couldn't say where. >>>> >>>> /Erik >>>> >>>>> On 2015-04-30 07:26, David Holmes wrote: >>>>> Hi Nevill, >>>>> >>>>> Just realized this was sent to hotspot-dev (attempting bcc) but is not a hotspot issue. With your new approach this is a build issue so cc'ing build-dev. >>>>> >>>>> The new approach seems better to me but build folk need to confirm the placement. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> On 29/04/2015 8:52 PM, Edward Nevill wrote: >>>>>>> On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote: >>>>>>> Hi Ed, >>>>>>> >>>>>>>> On 21/04/2015 7:16 PM, Edward Nevill wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> The current jdk9 tip fails to build from source on aarch64 with the following error message >>>>>>>> >>>>>>>> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': >>>>>>>> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon' >>>>>>>> collect2: error: ld returned 1 exit status >>>>>>>> >>>>>>>> The following webrev gets it building again. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/ >>>>>>> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm >>>>>>> also wondering how we would get __ARM_NEON defined but not __arm__? >>>>>> On arm 32 bit gcc defines the symbol __ARM_NEON if the flag -mfpu=neon is specified. Since this is not specified as part of the OpenJDK build the symbol is not defined and the build succeeds. >>>>>> >>>>>> On aarch64 the symbol __ARM_NEON is always defined (the theory being that aarch64 always supports Neon). Personally I think this is borken as it causes builds to fail (and not just OpenJDK, several other projects have had the same build failure - try googling the above error message). But we are stuck with gcc as it is. >>>>>> >>>>>> However, I don't like the above fix because it not only modifies the jdk, it modifies an external component which is pulled into jdk, which means every time a new revision of linpng is pulled in, the patch will have to be applied again. >>>>>> >>>>>> A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0 in the build (only if aarch64). >>>>>> >>>>>> The failing code in pngpriv.h reads >>>>>> >>>>>> #ifndef PNG_ARM_NEON_OPT >>>>>> >>>>>> ... >>>>>> >>>>>> # if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \ >>>>>> defined(PNG_ALIGNED_MEMORY_SUPPORTED) >>>>>> # define PNG_ARM_NEON_OPT 2 >>>>>> # else >>>>>> # define PNG_ARM_NEON_OPT 0 >>>>>> # endif >>>>>> #endif >>>>>> >>>>>> So, if we just predefine PNG_ARM_NEON=0 in the build this will have the same effect as adding defined(__arm__) or !defined(__aarch64__) above. >>>>>> >>>>>> The following patch webrev does this:- >>>>>> >>>>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.01/ >>>>>> >>>>>> If you are happy with this and if I could have another reviewer I will push this. >>>>>> >>>>>> All the best, >>>>>> Ed. >> > > From magnus.ihse.bursie at oracle.com Tue May 5 13:32:57 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 05 May 2015 15:32:57 +0200 Subject: [aarch64-port-dev ] aarch64: jdk9: 8078245: fails to build from source In-Reply-To: <1430817822.14347.8.camel@mylittlepony.linaroharston> References: <1429607797.4116.11.camel@mylittlepony.linaroharston> <5539EC8E.1060507@oracle.com> <1430304750.8394.56.camel@mylittlepony.linaroharston> <5541BD0A.3090305@oracle.com> <5547365F.1020105@oracle.com> <55478A4A.90301@oracle.com> <1430817822.14347.8.camel@mylittlepony.linaroharston> Message-ID: <5548C689.4010006@oracle.com> On 2015-05-05 11:23, Edward Nevill wrote: > Hi, > > You are right, there is a better place for this, > > in make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > > is the line > > LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE \ > > so, someone has already done this here for x86, so I just need to add the equivalent for aarch64 > > LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \ > > Note: I have not conditionalised this on OPENJDK_TARGET_CPU_ARCH as the corresponding x86 code is not conditionalised and I really don't think the symbol PNG_ARM_NEON_OPT will have any effect on any other architectures. I agree, good choice. > > Erik, Magnus & David, I have listed you as reviewers in the following webrev. If you are happy with this please let me know and I will push. > > http://cr.openjdk.java.net/~enevill/8078245/webrev.02/ Looks good to me! /Magnus > > All the best, > Ed. > > On Mon, 2015-05-04 at 17:03 +0200, Erik Joelsson wrote: >> Right, that does make sense. This isn't a toolchain global flag like >> some others we've had to deal with lately, but rather seems pretty >> specific to the png code, or am I missing something? If that's the case, >> then it's better added for the specific library. >> >> /Erik >> >> On 2015-05-04 16:43, Magnus Ihse Bursie wrote: >>> Why not just for the library that needs it? >>> >>> /Magnus >>> >>>> 4 maj 2015 kl. 11:05 skrev Erik Joelsson : >>>> >>>> Hello, >>>> >>>> I think this looks good enough. The flags handling is still a big mess so even if there were a better place for this, I couldn't say where. >>>> >>>> /Erik >>>> >>>>> On 2015-04-30 07:26, David Holmes wrote: >>>>> Hi Nevill, >>>>> >>>>> Just realized this was sent to hotspot-dev (attempting bcc) but is not a hotspot issue. With your new approach this is a build issue so cc'ing build-dev. >>>>> >>>>> The new approach seems better to me but build folk need to confirm the placement. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> On 29/04/2015 8:52 PM, Edward Nevill wrote: >>>>>>> On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote: >>>>>>> Hi Ed, >>>>>>> >>>>>>>> On 21/04/2015 7:16 PM, Edward Nevill wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> The current jdk9 tip fails to build from source on aarch64 with the following error message >>>>>>>> >>>>>>>> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': >>>>>>>> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon' >>>>>>>> collect2: error: ld returned 1 exit status >>>>>>>> >>>>>>>> The following webrev gets it building again. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/ >>>>>>> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm >>>>>>> also wondering how we would get __ARM_NEON defined but not __arm__? >>>>>> On arm 32 bit gcc defines the symbol __ARM_NEON if the flag -mfpu=neon is specified. Since this is not specified as part of the OpenJDK build the symbol is not defined and the build succeeds. >>>>>> >>>>>> On aarch64 the symbol __ARM_NEON is always defined (the theory being that aarch64 always supports Neon). Personally I think this is borken as it causes builds to fail (and not just OpenJDK, several other projects have had the same build failure - try googling the above error message). But we are stuck with gcc as it is. >>>>>> >>>>>> However, I don't like the above fix because it not only modifies the jdk, it modifies an external component which is pulled into jdk, which means every time a new revision of linpng is pulled in, the patch will have to be applied again. >>>>>> >>>>>> A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0 in the build (only if aarch64). >>>>>> >>>>>> The failing code in pngpriv.h reads >>>>>> >>>>>> #ifndef PNG_ARM_NEON_OPT >>>>>> >>>>>> ... >>>>>> >>>>>> # if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \ >>>>>> defined(PNG_ALIGNED_MEMORY_SUPPORTED) >>>>>> # define PNG_ARM_NEON_OPT 2 >>>>>> # else >>>>>> # define PNG_ARM_NEON_OPT 0 >>>>>> # endif >>>>>> #endif >>>>>> >>>>>> So, if we just predefine PNG_ARM_NEON=0 in the build this will have the same effect as adding defined(__arm__) or !defined(__aarch64__) above. >>>>>> >>>>>> The following patch webrev does this:- >>>>>> >>>>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.01/ >>>>>> >>>>>> If you are happy with this and if I could have another reviewer I will push this. >>>>>> >>>>>> All the best, >>>>>> Ed. > From erik.joelsson at oracle.com Tue May 5 14:03:44 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 05 May 2015 16:03:44 +0200 Subject: RFR: JDK-8079344: Allow custom or platform specific java source to automatically override shared source Message-ID: <5548CDC0.7010505@oracle.com> Hello, Currently it's possible to do this: src/$module/share/native/libfoo/foo.c src/$module/linux/native/libfoo/foo.c And the result will be that the most specific file, linux in this case, file will get compiled and the other one ignored. The same works for custom (closed) files overriding open. In addition to native code, this also works for files being copied by the SetupJavaCompilation macro, typically properties or other resources. For java code this does not work however and in the cases where such overrides are used, the makefiles need explicit excludes of the overridden file. I have implemented a solution for this that covers java files and cleaned files in addition to the copied files in SetupJavaCompilation, so we get consistent behavior for all sorts of sources. Along with the new functionality I removed all the now redundant excludes. I've added tests for the new functionality in SetupJavaCompilation as well as the new macro in MakeBase. I've also added a debugging convenience macro in MakeBase that isn't currently used, but makes my life easier when needing to print variables. Now I can write: $(call PrintVar, VARNAME) and it will print: VARNAME >$(VARNAME)< Bug: https://bugs.openjdk.java.net/browse/JDK-8079344 Webrev: http://cr.openjdk.java.net/~erikj/8079344/webrev.01/ /Erik From magnus.ihse.bursie at oracle.com Tue May 5 19:29:30 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 05 May 2015 21:29:30 +0200 Subject: RFR: JDK-8079344: Allow custom or platform specific java source to automatically override shared source In-Reply-To: <5548CDC0.7010505@oracle.com> References: <5548CDC0.7010505@oracle.com> Message-ID: <55491A1A.1090804@oracle.com> On 2015-05-05 16:03, Erik Joelsson wrote: > Hello, > > Currently it's possible to do this: > > src/$module/share/native/libfoo/foo.c > src/$module/linux/native/libfoo/foo.c > > And the result will be that the most specific file, linux in this > case, file will get compiled and the other one ignored. The same works > for custom (closed) files overriding open. In addition to native code, > this also works for files being copied by the SetupJavaCompilation > macro, typically properties or other resources. > > For java code this does not work however and in the cases where such > overrides are used, the makefiles need explicit excludes of the > overridden file. I have implemented a solution for this that covers > java files and cleaned files in addition to the copied files in > SetupJavaCompilation, so we get consistent behavior for all sorts of > sources. > > Along with the new functionality I removed all the now redundant > excludes. I've added tests for the new functionality in > SetupJavaCompilation as well as the new macro in MakeBase. > > I've also added a debugging convenience macro in MakeBase that isn't > currently used, but makes my life easier when needing to print > variables. Now I can write: > > $(call PrintVar, VARNAME) > > and it will print: > > VARNAME >$(VARNAME)< > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079344 > Webrev: http://cr.openjdk.java.net/~erikj/8079344/webrev.01/ Looks good to me. I'm happy to see that you are implementing test cases for this! (And also, of course, that we finally get this behavior consistent across macros.) /Magnus From magnus.ihse.bursie at oracle.com Tue May 5 19:30:21 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 05 May 2015 21:30:21 +0200 Subject: RFR: JDK-8079087: Add support for Cygwin 2.0 In-Reply-To: <5547766C.5000308@oracle.com> References: <5547766C.5000308@oracle.com> Message-ID: <55491A4D.2050104@oracle.com> On 2015-05-04 15:38, Erik Joelsson wrote: > Hello, > > Please review this small patch to configure which enables building on > Cygwin 2.0 and newer. Instead of explicitly testing for all versions > we know work, I inverted the check to exclude the ones we know won't > work. Hitting a known bad Cygwin version should be very rare anyway > since 1.7 has been around for a long time now and Cygwin is so > aggresive with keeping people updated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079087 > > Patch: > > diff -r bc02cff96b92 common/autoconf/basics_windows.m4 > --- a/common/autoconf/basics_windows.m4 > +++ b/common/autoconf/basics_windows.m4 > @@ -320,8 +320,8 @@ > WINDOWS_ENV_VENDOR='cygwin' > WINDOWS_ENV_VERSION="$CYGWIN_VERSION" > > - CYGWIN_VERSION_OK=`$ECHO $CYGWIN_VERSION | $GREP ^1.7.` > - if test "x$CYGWIN_VERSION_OK" = x; then > + CYGWIN_VERSION_OLD=`$ECHO $CYGWIN_VERSION | $GREP -e '^1\.[0-6]'` > + if test "x$CYGWIN_VERSION_OLD" != x; then > AC_MSG_NOTICE([Your cygwin is too old. You are running > $CYGWIN_VERSION, but at least cygwin 1.7 is required. Please upgrade.]) > AC_MSG_ERROR([Cannot continue]) > fi Looks good to me. /Magnus From staffan.larsen at oracle.com Wed May 6 09:24:58 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 6 May 2015 11:24:58 +0200 Subject: RFR: 8079345: After 8079248 fixed JDK still fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" Message-ID: My fix for 8079248 was broken, so here is a new attempt. I intend to push this directly to jdk9/hs since that is where 8079248 was pushed. bug: https://bugs.openjdk.java.net/browse/JDK-8079345#comment-13638237 webrev: http://cr.openjdk.java.net/~sla/8079345/webrev.00 Thanks, /Staffan From erik.joelsson at oracle.com Wed May 6 09:39:34 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 06 May 2015 11:39:34 +0200 Subject: RFR: 8079345: After 8079248 fixed JDK still fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" In-Reply-To: References: Message-ID: <5549E156.2020600@oracle.com> This one looks better. Sorry for not spotting the problem in the previous review. /Erik On 2015-05-06 11:24, Staffan Larsen wrote: > My fix for 8079248 was broken, so here is a new attempt. I intend to push this directly to jdk9/hs since that is where 8079248 was pushed. > > bug: https://bugs.openjdk.java.net/browse/JDK-8079345#comment-13638237 > webrev: http://cr.openjdk.java.net/~sla/8079345/webrev.00 > > Thanks, > /Staffan From magnus.ihse.bursie at oracle.com Wed May 6 09:46:58 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 06 May 2015 11:46:58 +0200 Subject: RFR: 8079345: After 8079248 fixed JDK still fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" In-Reply-To: <5549E156.2020600@oracle.com> References: <5549E156.2020600@oracle.com> Message-ID: <5549E312.3050703@oracle.com> On 2015-05-06 11:39, Erik Joelsson wrote: > This one looks better. Sorry for not spotting the problem in the > previous review. > > /Erik > > On 2015-05-06 11:24, Staffan Larsen wrote: >> My fix for 8079248 was broken, so here is a new attempt. I intend to >> push this directly to jdk9/hs since that is where 8079248 was pushed. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8079345#comment-13638237 >> webrev: http://cr.openjdk.java.net/~sla/8079345/webrev.00 >> Looks good to me. If you care, maybe you could move (and properly indent) the comment about the flag to inside the "if windows" clause? You don't need to respin the webrev if you do that. /Magnus From magnus.ihse.bursie at oracle.com Wed May 6 10:31:55 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 06 May 2015 12:31:55 +0200 Subject: RFR: JDK-8078046 Remove MCS post-processing on Solaris In-Reply-To: <5530DDF1.4040803@oracle.com> References: <5530CFCA.1060100@oracle.com> <5530DDF1.4040803@oracle.com> Message-ID: <5549ED9B.7070302@oracle.com> On 2015-04-17 12:18, David Holmes wrote: > Hi Magnus, > > On 17/04/2015 7:18 PM, Magnus Ihse Bursie wrote: >> We should remove the MCS post-processing on Solaris. >> >> The msc command is used to post-process the binaries on Solaris, with >> the intent of adding the version number. Post-processing of binaries is >> a step that we'd like to avoid, if possible. >> >> It now turns out that the MCS processing has been broken since at least >> JDK8, and nobody has noticed. I recommend we just remove it. > > In what way was it broken? > > What role was it serving? > > Who was the consumer of the added information? > > Are the people who can answer those questions likely to be watching > build-dev? ;-) > > Happy to see code removed and the build simplified, but only after > ensuring we understand the impact. Hi David, I have now conducted some research internally in Oracle. It seems noone here knows why this was added. The only reply I got was that the information in the .comment section on Solaris binaries are useful for sysadmins to determine e.g. what patch level of the OS was used when compiling the binary. Unfortunately, we strip that information away with the "-d" flag. :-( So I believe the patch is safe, and will indeed improve the usefulness of the Solaris binaries. Are you ok with this reply, and hence the patch? /Magnus > > Thanks, > David > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8078046 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8078046-remove-MCS/webrev.01 >> >> /Magnus From staffan.larsen at oracle.com Wed May 6 11:29:13 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 6 May 2015 13:29:13 +0200 Subject: RFR: 8079345: After 8079248 fixed JDK still fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" In-Reply-To: <5549E312.3050703@oracle.com> References: <5549E156.2020600@oracle.com> <5549E312.3050703@oracle.com> Message-ID: > On 6 maj 2015, at 11:46, Magnus Ihse Bursie wrote: > > On 2015-05-06 11:39, Erik Joelsson wrote: >> This one looks better. Sorry for not spotting the problem in the previous review. >> >> /Erik >> >> On 2015-05-06 11:24, Staffan Larsen wrote: >>> My fix for 8079248 was broken, so here is a new attempt. I intend to push this directly to jdk9/hs since that is where 8079248 was pushed. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8079345#comment-13638237 >>> webrev: http://cr.openjdk.java.net/~sla/8079345/webrev.00 > > Looks good to me. If you care, maybe you could move (and properly indent) the comment about the flag to inside the "if windows" clause? You don't need to respin the webrev if you do that. Done: diff --git a/make/lib/Lib-jdk.management.gmk b/make/lib/Lib-jdk.management.gmk --- a/make/lib/Lib-jdk.management.gmk +++ b/make/lib/Lib-jdk.management.gmk @@ -39,10 +39,12 @@ $(LIBJAVA_HEADER_FLAGS) \ # -# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate -# a binary that is compatible with windows versions older than 7/2008R2. -# See MSDN documentation for GetProcessMemoryInfo for more information. -BUILD_LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1 +ifeq ($(OPENJDK_TARGET_OS), windows) + # In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate + # a binary that is compatible with windows versions older than 7/2008R2. + # See MSDN documentation for GetProcessMemoryInfo for more information. + LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1 +endif LIBMANAGEMENT_EXT_OPTIMIZATION := HIGH ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) From david.holmes at oracle.com Wed May 6 11:50:19 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 May 2015 21:50:19 +1000 Subject: RFR: JDK-8078046 Remove MCS post-processing on Solaris In-Reply-To: <5549ED9B.7070302@oracle.com> References: <5530CFCA.1060100@oracle.com> <5530DDF1.4040803@oracle.com> <5549ED9B.7070302@oracle.com> Message-ID: <5549FFFB.8080502@oracle.com> On 6/05/2015 8:31 PM, Magnus Ihse Bursie wrote: > On 2015-04-17 12:18, David Holmes wrote: >> Hi Magnus, >> >> On 17/04/2015 7:18 PM, Magnus Ihse Bursie wrote: >>> We should remove the MCS post-processing on Solaris. >>> >>> The msc command is used to post-process the binaries on Solaris, with >>> the intent of adding the version number. Post-processing of binaries is >>> a step that we'd like to avoid, if possible. >>> >>> It now turns out that the MCS processing has been broken since at least >>> JDK8, and nobody has noticed. I recommend we just remove it. >> >> In what way was it broken? >> >> What role was it serving? >> >> Who was the consumer of the added information? >> >> Are the people who can answer those questions likely to be watching >> build-dev? ;-) >> >> Happy to see code removed and the build simplified, but only after >> ensuring we understand the impact. > > Hi David, > > I have now conducted some research internally in Oracle. It seems noone > here knows why this was added. The only reply I got was that the > information in the .comment section on Solaris binaries are useful for > sysadmins to determine e.g. what patch level of the OS was used when > compiling the binary. > > Unfortunately, we strip that information away with the "-d" flag. :-( > > So I believe the patch is safe, and will indeed improve the usefulness > of the Solaris binaries. > > Are you ok with this reply, and hence the patch? Yes - thanks for doing the due diligence on this. Now I bet we get an external complaint that this information has gone - from someone upgrading from 7u to 8 :) Cheers, David > /Magnus > > >> >> Thanks, >> David >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078046 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8078046-remove-MCS/webrev.01 >>> >>> /Magnus > From serguei.spitsyn at oracle.com Wed May 6 11:55:23 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 06 May 2015 04:55:23 -0700 Subject: RFR: 8079345: After 8079248 fixed JDK still fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" In-Reply-To: References: <5549E156.2020600@oracle.com> <5549E312.3050703@oracle.com> Message-ID: <554A012B.9040106@oracle.com> This looks good. It is better with the moved comment. Thanks, Serguei On 5/6/15 4:29 AM, Staffan Larsen wrote: >> On 6 maj 2015, at 11:46, Magnus Ihse Bursie wrote: >> >> On 2015-05-06 11:39, Erik Joelsson wrote: >>> This one looks better. Sorry for not spotting the problem in the previous review. >>> >>> /Erik >>> >>> On 2015-05-06 11:24, Staffan Larsen wrote: >>>> My fix for 8079248 was broken, so here is a new attempt. I intend to push this directly to jdk9/hs since that is where 8079248 was pushed. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8079345#comment-13638237 >>>> webrev: http://cr.openjdk.java.net/~sla/8079345/webrev.00 >> Looks good to me. If you care, maybe you could move (and properly indent) the comment about the flag to inside the "if windows" clause? You don't need to respin the webrev if you do that. > Done: > > diff --git a/make/lib/Lib-jdk.management.gmk b/make/lib/Lib-jdk.management.gmk > --- a/make/lib/Lib-jdk.management.gmk > +++ b/make/lib/Lib-jdk.management.gmk > @@ -39,10 +39,12 @@ > $(LIBJAVA_HEADER_FLAGS) \ > # > > -# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate > -# a binary that is compatible with windows versions older than 7/2008R2. > -# See MSDN documentation for GetProcessMemoryInfo for more information. > -BUILD_LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1 > +ifeq ($(OPENJDK_TARGET_OS), windows) > + # In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate > + # a binary that is compatible with windows versions older than 7/2008R2. > + # See MSDN documentation for GetProcessMemoryInfo for more information. > + LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1 > +endif > > LIBMANAGEMENT_EXT_OPTIMIZATION := HIGH > ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), ) > From peter.brunet at oracle.com Wed May 6 12:39:10 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 06 May 2015 07:39:10 -0500 Subject: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5 In-Reply-To: <5523F61A.4000303@oracle.com> References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com> <55230C8A.8060909@oracle.com> <55234669.3080007@oracle.com> <552377C1.7020305@oracle.com> <5523D3F3.40309@oracle.com> <5523F61A.4000303@oracle.com> Message-ID: <554A0B6E.5000907@oracle.com> Hi Vadim, I had to defer from this for a while but am back at it. Apparently --with-xcode-path isn't currently a valid option. Pete On 4/7/15 10:22 AM, Vadim Pakhnushev wrote: > Pete, have you tried > sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ > ? > It seems that the configure doesn't pick the correct path from the > xcode-select. > Although I successfully built jdk8u on 10.10 with both xcode-select > and --with-xcode-path > BTW, the correct path for xcode-select would be /Applications/Xcode\ > 4.6.3.app/Contents/Developer I guess. > > Thanks, > Vadim > > On 07.04.2015 15:56, Pete Brunet wrote: >> Hi, I need some help so I can build on MacOSX to fix a build break. >> >> First since I had Xcode 6.1.1 and configure complained that I didn't >> have v4 I installed v4.6.3. After installing 4.6.3 and doing >> sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/ >> I got past that. Then for some reason my compile environment is now >> bad. I get >> >> ... >> configure:20476: checking for C compiler version >> configure:20485: /usr/bin/gcc --version >&5 >> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build >> 5658) (LLVM build 2336.11.00) >> Copyright (C) 2007 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There >> is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> >> configure:20496: $? = 0 >> configure:20485: /usr/bin/gcc -v >&5 >> Using built-in specs. >> Target: i686-apple-darwin11 >> Configured with: >> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure >> --disable-checking --enable-werror >> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 >> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ >> --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ >> --with-slibdir=/usr/lib --build=i686-apple-darwin11 >> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local >> >> --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 >> --target=i686-apple-darwin11 >> --with-gxx-include-dir=/usr/include/c++/4.2.1 >> Thread model: posix >> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build >> 2336.11.00) >> configure:20496: $? = 0 >> configure:20485: /usr/bin/gcc -V >&5 >> llvm-gcc-4.2: argument to `-V' is missing >> configure:20496: $? = 1 >> configure:20485: /usr/bin/gcc -qversion >&5 >> i686-apple-darwin11-llvm-gcc-4.2: no input files >> configure:20496: $? = 1 >> configure:20516: checking whether the C compiler works >> configure:20538: /usr/bin/gcc conftest.c >&5 >> ld: library not found for -lcrt1.10.6.o >> collect2: ld returned 1 exit status >> ... >> >> Trying find from the root: >> find . -name crt1\* >> >> ... >> ./Applications/Xcode >> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o >> >> ./Applications/Xcode >> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o >> >> ./Applications/Xcode >> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o >> >> ./Applications/Xcode >> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o >> >> ./Applications/Xcode >> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o >> >> ./Applications/Xcode >> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o >> >> ./Applications/Xcode >> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o >> >> ./Applications/Xcode >> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o >> >> ./Applications/Xcode >> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o >> >> ./Applications/Xcode >> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o >> >> ./Applications/Xcode >> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o >> >> ./Applications/Xcode >> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o >> >> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o >> >> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o >> >> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o >> >> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o >> >> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o >> >> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o >> >> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o >> >> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o >> >> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o >> >> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o >> >> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o >> >> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o >> >> ... >> >> Xcode.app above is v6.1.1. I am on OS X 10.9.5 and notice that for 10.9 >> I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3. >> >> Pete > From vadim.pakhnushev at oracle.com Wed May 6 12:51:54 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 06 May 2015 15:51:54 +0300 Subject: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5 In-Reply-To: <554A0B6E.5000907@oracle.com> References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com> <55230C8A.8060909@oracle.com> <55234669.3080007@oracle.com> <552377C1.7020305@oracle.com> <5523D3F3.40309@oracle.com> <5523F61A.4000303@oracle.com> <554A0B6E.5000907@oracle.com> Message-ID: <554A0E6A.1080700@oracle.com> Hi Pete, How is that? I haven't tried this lately, but I just pulled 8u-dev sources and the option is there: $ sh configure --help .... --with-xcode-path explicit path to Xcode 4 (generally for building on 10.9 and later) Thanks, Vadim On 06.05.2015 15:39, Pete Brunet wrote: > Hi Vadim, I had to defer from this for a while but am back at it. > > Apparently --with-xcode-path isn't currently a valid option. > > Pete > > On 4/7/15 10:22 AM, Vadim Pakhnushev wrote: >> Pete, have you tried >> sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >> ? >> It seems that the configure doesn't pick the correct path from the >> xcode-select. >> Although I successfully built jdk8u on 10.10 with both xcode-select >> and --with-xcode-path >> BTW, the correct path for xcode-select would be /Applications/Xcode\ >> 4.6.3.app/Contents/Developer I guess. >> >> Thanks, >> Vadim >> >> On 07.04.2015 15:56, Pete Brunet wrote: >>> Hi, I need some help so I can build on MacOSX to fix a build break. >>> >>> First since I had Xcode 6.1.1 and configure complained that I didn't >>> have v4 I installed v4.6.3. After installing 4.6.3 and doing >>> sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/ >>> I got past that. Then for some reason my compile environment is now >>> bad. I get >>> >>> ... >>> configure:20476: checking for C compiler version >>> configure:20485: /usr/bin/gcc --version >&5 >>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build >>> 5658) (LLVM build 2336.11.00) >>> Copyright (C) 2007 Free Software Foundation, Inc. >>> This is free software; see the source for copying conditions. There >>> is NO >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>> PURPOSE. >>> >>> configure:20496: $? = 0 >>> configure:20485: /usr/bin/gcc -v >&5 >>> Using built-in specs. >>> Target: i686-apple-darwin11 >>> Configured with: >>> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure >>> --disable-checking --enable-werror >>> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 >>> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ >>> --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ >>> --with-slibdir=/usr/lib --build=i686-apple-darwin11 >>> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local >>> >>> --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 >>> --target=i686-apple-darwin11 >>> --with-gxx-include-dir=/usr/include/c++/4.2.1 >>> Thread model: posix >>> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build >>> 2336.11.00) >>> configure:20496: $? = 0 >>> configure:20485: /usr/bin/gcc -V >&5 >>> llvm-gcc-4.2: argument to `-V' is missing >>> configure:20496: $? = 1 >>> configure:20485: /usr/bin/gcc -qversion >&5 >>> i686-apple-darwin11-llvm-gcc-4.2: no input files >>> configure:20496: $? = 1 >>> configure:20516: checking whether the C compiler works >>> configure:20538: /usr/bin/gcc conftest.c >&5 >>> ld: library not found for -lcrt1.10.6.o >>> collect2: ld returned 1 exit status >>> ... >>> >>> Trying find from the root: >>> find . -name crt1\* >>> >>> ... >>> ./Applications/Xcode >>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o >>> >>> ./Applications/Xcode >>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o >>> >>> ./Applications/Xcode >>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o >>> >>> ./Applications/Xcode >>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o >>> >>> ./Applications/Xcode >>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o >>> >>> ./Applications/Xcode >>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o >>> >>> ./Applications/Xcode >>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o >>> >>> ./Applications/Xcode >>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o >>> >>> ./Applications/Xcode >>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o >>> >>> ./Applications/Xcode >>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o >>> >>> ./Applications/Xcode >>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o >>> >>> ./Applications/Xcode >>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o >>> >>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o >>> >>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o >>> >>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o >>> >>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o >>> >>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o >>> >>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o >>> >>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o >>> >>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o >>> >>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o >>> >>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o >>> >>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o >>> >>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o >>> >>> ... >>> >>> Xcode.app above is v6.1.1. I am on OS X 10.9.5 and notice that for 10.9 >>> I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3. >>> >>> Pete From peter.brunet at oracle.com Wed May 6 13:53:40 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 06 May 2015 08:53:40 -0500 Subject: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5 In-Reply-To: <554A0E6A.1080700@oracle.com> References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com> <55230C8A.8060909@oracle.com> <55234669.3080007@oracle.com> <552377C1.7020305@oracle.com> <5523D3F3.40309@oracle.com> <5523F61A.4000303@oracle.com> <554A0B6E.5000907@oracle.com> <554A0E6A.1080700@oracle.com> Message-ID: <554A1CE4.7060901@oracle.com> Maybe it's because now I am using the 9 repo: $ bash ./configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ 2>&1 | tee configure.log Running generated-configure.sh configure: error: unrecognized options: --with-xcode-path configure exiting with result code 1 On 5/6/15 7:51 AM, Vadim Pakhnushev wrote: > Hi Pete, > > How is that? > I haven't tried this lately, but I just pulled 8u-dev sources and the > option is there: > > $ sh configure --help > .... > --with-xcode-path explicit path to Xcode 4 (generally for > building on > 10.9 and later) > > Thanks, > Vadim > > On 06.05.2015 15:39, Pete Brunet wrote: >> Hi Vadim, I had to defer from this for a while but am back at it. >> >> Apparently --with-xcode-path isn't currently a valid option. >> >> Pete >> >> On 4/7/15 10:22 AM, Vadim Pakhnushev wrote: >>> Pete, have you tried >>> sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>> ? >>> It seems that the configure doesn't pick the correct path from the >>> xcode-select. >>> Although I successfully built jdk8u on 10.10 with both xcode-select >>> and --with-xcode-path >>> BTW, the correct path for xcode-select would be /Applications/Xcode\ >>> 4.6.3.app/Contents/Developer I guess. >>> >>> Thanks, >>> Vadim >>> >>> On 07.04.2015 15:56, Pete Brunet wrote: >>>> Hi, I need some help so I can build on MacOSX to fix a build break. >>>> >>>> First since I had Xcode 6.1.1 and configure complained that I didn't >>>> have v4 I installed v4.6.3. After installing 4.6.3 and doing >>>> sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/ >>>> I got past that. Then for some reason my compile environment is now >>>> bad. I get >>>> >>>> ... >>>> configure:20476: checking for C compiler version >>>> configure:20485: /usr/bin/gcc --version >&5 >>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. >>>> build >>>> 5658) (LLVM build 2336.11.00) >>>> Copyright (C) 2007 Free Software Foundation, Inc. >>>> This is free software; see the source for copying conditions. There >>>> is NO >>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>>> PURPOSE. >>>> >>>> configure:20496: $? = 0 >>>> configure:20485: /usr/bin/gcc -v >&5 >>>> Using built-in specs. >>>> Target: i686-apple-darwin11 >>>> Configured with: >>>> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure >>>> --disable-checking --enable-werror >>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 >>>> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ >>>> --program-prefix=llvm- >>>> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ >>>> --with-slibdir=/usr/lib --build=i686-apple-darwin11 >>>> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local >>>> >>>> >>>> --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 >>>> --target=i686-apple-darwin11 >>>> --with-gxx-include-dir=/usr/include/c++/4.2.1 >>>> Thread model: posix >>>> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build >>>> 2336.11.00) >>>> configure:20496: $? = 0 >>>> configure:20485: /usr/bin/gcc -V >&5 >>>> llvm-gcc-4.2: argument to `-V' is missing >>>> configure:20496: $? = 1 >>>> configure:20485: /usr/bin/gcc -qversion >&5 >>>> i686-apple-darwin11-llvm-gcc-4.2: no input files >>>> configure:20496: $? = 1 >>>> configure:20516: checking whether the C compiler works >>>> configure:20538: /usr/bin/gcc conftest.c >&5 >>>> ld: library not found for -lcrt1.10.6.o >>>> collect2: ld returned 1 exit status >>>> ... >>>> >>>> Trying find from the root: >>>> find . -name crt1\* >>>> >>>> ... >>>> ./Applications/Xcode >>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o >>>> >>>> >>>> ./Applications/Xcode >>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o >>>> >>>> >>>> ./Applications/Xcode >>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o >>>> >>>> >>>> ./Applications/Xcode >>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o >>>> >>>> >>>> ./Applications/Xcode >>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o >>>> >>>> >>>> ./Applications/Xcode >>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o >>>> >>>> >>>> ./Applications/Xcode >>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o >>>> >>>> >>>> ./Applications/Xcode >>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o >>>> >>>> >>>> ./Applications/Xcode >>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o >>>> >>>> >>>> ./Applications/Xcode >>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o >>>> >>>> >>>> ./Applications/Xcode >>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o >>>> >>>> >>>> ./Applications/Xcode >>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o >>>> >>>> >>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o >>>> >>>> >>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o >>>> >>>> >>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o >>>> >>>> >>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o >>>> >>>> >>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o >>>> >>>> >>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o >>>> >>>> >>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o >>>> >>>> >>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o >>>> >>>> >>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o >>>> >>>> >>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o >>>> >>>> >>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o >>>> >>>> >>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o >>>> >>>> >>>> ... >>>> >>>> Xcode.app above is v6.1.1. I am on OS X 10.9.5 and notice that for >>>> 10.9 >>>> I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3. >>>> >>>> Pete > From vadim.pakhnushev at oracle.com Wed May 6 14:02:09 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 06 May 2015 17:02:09 +0300 Subject: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5 In-Reply-To: <554A1CE4.7060901@oracle.com> References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com> <55230C8A.8060909@oracle.com> <55234669.3080007@oracle.com> <552377C1.7020305@oracle.com> <5523D3F3.40309@oracle.com> <5523F61A.4000303@oracle.com> <554A0B6E.5000907@oracle.com> <554A0E6A.1080700@oracle.com> <554A1CE4.7060901@oracle.com> Message-ID: <554A1EE1.8020404@oracle.com> Pete, I think that you should build JDK 9 with the latest Xcode. With Xcode 6.3 this fix is needed (not yet integrated into the 9-dev) https://bugs.openjdk.java.net/browse/JDK-8077364. Thanks, Vadim On 06.05.2015 16:53, Pete Brunet wrote: > Maybe it's because now I am using the 9 repo: > > $ bash ./configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ > 2>&1 | tee configure.log > Running generated-configure.sh > configure: error: unrecognized options: --with-xcode-path > configure exiting with result code 1 > > On 5/6/15 7:51 AM, Vadim Pakhnushev wrote: >> Hi Pete, >> >> How is that? >> I haven't tried this lately, but I just pulled 8u-dev sources and the >> option is there: >> >> $ sh configure --help >> .... >> --with-xcode-path explicit path to Xcode 4 (generally for >> building on >> 10.9 and later) >> >> Thanks, >> Vadim >> >> On 06.05.2015 15:39, Pete Brunet wrote: >>> Hi Vadim, I had to defer from this for a while but am back at it. >>> >>> Apparently --with-xcode-path isn't currently a valid option. >>> >>> Pete >>> >>> On 4/7/15 10:22 AM, Vadim Pakhnushev wrote: >>>> Pete, have you tried >>>> sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>>> ? >>>> It seems that the configure doesn't pick the correct path from the >>>> xcode-select. >>>> Although I successfully built jdk8u on 10.10 with both xcode-select >>>> and --with-xcode-path >>>> BTW, the correct path for xcode-select would be /Applications/Xcode\ >>>> 4.6.3.app/Contents/Developer I guess. >>>> >>>> Thanks, >>>> Vadim >>>> >>>> On 07.04.2015 15:56, Pete Brunet wrote: >>>>> Hi, I need some help so I can build on MacOSX to fix a build break. >>>>> >>>>> First since I had Xcode 6.1.1 and configure complained that I didn't >>>>> have v4 I installed v4.6.3. After installing 4.6.3 and doing >>>>> sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/ >>>>> I got past that. Then for some reason my compile environment is now >>>>> bad. I get >>>>> >>>>> ... >>>>> configure:20476: checking for C compiler version >>>>> configure:20485: /usr/bin/gcc --version >&5 >>>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. >>>>> build >>>>> 5658) (LLVM build 2336.11.00) >>>>> Copyright (C) 2007 Free Software Foundation, Inc. >>>>> This is free software; see the source for copying conditions. There >>>>> is NO >>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>>>> PURPOSE. >>>>> >>>>> configure:20496: $? = 0 >>>>> configure:20485: /usr/bin/gcc -v >&5 >>>>> Using built-in specs. >>>>> Target: i686-apple-darwin11 >>>>> Configured with: >>>>> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure >>>>> --disable-checking --enable-werror >>>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 >>>>> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ >>>>> --program-prefix=llvm- >>>>> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ >>>>> --with-slibdir=/usr/lib --build=i686-apple-darwin11 >>>>> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local >>>>> >>>>> >>>>> --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 >>>>> --target=i686-apple-darwin11 >>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1 >>>>> Thread model: posix >>>>> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build >>>>> 2336.11.00) >>>>> configure:20496: $? = 0 >>>>> configure:20485: /usr/bin/gcc -V >&5 >>>>> llvm-gcc-4.2: argument to `-V' is missing >>>>> configure:20496: $? = 1 >>>>> configure:20485: /usr/bin/gcc -qversion >&5 >>>>> i686-apple-darwin11-llvm-gcc-4.2: no input files >>>>> configure:20496: $? = 1 >>>>> configure:20516: checking whether the C compiler works >>>>> configure:20538: /usr/bin/gcc conftest.c >&5 >>>>> ld: library not found for -lcrt1.10.6.o >>>>> collect2: ld returned 1 exit status >>>>> ... >>>>> >>>>> Trying find from the root: >>>>> find . -name crt1\* >>>>> >>>>> ... >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ... >>>>> >>>>> Xcode.app above is v6.1.1. I am on OS X 10.9.5 and notice that for >>>>> 10.9 >>>>> I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3. >>>>> >>>>> Pete From david.dehaven at oracle.com Wed May 6 16:11:40 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 6 May 2015 09:11:40 -0700 Subject: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5 In-Reply-To: <554A1CE4.7060901@oracle.com> References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com> <55230C8A.8060909@oracle.com> <55234669.3080007@oracle.com> <552377C1.7020305@oracle.com> <5523D3F3.40309@oracle.com> <5523F61A.4000303@oracle.com> <554A0B6E.5000907@oracle.com> <554A0E6A.1080700@oracle.com> <554A1CE4.7060901@oracle.com> Message-ID: Correct, --with-xcode-path is for jdk8u only as it requires building with Xcode 4. For jdk9 use the Xcode 5.1 or later. The Xcode 6.3 patch is in hotspot, it will be integrated to dev hopefully in the near future. In the meantime you can apply the patch to your local workspace. Or, if you have an ADC account, you should be able to download Xcode 6.1 or 6.2 (listed in the "other" downloads). Just install it somewhere besides /Applications or the Mac App Store will try to auto-update it for you. Once installed, just use "sudo xcode-select --switch /path/to/Xcode-6.2.app" to use it. -DrD- > Maybe it's because now I am using the 9 repo: > > $ bash ./configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ > 2>&1 | tee configure.log > Running generated-configure.sh > configure: error: unrecognized options: --with-xcode-path > configure exiting with result code 1 > > On 5/6/15 7:51 AM, Vadim Pakhnushev wrote: >> Hi Pete, >> >> How is that? >> I haven't tried this lately, but I just pulled 8u-dev sources and the >> option is there: >> >> $ sh configure --help >> .... >> --with-xcode-path explicit path to Xcode 4 (generally for >> building on >> 10.9 and later) >> >> Thanks, >> Vadim >> >> On 06.05.2015 15:39, Pete Brunet wrote: >>> Hi Vadim, I had to defer from this for a while but am back at it. >>> >>> Apparently --with-xcode-path isn't currently a valid option. >>> >>> Pete >>> >>> On 4/7/15 10:22 AM, Vadim Pakhnushev wrote: >>>> Pete, have you tried >>>> sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>>> ? >>>> It seems that the configure doesn't pick the correct path from the >>>> xcode-select. >>>> Although I successfully built jdk8u on 10.10 with both xcode-select >>>> and --with-xcode-path >>>> BTW, the correct path for xcode-select would be /Applications/Xcode\ >>>> 4.6.3.app/Contents/Developer I guess. >>>> >>>> Thanks, >>>> Vadim >>>> >>>> On 07.04.2015 15:56, Pete Brunet wrote: >>>>> Hi, I need some help so I can build on MacOSX to fix a build break. >>>>> >>>>> First since I had Xcode 6.1.1 and configure complained that I didn't >>>>> have v4 I installed v4.6.3. After installing 4.6.3 and doing >>>>> sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/ >>>>> I got past that. Then for some reason my compile environment is now >>>>> bad. I get >>>>> >>>>> ... >>>>> configure:20476: checking for C compiler version >>>>> configure:20485: /usr/bin/gcc --version >&5 >>>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. >>>>> build >>>>> 5658) (LLVM build 2336.11.00) >>>>> Copyright (C) 2007 Free Software Foundation, Inc. >>>>> This is free software; see the source for copying conditions. There >>>>> is NO >>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>>>> PURPOSE. >>>>> >>>>> configure:20496: $? = 0 >>>>> configure:20485: /usr/bin/gcc -v >&5 >>>>> Using built-in specs. >>>>> Target: i686-apple-darwin11 >>>>> Configured with: >>>>> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure >>>>> --disable-checking --enable-werror >>>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 >>>>> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ >>>>> --program-prefix=llvm- >>>>> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ >>>>> --with-slibdir=/usr/lib --build=i686-apple-darwin11 >>>>> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local >>>>> >>>>> >>>>> --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 >>>>> --target=i686-apple-darwin11 >>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1 >>>>> Thread model: posix >>>>> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build >>>>> 2336.11.00) >>>>> configure:20496: $? = 0 >>>>> configure:20485: /usr/bin/gcc -V >&5 >>>>> llvm-gcc-4.2: argument to `-V' is missing >>>>> configure:20496: $? = 1 >>>>> configure:20485: /usr/bin/gcc -qversion >&5 >>>>> i686-apple-darwin11-llvm-gcc-4.2: no input files >>>>> configure:20496: $? = 1 >>>>> configure:20516: checking whether the C compiler works >>>>> configure:20538: /usr/bin/gcc conftest.c >&5 >>>>> ld: library not found for -lcrt1.10.6.o >>>>> collect2: ld returned 1 exit status >>>>> ... >>>>> >>>>> Trying find from the root: >>>>> find . -name crt1\* >>>>> >>>>> ... >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o >>>>> >>>>> >>>>> ./Applications/Xcode >>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o >>>>> >>>>> >>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o >>>>> >>>>> >>>>> ... >>>>> >>>>> Xcode.app above is v6.1.1. I am on OS X 10.9.5 and notice that for >>>>> 10.9 >>>>> I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3. >>>>> >>>>> Pete >> > From staffan.larsen at oracle.com Wed May 6 18:51:18 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 6 May 2015 20:51:18 +0200 Subject: RFR: 8079360 AttachProviderImpl could not be instantiated Message-ID: <64EEA73D-FF3A-4868-8F93-530D419A7D04@oracle.com> This is another library that needs to be compiled with -DPSAPI_VERSION=1 due to the recent Windows compiler upgrade. I have also fixed a better error message that prints the underlaying exception if something like this happens again. webrev: http://cr.openjdk.java.net/~sla/8079360/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8079360 Thanks, /Staffan From peter.brunet at oracle.com Wed May 6 19:49:15 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 06 May 2015 14:49:15 -0500 Subject: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5 In-Reply-To: References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com> <55230C8A.8060909@oracle.com> <55234669.3080007@oracle.com> <552377C1.7020305@oracle.com> <5523D3F3.40309@oracle.com> <5523F61A.4000303@oracle.com> <554A0B6E.5000907@oracle.com> <554A0E6A.1080700@oracle.com> <554A1CE4.7060901@oracle.com> Message-ID: <554A703B.5060506@oracle.com> Thanks David, I have Xcode 6.1.1 and configure fails with "Could not find freetype! These sites http://blog.shelan.org/2015/03/how-to-build-open-jdk-9-on-mac-osx.html http://gvsmirnov.ru/blog/tech/2014/02/07/building-openjdk-8-on-osx-maverick.html say to install XQuartz, but that didn't help. BTW, My OS is Mavericks. If it matters I have not yet moved Xcode out of /Applications. Pete On 5/6/15 11:11 AM, David DeHaven wrote: > Correct, --with-xcode-path is for jdk8u only as it requires building with Xcode 4. For jdk9 use the Xcode 5.1 or later. > > The Xcode 6.3 patch is in hotspot, it will be integrated to dev hopefully in the near future. In the meantime you can apply the patch to your local workspace. > > Or, if you have an ADC account, you should be able to download Xcode 6.1 or 6.2 (listed in the "other" downloads). Just install it somewhere besides /Applications or the Mac App Store will try to auto-update it for you. Once installed, just use "sudo xcode-select --switch /path/to/Xcode-6.2.app" to use it. > > -DrD- > >> Maybe it's because now I am using the 9 repo: >> >> $ bash ./configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >> 2>&1 | tee configure.log >> Running generated-configure.sh >> configure: error: unrecognized options: --with-xcode-path >> configure exiting with result code 1 >> >> On 5/6/15 7:51 AM, Vadim Pakhnushev wrote: >>> Hi Pete, >>> >>> How is that? >>> I haven't tried this lately, but I just pulled 8u-dev sources and the >>> option is there: >>> >>> $ sh configure --help >>> .... >>> --with-xcode-path explicit path to Xcode 4 (generally for >>> building on >>> 10.9 and later) >>> >>> Thanks, >>> Vadim >>> >>> On 06.05.2015 15:39, Pete Brunet wrote: >>>> Hi Vadim, I had to defer from this for a while but am back at it. >>>> >>>> Apparently --with-xcode-path isn't currently a valid option. >>>> >>>> Pete >>>> >>>> On 4/7/15 10:22 AM, Vadim Pakhnushev wrote: >>>>> Pete, have you tried >>>>> sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>>>> ? >>>>> It seems that the configure doesn't pick the correct path from the >>>>> xcode-select. >>>>> Although I successfully built jdk8u on 10.10 with both xcode-select >>>>> and --with-xcode-path >>>>> BTW, the correct path for xcode-select would be /Applications/Xcode\ >>>>> 4.6.3.app/Contents/Developer I guess. >>>>> >>>>> Thanks, >>>>> Vadim >>>>> >>>>> On 07.04.2015 15:56, Pete Brunet wrote: >>>>>> Hi, I need some help so I can build on MacOSX to fix a build break. >>>>>> >>>>>> First since I had Xcode 6.1.1 and configure complained that I didn't >>>>>> have v4 I installed v4.6.3. After installing 4.6.3 and doing >>>>>> sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/ >>>>>> I got past that. Then for some reason my compile environment is now >>>>>> bad. I get >>>>>> >>>>>> ... >>>>>> configure:20476: checking for C compiler version >>>>>> configure:20485: /usr/bin/gcc --version >&5 >>>>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. >>>>>> build >>>>>> 5658) (LLVM build 2336.11.00) >>>>>> Copyright (C) 2007 Free Software Foundation, Inc. >>>>>> This is free software; see the source for copying conditions. There >>>>>> is NO >>>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>>>>> PURPOSE. >>>>>> >>>>>> configure:20496: $? = 0 >>>>>> configure:20485: /usr/bin/gcc -v >&5 >>>>>> Using built-in specs. >>>>>> Target: i686-apple-darwin11 >>>>>> Configured with: >>>>>> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure >>>>>> --disable-checking --enable-werror >>>>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 >>>>>> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ >>>>>> --program-prefix=llvm- >>>>>> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ >>>>>> --with-slibdir=/usr/lib --build=i686-apple-darwin11 >>>>>> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local >>>>>> >>>>>> >>>>>> --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 >>>>>> --target=i686-apple-darwin11 >>>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1 >>>>>> Thread model: posix >>>>>> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build >>>>>> 2336.11.00) >>>>>> configure:20496: $? = 0 >>>>>> configure:20485: /usr/bin/gcc -V >&5 >>>>>> llvm-gcc-4.2: argument to `-V' is missing >>>>>> configure:20496: $? = 1 >>>>>> configure:20485: /usr/bin/gcc -qversion >&5 >>>>>> i686-apple-darwin11-llvm-gcc-4.2: no input files >>>>>> configure:20496: $? = 1 >>>>>> configure:20516: checking whether the C compiler works >>>>>> configure:20538: /usr/bin/gcc conftest.c >&5 >>>>>> ld: library not found for -lcrt1.10.6.o >>>>>> collect2: ld returned 1 exit status >>>>>> ... >>>>>> >>>>>> Trying find from the root: >>>>>> find . -name crt1\* >>>>>> >>>>>> ... >>>>>> ./Applications/Xcode >>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode >>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode >>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode >>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode >>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode >>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode >>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode >>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode >>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode >>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode >>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode >>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o >>>>>> >>>>>> >>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o >>>>>> >>>>>> >>>>>> ... >>>>>> >>>>>> Xcode.app above is v6.1.1. I am on OS X 10.9.5 and notice that for >>>>>> 10.9 >>>>>> I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3. >>>>>> >>>>>> Pete From dmitry.samersoff at oracle.com Wed May 6 19:50:36 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 06 May 2015 22:50:36 +0300 Subject: RFR: 8079360 AttachProviderImpl could not be instantiated In-Reply-To: <64EEA73D-FF3A-4868-8F93-530D419A7D04@oracle.com> References: <64EEA73D-FF3A-4868-8F93-530D419A7D04@oracle.com> Message-ID: <554A708C.5090206@oracle.com> Staffan, Looks good for me. -Dmitry On 2015-05-06 21:51, Staffan Larsen wrote: > This is another library that needs to be compiled with -DPSAPI_VERSION=1 > due to the recent Windows compiler upgrade. > > I have also fixed a better error message that prints the underlaying > exception if something like this happens again. > > webrev: http://cr.openjdk.java.net/~sla/8079360/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8079360 > > Thanks, > /Staffan > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From vadim.pakhnushev at oracle.com Wed May 6 20:09:15 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 06 May 2015 23:09:15 +0300 Subject: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5 In-Reply-To: <554A703B.5060506@oracle.com> References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com> <55230C8A.8060909@oracle.com> <55234669.3080007@oracle.com> <552377C1.7020305@oracle.com> <5523D3F3.40309@oracle.com> <5523F61A.4000303@oracle.com> <554A0B6E.5000907@oracle.com> <554A0E6A.1080700@oracle.com> <554A1CE4.7060901@oracle.com> <554A703B.5060506@oracle.com> Message-ID: <554A74EB.1090307@oracle.com> My experience was that configure didn't find freetype even with the --with-freetype so I just did sudo make install and it found it in the /usr/local Thanks, Vadim On 06.05.2015 22:49, Pete Brunet wrote: > Thanks David, > > I have Xcode 6.1.1 and configure fails with "Could not find freetype! > These sites > http://blog.shelan.org/2015/03/how-to-build-open-jdk-9-on-mac-osx.html > http://gvsmirnov.ru/blog/tech/2014/02/07/building-openjdk-8-on-osx-maverick.html > say to install XQuartz, but that didn't help. BTW, My OS is Mavericks. > > If it matters I have not yet moved Xcode out of /Applications. > > Pete > > On 5/6/15 11:11 AM, David DeHaven wrote: >> Correct, --with-xcode-path is for jdk8u only as it requires building with Xcode 4. For jdk9 use the Xcode 5.1 or later. >> >> The Xcode 6.3 patch is in hotspot, it will be integrated to dev hopefully in the near future. In the meantime you can apply the patch to your local workspace. >> >> Or, if you have an ADC account, you should be able to download Xcode 6.1 or 6.2 (listed in the "other" downloads). Just install it somewhere besides /Applications or the Mac App Store will try to auto-update it for you. Once installed, just use "sudo xcode-select --switch /path/to/Xcode-6.2.app" to use it. >> >> -DrD- >> >>> Maybe it's because now I am using the 9 repo: >>> >>> $ bash ./configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>> 2>&1 | tee configure.log >>> Running generated-configure.sh >>> configure: error: unrecognized options: --with-xcode-path >>> configure exiting with result code 1 >>> >>> On 5/6/15 7:51 AM, Vadim Pakhnushev wrote: >>>> Hi Pete, >>>> >>>> How is that? >>>> I haven't tried this lately, but I just pulled 8u-dev sources and the >>>> option is there: >>>> >>>> $ sh configure --help >>>> .... >>>> --with-xcode-path explicit path to Xcode 4 (generally for >>>> building on >>>> 10.9 and later) >>>> >>>> Thanks, >>>> Vadim >>>> >>>> On 06.05.2015 15:39, Pete Brunet wrote: >>>>> Hi Vadim, I had to defer from this for a while but am back at it. >>>>> >>>>> Apparently --with-xcode-path isn't currently a valid option. >>>>> >>>>> Pete >>>>> >>>>> On 4/7/15 10:22 AM, Vadim Pakhnushev wrote: >>>>>> Pete, have you tried >>>>>> sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>>>>> ? >>>>>> It seems that the configure doesn't pick the correct path from the >>>>>> xcode-select. >>>>>> Although I successfully built jdk8u on 10.10 with both xcode-select >>>>>> and --with-xcode-path >>>>>> BTW, the correct path for xcode-select would be /Applications/Xcode\ >>>>>> 4.6.3.app/Contents/Developer I guess. >>>>>> >>>>>> Thanks, >>>>>> Vadim >>>>>> >>>>>> On 07.04.2015 15:56, Pete Brunet wrote: >>>>>>> Hi, I need some help so I can build on MacOSX to fix a build break. >>>>>>> >>>>>>> First since I had Xcode 6.1.1 and configure complained that I didn't >>>>>>> have v4 I installed v4.6.3. After installing 4.6.3 and doing >>>>>>> sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/ >>>>>>> I got past that. Then for some reason my compile environment is now >>>>>>> bad. I get >>>>>>> >>>>>>> ... >>>>>>> configure:20476: checking for C compiler version >>>>>>> configure:20485: /usr/bin/gcc --version >&5 >>>>>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. >>>>>>> build >>>>>>> 5658) (LLVM build 2336.11.00) >>>>>>> Copyright (C) 2007 Free Software Foundation, Inc. >>>>>>> This is free software; see the source for copying conditions. There >>>>>>> is NO >>>>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>>>>>> PURPOSE. >>>>>>> >>>>>>> configure:20496: $? = 0 >>>>>>> configure:20485: /usr/bin/gcc -v >&5 >>>>>>> Using built-in specs. >>>>>>> Target: i686-apple-darwin11 >>>>>>> Configured with: >>>>>>> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure >>>>>>> --disable-checking --enable-werror >>>>>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 >>>>>>> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ >>>>>>> --program-prefix=llvm- >>>>>>> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ >>>>>>> --with-slibdir=/usr/lib --build=i686-apple-darwin11 >>>>>>> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local >>>>>>> >>>>>>> >>>>>>> --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 >>>>>>> --target=i686-apple-darwin11 >>>>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1 >>>>>>> Thread model: posix >>>>>>> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build >>>>>>> 2336.11.00) >>>>>>> configure:20496: $? = 0 >>>>>>> configure:20485: /usr/bin/gcc -V >&5 >>>>>>> llvm-gcc-4.2: argument to `-V' is missing >>>>>>> configure:20496: $? = 1 >>>>>>> configure:20485: /usr/bin/gcc -qversion >&5 >>>>>>> i686-apple-darwin11-llvm-gcc-4.2: no input files >>>>>>> configure:20496: $? = 1 >>>>>>> configure:20516: checking whether the C compiler works >>>>>>> configure:20538: /usr/bin/gcc conftest.c >&5 >>>>>>> ld: library not found for -lcrt1.10.6.o >>>>>>> collect2: ld returned 1 exit status >>>>>>> ... >>>>>>> >>>>>>> Trying find from the root: >>>>>>> find . -name crt1\* >>>>>>> >>>>>>> ... >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> Xcode.app above is v6.1.1. I am on OS X 10.9.5 and notice that for >>>>>>> 10.9 >>>>>>> I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3. >>>>>>> >>>>>>> Pete From peter.brunet at oracle.com Wed May 6 20:09:36 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 06 May 2015 15:09:36 -0500 Subject: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5 In-Reply-To: <554A703B.5060506@oracle.com> References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com> <55230C8A.8060909@oracle.com> <55234669.3080007@oracle.com> <552377C1.7020305@oracle.com> <5523D3F3.40309@oracle.com> <5523F61A.4000303@oracle.com> <554A0B6E.5000907@oracle.com> <554A0E6A.1080700@oracle.com> <554A1CE4.7060901@oracle.com> <554A703B.5060506@oracle.com> Message-ID: <554A7500.6060808@oracle.com> After installing XQuartz, thanks to the text at Problem #1 at http://mail.openjdk.java.net/pipermail/build-dev/2014-October.txt using these options worked --with-freetype-include=/usr/X11/include/freetype2 --with-freetype-lib=/usr/X11/lib Pete On 5/6/15 2:49 PM, Pete Brunet wrote: > Thanks David, > > I have Xcode 6.1.1 and configure fails with "Could not find freetype! > These sites > http://blog.shelan.org/2015/03/how-to-build-open-jdk-9-on-mac-osx.html > http://gvsmirnov.ru/blog/tech/2014/02/07/building-openjdk-8-on-osx-maverick.html > say to install XQuartz, but that didn't help. BTW, My OS is Mavericks. > > If it matters I have not yet moved Xcode out of /Applications. > > Pete > > On 5/6/15 11:11 AM, David DeHaven wrote: >> Correct, --with-xcode-path is for jdk8u only as it requires building with Xcode 4. For jdk9 use the Xcode 5.1 or later. >> >> The Xcode 6.3 patch is in hotspot, it will be integrated to dev hopefully in the near future. In the meantime you can apply the patch to your local workspace. >> >> Or, if you have an ADC account, you should be able to download Xcode 6.1 or 6.2 (listed in the "other" downloads). Just install it somewhere besides /Applications or the Mac App Store will try to auto-update it for you. Once installed, just use "sudo xcode-select --switch /path/to/Xcode-6.2.app" to use it. >> >> -DrD- >> >>> Maybe it's because now I am using the 9 repo: >>> >>> $ bash ./configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>> 2>&1 | tee configure.log >>> Running generated-configure.sh >>> configure: error: unrecognized options: --with-xcode-path >>> configure exiting with result code 1 >>> >>> On 5/6/15 7:51 AM, Vadim Pakhnushev wrote: >>>> Hi Pete, >>>> >>>> How is that? >>>> I haven't tried this lately, but I just pulled 8u-dev sources and the >>>> option is there: >>>> >>>> $ sh configure --help >>>> .... >>>> --with-xcode-path explicit path to Xcode 4 (generally for >>>> building on >>>> 10.9 and later) >>>> >>>> Thanks, >>>> Vadim >>>> >>>> On 06.05.2015 15:39, Pete Brunet wrote: >>>>> Hi Vadim, I had to defer from this for a while but am back at it. >>>>> >>>>> Apparently --with-xcode-path isn't currently a valid option. >>>>> >>>>> Pete >>>>> >>>>> On 4/7/15 10:22 AM, Vadim Pakhnushev wrote: >>>>>> Pete, have you tried >>>>>> sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>>>>> ? >>>>>> It seems that the configure doesn't pick the correct path from the >>>>>> xcode-select. >>>>>> Although I successfully built jdk8u on 10.10 with both xcode-select >>>>>> and --with-xcode-path >>>>>> BTW, the correct path for xcode-select would be /Applications/Xcode\ >>>>>> 4.6.3.app/Contents/Developer I guess. >>>>>> >>>>>> Thanks, >>>>>> Vadim >>>>>> >>>>>> On 07.04.2015 15:56, Pete Brunet wrote: >>>>>>> Hi, I need some help so I can build on MacOSX to fix a build break. >>>>>>> >>>>>>> First since I had Xcode 6.1.1 and configure complained that I didn't >>>>>>> have v4 I installed v4.6.3. After installing 4.6.3 and doing >>>>>>> sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/ >>>>>>> I got past that. Then for some reason my compile environment is now >>>>>>> bad. I get >>>>>>> >>>>>>> ... >>>>>>> configure:20476: checking for C compiler version >>>>>>> configure:20485: /usr/bin/gcc --version >&5 >>>>>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. >>>>>>> build >>>>>>> 5658) (LLVM build 2336.11.00) >>>>>>> Copyright (C) 2007 Free Software Foundation, Inc. >>>>>>> This is free software; see the source for copying conditions. There >>>>>>> is NO >>>>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>>>>>> PURPOSE. >>>>>>> >>>>>>> configure:20496: $? = 0 >>>>>>> configure:20485: /usr/bin/gcc -v >&5 >>>>>>> Using built-in specs. >>>>>>> Target: i686-apple-darwin11 >>>>>>> Configured with: >>>>>>> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure >>>>>>> --disable-checking --enable-werror >>>>>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 >>>>>>> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ >>>>>>> --program-prefix=llvm- >>>>>>> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ >>>>>>> --with-slibdir=/usr/lib --build=i686-apple-darwin11 >>>>>>> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local >>>>>>> >>>>>>> >>>>>>> --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 >>>>>>> --target=i686-apple-darwin11 >>>>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1 >>>>>>> Thread model: posix >>>>>>> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build >>>>>>> 2336.11.00) >>>>>>> configure:20496: $? = 0 >>>>>>> configure:20485: /usr/bin/gcc -V >&5 >>>>>>> llvm-gcc-4.2: argument to `-V' is missing >>>>>>> configure:20496: $? = 1 >>>>>>> configure:20485: /usr/bin/gcc -qversion >&5 >>>>>>> i686-apple-darwin11-llvm-gcc-4.2: no input files >>>>>>> configure:20496: $? = 1 >>>>>>> configure:20516: checking whether the C compiler works >>>>>>> configure:20538: /usr/bin/gcc conftest.c >&5 >>>>>>> ld: library not found for -lcrt1.10.6.o >>>>>>> collect2: ld returned 1 exit status >>>>>>> ... >>>>>>> >>>>>>> Trying find from the root: >>>>>>> find . -name crt1\* >>>>>>> >>>>>>> ... >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode >>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o >>>>>>> >>>>>>> >>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o >>>>>>> >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> Xcode.app above is v6.1.1. I am on OS X 10.9.5 and notice that for >>>>>>> 10.9 >>>>>>> I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3. >>>>>>> >>>>>>> Pete From vadim.pakhnushev at oracle.com Wed May 6 20:11:34 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 06 May 2015 23:11:34 +0300 Subject: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5 In-Reply-To: <554A74EB.1090307@oracle.com> References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com> <55230C8A.8060909@oracle.com> <55234669.3080007@oracle.com> <552377C1.7020305@oracle.com> <5523D3F3.40309@oracle.com> <5523F61A.4000303@oracle.com> <554A0B6E.5000907@oracle.com> <554A0E6A.1080700@oracle.com> <554A1CE4.7060901@oracle.com> <554A703B.5060506@oracle.com> <554A74EB.1090307@oracle.com> Message-ID: <554A7576.3020400@oracle.com> That is, I downloaded freetype tarball from the freetype site and did 'sudo make install' in the extracted directory... On 06.05.2015 23:09, Vadim Pakhnushev wrote: > My experience was that configure didn't find freetype even with the > --with-freetype so I just did sudo make install and it found it in the > /usr/local > > Thanks, > Vadim > > On 06.05.2015 22:49, Pete Brunet wrote: >> Thanks David, >> >> I have Xcode 6.1.1 and configure fails with "Could not find freetype! >> These sites >> http://blog.shelan.org/2015/03/how-to-build-open-jdk-9-on-mac-osx.html >> http://gvsmirnov.ru/blog/tech/2014/02/07/building-openjdk-8-on-osx-maverick.html >> >> say to install XQuartz, but that didn't help. BTW, My OS is Mavericks. >> >> If it matters I have not yet moved Xcode out of /Applications. >> >> Pete >> >> On 5/6/15 11:11 AM, David DeHaven wrote: >>> Correct, --with-xcode-path is for jdk8u only as it requires building >>> with Xcode 4. For jdk9 use the Xcode 5.1 or later. >>> >>> The Xcode 6.3 patch is in hotspot, it will be integrated to dev >>> hopefully in the near future. In the meantime you can apply the >>> patch to your local workspace. >>> >>> Or, if you have an ADC account, you should be able to download Xcode >>> 6.1 or 6.2 (listed in the "other" downloads). Just install it >>> somewhere besides /Applications or the Mac App Store will try to >>> auto-update it for you. Once installed, just use "sudo xcode-select >>> --switch /path/to/Xcode-6.2.app" to use it. >>> >>> -DrD- >>> >>>> Maybe it's because now I am using the 9 repo: >>>> >>>> $ bash ./configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>>> 2>&1 | tee configure.log >>>> Running generated-configure.sh >>>> configure: error: unrecognized options: --with-xcode-path >>>> configure exiting with result code 1 >>>> >>>> On 5/6/15 7:51 AM, Vadim Pakhnushev wrote: >>>>> Hi Pete, >>>>> >>>>> How is that? >>>>> I haven't tried this lately, but I just pulled 8u-dev sources and the >>>>> option is there: >>>>> >>>>> $ sh configure --help >>>>> .... >>>>> --with-xcode-path explicit path to Xcode 4 (generally for >>>>> building on >>>>> 10.9 and later) >>>>> >>>>> Thanks, >>>>> Vadim >>>>> >>>>> On 06.05.2015 15:39, Pete Brunet wrote: >>>>>> Hi Vadim, I had to defer from this for a while but am back at it. >>>>>> >>>>>> Apparently --with-xcode-path isn't currently a valid option. >>>>>> >>>>>> Pete >>>>>> >>>>>> On 4/7/15 10:22 AM, Vadim Pakhnushev wrote: >>>>>>> Pete, have you tried >>>>>>> sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>>>>>> ? >>>>>>> It seems that the configure doesn't pick the correct path from the >>>>>>> xcode-select. >>>>>>> Although I successfully built jdk8u on 10.10 with both xcode-select >>>>>>> and --with-xcode-path >>>>>>> BTW, the correct path for xcode-select would be >>>>>>> /Applications/Xcode\ >>>>>>> 4.6.3.app/Contents/Developer I guess. >>>>>>> >>>>>>> Thanks, >>>>>>> Vadim >>>>>>> >>>>>>> On 07.04.2015 15:56, Pete Brunet wrote: >>>>>>>> Hi, I need some help so I can build on MacOSX to fix a build >>>>>>>> break. >>>>>>>> >>>>>>>> First since I had Xcode 6.1.1 and configure complained that I >>>>>>>> didn't >>>>>>>> have v4 I installed v4.6.3. After installing 4.6.3 and doing >>>>>>>> sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/ >>>>>>>> I got past that. Then for some reason my compile environment >>>>>>>> is now >>>>>>>> bad. I get >>>>>>>> >>>>>>>> ... >>>>>>>> configure:20476: checking for C compiler version >>>>>>>> configure:20485: /usr/bin/gcc --version >&5 >>>>>>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. >>>>>>>> build >>>>>>>> 5658) (LLVM build 2336.11.00) >>>>>>>> Copyright (C) 2007 Free Software Foundation, Inc. >>>>>>>> This is free software; see the source for copying conditions. >>>>>>>> There >>>>>>>> is NO >>>>>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>>>>>>> PURPOSE. >>>>>>>> >>>>>>>> configure:20496: $? = 0 >>>>>>>> configure:20485: /usr/bin/gcc -v >&5 >>>>>>>> Using built-in specs. >>>>>>>> Target: i686-apple-darwin11 >>>>>>>> Configured with: >>>>>>>> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure >>>>>>>> --disable-checking --enable-werror >>>>>>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 >>>>>>>> >>>>>>>> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ >>>>>>>> --program-prefix=llvm- >>>>>>>> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ >>>>>>>> --with-slibdir=/usr/lib --build=i686-apple-darwin11 >>>>>>>> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 >>>>>>>> --target=i686-apple-darwin11 >>>>>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1 >>>>>>>> Thread model: posix >>>>>>>> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build >>>>>>>> 2336.11.00) >>>>>>>> configure:20496: $? = 0 >>>>>>>> configure:20485: /usr/bin/gcc -V >&5 >>>>>>>> llvm-gcc-4.2: argument to `-V' is missing >>>>>>>> configure:20496: $? = 1 >>>>>>>> configure:20485: /usr/bin/gcc -qversion >&5 >>>>>>>> i686-apple-darwin11-llvm-gcc-4.2: no input files >>>>>>>> configure:20496: $? = 1 >>>>>>>> configure:20516: checking whether the C compiler works >>>>>>>> configure:20538: /usr/bin/gcc conftest.c >&5 >>>>>>>> ld: library not found for -lcrt1.10.6.o >>>>>>>> collect2: ld returned 1 exit status >>>>>>>> ... >>>>>>>> >>>>>>>> Trying find from the root: >>>>>>>> find . -name crt1\* >>>>>>>> >>>>>>>> ... >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> Xcode.app above is v6.1.1. I am on OS X 10.9.5 and notice that >>>>>>>> for >>>>>>>> 10.9 >>>>>>>> I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3. >>>>>>>> >>>>>>>> Pete > From peter.brunet at oracle.com Wed May 6 20:49:15 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 06 May 2015 15:49:15 -0500 Subject: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5 In-Reply-To: <554A7500.6060808@oracle.com> References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com> <55230C8A.8060909@oracle.com> <55234669.3080007@oracle.com> <552377C1.7020305@oracle.com> <5523D3F3.40309@oracle.com> <5523F61A.4000303@oracle.com> <554A0B6E.5000907@oracle.com> <554A0E6A.1080700@oracle.com> <554A1CE4.7060901@oracle.com> <554A703B.5060506@oracle.com> <554A7500.6060808@oracle.com> Message-ID: <554A7E4B.7090709@oracle.com> p.s. make images ran with no problems. On 5/6/15 3:09 PM, Pete Brunet wrote: > After installing XQuartz, thanks to the text at Problem #1 at > http://mail.openjdk.java.net/pipermail/build-dev/2014-October.txt > using these options worked > --with-freetype-include=/usr/X11/include/freetype2 > --with-freetype-lib=/usr/X11/lib > > Pete > > On 5/6/15 2:49 PM, Pete Brunet wrote: >> Thanks David, >> >> I have Xcode 6.1.1 and configure fails with "Could not find freetype! >> These sites >> http://blog.shelan.org/2015/03/how-to-build-open-jdk-9-on-mac-osx.html >> http://gvsmirnov.ru/blog/tech/2014/02/07/building-openjdk-8-on-osx-maverick.html >> say to install XQuartz, but that didn't help. BTW, My OS is Mavericks. >> >> If it matters I have not yet moved Xcode out of /Applications. >> >> Pete >> >> On 5/6/15 11:11 AM, David DeHaven wrote: >>> Correct, --with-xcode-path is for jdk8u only as it requires building with Xcode 4. For jdk9 use the Xcode 5.1 or later. >>> >>> The Xcode 6.3 patch is in hotspot, it will be integrated to dev hopefully in the near future. In the meantime you can apply the patch to your local workspace. >>> >>> Or, if you have an ADC account, you should be able to download Xcode 6.1 or 6.2 (listed in the "other" downloads). Just install it somewhere besides /Applications or the Mac App Store will try to auto-update it for you. Once installed, just use "sudo xcode-select --switch /path/to/Xcode-6.2.app" to use it. >>> >>> -DrD- >>> >>>> Maybe it's because now I am using the 9 repo: >>>> >>>> $ bash ./configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>>> 2>&1 | tee configure.log >>>> Running generated-configure.sh >>>> configure: error: unrecognized options: --with-xcode-path >>>> configure exiting with result code 1 >>>> >>>> On 5/6/15 7:51 AM, Vadim Pakhnushev wrote: >>>>> Hi Pete, >>>>> >>>>> How is that? >>>>> I haven't tried this lately, but I just pulled 8u-dev sources and the >>>>> option is there: >>>>> >>>>> $ sh configure --help >>>>> .... >>>>> --with-xcode-path explicit path to Xcode 4 (generally for >>>>> building on >>>>> 10.9 and later) >>>>> >>>>> Thanks, >>>>> Vadim >>>>> >>>>> On 06.05.2015 15:39, Pete Brunet wrote: >>>>>> Hi Vadim, I had to defer from this for a while but am back at it. >>>>>> >>>>>> Apparently --with-xcode-path isn't currently a valid option. >>>>>> >>>>>> Pete >>>>>> >>>>>> On 4/7/15 10:22 AM, Vadim Pakhnushev wrote: >>>>>>> Pete, have you tried >>>>>>> sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>>>>>> ? >>>>>>> It seems that the configure doesn't pick the correct path from the >>>>>>> xcode-select. >>>>>>> Although I successfully built jdk8u on 10.10 with both xcode-select >>>>>>> and --with-xcode-path >>>>>>> BTW, the correct path for xcode-select would be /Applications/Xcode\ >>>>>>> 4.6.3.app/Contents/Developer I guess. >>>>>>> >>>>>>> Thanks, >>>>>>> Vadim >>>>>>> >>>>>>> On 07.04.2015 15:56, Pete Brunet wrote: >>>>>>>> Hi, I need some help so I can build on MacOSX to fix a build break. >>>>>>>> >>>>>>>> First since I had Xcode 6.1.1 and configure complained that I didn't >>>>>>>> have v4 I installed v4.6.3. After installing 4.6.3 and doing >>>>>>>> sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/ >>>>>>>> I got past that. Then for some reason my compile environment is now >>>>>>>> bad. I get >>>>>>>> >>>>>>>> ... >>>>>>>> configure:20476: checking for C compiler version >>>>>>>> configure:20485: /usr/bin/gcc --version >&5 >>>>>>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. >>>>>>>> build >>>>>>>> 5658) (LLVM build 2336.11.00) >>>>>>>> Copyright (C) 2007 Free Software Foundation, Inc. >>>>>>>> This is free software; see the source for copying conditions. There >>>>>>>> is NO >>>>>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>>>>>>> PURPOSE. >>>>>>>> >>>>>>>> configure:20496: $? = 0 >>>>>>>> configure:20485: /usr/bin/gcc -v >&5 >>>>>>>> Using built-in specs. >>>>>>>> Target: i686-apple-darwin11 >>>>>>>> Configured with: >>>>>>>> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure >>>>>>>> --disable-checking --enable-werror >>>>>>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 >>>>>>>> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ >>>>>>>> --program-prefix=llvm- >>>>>>>> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ >>>>>>>> --with-slibdir=/usr/lib --build=i686-apple-darwin11 >>>>>>>> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local >>>>>>>> >>>>>>>> >>>>>>>> --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 >>>>>>>> --target=i686-apple-darwin11 >>>>>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1 >>>>>>>> Thread model: posix >>>>>>>> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build >>>>>>>> 2336.11.00) >>>>>>>> configure:20496: $? = 0 >>>>>>>> configure:20485: /usr/bin/gcc -V >&5 >>>>>>>> llvm-gcc-4.2: argument to `-V' is missing >>>>>>>> configure:20496: $? = 1 >>>>>>>> configure:20485: /usr/bin/gcc -qversion >&5 >>>>>>>> i686-apple-darwin11-llvm-gcc-4.2: no input files >>>>>>>> configure:20496: $? = 1 >>>>>>>> configure:20516: checking whether the C compiler works >>>>>>>> configure:20538: /usr/bin/gcc conftest.c >&5 >>>>>>>> ld: library not found for -lcrt1.10.6.o >>>>>>>> collect2: ld returned 1 exit status >>>>>>>> ... >>>>>>>> >>>>>>>> Trying find from the root: >>>>>>>> find . -name crt1\* >>>>>>>> >>>>>>>> ... >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode >>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o >>>>>>>> >>>>>>>> >>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o >>>>>>>> >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> Xcode.app above is v6.1.1. I am on OS X 10.9.5 and notice that for >>>>>>>> 10.9 >>>>>>>> I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3. >>>>>>>> >>>>>>>> Pete From david.dehaven at oracle.com Wed May 6 20:57:48 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 6 May 2015 13:57:48 -0700 Subject: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5 In-Reply-To: <554A7E4B.7090709@oracle.com> References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com> <55230C8A.8060909@oracle.com> <55234669.3080007@oracle.com> <552377C1.7020305@oracle.com> <5523D3F3.40309@oracle.com> <5523F61A.4000303@oracle.com> <554A0B6E.5000907@oracle.com> <554A0E6A.1080700@oracle.com> <554A1CE4.7060901@oracle.com> <554A703B.5060506@oracle.com> <554A7500.6060808@oracle.com> <554A7E4B.7090709@oracle.com> Message-ID: <50A7A682-059F-42EC-8C7B-F80ADB57559E@oracle.com> Odd, I thought we checked that location by default. A fix for Yosemite was added, but Mavericks should still work. -DrD- > p.s. make images ran with no problems. > > On 5/6/15 3:09 PM, Pete Brunet wrote: >> After installing XQuartz, thanks to the text at Problem #1 at >> http://mail.openjdk.java.net/pipermail/build-dev/2014-October.txt >> using these options worked >> --with-freetype-include=/usr/X11/include/freetype2 >> --with-freetype-lib=/usr/X11/lib >> >> Pete >> >> On 5/6/15 2:49 PM, Pete Brunet wrote: >>> Thanks David, >>> >>> I have Xcode 6.1.1 and configure fails with "Could not find freetype! >>> These sites >>> http://blog.shelan.org/2015/03/how-to-build-open-jdk-9-on-mac-osx.html >>> http://gvsmirnov.ru/blog/tech/2014/02/07/building-openjdk-8-on-osx-maverick.html >>> say to install XQuartz, but that didn't help. BTW, My OS is Mavericks. >>> >>> If it matters I have not yet moved Xcode out of /Applications. >>> >>> Pete >>> >>> On 5/6/15 11:11 AM, David DeHaven wrote: >>>> Correct, --with-xcode-path is for jdk8u only as it requires building with Xcode 4. For jdk9 use the Xcode 5.1 or later. >>>> >>>> The Xcode 6.3 patch is in hotspot, it will be integrated to dev hopefully in the near future. In the meantime you can apply the patch to your local workspace. >>>> >>>> Or, if you have an ADC account, you should be able to download Xcode 6.1 or 6.2 (listed in the "other" downloads). Just install it somewhere besides /Applications or the Mac App Store will try to auto-update it for you. Once installed, just use "sudo xcode-select --switch /path/to/Xcode-6.2.app" to use it. >>>> >>>> -DrD- >>>> >>>>> Maybe it's because now I am using the 9 repo: >>>>> >>>>> $ bash ./configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>>>> 2>&1 | tee configure.log >>>>> Running generated-configure.sh >>>>> configure: error: unrecognized options: --with-xcode-path >>>>> configure exiting with result code 1 >>>>> >>>>> On 5/6/15 7:51 AM, Vadim Pakhnushev wrote: >>>>>> Hi Pete, >>>>>> >>>>>> How is that? >>>>>> I haven't tried this lately, but I just pulled 8u-dev sources and the >>>>>> option is there: >>>>>> >>>>>> $ sh configure --help >>>>>> .... >>>>>> --with-xcode-path explicit path to Xcode 4 (generally for >>>>>> building on >>>>>> 10.9 and later) >>>>>> >>>>>> Thanks, >>>>>> Vadim >>>>>> >>>>>> On 06.05.2015 15:39, Pete Brunet wrote: >>>>>>> Hi Vadim, I had to defer from this for a while but am back at it. >>>>>>> >>>>>>> Apparently --with-xcode-path isn't currently a valid option. >>>>>>> >>>>>>> Pete >>>>>>> >>>>>>> On 4/7/15 10:22 AM, Vadim Pakhnushev wrote: >>>>>>>> Pete, have you tried >>>>>>>> sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/ >>>>>>>> ? >>>>>>>> It seems that the configure doesn't pick the correct path from the >>>>>>>> xcode-select. >>>>>>>> Although I successfully built jdk8u on 10.10 with both xcode-select >>>>>>>> and --with-xcode-path >>>>>>>> BTW, the correct path for xcode-select would be /Applications/Xcode\ >>>>>>>> 4.6.3.app/Contents/Developer I guess. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vadim >>>>>>>> >>>>>>>> On 07.04.2015 15:56, Pete Brunet wrote: >>>>>>>>> Hi, I need some help so I can build on MacOSX to fix a build break. >>>>>>>>> >>>>>>>>> First since I had Xcode 6.1.1 and configure complained that I didn't >>>>>>>>> have v4 I installed v4.6.3. After installing 4.6.3 and doing >>>>>>>>> sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/ >>>>>>>>> I got past that. Then for some reason my compile environment is now >>>>>>>>> bad. I get >>>>>>>>> >>>>>>>>> ... >>>>>>>>> configure:20476: checking for C compiler version >>>>>>>>> configure:20485: /usr/bin/gcc --version >&5 >>>>>>>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. >>>>>>>>> build >>>>>>>>> 5658) (LLVM build 2336.11.00) >>>>>>>>> Copyright (C) 2007 Free Software Foundation, Inc. >>>>>>>>> This is free software; see the source for copying conditions. There >>>>>>>>> is NO >>>>>>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>>>>>>>> PURPOSE. >>>>>>>>> >>>>>>>>> configure:20496: $? = 0 >>>>>>>>> configure:20485: /usr/bin/gcc -v >&5 >>>>>>>>> Using built-in specs. >>>>>>>>> Target: i686-apple-darwin11 >>>>>>>>> Configured with: >>>>>>>>> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure >>>>>>>>> --disable-checking --enable-werror >>>>>>>>> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 >>>>>>>>> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ >>>>>>>>> --program-prefix=llvm- >>>>>>>>> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ >>>>>>>>> --with-slibdir=/usr/lib --build=i686-apple-darwin11 >>>>>>>>> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local >>>>>>>>> >>>>>>>>> >>>>>>>>> --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 >>>>>>>>> --target=i686-apple-darwin11 >>>>>>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1 >>>>>>>>> Thread model: posix >>>>>>>>> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build >>>>>>>>> 2336.11.00) >>>>>>>>> configure:20496: $? = 0 >>>>>>>>> configure:20485: /usr/bin/gcc -V >&5 >>>>>>>>> llvm-gcc-4.2: argument to `-V' is missing >>>>>>>>> configure:20496: $? = 1 >>>>>>>>> configure:20485: /usr/bin/gcc -qversion >&5 >>>>>>>>> i686-apple-darwin11-llvm-gcc-4.2: no input files >>>>>>>>> configure:20496: $? = 1 >>>>>>>>> configure:20516: checking whether the C compiler works >>>>>>>>> configure:20538: /usr/bin/gcc conftest.c >&5 >>>>>>>>> ld: library not found for -lcrt1.10.6.o >>>>>>>>> collect2: ld returned 1 exit status >>>>>>>>> ... >>>>>>>>> >>>>>>>>> Trying find from the root: >>>>>>>>> find . -name crt1\* >>>>>>>>> >>>>>>>>> ... >>>>>>>>> ./Applications/Xcode >>>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode >>>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode >>>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode >>>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode >>>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode >>>>>>>>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode >>>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode >>>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode >>>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode >>>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode >>>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode >>>>>>>>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o >>>>>>>>> >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> Xcode.app above is v6.1.1. I am on OS X 10.9.5 and notice that for >>>>>>>>> 10.9 >>>>>>>>> I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3. >>>>>>>>> >>>>>>>>> Pete > From serguei.spitsyn at oracle.com Wed May 6 22:06:10 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 06 May 2015 15:06:10 -0700 Subject: RFR: 8079360 AttachProviderImpl could not be instantiated In-Reply-To: <64EEA73D-FF3A-4868-8F93-530D419A7D04@oracle.com> References: <64EEA73D-FF3A-4868-8F93-530D419A7D04@oracle.com> Message-ID: <554A9052.6010709@oracle.com> Looks good. Thanks, Serguei On 5/6/15 11:51 AM, Staffan Larsen wrote: > This is another library that needs to be compiled with > -DPSAPI_VERSION=1 due to the recent Windows compiler upgrade. > > I have also fixed a better error message that prints the underlaying > exception if something like this happens again. > > webrev: http://cr.openjdk.java.net/~sla/8079360/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8079360 > > Thanks, > /Staffan > From magnus.ihse.bursie at oracle.com Thu May 7 07:08:30 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 7 May 2015 09:08:30 +0200 Subject: RFR: 8079360 AttachProviderImpl could not be instantiated In-Reply-To: <64EEA73D-FF3A-4868-8F93-530D419A7D04@oracle.com> References: <64EEA73D-FF3A-4868-8F93-530D419A7D04@oracle.com> Message-ID: <9E353370-E0C9-43F0-8A76-398FE0F1E82F@oracle.com> Build changes look good to me. /Magnus > 6 maj 2015 kl. 20:51 skrev Staffan Larsen : > > This is another library that needs to be compiled with -DPSAPI_VERSION=1 due to the recent Windows compiler upgrade. > > I have also fixed a better error message that prints the underlaying exception if something like this happens again. > > webrev: http://cr.openjdk.java.net/~sla/8079360/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8079360 > > Thanks, > /Staffan > From erik.joelsson at oracle.com Thu May 7 08:02:12 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 07 May 2015 10:02:12 +0200 Subject: RFR: 8079360 AttachProviderImpl could not be instantiated In-Reply-To: <64EEA73D-FF3A-4868-8F93-530D419A7D04@oracle.com> References: <64EEA73D-FF3A-4868-8F93-530D419A7D04@oracle.com> Message-ID: <554B1C04.2020709@oracle.com> Looks good to me. /Erik On 2015-05-06 20:51, Staffan Larsen wrote: > This is another library that needs to be compiled with -DPSAPI_VERSION=1 due to the recent Windows compiler upgrade. > > I have also fixed a better error message that prints the underlaying exception if something like this happens again. > > webrev: http://cr.openjdk.java.net/~sla/8079360/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8079360 > > Thanks, > /Staffan > From asmundak at google.com Fri May 8 02:46:53 2015 From: asmundak at google.com (Alexander Smundak) Date: Thu, 7 May 2015 19:46:53 -0700 Subject: Backport multiple toolchains support to JDK8? Message-ID: I have backported "8034788: Rewrite toolchain.m4 to support multiple toolchains per platform." and related changes to jdk8u40 in order to build JDK8 with Clang/LLVM on Linux. Can I mail this change for the review? Sasha From magnus.ihse.bursie at oracle.com Fri May 8 07:18:44 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 08 May 2015 09:18:44 +0200 Subject: RFR: JDK-8079771 Fix SoundLibraries.gmk mismerge after JDK-8072665 Message-ID: <554C6354.8040204@oracle.com> The merge changeset c892d81d7bba unfortunately re-introduced the X_ARCH define for aarch64, even though JDK-8072665 had removed it. Bug: https://bugs.openjdk.java.net/browse/JDK-8079771 WebRev inline: diff --git a/make/lib/SoundLibraries.gmk b/make/lib/SoundLibraries.gmk --- a/make/lib/SoundLibraries.gmk +++ b/make/lib/SoundLibraries.gmk @@ -113,10 +113,6 @@ LIBJSOUND_SRC_FILES += $(LIBJSOUND_DAUDIOFILES) endif # OPENJDK_TARGET_OS solaris - - ifeq ($(OPENJDK_TARGET_CPU), aarch64) - LIBJSOUND_CFLAGS += -DX_ARCH=X_AARCH64 - endif LIBJSOUND_CFLAGS += -DEXTRA_SOUND_JNI_LIBS='"$(EXTRA_SOUND_JNI_LIBS)"' $(eval $(call SetupNativeCompilation,BUILD_LIBJSOUND, \ /Magnus From david.holmes at oracle.com Fri May 8 07:34:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 May 2015 17:34:51 +1000 Subject: RFR: JDK-8079771 Fix SoundLibraries.gmk mismerge after JDK-8072665 In-Reply-To: <554C6354.8040204@oracle.com> References: <554C6354.8040204@oracle.com> Message-ID: <554C671B.5060306@oracle.com> Hi Magnus, On 8/05/2015 5:18 PM, Magnus Ihse Bursie wrote: > The merge changeset c892d81d7bba unfortunately re-introduced the X_ARCH > define for aarch64, even though JDK-8072665 had removed it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079771 > WebRev inline: > > diff --git a/make/lib/SoundLibraries.gmk b/make/lib/SoundLibraries.gmk > --- a/make/lib/SoundLibraries.gmk > +++ b/make/lib/SoundLibraries.gmk > @@ -113,10 +113,6 @@ > LIBJSOUND_SRC_FILES += $(LIBJSOUND_DAUDIOFILES) > endif # OPENJDK_TARGET_OS solaris > > - > - ifeq ($(OPENJDK_TARGET_CPU), aarch64) > - LIBJSOUND_CFLAGS += -DX_ARCH=X_AARCH64 > - endif > LIBJSOUND_CFLAGS += -DEXTRA_SOUND_JNI_LIBS='"$(EXTRA_SOUND_JNI_LIBS)"' > > $(eval $(call SetupNativeCompilation,BUILD_LIBJSOUND, \ Looks okay. This should also be removed: ./java.desktop/share/native/libjsound/SoundDefs.h:#define X_AARCH64 9 Cheers, David > /Magnus From erik.joelsson at oracle.com Fri May 8 07:38:05 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 08 May 2015 09:38:05 +0200 Subject: RFR: JDK-8079771 Fix SoundLibraries.gmk mismerge after JDK-8072665 In-Reply-To: <554C671B.5060306@oracle.com> References: <554C6354.8040204@oracle.com> <554C671B.5060306@oracle.com> Message-ID: <554C67DD.3080500@oracle.com> With Davids addition, this looks good to me. /Erik On 2015-05-08 09:34, David Holmes wrote: > Hi Magnus, > > On 8/05/2015 5:18 PM, Magnus Ihse Bursie wrote: >> The merge changeset c892d81d7bba unfortunately re-introduced the X_ARCH >> define for aarch64, even though JDK-8072665 had removed it. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8079771 >> WebRev inline: >> >> diff --git a/make/lib/SoundLibraries.gmk b/make/lib/SoundLibraries.gmk >> --- a/make/lib/SoundLibraries.gmk >> +++ b/make/lib/SoundLibraries.gmk >> @@ -113,10 +113,6 @@ >> LIBJSOUND_SRC_FILES += $(LIBJSOUND_DAUDIOFILES) >> endif # OPENJDK_TARGET_OS solaris >> >> - >> - ifeq ($(OPENJDK_TARGET_CPU), aarch64) >> - LIBJSOUND_CFLAGS += -DX_ARCH=X_AARCH64 >> - endif >> LIBJSOUND_CFLAGS += -DEXTRA_SOUND_JNI_LIBS='"$(EXTRA_SOUND_JNI_LIBS)"' >> >> $(eval $(call SetupNativeCompilation,BUILD_LIBJSOUND, \ > > Looks okay. > > This should also be removed: > > ./java.desktop/share/native/libjsound/SoundDefs.h:#define > X_AARCH64 9 > > Cheers, > David > > >> /Magnus From magnus.ihse.bursie at oracle.com Fri May 8 07:43:48 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 08 May 2015 09:43:48 +0200 Subject: RFR: JDK-8079771 Fix SoundLibraries.gmk mismerge after JDK-8072665 In-Reply-To: <554C671B.5060306@oracle.com> References: <554C6354.8040204@oracle.com> <554C671B.5060306@oracle.com> Message-ID: <554C6934.9080803@oracle.com> On 2015-05-08 09:34, David Holmes wrote: > Hi Magnus, > > On 8/05/2015 5:18 PM, Magnus Ihse Bursie wrote: >> The merge changeset c892d81d7bba unfortunately re-introduced the X_ARCH >> define for aarch64, even though JDK-8072665 had removed it. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8079771 >> WebRev inline: >> >> diff --git a/make/lib/SoundLibraries.gmk b/make/lib/SoundLibraries.gmk >> --- a/make/lib/SoundLibraries.gmk >> +++ b/make/lib/SoundLibraries.gmk >> @@ -113,10 +113,6 @@ >> LIBJSOUND_SRC_FILES += $(LIBJSOUND_DAUDIOFILES) >> endif # OPENJDK_TARGET_OS solaris >> >> - >> - ifeq ($(OPENJDK_TARGET_CPU), aarch64) >> - LIBJSOUND_CFLAGS += -DX_ARCH=X_AARCH64 >> - endif >> LIBJSOUND_CFLAGS += -DEXTRA_SOUND_JNI_LIBS='"$(EXTRA_SOUND_JNI_LIBS)"' >> >> $(eval $(call SetupNativeCompilation,BUILD_LIBJSOUND, \ > > Looks okay. > > This should also be removed: > > ./java.desktop/share/native/libjsound/SoundDefs.h:#define > X_AARCH64 9 Ok, fixed. Thanks. /Magnus From magnus.ihse.bursie at oracle.com Fri May 8 07:57:50 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 08 May 2015 09:57:50 +0200 Subject: RFR: JDK-8074859 Turn on warnings as error In-Reply-To: <5534A475.2090909@oracle.com> References: <55310207.9050207@oracle.com> <5534A475.2090909@oracle.com> Message-ID: <554C6C7E.9000309@oracle.com> On 2015-04-20 09:02, Erik Joelsson wrote: > Looks good to me. Thanks Erik. Unfortunately, I never got round to pushing this. In the meantime, the codebase evolved, and I had to add a couple of more disabled warnings. I also modified the help text on a failed build slightly. Here's the updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors/webrev.01 /Magnus > > /Erik > > On 2015-04-17 14:52, Magnus Ihse Bursie wrote: >> With JDK-8074096, the number of warnings in the product was reduced >> to a minimum. This enables the next step, which is turning on the >> respective compiler flags that turns warnings into errors. In the >> long run, this is the only way to keep the warnings from creeping back. >> >> Even with JDK-8074096, the product does not build 100% warning free. >> This is due to some warnings that cannot be disabled, or (in one >> case) where C and C++ code is mixed, and warnings for both languages >> cannot be used. A system similar to the one introduced in JDK-8074096 >> is therefore needed, in which individual libraries can be exempted >> from this flag, until such warnings are fixed. A library can thus >> disable warnings as errors with WARNINGS_AS_ERRORS := false, or >> (better) use a toolchain-specific version, e.g WARNINGS_AS_ERRORS_gcc >> := false. This is intended as a temporary measure, though. The >> long-term solution is reasonably to fix the warnings and remove that >> argument. >> >> Also, different versions of compilers can generate a different set of >> warnings. It is therefore necessary to be able to turn off this >> globally. Therefor a new flag for configure is introduced: >> --disable-warnings-as-errors. >> >> While the code compiles without errors on the build systems used >> internally at Oracle, this might not be the case on other >> combinations of operating system versions and toolchain versions. To >> facilitate for unexpecting developers, a help message is added if the >> build fails, that suggests using --disable-warnings-as-errors. This >> solution was chosen as a compromise between the "hard core" solution >> of turning on warnings as errors by default for anyone, and the >> cowar... erm, conservative solution of checking if the compiler >> versions exactly match what's used inside Oracle (and therefore >> regularly tested), and only turn it on in that case. >> >> Similarly to JDK-8074096, I intend to file follow-up bugs for each >> individual library that got a WARNINGS_AS_ERRORS_* := false. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074859 >> WebRev for top: >> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-top/webrev.01 >> WebRev for jdk: >> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-jdk/webrev.01 >> >> Some comments: >> >> * I needed to add a few more DISABLED_WARNINGS. For windows, this is >> most likely due to the recent compiler change. For other libraries, >> I'm not sure, but it might well be the result of recent changes that >> has introduced new warnings. If so, it highlights the need of this >> patch to keep the build warning free. >> >> * For a few libraries and toolchains, there is *both* >> WARNINGS_AS_ERRORS := false and a DISABLED_WARNINGS list. This is the >> case if not all warnings are possible to disable. >> >> * I have removed some incorrect uses of SHARED_LIBRARY_FLAGS. This is >> included in our JDK LDFLAGS, so it should not be set separately, and >> definitely not as CFLAGS. (This caused compiler warnings, which now >> turned into errors.) However, a more suitable long-term solution is >> probably to move the knowledge of how to create shared libraries more >> specifically into SetupNativeCompilation, and not set it as part of >> the JDK flags. >> >> /Magnus > From erik.joelsson at oracle.com Fri May 8 08:32:20 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 08 May 2015 10:32:20 +0200 Subject: RFR: JDK-8074859 Turn on warnings as error In-Reply-To: <554C6C7E.9000309@oracle.com> References: <55310207.9050207@oracle.com> <5534A475.2090909@oracle.com> <554C6C7E.9000309@oracle.com> Message-ID: <554C7494.40209@oracle.com> Looks good. /Erik On 2015-05-08 09:57, Magnus Ihse Bursie wrote: > On 2015-04-20 09:02, Erik Joelsson wrote: >> Looks good to me. > Thanks Erik. > > Unfortunately, I never got round to pushing this. In the meantime, the > codebase evolved, and I had to add a couple of more disabled warnings. > I also modified the help text on a failed build slightly. > > Here's the updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors/webrev.01 > > /Magnus > > >> >> /Erik >> >> On 2015-04-17 14:52, Magnus Ihse Bursie wrote: >>> With JDK-8074096, the number of warnings in the product was reduced >>> to a minimum. This enables the next step, which is turning on the >>> respective compiler flags that turns warnings into errors. In the >>> long run, this is the only way to keep the warnings from creeping back. >>> >>> Even with JDK-8074096, the product does not build 100% warning free. >>> This is due to some warnings that cannot be disabled, or (in one >>> case) where C and C++ code is mixed, and warnings for both languages >>> cannot be used. A system similar to the one introduced in >>> JDK-8074096 is therefore needed, in which individual libraries can >>> be exempted from this flag, until such warnings are fixed. A library >>> can thus disable warnings as errors with WARNINGS_AS_ERRORS := >>> false, or (better) use a toolchain-specific version, e.g >>> WARNINGS_AS_ERRORS_gcc := false. This is intended as a temporary >>> measure, though. The long-term solution is reasonably to fix the >>> warnings and remove that argument. >>> >>> Also, different versions of compilers can generate a different set >>> of warnings. It is therefore necessary to be able to turn off this >>> globally. Therefor a new flag for configure is introduced: >>> --disable-warnings-as-errors. >>> >>> While the code compiles without errors on the build systems used >>> internally at Oracle, this might not be the case on other >>> combinations of operating system versions and toolchain versions. To >>> facilitate for unexpecting developers, a help message is added if >>> the build fails, that suggests using --disable-warnings-as-errors. >>> This solution was chosen as a compromise between the "hard core" >>> solution of turning on warnings as errors by default for anyone, and >>> the cowar... erm, conservative solution of checking if the compiler >>> versions exactly match what's used inside Oracle (and therefore >>> regularly tested), and only turn it on in that case. >>> >>> Similarly to JDK-8074096, I intend to file follow-up bugs for each >>> individual library that got a WARNINGS_AS_ERRORS_* := false. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074859 >>> WebRev for top: >>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-top/webrev.01 >>> WebRev for jdk: >>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-jdk/webrev.01 >>> >>> Some comments: >>> >>> * I needed to add a few more DISABLED_WARNINGS. For windows, this is >>> most likely due to the recent compiler change. For other libraries, >>> I'm not sure, but it might well be the result of recent changes that >>> has introduced new warnings. If so, it highlights the need of this >>> patch to keep the build warning free. >>> >>> * For a few libraries and toolchains, there is *both* >>> WARNINGS_AS_ERRORS := false and a DISABLED_WARNINGS list. This is >>> the case if not all warnings are possible to disable. >>> >>> * I have removed some incorrect uses of SHARED_LIBRARY_FLAGS. This >>> is included in our JDK LDFLAGS, so it should not be set separately, >>> and definitely not as CFLAGS. (This caused compiler warnings, which >>> now turned into errors.) However, a more suitable long-term solution >>> is probably to move the knowledge of how to create shared libraries >>> more specifically into SetupNativeCompilation, and not set it as >>> part of the JDK flags. >>> >>> /Magnus >> > From magnus.ihse.bursie at oracle.com Fri May 8 09:00:34 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 08 May 2015 11:00:34 +0200 Subject: Backport multiple toolchains support to JDK8? In-Reply-To: References: Message-ID: <554C7B32.2050000@oracle.com> On 2015-05-08 04:46, Alexander Smundak wrote: > I have backported "8034788: Rewrite toolchain.m4 to support multiple > toolchains per platform." and related changes to jdk8u40 in order to > build JDK8 with Clang/LLVM on Linux. Can I mail this change for the > review? JDK 8u40 is already released. Did you mean 8u60? To get a backport in 8u60 means you need to get approval according to http://openjdk.java.net/projects/jdk8u/groundrules.html. If the backport does not apply cleanly (which I suspect in this case), then you also need a review from the build team. As I understand, 8u60 is already feature complete, and this change in question is quite intrusive. I would not recommend backporting it to 8u60 at this point. /Magnus From asmundak at google.com Fri May 8 16:49:34 2015 From: asmundak at google.com (Alexander Smundak) Date: Fri, 8 May 2015 09:49:34 -0700 Subject: Backport multiple toolchains support to JDK8? In-Reply-To: <554C7B32.2050000@oracle.com> References: <554C7B32.2050000@oracle.com> Message-ID: And I guess the successor of the 8u60 is going to be the last JDK8 release? On Fri, May 8, 2015 at 2:00 AM, Magnus Ihse Bursie wrote: > On 2015-05-08 04:46, Alexander Smundak wrote: >> >> I have backported "8034788: Rewrite toolchain.m4 to support multiple >> toolchains per platform." and related changes to jdk8u40 in order to >> build JDK8 with Clang/LLVM on Linux. Can I mail this change for the >> review? > > > JDK 8u40 is already released. Did you mean 8u60? > > To get a backport in 8u60 means you need to get approval according to > http://openjdk.java.net/projects/jdk8u/groundrules.html. > > If the backport does not apply cleanly (which I suspect in this case), then > you also need a review from the build team. > > As I understand, 8u60 is already feature complete, and this change in > question is quite intrusive. I would not recommend backporting it to 8u60 at > this point. > > /Magnus From tim.bell at oracle.com Sat May 9 04:30:44 2015 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 08 May 2015 21:30:44 -0700 Subject: RFR: JDK-8074859 Turn on warnings as error In-Reply-To: <554C7494.40209@oracle.com> References: <55310207.9050207@oracle.com> <5534A475.2090909@oracle.com> <554C6C7E.9000309@oracle.com> <554C7494.40209@oracle.com> Message-ID: <554D8D74.4030505@oracle.com> Magnus: Looks good to me as well. Tim On 05/08/15 01:32, Erik Joelsson wrote: > Looks good. > > /Erik > > On 2015-05-08 09:57, Magnus Ihse Bursie wrote: >> On 2015-04-20 09:02, Erik Joelsson wrote: >>> Looks good to me. >> Thanks Erik. >> >> Unfortunately, I never got round to pushing this. In the meantime, >> the codebase evolved, and I had to add a couple of more disabled >> warnings. I also modified the help text on a failed build slightly. >> >> Here's the updated webrev: >> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors/webrev.01 >> >> /Magnus >> >> >>> >>> /Erik >>> >>> On 2015-04-17 14:52, Magnus Ihse Bursie wrote: >>>> With JDK-8074096, the number of warnings in the product was reduced >>>> to a minimum. This enables the next step, which is turning on the >>>> respective compiler flags that turns warnings into errors. In the >>>> long run, this is the only way to keep the warnings from creeping >>>> back. >>>> >>>> Even with JDK-8074096, the product does not build 100% warning >>>> free. This is due to some warnings that cannot be disabled, or (in >>>> one case) where C and C++ code is mixed, and warnings for both >>>> languages cannot be used. A system similar to the one introduced in >>>> JDK-8074096 is therefore needed, in which individual libraries can >>>> be exempted from this flag, until such warnings are fixed. A >>>> library can thus disable warnings as errors with WARNINGS_AS_ERRORS >>>> := false, or (better) use a toolchain-specific version, e.g >>>> WARNINGS_AS_ERRORS_gcc := false. This is intended as a temporary >>>> measure, though. The long-term solution is reasonably to fix the >>>> warnings and remove that argument. >>>> >>>> Also, different versions of compilers can generate a different set >>>> of warnings. It is therefore necessary to be able to turn off this >>>> globally. Therefor a new flag for configure is introduced: >>>> --disable-warnings-as-errors. >>>> >>>> While the code compiles without errors on the build systems used >>>> internally at Oracle, this might not be the case on other >>>> combinations of operating system versions and toolchain versions. >>>> To facilitate for unexpecting developers, a help message is added >>>> if the build fails, that suggests using >>>> --disable-warnings-as-errors. This solution was chosen as a >>>> compromise between the "hard core" solution of turning on warnings >>>> as errors by default for anyone, and the cowar... erm, conservative >>>> solution of checking if the compiler versions exactly match what's >>>> used inside Oracle (and therefore regularly tested), and only turn >>>> it on in that case. >>>> >>>> Similarly to JDK-8074096, I intend to file follow-up bugs for each >>>> individual library that got a WARNINGS_AS_ERRORS_* := false. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074859 >>>> WebRev for top: >>>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-top/webrev.01 >>>> WebRev for jdk: >>>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-jdk/webrev.01 >>>> >>>> Some comments: >>>> >>>> * I needed to add a few more DISABLED_WARNINGS. For windows, this >>>> is most likely due to the recent compiler change. For other >>>> libraries, I'm not sure, but it might well be the result of recent >>>> changes that has introduced new warnings. If so, it highlights the >>>> need of this patch to keep the build warning free. >>>> >>>> * For a few libraries and toolchains, there is *both* >>>> WARNINGS_AS_ERRORS := false and a DISABLED_WARNINGS list. This is >>>> the case if not all warnings are possible to disable. >>>> >>>> * I have removed some incorrect uses of SHARED_LIBRARY_FLAGS. This >>>> is included in our JDK LDFLAGS, so it should not be set separately, >>>> and definitely not as CFLAGS. (This caused compiler warnings, which >>>> now turned into errors.) However, a more suitable long-term >>>> solution is probably to move the knowledge of how to create shared >>>> libraries more specifically into SetupNativeCompilation, and not >>>> set it as part of the JDK flags. >>>> >>>> /Magnus >>> >> > From philip.race at oracle.com Sun May 10 02:27:42 2015 From: philip.race at oracle.com (Phil Race) Date: Sat, 09 May 2015 19:27:42 -0700 Subject: RFR: JDK-8079771 Fix SoundLibraries.gmk mismerge after JDK-8072665 In-Reply-To: <554C6354.8040204@oracle.com> References: <554C6354.8040204@oracle.com> Message-ID: <554EC21E.3030500@oracle.com> I guess this was my merge .. I know it was 2 months ago but I do not remember being asked to merge this manually so it looks like an odd auto-merge anomaly as it seemed to get all the other 6 or so cases right. -phil. On 5/8/15 12:18 AM, Magnus Ihse Bursie wrote: > The merge changeset c892d81d7bba unfortunately re-introduced the > X_ARCH define for aarch64, even though JDK-8072665 had removed it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079771 > WebRev inline: > > diff --git a/make/lib/SoundLibraries.gmk b/make/lib/SoundLibraries.gmk > --- a/make/lib/SoundLibraries.gmk > +++ b/make/lib/SoundLibraries.gmk > @@ -113,10 +113,6 @@ > LIBJSOUND_SRC_FILES += $(LIBJSOUND_DAUDIOFILES) > endif # OPENJDK_TARGET_OS solaris > > - > - ifeq ($(OPENJDK_TARGET_CPU), aarch64) > - LIBJSOUND_CFLAGS += -DX_ARCH=X_AARCH64 > - endif > LIBJSOUND_CFLAGS += -DEXTRA_SOUND_JNI_LIBS='"$(EXTRA_SOUND_JNI_LIBS)"' > > $(eval $(call SetupNativeCompilation,BUILD_LIBJSOUND, \ > > /Magnus From magnus.ihse.bursie at oracle.com Mon May 11 07:49:12 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 11 May 2015 09:49:12 +0200 Subject: RFR: JDK-8079771 Fix SoundLibraries.gmk mismerge after JDK-8072665 In-Reply-To: <554EC21E.3030500@oracle.com> References: <554C6354.8040204@oracle.com> <554EC21E.3030500@oracle.com> Message-ID: <55505EF8.2090002@oracle.com> On 2015-05-10 04:27, Phil Race wrote: > I guess this was my merge .. I know it was 2 months ago but > I do not remember being asked to merge this manually so it > looks like an odd auto-merge anomaly as it seemed to get > all the other 6 or so cases right. Merges of code you haven't written yourself can be bitches sometimes. :-/ When I'm really paranoid I never trust the automerge but manually re-checks all files. But that really only works if you know exactly what you're looking at (and for). /Magnus From magnus.ihse.bursie at oracle.com Mon May 11 09:05:00 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 11 May 2015 11:05:00 +0200 Subject: RFR: JDK-8079891 Store configure log in $BUILD/configure.log Message-ID: <555070BC.40109@oracle.com> It is trivial to save the log file of configure in the build output directory. We should do that. I also noted that the repeat of warnings at the end of the configure run had stopped working since we moved config.log to configure-support. (Also, it was incorrectly indented.) I fixed this as well. After a successful configure run, build/$BUILD/configure.log will be created, and contain exactly what was printed to stdout/stderr during the configure execution. In case of a repeated run of configure, the old log will be rotated to configure.log.old before being deleted, similar to how build.log works. If configure fails before completion, the configure.log file will be left in the current directory -- same as the current autoconf artifacts. This code utilized the functionality already present for the flag --debug-configure. This means that this flag slightly changes meaning. It will log configure output as before, but to the new name (configure.log). The only effect of this flag now is to change the "debug level" of configure. Bug: https://bugs.openjdk.java.net/browse/JDK-8079891 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8079891-save-configure-log/webrev.01 /Magnus From erik.joelsson at oracle.com Mon May 11 09:15:26 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 May 2015 11:15:26 +0200 Subject: RFR: JDK-8079891 Store configure log in $BUILD/configure.log In-Reply-To: <555070BC.40109@oracle.com> References: <555070BC.40109@oracle.com> Message-ID: <5550732E.5090401@oracle.com> Looks good to me. /Erik On 2015-05-11 11:05, Magnus Ihse Bursie wrote: > It is trivial to save the log file of configure in the build output > directory. We should do that. > > I also noted that the repeat of warnings at the end of the configure > run had stopped working since we moved config.log to > configure-support. (Also, it was incorrectly indented.) I fixed this > as well. > > After a successful configure run, build/$BUILD/configure.log will be > created, and contain exactly what was printed to stdout/stderr during > the configure execution. In case of a repeated run of configure, the > old log will be rotated to configure.log.old before being deleted, > similar to how build.log works. If configure fails before completion, > the configure.log file will be left in the current directory -- same > as the current autoconf artifacts. > > This code utilized the functionality already present for the flag > --debug-configure. This means that this flag slightly changes meaning. > It will log configure output as before, but to the new name > (configure.log). The only effect of this flag now is to change the > "debug level" of configure. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079891 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8079891-save-configure-log/webrev.01 > > /Magnus From pujarimahesh_kumar at yahoo.com Mon May 11 09:47:26 2015 From: pujarimahesh_kumar at yahoo.com (Mahesh Pujari) Date: Mon, 11 May 2015 09:47:26 +0000 (UTC) Subject: Issues with dtrace enabled in OpenJdk 9 Message-ID: <492026430.450025.1431337646786.JavaMail.yahoo@mail.yahoo.com> Hi all, I am trying make OpenJdk 9 with dtrace enabled, on my Ubuntu machine (installed with https://github.com/dtrace4linux/linux), with configuration as below (and I am noob). ./configure --enable-option-checking=fatal --with-debug-level=slowdebug --with-target-bits=64 --disable-zip-debug-info --with-boot-jdk=/mnt/ubuntu/setup/jdk1.8.0 CFLAGS=-DDTRACE_ENABLED=1 --with-extra-cflags=-D_DTRACE_VERSION=1 Below is my system info (using uname -a)Linux PHP0045 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux When I do "make all", I end up in error as below... ... vmThread.o: In function `VMOperationQueue::add(VM_Operation*)': /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:156: undefined reference to `__dtrace_hotspot___vmops__request' vmThread.o: In function `VMThread::evaluate_operation(VM_Operation*)': /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:354: undefined reference to `__dtrace_hotspot___vmops__begin' /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:374: undefined reference to `__dtrace_hotspot___vmops__end'...... Can some one direct me about what I might be missing. Can we actually build dtrace with enabled on Ubuntu, if not what other way I can do tracing (may be using systemtap, any pointers please). Am I on right track? (please direct). thanks and regards,Mahesh Pujari From erik.joelsson at oracle.com Mon May 11 10:23:51 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 May 2015 12:23:51 +0200 Subject: Issues with dtrace enabled in OpenJdk 9 In-Reply-To: <492026430.450025.1431337646786.JavaMail.yahoo@mail.yahoo.com> References: <492026430.450025.1431337646786.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55508337.4090405@oracle.com> Hello, I don't have any experience building with dtrace support, but the Hotspot makefiles seem to imply that it can be achieved by running: make DTRACE_ENABLED=true That variable will trigger the appropriate preprocessor flags to be added at least. See hotspot/make/linux/makefiles/dtrace.make. The jdk libraries do not support dtrace AFAIK. /Erik On 2015-05-11 11:47, Mahesh Pujari wrote: > Hi all, > I am trying make OpenJdk 9 with dtrace enabled, on my Ubuntu machine (installed with https://github.com/dtrace4linux/linux), with configuration as below (and I am noob). > ./configure --enable-option-checking=fatal --with-debug-level=slowdebug --with-target-bits=64 --disable-zip-debug-info --with-boot-jdk=/mnt/ubuntu/setup/jdk1.8.0 CFLAGS=-DDTRACE_ENABLED=1 --with-extra-cflags=-D_DTRACE_VERSION=1 > > Below is my system info (using uname -a)Linux PHP0045 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > When I do "make all", I end up in error as below... > ... > vmThread.o: In function `VMOperationQueue::add(VM_Operation*)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:156: undefined reference to `__dtrace_hotspot___vmops__request' > vmThread.o: In function `VMThread::evaluate_operation(VM_Operation*)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:354: undefined reference to `__dtrace_hotspot___vmops__begin' > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:374: undefined reference to `__dtrace_hotspot___vmops__end'...... > > Can some one direct me about what I might be missing. Can we actually build dtrace with enabled on Ubuntu, if not what other way I can do tracing (may be using systemtap, any pointers please). Am I on right track? (please direct). > > > thanks and regards,Mahesh Pujari From sundararajan.athijegannathan at oracle.com Mon May 11 10:47:46 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 11 May 2015 16:17:46 +0530 Subject: RFR 8079900: javadoc is missing for jdk.nashorn.api.tree package Message-ID: <555088D2.3070608@oracle.com> Please review fix for http://cr.openjdk.java.net/~sundar/8079900/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8079900#comment-13640520 Note that jdk.nashorn.api.tree is part of nashorn API as specified by Nashorn Parser API JEP http://openjdk.java.net/jeps/236 Thanks, -Sundar From pujarimahesh_kumar at yahoo.com Mon May 11 10:51:52 2015 From: pujarimahesh_kumar at yahoo.com (Mahesh Pujari) Date: Mon, 11 May 2015 10:51:52 +0000 (UTC) Subject: Issues with dtrace enabled in OpenJdk 9 In-Reply-To: <55508337.4090405@oracle.com> References: <55508337.4090405@oracle.com> Message-ID: <453340897.459724.1431341512645.JavaMail.yahoo@mail.yahoo.com> Thanks for replying back Erik. I ran as you stated i.e. using "make DTRACE_ENABLED=true" but then I realized that the configure that I was running would do the same i.e. by having CFLAGS=-DDTRACE_ENABLED=1. When I make (using your approach and passing enable in configure), I end up with lots and lots of "undefined reference to" errors during make, seems I am missing something, below are some error from build.logs. classLoadingService.o: In function `ClassLoadingService::notify_class_unloaded(InstanceKlass*)': /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119: undefined reference to `__dtrace_hotspot___class__unloaded' classLoadingService.o: In function `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144: undefined reference to `__dtrace_hotspot___class__loaded' compileBroker.o: In function `CompileBroker::invoke_compiler_on_method(CompileTask*)': /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: undefined reference to `__dtrace_hotspot___method__compile__begin' /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:2028: undefined reference to `__dtrace_hotspot___method__compile__end' thanks and regards,Mahesh Pujari On Monday, May 11, 2015 3:53 PM, Erik Joelsson wrote: Hello, I don't have any experience building with dtrace support, but the Hotspot makefiles seem to imply that it can be achieved by running: make DTRACE_ENABLED=true That variable will trigger the appropriate preprocessor flags to be added at least. See hotspot/make/linux/makefiles/dtrace.make. The jdk libraries do not support dtrace AFAIK. /Erik On 2015-05-11 11:47, Mahesh Pujari wrote: > Hi all, > I am trying make OpenJdk 9 with dtrace enabled, on my Ubuntu machine (installed with https://github.com/dtrace4linux/linux), with configuration as below (and I am noob). > ./configure --enable-option-checking=fatal --with-debug-level=slowdebug --with-target-bits=64 --disable-zip-debug-info --with-boot-jdk=/mnt/ubuntu/setup/jdk1.8.0 CFLAGS=-DDTRACE_ENABLED=1 --with-extra-cflags=-D_DTRACE_VERSION=1 > > Below is my system info (using uname -a)Linux PHP0045 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > When I do "make all", I end up in error as below... > ... > vmThread.o: In function `VMOperationQueue::add(VM_Operation*)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:156: undefined reference to `__dtrace_hotspot___vmops__request' > vmThread.o: In function `VMThread::evaluate_operation(VM_Operation*)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:354: undefined reference to `__dtrace_hotspot___vmops__begin' > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:374: undefined reference to `__dtrace_hotspot___vmops__end'...... > > Can some one direct me about what I might be missing. Can we actually build dtrace with enabled on Ubuntu, if not what other way I can do tracing (may be using systemtap, any pointers please). Am I on right track? (please direct). > > > thanks and regards,Mahesh Pujari From marcus.lagergren at oracle.com Mon May 11 10:55:46 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 11 May 2015 12:55:46 +0200 Subject: RFR 8079900: javadoc is missing for jdk.nashorn.api.tree package In-Reply-To: <555088D2.3070608@oracle.com> References: <555088D2.3070608@oracle.com> Message-ID: +1 > On 11 May 2015, at 12:47, A. Sundararajan wrote: > > Please review fix for http://cr.openjdk.java.net/~sundar/8079900/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8079900#comment-13640520 > > Note that jdk.nashorn.api.tree is part of nashorn API as specified by Nashorn Parser API JEP http://openjdk.java.net/jeps/236 > > Thanks, > -Sundar From erik.joelsson at oracle.com Mon May 11 11:00:28 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 May 2015 13:00:28 +0200 Subject: RFR 8079900: javadoc is missing for jdk.nashorn.api.tree package In-Reply-To: References: <555088D2.3070608@oracle.com> Message-ID: <55508BCC.1050804@oracle.com> Looks good to me. /Erik On 2015-05-11 12:55, Marcus Lagergren wrote: > +1 > >> On 11 May 2015, at 12:47, A. Sundararajan wrote: >> >> Please review fix for http://cr.openjdk.java.net/~sundar/8079900/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8079900#comment-13640520 >> >> Note that jdk.nashorn.api.tree is part of nashorn API as specified by Nashorn Parser API JEP http://openjdk.java.net/jeps/236 >> >> Thanks, >> -Sundar From Roger.Riggs at Oracle.com Mon May 11 11:02:31 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 11 May 2015 07:02:31 -0400 Subject: RFR: JDK-8079891 Store configure log in $BUILD/configure.log In-Reply-To: <555070BC.40109@oracle.com> References: <555070BC.40109@oracle.com> Message-ID: <55508C47.108@Oracle.com> Hi, Great to see the log output to a file. I don't find the blast of trivial output from configure to be useful. It would be a separate change, but can the output be limited to just error and warnings or only the notable intermediate results. $.02, Roger On 5/11/2015 5:05 AM, Magnus Ihse Bursie wrote: > It is trivial to save the log file of configure in the build output > directory. We should do that. > > I also noted that the repeat of warnings at the end of the configure > run had stopped working since we moved config.log to > configure-support. (Also, it was incorrectly indented.) I fixed this > as well. > > After a successful configure run, build/$BUILD/configure.log will be > created, and contain exactly what was printed to stdout/stderr during > the configure execution. In case of a repeated run of configure, the > old log will be rotated to configure.log.old before being deleted, > similar to how build.log works. If configure fails before completion, > the configure.log file will be left in the current directory -- same > as the current autoconf artifacts. > > This code utilized the functionality already present for the flag > --debug-configure. This means that this flag slightly changes meaning. > It will log configure output as before, but to the new name > (configure.log). The only effect of this flag now is to change the > "debug level" of configure. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079891 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8079891-save-configure-log/webrev.01 > > /Magnus From david.holmes at oracle.com Mon May 11 11:21:09 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 May 2015 21:21:09 +1000 Subject: Issues with dtrace enabled in OpenJdk 9 In-Reply-To: <453340897.459724.1431341512645.JavaMail.yahoo@mail.yahoo.com> References: <55508337.4090405@oracle.com> <453340897.459724.1431341512645.JavaMail.yahoo@mail.yahoo.com> Message-ID: <555090A5.4070207@oracle.com> On 11/05/2015 8:51 PM, Mahesh Pujari wrote: > Thanks for replying back Erik. > I ran as you stated i.e. using "make DTRACE_ENABLED=true" but then I realized that the configure that I was running would do the same i.e. by having CFLAGS=-DDTRACE_ENABLED=1. No it isn't the same. The linux/makefiles/dtrace.make looks for DTRACE_ENABLED and will define additional targets if it is set, as well as setting -DDTRACE_ENABLED. If you just set the define then you miss other things. But that aside you don't set DTRACE_ENABLED either. dtrace will be enabled if the SDT header file is found. If you just do a build without trying to force dtrace on what does the log show? David ----- > When I make (using your approach and passing enable in configure), I end up with lots and lots of "undefined reference to" errors during make, seems I am missing something, below are some error from build.logs. > classLoadingService.o: In function `ClassLoadingService::notify_class_unloaded(InstanceKlass*)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119: undefined reference to `__dtrace_hotspot___class__unloaded' > classLoadingService.o: In function `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144: undefined reference to `__dtrace_hotspot___class__loaded' > compileBroker.o: In function `CompileBroker::invoke_compiler_on_method(CompileTask*)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: undefined reference to `__dtrace_hotspot___method__compile__begin' > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:2028: undefined reference to `__dtrace_hotspot___method__compile__end' > > thanks and regards,Mahesh Pujari > > > > On Monday, May 11, 2015 3:53 PM, Erik Joelsson wrote: > > > Hello, > > I don't have any experience building with dtrace support, but the > Hotspot makefiles seem to imply that it can be achieved by running: > > make DTRACE_ENABLED=true > > That variable will trigger the appropriate preprocessor flags to be > added at least. See hotspot/make/linux/makefiles/dtrace.make. > > The jdk libraries do not support dtrace AFAIK. > > /Erik > > On 2015-05-11 11:47, Mahesh Pujari wrote: >> Hi all, >> I am trying make OpenJdk 9 with dtrace enabled, on my Ubuntu machine (installed with https://github.com/dtrace4linux/linux), with configuration as below (and I am noob). >> ./configure --enable-option-checking=fatal --with-debug-level=slowdebug --with-target-bits=64 --disable-zip-debug-info --with-boot-jdk=/mnt/ubuntu/setup/jdk1.8.0 CFLAGS=-DDTRACE_ENABLED=1 --with-extra-cflags=-D_DTRACE_VERSION=1 >> >> Below is my system info (using uname -a)Linux PHP0045 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> >> When I do "make all", I end up in error as below... >> ... >> vmThread.o: In function `VMOperationQueue::add(VM_Operation*)': >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:156: undefined reference to `__dtrace_hotspot___vmops__request' >> vmThread.o: In function `VMThread::evaluate_operation(VM_Operation*)': >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:354: undefined reference to `__dtrace_hotspot___vmops__begin' >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:374: undefined reference to `__dtrace_hotspot___vmops__end'...... >> >> Can some one direct me about what I might be missing. Can we actually build dtrace with enabled on Ubuntu, if not what other way I can do tracing (may be using systemtap, any pointers please). Am I on right track? (please direct). >> >> >> thanks and regards,Mahesh Pujari > > > > > From staffan.larsen at oracle.com Mon May 11 11:38:13 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 11 May 2015 13:38:13 +0200 Subject: Issues with dtrace enabled in OpenJdk 9 In-Reply-To: <555090A5.4070207@oracle.com> References: <55508337.4090405@oracle.com> <453340897.459724.1431341512645.JavaMail.yahoo@mail.yahoo.com> <555090A5.4070207@oracle.com> Message-ID: Note that SDT and dtrace4linux are different things. As far as I know, no one has tried dtrace4linux with Hotspot so you are in uncharted territories. SDT should work (if installed). Oracle Linux also has an implementation of Dtrace that I think is different from dtrace4linux. This is also untested. /Staffan > On 11 maj 2015, at 13:21, David Holmes wrote: > > On 11/05/2015 8:51 PM, Mahesh Pujari wrote: >> Thanks for replying back Erik. >> I ran as you stated i.e. using "make DTRACE_ENABLED=true" but then I realized that the configure that I was running would do the same i.e. by having CFLAGS=-DDTRACE_ENABLED=1. > > No it isn't the same. The linux/makefiles/dtrace.make looks for DTRACE_ENABLED and will define additional targets if it is set, as well as setting -DDTRACE_ENABLED. If you just set the define then you miss other things. > > But that aside you don't set DTRACE_ENABLED either. dtrace will be enabled if the SDT header file is found. If you just do a build without trying to force dtrace on what does the log show? > > David > ----- > >> When I make (using your approach and passing enable in configure), I end up with lots and lots of "undefined reference to" errors during make, seems I am missing something, below are some error from build.logs. >> classLoadingService.o: In function `ClassLoadingService::notify_class_unloaded(InstanceKlass*)': >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119: undefined reference to `__dtrace_hotspot___class__unloaded' >> classLoadingService.o: In function `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144: undefined reference to `__dtrace_hotspot___class__loaded' >> compileBroker.o: In function `CompileBroker::invoke_compiler_on_method(CompileTask*)': >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: undefined reference to `__dtrace_hotspot___method__compile__begin' >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:2028: undefined reference to `__dtrace_hotspot___method__compile__end' >> >> thanks and regards,Mahesh Pujari >> >> >> >> On Monday, May 11, 2015 3:53 PM, Erik Joelsson wrote: >> >> >> Hello, >> >> I don't have any experience building with dtrace support, but the >> Hotspot makefiles seem to imply that it can be achieved by running: >> >> make DTRACE_ENABLED=true >> >> That variable will trigger the appropriate preprocessor flags to be >> added at least. See hotspot/make/linux/makefiles/dtrace.make. >> >> The jdk libraries do not support dtrace AFAIK. >> >> /Erik >> >> On 2015-05-11 11:47, Mahesh Pujari wrote: >>> Hi all, >>> I am trying make OpenJdk 9 with dtrace enabled, on my Ubuntu machine (installed with https://github.com/dtrace4linux/linux), with configuration as below (and I am noob). >>> ./configure --enable-option-checking=fatal --with-debug-level=slowdebug --with-target-bits=64 --disable-zip-debug-info --with-boot-jdk=/mnt/ubuntu/setup/jdk1.8.0 CFLAGS=-DDTRACE_ENABLED=1 --with-extra-cflags=-D_DTRACE_VERSION=1 >>> >>> Below is my system info (using uname -a)Linux PHP0045 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>> >>> When I do "make all", I end up in error as below... >>> ... >>> vmThread.o: In function `VMOperationQueue::add(VM_Operation*)': >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:156: undefined reference to `__dtrace_hotspot___vmops__request' >>> vmThread.o: In function `VMThread::evaluate_operation(VM_Operation*)': >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:354: undefined reference to `__dtrace_hotspot___vmops__begin' >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:374: undefined reference to `__dtrace_hotspot___vmops__end'...... >>> >>> Can some one direct me about what I might be missing. Can we actually build dtrace with enabled on Ubuntu, if not what other way I can do tracing (may be using systemtap, any pointers please). Am I on right track? (please direct). >>> >>> >>> thanks and regards,Mahesh Pujari >> >> >> >> >> From magnus.ihse.bursie at oracle.com Mon May 11 11:41:55 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 11 May 2015 13:41:55 +0200 Subject: RFR: JDK-8079891 Store configure log in $BUILD/configure.log In-Reply-To: <55508C47.108@Oracle.com> References: <555070BC.40109@oracle.com> <55508C47.108@Oracle.com> Message-ID: <55509583.2080903@oracle.com> On 2015-05-11 13:02, Roger Riggs wrote: > Hi, > > Great to see the log output to a file. > > I don't find the blast of trivial output from configure to be useful. > It would be a separate change, but can the output be limited to just > error and warnings or only the notable intermediate results. Unfortunately, this is not easily changed, since it is a result of the (highly inflexible :-() autoconf framework we're dependent on. /Magnus From magnus.ihse.bursie at oracle.com Mon May 11 12:05:57 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 11 May 2015 14:05:57 +0200 Subject: RFR: JDK-8080013 OpenJDK windows build fails due to warning in libfontmanager Message-ID: <55509B25.4040205@oracle.com> JDK-8074859, which turns on warnings-as-errors, unfortunately was not properly tested with open-only, just the Oracle closed build. An extra warning present in freetype2 code causes the build to fail. Bug: https://bugs.openjdk.java.net/browse/JDK-8080013 WebRev inline: diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -653,7 +653,7 @@ DISABLED_WARNINGS_clang := unused-value incompatible-pointer-types \ tautological-constant-out-of-range-compare int-to-pointer-cast, \ DISABLED_WARNINGS_solstudio := truncwarn, \ - DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996, \ + DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146, \ WARNINGS_AS_ERRORS_gcc := false, \ WARNINGS_AS_ERRORS_solstudio := false, \ MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \ /Magnus From erik.joelsson at oracle.com Mon May 11 12:13:30 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 May 2015 14:13:30 +0200 Subject: RFR: JDK-8080013 OpenJDK windows build fails due to warning in libfontmanager In-Reply-To: <55509B25.4040205@oracle.com> References: <55509B25.4040205@oracle.com> Message-ID: <55509CEA.3080607@oracle.com> Looks good to me. /Erik On 2015-05-11 14:05, Magnus Ihse Bursie wrote: > JDK-8074859, which turns on warnings-as-errors, unfortunately was not > properly tested with open-only, just the Oracle closed build. An extra > warning present in freetype2 code causes the build to fail. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8080013 > WebRev inline: > > diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk > +++ b/make/lib/Awt2dLibraries.gmk > @@ -653,7 +653,7 @@ > DISABLED_WARNINGS_clang := unused-value incompatible-pointer-types \ > tautological-constant-out-of-range-compare > int-to-pointer-cast, \ > DISABLED_WARNINGS_solstudio := truncwarn, \ > - DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996, \ > + DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146, \ > WARNINGS_AS_ERRORS_gcc := false, \ > WARNINGS_AS_ERRORS_solstudio := false, \ > MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \ > > /Magnus From magnus.ihse.bursie at oracle.com Mon May 11 12:19:09 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 11 May 2015 14:19:09 +0200 Subject: Backport multiple toolchains support to JDK8? In-Reply-To: References: <554C7B32.2050000@oracle.com> Message-ID: <55509E3D.8080102@oracle.com> On 2015-05-08 18:49, Alexander Smundak wrote: > And I guess the successor of the 8u60 is going to be the last JDK8 release? As far as I know, 8u60 is the last JDK8 feature release being done by Oracle. /Magnus > > On Fri, May 8, 2015 at 2:00 AM, Magnus Ihse Bursie > wrote: >> On 2015-05-08 04:46, Alexander Smundak wrote: >>> I have backported "8034788: Rewrite toolchain.m4 to support multiple >>> toolchains per platform." and related changes to jdk8u40 in order to >>> build JDK8 with Clang/LLVM on Linux. Can I mail this change for the >>> review? >> >> JDK 8u40 is already released. Did you mean 8u60? >> >> To get a backport in 8u60 means you need to get approval according to >> http://openjdk.java.net/projects/jdk8u/groundrules.html. >> >> If the backport does not apply cleanly (which I suspect in this case), then >> you also need a review from the build team. >> >> As I understand, 8u60 is already feature complete, and this change in >> question is quite intrusive. I would not recommend backporting it to 8u60 at >> this point. >> >> /Magnus From erik.joelsson at oracle.com Mon May 11 12:31:50 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 May 2015 14:31:50 +0200 Subject: RFR: JDK-8039426: gcc can target wrong instruction set when building JDK native code Message-ID: <5550A136.4050107@oracle.com> Hello, Please review this small fix to CFLAGS when compiling with GCC on a 32-bit system. Hotspot currently sets -march=i586 and the jdk libraries should do the same for consistency. Bug: https://bugs.openjdk.java.net/browse/JDK-8039426 Webrev: http://cr.openjdk.java.net/~erikj/8039426/webrev.01/ /Erik From magnus.ihse.bursie at oracle.com Mon May 11 13:48:01 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 11 May 2015 15:48:01 +0200 Subject: RFR: JDK-8039426: gcc can target wrong instruction set when building JDK native code In-Reply-To: <5550A136.4050107@oracle.com> References: <5550A136.4050107@oracle.com> Message-ID: <5550B311.9000204@oracle.com> On 2015-05-11 14:31, Erik Joelsson wrote: > Hello, > > Please review this small fix to CFLAGS when compiling with GCC on a > 32-bit system. Hotspot currently sets -march=i586 and the jdk > libraries should do the same for consistency. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8039426 > Webrev: http://cr.openjdk.java.net/~erikj/8039426/webrev.01/ Looks good to me. /Magnus From david.holmes at oracle.com Mon May 11 20:27:49 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 May 2015 06:27:49 +1000 Subject: RFR: JDK-8039426: gcc can target wrong instruction set when building JDK native code In-Reply-To: <5550A136.4050107@oracle.com> References: <5550A136.4050107@oracle.com> Message-ID: <555110C5.7030606@oracle.com> Hi Erik, On 11/05/2015 10:31 PM, Erik Joelsson wrote: > Hello, > > Please review this small fix to CFLAGS when compiling with GCC on a > 32-bit system. Hotspot currently sets -march=i586 and the jdk libraries > should do the same for consistency. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8039426 > Webrev: http://cr.openjdk.java.net/~erikj/8039426/webrev.01/ Change is fine as far as it goes but the bug report never resolved whether we should also be specifying -mtune. Thanks, David > /Erik From magnus.ihse.bursie at oracle.com Tue May 12 01:44:29 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 12 May 2015 03:44:29 +0200 Subject: RFR: JDK-8080082 configure fails if you create an empty directory and then run configure from it Message-ID: <55515AFD.6090900@oracle.com> JDK-8079891 caused this behavior: /scratch/dh198349/jdk9-dev > mkdir mybuild /scratch/dh198349/jdk9-dev > cd mybuild /scratch/dh198349/jdk9-dev/mybuild > bash ../configure Running custom generated-configure.sh configure: Configuration created at Mon May 11 19:09:12 EDT 2015. configure: configure script generated at timestamp 1431344623. ... checking for extra path... checking where to store configuration... in current directory configure: Current directory is /scratch/dh198349/jdk9-dev/mybuild. configure: Since this is not the source root, configure will output the configuration here configure: (as opposed to creating a configuration in /build/). configure: However, this directory is not empty. This is not allowed, since it could configure: seriously mess up just about everything. configure: Try 'cd /scratch/dh198349/jdk9-dev' and restart configure configure: (or create a new empty directory and cd to it). configure: error: Will not continue creating configuration in /scratch/dh198349/jdk9-dev/mybuild With JDK-8079891, a new file, configure.log will be present in the current directory, and this file is not filtered out when checking if the directory is (otherwise) empty. Introspection shows that running "configure --debug-configure" in an empty directory has probably been failing for a long time. I also took the liberty of removing fixpath.exe from the filters, since fixpath is (nowadays) created much later in the configure process (and stored in a different place), and replacing tabs with spaces. Bug: https://bugs.openjdk.java.net/browse/JDK-8080082 WebRev inline: diff -r 98e85b507b09 common/autoconf/basics.m4 --- a/common/autoconf/basics.m4 Mon May 11 13:45:39 2015 +0200 +++ b/common/autoconf/basics.m4 Tue May 12 03:43:07 2015 +0200 @@ -705,9 +705,9 @@ # is performed. filtered_files=`$ECHO "$files_present" \ | $SED -e 's/config.log//g' \ - -e 's/confdefs.h//g' \ - -e 's/fixpath.exe//g' \ - -e 's/ //g' \ + -e 's/configure.log//g' \ + -e 's/confdefs.h//g' \ + -e 's/ //g' \ | $TR -d '\n'` if test "x$filtered_files" != x; then AC_MSG_NOTICE([Current directory is $CURDIR.]) From david.holmes at oracle.com Tue May 12 02:52:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 May 2015 12:52:25 +1000 Subject: RFR: JDK-8080082 configure fails if you create an empty directory and then run configure from it In-Reply-To: <55515AFD.6090900@oracle.com> References: <55515AFD.6090900@oracle.com> Message-ID: <55516AE9.3040503@oracle.com> On 12/05/2015 11:44 AM, Magnus Ihse Bursie wrote: > JDK-8079891 caused this behavior: > > /scratch/dh198349/jdk9-dev > mkdir mybuild > /scratch/dh198349/jdk9-dev > cd mybuild > /scratch/dh198349/jdk9-dev/mybuild > bash ../configure > Running custom generated-configure.sh > configure: Configuration created at Mon May 11 19:09:12 EDT 2015. > configure: configure script generated at timestamp 1431344623. > ... > checking for extra path... > checking where to store configuration... in current directory > configure: Current directory is /scratch/dh198349/jdk9-dev/mybuild. > configure: Since this is not the source root, configure will output the > configuration here > configure: (as opposed to creating a configuration in > /build/). > configure: However, this directory is not empty. This is not allowed, > since it could > configure: seriously mess up just about everything. > configure: Try 'cd /scratch/dh198349/jdk9-dev' and restart configure > configure: (or create a new empty directory and cd to it). > configure: error: Will not continue creating configuration in > /scratch/dh198349/jdk9-dev/mybuild > > With JDK-8079891, a new file, configure.log will be present in the > current directory, and this file is not filtered out when checking if > the directory is (otherwise) empty. Introspection shows that running > "configure --debug-configure" in an empty directory has probably been > failing for a long time. > > I also took the liberty of removing fixpath.exe from the filters, since > fixpath is (nowadays) created much later in the configure process (and > stored in a different place), and replacing tabs with spaces. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8080082 > WebRev inline: > > diff -r 98e85b507b09 common/autoconf/basics.m4 > --- a/common/autoconf/basics.m4 Mon May 11 13:45:39 2015 +0200 > +++ b/common/autoconf/basics.m4 Tue May 12 03:43:07 2015 +0200 > @@ -705,9 +705,9 @@ > # is performed. > filtered_files=`$ECHO "$files_present" \ > | $SED -e 's/config.log//g' \ > - -e 's/confdefs.h//g' \ > - -e 's/fixpath.exe//g' \ > - -e 's/ //g' \ > + -e 's/configure.log//g' \ > + -e 's/confdefs.h//g' \ > + -e 's/ //g' \ > | $TR -d '\n'` > if test "x$filtered_files" != x; then > AC_MSG_NOTICE([Current directory is $CURDIR.]) Your patch didn't apply locally for me but I verified that replacing fixpath.exe with configure.log resolved the issue. Thanks, David From erik.joelsson at oracle.com Tue May 12 06:54:48 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 12 May 2015 08:54:48 +0200 Subject: RFR: JDK-8080082 configure fails if you create an empty directory and then run configure from it In-Reply-To: <55515AFD.6090900@oracle.com> References: <55515AFD.6090900@oracle.com> Message-ID: <5551A3B8.2030700@oracle.com> Looks good to me. /Erik On 2015-05-12 03:44, Magnus Ihse Bursie wrote: > JDK-8079891 caused this behavior: > > /scratch/dh198349/jdk9-dev > mkdir mybuild > /scratch/dh198349/jdk9-dev > cd mybuild > /scratch/dh198349/jdk9-dev/mybuild > bash ../configure > Running custom generated-configure.sh > configure: Configuration created at Mon May 11 19:09:12 EDT 2015. > configure: configure script generated at timestamp 1431344623. > ... > checking for extra path... > checking where to store configuration... in current directory > configure: Current directory is /scratch/dh198349/jdk9-dev/mybuild. > configure: Since this is not the source root, configure will output > the configuration here > configure: (as opposed to creating a configuration in > /build/). > configure: However, this directory is not empty. This is not allowed, > since it could > configure: seriously mess up just about everything. > configure: Try 'cd /scratch/dh198349/jdk9-dev' and restart configure > configure: (or create a new empty directory and cd to it). > configure: error: Will not continue creating configuration in > /scratch/dh198349/jdk9-dev/mybuild > > With JDK-8079891, a new file, configure.log will be present in the > current directory, and this file is not filtered out when checking if > the directory is (otherwise) empty. Introspection shows that running > "configure --debug-configure" in an empty directory has probably been > failing for a long time. > > I also took the liberty of removing fixpath.exe from the filters, > since fixpath is (nowadays) created much later in the configure > process (and stored in a different place), and replacing tabs with > spaces. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8080082 > WebRev inline: > > diff -r 98e85b507b09 common/autoconf/basics.m4 > --- a/common/autoconf/basics.m4 Mon May 11 13:45:39 2015 +0200 > +++ b/common/autoconf/basics.m4 Tue May 12 03:43:07 2015 +0200 > @@ -705,9 +705,9 @@ > # is performed. > filtered_files=`$ECHO "$files_present" \ > | $SED -e 's/config.log//g' \ > - -e 's/confdefs.h//g' \ > - -e 's/fixpath.exe//g' \ > - -e 's/ //g' \ > + -e 's/configure.log//g' \ > + -e 's/confdefs.h//g' \ > + -e 's/ //g' \ > | $TR -d '\n'` > if test "x$filtered_files" != x; then > AC_MSG_NOTICE([Current directory is $CURDIR.]) > > From david.holmes at oracle.com Tue May 12 07:02:36 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 May 2015 17:02:36 +1000 Subject: RFR: JDK-8039426: gcc can target wrong instruction set when building JDK native code In-Reply-To: <555110C5.7030606@oracle.com> References: <5550A136.4050107@oracle.com> <555110C5.7030606@oracle.com> Message-ID: <5551A58C.6090506@oracle.com> On 12/05/2015 6:27 AM, David Holmes wrote: > Hi Erik, > > On 11/05/2015 10:31 PM, Erik Joelsson wrote: >> Hello, >> >> Please review this small fix to CFLAGS when compiling with GCC on a >> 32-bit system. Hotspot currently sets -march=i586 and the jdk libraries >> should do the same for consistency. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8039426 >> Webrev: http://cr.openjdk.java.net/~erikj/8039426/webrev.01/ > > Change is fine as far as it goes but the bug report never resolved > whether we should also be specifying -mtune. Bug report updated. I'm happy. Thanks, David > Thanks, > David > >> /Erik From pujarimahesh_kumar at yahoo.com Tue May 12 08:21:47 2015 From: pujarimahesh_kumar at yahoo.com (Mahesh Pujari) Date: Tue, 12 May 2015 08:21:47 +0000 (UTC) Subject: Issues with dtrace enabled in OpenJdk 9 In-Reply-To: References: Message-ID: <1863678729.45628.1431418907030.JavaMail.yahoo@mail.yahoo.com> I think I have mixed up things, like thinking SDT and dtrace4linux as same, but there are not as pointed out by Staffan. So first I build jdk9 with not having SDT headers i.e. not having systemtap-dev. Build was success as expected. Next I did a build having SDT headers in path (i.e. I having installed systemtap and systemtap-dev), as pointed out by David, dtrace will be enabled by default, it seems its working as expected, i.e. dtrace was enabled but the build failed with below error. In file included from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/utilities/dtrace.hpp:49:0, ???????????????? from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/utilities/hashtable.inline.hpp:31, ???????????????? from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/classfile/systemDictionary.hpp:35, ???????????????? from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciEnv.hpp:30, ???????????????? from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciUtilities.hpp:28, ???????????????? from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciNullObject.hpp:30, ???????????????? from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciConstant.hpp:29, ???????????????? from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciArray.hpp:29, ???????????????? from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/precompiled/precompiled.hpp:33: ../generated/dtracefiles/hotspot.h:14:5: error: "_DTRACE_VERSION" is not defined [-Werror=undef] To fix this, I re-configured with "--with-extra-cflags=-D_DTRACE_VERSION=true" and did "make all LOG=info", now compilation are success but linking failed (lot of them), few of the logs as below Compiling /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vm_version.cpp Linking vm... classLoadingService.o: In function `ClassLoadingService::notify_class_unloaded(InstanceKlass*)': /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119: undefined reference to `__dtrace_hotspot___class__unloaded' classLoadingService.o: In function `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144: undefined reference to `__dtrace_hotspot___class__loaded' compileBroker.o: In function `CompileBroker::invoke_compiler_on_method(CompileTask*)': /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: undefined reference to `__dtrace_hotspot___method__compile__begin' Do I need to install some other libraries, what am I missing here. thanks and regards,Mahesh Pujari On Monday, May 11, 2015 5:08 PM, Staffan Larsen wrote: Note that SDT and dtrace4linux are different things. As far as I know, no one has tried dtrace4linux with Hotspot so you are in uncharted territories. SDT should work (if installed). Oracle Linux also has an implementation of Dtrace that I think is different from dtrace4linux. This is also untested. /Staffan > On 11 maj 2015, at 13:21, David Holmes wrote: > > On 11/05/2015 8:51 PM, Mahesh Pujari wrote: >> Thanks for replying back Erik. >> I ran as you stated i.e. using "make DTRACE_ENABLED=true" but then I realized that the configure that I was running would do the same i.e. by having CFLAGS=-DDTRACE_ENABLED=1. > > No it isn't the same. The linux/makefiles/dtrace.make looks for DTRACE_ENABLED and will define additional targets if it is set, as well as setting -DDTRACE_ENABLED. If you just set the define then you miss other things. > > But that aside you don't set DTRACE_ENABLED either. dtrace will be enabled if the SDT header file is found. If you just do a build without trying to force dtrace on what does the log show? > > David > ----- > >> When I make (using your approach and passing enable in configure), I end up with lots and lots of "undefined reference to" errors during make, seems I am missing something, below are some error from build.logs. >> classLoadingService.o: In function `ClassLoadingService::notify_class_unloaded(InstanceKlass*)': >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119: undefined reference to `__dtrace_hotspot___class__unloaded' >> classLoadingService.o: In function `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144: undefined reference to `__dtrace_hotspot___class__loaded' >> compileBroker.o: In function `CompileBroker::invoke_compiler_on_method(CompileTask*)': >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: undefined reference to `__dtrace_hotspot___method__compile__begin' >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:2028: undefined reference to `__dtrace_hotspot___method__compile__end' >> >> thanks and regards,Mahesh Pujari >> >> >> >>? ? ? On Monday, May 11, 2015 3:53 PM, Erik Joelsson wrote: >> >> >>? Hello, >> >> I don't have any experience building with dtrace support, but the >> Hotspot makefiles seem to imply that it can be achieved by running: >> >> make DTRACE_ENABLED=true >> >> That variable will trigger the appropriate preprocessor flags to be >> added at least. See hotspot/make/linux/makefiles/dtrace.make. >> >> The jdk libraries do not support dtrace AFAIK. >> >> /Erik >> >> On 2015-05-11 11:47, Mahesh Pujari wrote: >>> Hi all, >>> I am trying make OpenJdk 9 with dtrace enabled, on my Ubuntu machine (installed with https://github.com/dtrace4linux/linux), with configuration as below (and I am noob). >>> ./configure --enable-option-checking=fatal --with-debug-level=slowdebug --with-target-bits=64 --disable-zip-debug-info --with-boot-jdk=/mnt/ubuntu/setup/jdk1.8.0 CFLAGS=-DDTRACE_ENABLED=1 --with-extra-cflags=-D_DTRACE_VERSION=1 >>> >>> Below is my system info (using uname -a)Linux PHP0045 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>> >>> When I do "make all", I end up in error as below... >>> ... >>> vmThread.o: In function `VMOperationQueue::add(VM_Operation*)': >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:156: undefined reference to `__dtrace_hotspot___vmops__request' >>> vmThread.o: In function `VMThread::evaluate_operation(VM_Operation*)': >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:354: undefined reference to `__dtrace_hotspot___vmops__begin' >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:374: undefined reference to `__dtrace_hotspot___vmops__end'...... >>> >>> Can some one direct me about what I might be missing. Can we actually build dtrace with enabled on Ubuntu, if not what other way I can do tracing (may be using systemtap, any pointers please). Am I on right track? (please direct). >>> >>> >>> thanks and regards,Mahesh Pujari >> >> >> >> >> From staffan.larsen at oracle.com Tue May 12 08:35:55 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 May 2015 10:35:55 +0200 Subject: Issues with dtrace enabled in OpenJdk 9 In-Reply-To: <1863678729.45628.1431418907030.JavaMail.yahoo@mail.yahoo.com> References: <1863678729.45628.1431418907030.JavaMail.yahoo@mail.yahoo.com> Message-ID: <6993275C-FD77-482B-85E2-7F30A08495A4@oracle.com> The SDT support is maintained by the IcedTea folks. Perhaps asking on their email list [1] would get you closer, or on the hotspot-dev list. /Staffan [1] http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev > On 12 maj 2015, at 10:21, Mahesh Pujari wrote: > > I think I have mixed up things, like thinking SDT and dtrace4linux as same, but there are not as pointed out by Staffan. > > So first I build jdk9 with not having SDT headers i.e. not having systemtap-dev. Build was success as expected. > > Next I did a build having SDT headers in path (i.e. I having installed systemtap and systemtap-dev), as pointed out by David, dtrace will be enabled by default, it seems its working as expected, i.e. dtrace was enabled but the build failed with below error. > > In file included from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/utilities/dtrace.hpp:49:0, > from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/utilities/hashtable.inline.hpp:31, > from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/classfile/systemDictionary.hpp:35, > from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciEnv.hpp:30, > from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciUtilities.hpp:28, > from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciNullObject.hpp:30, > from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciConstant.hpp:29, > from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciArray.hpp:29, > from /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/precompiled/precompiled.hpp:33: > ../generated/dtracefiles/hotspot.h:14:5: error: "_DTRACE_VERSION" is not defined [-Werror=undef] > > To fix this, I re-configured with "--with-extra-cflags=-D_DTRACE_VERSION=true" and did "make all LOG=info", now compilation are success but linking failed (lot of them), few of the logs as below > > Compiling /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vm_version.cpp > Linking vm... > classLoadingService.o: In function `ClassLoadingService::notify_class_unloaded(InstanceKlass*)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119: undefined reference to `__dtrace_hotspot___class__unloaded' > classLoadingService.o: In function `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144: undefined reference to `__dtrace_hotspot___class__loaded' > compileBroker.o: In function `CompileBroker::invoke_compiler_on_method(CompileTask*)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: undefined reference to `__dtrace_hotspot___method__compile__begin' > > > Do I need to install some other libraries, what am I missing here. > > thanks and regards, > Mahesh Pujari > > > > On Monday, May 11, 2015 5:08 PM, Staffan Larsen wrote: > > > Note that SDT and dtrace4linux are different things. As far as I know, no one has tried dtrace4linux with Hotspot so you are in uncharted territories. SDT should work (if installed). Oracle Linux also has an implementation of Dtrace that I think is different from dtrace4linux. This is also untested. > > /Staffan > > > > > On 11 maj 2015, at 13:21, David Holmes > wrote: > > > > On 11/05/2015 8:51 PM, Mahesh Pujari wrote: > >> Thanks for replying back Erik. > >> I ran as you stated i.e. using "make DTRACE_ENABLED=true" but then I realized that the configure that I was running would do the same i.e. by having CFLAGS=-DDTRACE_ENABLED=1. > > > > No it isn't the same. The linux/makefiles/dtrace.make looks for DTRACE_ENABLED and will define additional targets if it is set, as well as setting -DDTRACE_ENABLED. If you just set the define then you miss other things. > > > > But that aside you don't set DTRACE_ENABLED either. dtrace will be enabled if the SDT header file is found. If you just do a build without trying to force dtrace on what does the log show? > > > > David > > ----- > > > >> When I make (using your approach and passing enable in configure), I end up with lots and lots of "undefined reference to" errors during make, seems I am missing something, below are some error from build.logs. > >> classLoadingService.o: In function `ClassLoadingService::notify_class_unloaded(InstanceKlass*)': > >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119: undefined reference to `__dtrace_hotspot___class__unloaded' > >> classLoadingService.o: In function `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': > >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144: undefined reference to `__dtrace_hotspot___class__loaded' > >> compileBroker.o: In function `CompileBroker::invoke_compiler_on_method(CompileTask*)': > >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: undefined reference to `__dtrace_hotspot___method__compile__begin' > >> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:2028: undefined reference to `__dtrace_hotspot___method__compile__end' > >> > >> thanks and regards,Mahesh Pujari > >> > >> > >> > >> On Monday, May 11, 2015 3:53 PM, Erik Joelsson > wrote: > >> > >> > >> Hello, > >> > >> I don't have any experience building with dtrace support, but the > >> Hotspot makefiles seem to imply that it can be achieved by running: > >> > >> make DTRACE_ENABLED=true > >> > >> That variable will trigger the appropriate preprocessor flags to be > >> added at least. See hotspot/make/linux/makefiles/dtrace.make. > >> > >> The jdk libraries do not support dtrace AFAIK. > >> > >> /Erik > >> > >> On 2015-05-11 11:47, Mahesh Pujari wrote: > >>> Hi all, > >>> I am trying make OpenJdk 9 with dtrace enabled, on my Ubuntu machine (installed with https://github.com/dtrace4linux/linux ), with configuration as below (and I am noob). > >>> ./configure --enable-option-checking=fatal --with-debug-level=slowdebug --with-target-bits=64 --disable-zip-debug-info --with-boot-jdk=/mnt/ubuntu/setup/jdk1.8.0 CFLAGS=-DDTRACE_ENABLED=1 --with-extra-cflags=-D_DTRACE_VERSION=1 > >>> > >>> Below is my system info (using uname -a)Linux PHP0045 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > >>> > >>> When I do "make all", I end up in error as below... > >>> ... > >>> vmThread.o: In function `VMOperationQueue::add(VM_Operation*)': > >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:156: undefined reference to `__dtrace_hotspot___vmops__request' > >>> vmThread.o: In function `VMThread::evaluate_operation(VM_Operation*)': > >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:354: undefined reference to `__dtrace_hotspot___vmops__begin' > >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:374: undefined reference to `__dtrace_hotspot___vmops__end'...... > >>> > >>> Can some one direct me about what I might be missing. Can we actually build dtrace with enabled on Ubuntu, if not what other way I can do tracing (may be using systemtap, any pointers please). Am I on right track? (please direct). > >>> > >>> > >>> thanks and regards,Mahesh Pujari > >> > >> > >> > >> > >> > > From david.holmes at oracle.com Tue May 12 09:16:21 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 May 2015 19:16:21 +1000 Subject: Issues with dtrace enabled in OpenJdk 9 In-Reply-To: <1863678729.45628.1431418907030.JavaMail.yahoo@mail.yahoo.com> References: <1863678729.45628.1431418907030.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5551C4E5.5010605@oracle.com> On 12/05/2015 6:21 PM, Mahesh Pujari wrote: > I think I have mixed up things, like thinking SDT and dtrace4linux as > same, but there are not as pointed out by Staffan. > > So first I build jdk9 with not having SDT headers i.e. not having > systemtap-dev. Build was success as expected. > > Next I did a build having SDT headers in path (i.e. I having installed > systemtap and systemtap-dev), as pointed out by David, dtrace will be > enabled by default, it seems its working as expected, i.e. dtrace was > enabled but the build failed with below error. > > In file included from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/utilities/dtrace.hpp:49:0, > from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/utilities/hashtable.inline.hpp:31, > from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/classfile/systemDictionary.hpp:35, > from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciEnv.hpp:30, > from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciUtilities.hpp:28, > from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciNullObject.hpp:30, > from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciConstant.hpp:29, > from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciArray.hpp:29, > from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/precompiled/precompiled.hpp:33: > ../generated/dtracefiles/hotspot.h:14:5: error: "_DTRACE_VERSION" is not > defined [-Werror=undef] What do the generated/dtracefiles contain? Does the log show them being created correctly? David ----- > To fix this, I re-configured with > "--with-extra-cflags=-D_DTRACE_VERSION=true" and did "make all > LOG=info", now compilation are success but linking failed (lot of them), > few of the logs as below > > Compiling /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vm_version.cpp > Linking vm... > classLoadingService.o: In function > `ClassLoadingService::notify_class_unloaded(InstanceKlass*)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119: > undefined reference to `__dtrace_hotspot___class__unloaded' > classLoadingService.o: In function > `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144: > undefined reference to `__dtrace_hotspot___class__loaded' > compileBroker.o: In function > `CompileBroker::invoke_compiler_on_method(CompileTask*)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: > undefined reference to `__dtrace_hotspot___method__compile__begin' > > > Do I need to install some other libraries, what am I missing here. > > thanks and regards, > Mahesh Pujari > > > > On Monday, May 11, 2015 5:08 PM, Staffan Larsen > wrote: > > > Note that SDT and dtrace4linux are different things. As far as I know, > no one has tried dtrace4linux with Hotspot so you are in uncharted > territories. SDT should work (if installed). Oracle Linux also has an > implementation of Dtrace that I think is different from dtrace4linux. > This is also untested. > > /Staffan > > > > > On 11 maj 2015, at 13:21, David Holmes > wrote: > > > > On 11/05/2015 8:51 PM, Mahesh Pujari wrote: > >> Thanks for replying back Erik. > >> I ran as you stated i.e. using "make DTRACE_ENABLED=true" but then I > realized that the configure that I was running would do the same i.e. by > having CFLAGS=-DDTRACE_ENABLED=1. > > > > No it isn't the same. The linux/makefiles/dtrace.make looks for > DTRACE_ENABLED and will define additional targets if it is set, as well > as setting -DDTRACE_ENABLED. If you just set the define then you miss > other things. > > > > But that aside you don't set DTRACE_ENABLED either. dtrace will be > enabled if the SDT header file is found. If you just do a build without > trying to force dtrace on what does the log show? > > > > David > > ----- > > > >> When I make (using your approach and passing enable in configure), I > end up with lots and lots of "undefined reference to" errors during > make, seems I am missing something, below are some error from build.logs. > >> classLoadingService.o: In function > `ClassLoadingService::notify_class_unloaded(InstanceKlass*)': > >> > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119: > undefined reference to `__dtrace_hotspot___class__unloaded' > >> classLoadingService.o: In function > `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': > >> > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144: > undefined reference to `__dtrace_hotspot___class__loaded' > >> compileBroker.o: In function > `CompileBroker::invoke_compiler_on_method(CompileTask*)': > >> > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: > undefined reference to `__dtrace_hotspot___method__compile__begin' > >> > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:2028: > undefined reference to `__dtrace_hotspot___method__compile__end' > >> > >> thanks and regards,Mahesh Pujari > >> > >> > >> > >> On Monday, May 11, 2015 3:53 PM, Erik Joelsson > > wrote: > >> > >> > >> Hello, > >> > >> I don't have any experience building with dtrace support, but the > >> Hotspot makefiles seem to imply that it can be achieved by running: > >> > >> make DTRACE_ENABLED=true > >> > >> That variable will trigger the appropriate preprocessor flags to be > >> added at least. See hotspot/make/linux/makefiles/dtrace.make. > >> > >> The jdk libraries do not support dtrace AFAIK. > >> > >> /Erik > >> > >> On 2015-05-11 11:47, Mahesh Pujari wrote: > >>> Hi all, > >>> I am trying make OpenJdk 9 with dtrace enabled, on my Ubuntu > machine (installed with https://github.com/dtrace4linux/linux), with > configuration as below (and I am noob). > >>> ./configure --enable-option-checking=fatal > --with-debug-level=slowdebug --with-target-bits=64 > --disable-zip-debug-info --with-boot-jdk=/mnt/ubuntu/setup/jdk1.8.0 > CFLAGS=-DDTRACE_ENABLED=1 --with-extra-cflags=-D_DTRACE_VERSION=1 > >>> > >>> Below is my system info (using uname -a)Linux PHP0045 > 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 > x86_64 x86_64 GNU/Linux > >>> > >>> When I do "make all", I end up in error as below... > >>> ... > >>> vmThread.o: In function `VMOperationQueue::add(VM_Operation*)': > >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:156: > undefined reference to `__dtrace_hotspot___vmops__request' > >>> vmThread.o: In function `VMThread::evaluate_operation(VM_Operation*)': > >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:354: > undefined reference to `__dtrace_hotspot___vmops__begin' > >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:374: > undefined reference to `__dtrace_hotspot___vmops__end'...... > >>> > >>> Can some one direct me about what I might be missing. Can we > actually build dtrace with enabled on Ubuntu, if not what other way I > can do tracing (may be using systemtap, any pointers please). Am I on > right track? (please direct). > >>> > >>> > >>> thanks and regards,Mahesh Pujari > >> > >> > >> > >> > >> > > From martinrb at google.com Tue May 12 17:43:20 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 12 May 2015 10:43:20 -0700 Subject: Backport multiple toolchains support to JDK8? In-Reply-To: <55509E3D.8080102@oracle.com> References: <554C7B32.2050000@oracle.com> <55509E3D.8080102@oracle.com> Message-ID: I also think that backporting multiple toolchain support seems too risky for jdk8u. At the same time, it may be very useful for others trying to test or port the jdk8u code base (at google, we are motivated by running asan via clang). It would be good if there was a way to share such a backport without being integrated into the jdk8u forest proper. Currently the only way supported by openjdk infrastructure is a webrev, I think... On Mon, May 11, 2015 at 5:19 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2015-05-08 18:49, Alexander Smundak wrote: > >> And I guess the successor of the 8u60 is going to be the last JDK8 >> release? >> > As far as I know, 8u60 is the last JDK8 feature release being done by > Oracle. > > /Magnus > > >> On Fri, May 8, 2015 at 2:00 AM, Magnus Ihse Bursie >> wrote: >> >>> On 2015-05-08 04:46, Alexander Smundak wrote: >>> >>>> I have backported "8034788: Rewrite toolchain.m4 to support multiple >>>> toolchains per platform." and related changes to jdk8u40 in order to >>>> build JDK8 with Clang/LLVM on Linux. Can I mail this change for the >>>> review? >>>> >>> >>> JDK 8u40 is already released. Did you mean 8u60? >>> >>> To get a backport in 8u60 means you need to get approval according to >>> http://openjdk.java.net/projects/jdk8u/groundrules.html. >>> >>> If the backport does not apply cleanly (which I suspect in this case), >>> then >>> you also need a review from the build team. >>> >>> As I understand, 8u60 is already feature complete, and this change in >>> question is quite intrusive. I would not recommend backporting it to >>> 8u60 at >>> this point. >>> >>> /Magnus >>> >> > From weijun.wang at oracle.com Wed May 13 15:43:43 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 13 May 2015 23:43:43 +0800 Subject: vs2010+cygwin build failure jdk9/dev, char cannot be represented in current code page Message-ID: <5553712F.4080100@oracle.com> I have just synced my local jdk9/dev repos and today I see this build error: c:/cygwin/space/repos/jdk9/dev/jdk/src/java.desktop/share/native/liblcms/cmscgats.c : error C2220: warning treated as error - no 'object' file generated c:/cygwin/space/repos/jdk9/dev/jdk/src/java.desktop/share/native/liblcms/cmscgats.c : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss Same in src/closed/java.desktop/share/native/libt2k/t2k/ttHints/FntDebug.c. Looks like there are several <0x93> <0x94> or (c) chars there. Must I upgrade to VS2013? Or is there something else go wrong? Thanks Max From pujarimahesh_kumar at yahoo.com Wed May 13 19:00:07 2015 From: pujarimahesh_kumar at yahoo.com (Mahesh Pujari) Date: Wed, 13 May 2015 19:00:07 +0000 (UTC) Subject: Issues with dtrace enabled in OpenJdk 9 In-Reply-To: <5551C4E5.5010605@oracle.com> References: <5551C4E5.5010605@oracle.com> Message-ID: <259125904.697384.1431543607388.JavaMail.yahoo@mail.yahoo.com> Sorry for replying late. Thanks Staffan, I will be mailing the details as you pointed out. David, generated/dtracefiles contain just 3 header files, hotspot.h, hotspot_jni.h and hs_private.h and if we take hotspot.h file, it contains the lines as below #if _DTRACE_VERSION #define HOTSPOT_CLASS_INITIALIZATION_CLINIT(arg0, arg1, arg2, arg3, arg4) \ ??????? __dtrace_hotspot___class__initialization__clinit(arg0, arg1, arg2, arg3, arg4) #ifndef __sparc #define HOTSPOT_CLASS_INITIALIZATION_CLINIT_ENABLED() \ ??????? __dtraceenabled_hotspot___class__initialization__clinit() #else and they all are defined as extern in hotspot.h as below one such exampleextern void __dtrace_hotspot___class__initialization__clinit(char *, uintptr_t, void *, intptr_t, int); any thoughts on how to solve it, am I missing something. thanks and regards,Mahesh Pujari ? On Tuesday, May 12, 2015 2:47 PM, David Holmes wrote: On 12/05/2015 6:21 PM, Mahesh Pujari wrote: > I think I have mixed up things, like thinking SDT and dtrace4linux as > same, but there are not as pointed out by Staffan. > > So first I build jdk9 with not having SDT headers i.e. not having > systemtap-dev. Build was success as expected. > > Next I did a build having SDT headers in path (i.e. I having installed > systemtap and systemtap-dev), as pointed out by David, dtrace will be > enabled by default, it seems its working as expected, i.e. dtrace was > enabled but the build failed with below error. > > In file included from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/utilities/dtrace.hpp:49:0, >? ? ? ? ? ? ? ? ? from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/utilities/hashtable.inline.hpp:31, >? ? ? ? ? ? ? ? ? from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/classfile/systemDictionary.hpp:35, >? ? ? ? ? ? ? ? ? from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciEnv.hpp:30, >? ? ? ? ? ? ? ? ? from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciUtilities.hpp:28, >? ? ? ? ? ? ? ? ? from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciNullObject.hpp:30, >? ? ? ? ? ? ? ? ? from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciConstant.hpp:29, >? ? ? ? ? ? ? ? ? from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciArray.hpp:29, >? ? ? ? ? ? ? ? ? from > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/precompiled/precompiled.hpp:33: > ../generated/dtracefiles/hotspot.h:14:5: error: "_DTRACE_VERSION" is not > defined [-Werror=undef] What do the generated/dtracefiles contain? Does the log show them being created correctly? David ----- > To fix this, I re-configured with > "--with-extra-cflags=-D_DTRACE_VERSION=true" and did "make all > LOG=info", now compilation are success but linking failed (lot of them), > few of the logs as below > > Compiling /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vm_version.cpp > Linking vm... > classLoadingService.o: In function > `ClassLoadingService::notify_class_unloaded(InstanceKlass*)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119: > undefined reference to `__dtrace_hotspot___class__unloaded' > classLoadingService.o: In function > `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144: > undefined reference to `__dtrace_hotspot___class__loaded' > compileBroker.o: In function > `CompileBroker::invoke_compiler_on_method(CompileTask*)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: > undefined reference to `__dtrace_hotspot___method__compile__begin' > > > Do I need to install some other libraries, what am I missing here. > > thanks and regards, > Mahesh Pujari > > > > On Monday, May 11, 2015 5:08 PM, Staffan Larsen > wrote: > > > Note that SDT and dtrace4linux are different things. As far as I know, > no one has tried dtrace4linux with Hotspot so you are in uncharted > territories. SDT should work (if installed). Oracle Linux also has an > implementation of Dtrace that I think is different from dtrace4linux. > This is also untested. > > /Staffan > > > >? > On 11 maj 2015, at 13:21, David Holmes > wrote: >? > >? > On 11/05/2015 8:51 PM, Mahesh Pujari wrote: >? >> Thanks for replying back Erik. >? >> I ran as you stated i.e. using "make DTRACE_ENABLED=true" but then I > realized that the configure that I was running would do the same i.e. by > having CFLAGS=-DDTRACE_ENABLED=1. >? > >? > No it isn't the same. The linux/makefiles/dtrace.make looks for > DTRACE_ENABLED and will define additional targets if it is set, as well > as setting -DDTRACE_ENABLED. If you just set the define then you miss > other things. >? > >? > But that aside you don't set DTRACE_ENABLED either. dtrace will be > enabled if the SDT header file is found. If you just do a build without > trying to force dtrace on what does the log show? >? > >? > David >? > ----- >? > >? >> When I make (using your approach and passing enable in configure), I > end up with lots and lots of "undefined reference to" errors during > make, seems I am missing something, below are some error from build.logs. >? >> classLoadingService.o: In function > `ClassLoadingService::notify_class_unloaded(InstanceKlass*)': >? >> > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119: > undefined reference to `__dtrace_hotspot___class__unloaded' >? >> classLoadingService.o: In function > `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': >? >> > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144: > undefined reference to `__dtrace_hotspot___class__loaded' >? >> compileBroker.o: In function > `CompileBroker::invoke_compiler_on_method(CompileTask*)': >? >> > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: > undefined reference to `__dtrace_hotspot___method__compile__begin' >? >> > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:2028: > undefined reference to `__dtrace_hotspot___method__compile__end' >? >> >? >> thanks and regards,Mahesh Pujari >? >> >? >> >? >> >? >>? ? ? On Monday, May 11, 2015 3:53 PM, Erik Joelsson > > wrote: >? >> >? >> >? >>? Hello, >? >> >? >> I don't have any experience building with dtrace support, but the >? >> Hotspot makefiles seem to imply that it can be achieved by running: >? >> >? >> make DTRACE_ENABLED=true >? >> >? >> That variable will trigger the appropriate preprocessor flags to be >? >> added at least. See hotspot/make/linux/makefiles/dtrace.make. >? >> >? >> The jdk libraries do not support dtrace AFAIK. >? >> >? >> /Erik >? >> >? >> On 2015-05-11 11:47, Mahesh Pujari wrote: >? >>> Hi all, >? >>> I am trying make OpenJdk 9 with dtrace enabled, on my Ubuntu > machine (installed with https://github.com/dtrace4linux/linux), with > configuration as below (and I am noob). >? >>> ./configure --enable-option-checking=fatal > --with-debug-level=slowdebug --with-target-bits=64 > --disable-zip-debug-info --with-boot-jdk=/mnt/ubuntu/setup/jdk1.8.0 > CFLAGS=-DDTRACE_ENABLED=1 --with-extra-cflags=-D_DTRACE_VERSION=1 >? >>> >? >>> Below is my system info (using uname -a)Linux PHP0045 > 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 > x86_64 x86_64 GNU/Linux >? >>> >? >>> When I do "make all", I end up in error as below... >? >>> ... >? >>> vmThread.o: In function `VMOperationQueue::add(VM_Operation*)': >? >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:156: > undefined reference to `__dtrace_hotspot___vmops__request' >? >>> vmThread.o: In function `VMThread::evaluate_operation(VM_Operation*)': >? >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:354: > undefined reference to `__dtrace_hotspot___vmops__begin' >? >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:374: > undefined reference to `__dtrace_hotspot___vmops__end'...... >? >>> >? >>> Can some one direct me about what I might be missing. Can we > actually build dtrace with enabled on Ubuntu, if not what other way I > can do tracing (may be using systemtap, any pointers please). Am I on > right track? (please direct). >? >>> >? >>> >? >>> thanks and regards,Mahesh Pujari >? >> >? >> >? >> >? >> >? >> > > From david.holmes at oracle.com Thu May 14 03:07:06 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 May 2015 13:07:06 +1000 Subject: Issues with dtrace enabled in OpenJdk 9 In-Reply-To: <259125904.697384.1431543607388.JavaMail.yahoo@mail.yahoo.com> References: <5551C4E5.5010605@oracle.com> <259125904.697384.1431543607388.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5554115A.50603@oracle.com> Hi Mahesh, On 14/05/2015 5:00 AM, Mahesh Pujari wrote: > Sorry for replying late. > > Thanks Staffan, I will be mailing the details as you pointed out. > > David, generated/dtracefiles contain just 3 header files, hotspot.h, > hotspot_jni.h and hs_private.h and if we take hotspot.h file, it > contains the lines as below > > #if _DTRACE_VERSION > > #define HOTSPOT_CLASS_INITIALIZATION_CLINIT(arg0, arg1, arg2, arg3, arg4) \ > __dtrace_hotspot___class__initialization__clinit(arg0, arg1, > arg2, arg3, arg4) > #ifndef __sparc > #define HOTSPOT_CLASS_INITIALIZATION_CLINIT_ENABLED() \ > __dtraceenabled_hotspot___class__initialization__clinit() > #else > > and they all are defined as extern in hotspot.h as below one such example > extern void __dtrace_hotspot___class__initialization__clinit(char *, > uintptr_t, void *, intptr_t, int); > > any thoughts on how to solve it, am I missing something. I think this may just be a conflict between SDT/Dtrace and recent changes to the build settings. We enabled -Wundef to detect undefined macro variables, but dtrace explicitly uses: #if _DTRACE_VERSION which will fail when _DTRACE_VERSION is not defined. And from what I have read you have to manually define it when building - -D _DTRACE_VERSION (no need for a specific value). So you need to use --with-extra-cxxflags="-D _DTRACE_VERSION" I think. (Not sure why this isn't automatically set though - seems reasonable - and some OS do it via sdt.h David ----- > thanks and regards, > Mahesh Pujari > > > > On Tuesday, May 12, 2015 2:47 PM, David Holmes > wrote: > > > On 12/05/2015 6:21 PM, Mahesh Pujari wrote: > > I think I have mixed up things, like thinking SDT and dtrace4linux as > > same, but there are not as pointed out by Staffan. > > > > So first I build jdk9 with not having SDT headers i.e. not having > > systemtap-dev. Build was success as expected. > > > > Next I did a build having SDT headers in path (i.e. I having installed > > systemtap and systemtap-dev), as pointed out by David, dtrace will be > > enabled by default, it seems its working as expected, i.e. dtrace was > > enabled but the build failed with below error. > > > > In file included from > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/utilities/dtrace.hpp:49:0, > > from > > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/utilities/hashtable.inline.hpp:31, > > from > > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/classfile/systemDictionary.hpp:35, > > from > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciEnv.hpp:30, > > from > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciUtilities.hpp:28, > > from > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciNullObject.hpp:30, > > from > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciConstant.hpp:29, > > from > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciArray.hpp:29, > > from > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/precompiled/precompiled.hpp:33: > > ../generated/dtracefiles/hotspot.h:14:5: error: "_DTRACE_VERSION" is not > > defined [-Werror=undef] > > What do the generated/dtracefiles contain? Does the log show them being > created correctly? > > David > ----- > > > To fix this, I re-configured with > > "--with-extra-cflags=-D_DTRACE_VERSION=true" and did "make all > > LOG=info", now compilation are success but linking failed (lot of them), > > few of the logs as below > > > > Compiling > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vm_version.cpp > > Linking vm... > > classLoadingService.o: In function > > `ClassLoadingService::notify_class_unloaded(InstanceKlass*)': > > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119: > > undefined reference to `__dtrace_hotspot___class__unloaded' > > classLoadingService.o: In function > > `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': > > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144: > > undefined reference to `__dtrace_hotspot___class__loaded' > > compileBroker.o: In function > > `CompileBroker::invoke_compiler_on_method(CompileTask*)': > > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: > > undefined reference to `__dtrace_hotspot___method__compile__begin' > > > > > > Do I need to install some other libraries, what am I missing here. > > > > thanks and regards, > > Mahesh Pujari > > > > > > > > On Monday, May 11, 2015 5:08 PM, Staffan Larsen > > > wrote: > > > > > > Note that SDT and dtrace4linux are different things. As far as I know, > > no one has tried dtrace4linux with Hotspot so you are in uncharted > > territories. SDT should work (if installed). Oracle Linux also has an > > implementation of Dtrace that I think is different from dtrace4linux. > > This is also untested. > > > > /Staffan > > > > > > > > > On 11 maj 2015, at 13:21, David Holmes > > >> wrote: > > > > > > On 11/05/2015 8:51 PM, Mahesh Pujari wrote: > > >> Thanks for replying back Erik. > > >> I ran as you stated i.e. using "make DTRACE_ENABLED=true" but then I > > realized that the configure that I was running would do the same i.e. by > > having CFLAGS=-DDTRACE_ENABLED=1. > > > > > > No it isn't the same. The linux/makefiles/dtrace.make looks for > > DTRACE_ENABLED and will define additional targets if it is set, as well > > as setting -DDTRACE_ENABLED. If you just set the define then you miss > > other things. > > > > > > But that aside you don't set DTRACE_ENABLED either. dtrace will be > > enabled if the SDT header file is found. If you just do a build without > > trying to force dtrace on what does the log show? > > > > > > David > > > ----- > > > > > >> When I make (using your approach and passing enable in configure), I > > end up with lots and lots of "undefined reference to" errors during > > make, seems I am missing something, below are some error from build.logs. > > >> classLoadingService.o: In function > > `ClassLoadingService::notify_class_unloaded(InstanceKlass*)': > > >> > > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119: > > undefined reference to `__dtrace_hotspot___class__unloaded' > > >> classLoadingService.o: In function > > `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': > > >> > > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144: > > undefined reference to `__dtrace_hotspot___class__loaded' > > >> compileBroker.o: In function > > `CompileBroker::invoke_compiler_on_method(CompileTask*)': > > >> > > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: > > undefined reference to `__dtrace_hotspot___method__compile__begin' > > >> > > > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:2028: > > undefined reference to `__dtrace_hotspot___method__compile__end' > > >> > > >> thanks and regards,Mahesh Pujari > > >> > > >> > > >> > > >> On Monday, May 11, 2015 3:53 PM, Erik Joelsson > > > >> wrote: > > > >> > > >> > > >> Hello, > > >> > > >> I don't have any experience building with dtrace support, but the > > >> Hotspot makefiles seem to imply that it can be achieved by running: > > >> > > >> make DTRACE_ENABLED=true > > >> > > >> That variable will trigger the appropriate preprocessor flags to be > > >> added at least. See hotspot/make/linux/makefiles/dtrace.make. > > >> > > >> The jdk libraries do not support dtrace AFAIK. > > >> > > >> /Erik > > >> > > >> On 2015-05-11 11:47, Mahesh Pujari wrote: > > >>> Hi all, > > >>> I am trying make OpenJdk 9 with dtrace enabled, on my Ubuntu > > machine (installed with https://github.com/dtrace4linux/linux), with > > configuration as below (and I am noob). > > >>> ./configure --enable-option-checking=fatal > > --with-debug-level=slowdebug --with-target-bits=64 > > --disable-zip-debug-info --with-boot-jdk=/mnt/ubuntu/setup/jdk1.8.0 > > CFLAGS=-DDTRACE_ENABLED=1 --with-extra-cflags=-D_DTRACE_VERSION=1 > > >>> > > >>> Below is my system info (using uname -a)Linux PHP0045 > > 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 > > x86_64 x86_64 GNU/Linux > > >>> > > >>> When I do "make all", I end up in error as below... > > >>> ... > > >>> vmThread.o: In function `VMOperationQueue::add(VM_Operation*)': > > >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:156: > > undefined reference to `__dtrace_hotspot___vmops__request' > > >>> vmThread.o: In function > `VMThread::evaluate_operation(VM_Operation*)': > > >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:354: > > undefined reference to `__dtrace_hotspot___vmops__begin' > > >>> /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp:374: > > undefined reference to `__dtrace_hotspot___vmops__end'...... > > >>> > > >>> Can some one direct me about what I might be missing. Can we > > actually build dtrace with enabled on Ubuntu, if not what other way I > > can do tracing (may be using systemtap, any pointers please). Am I on > > right track? (please direct). > > >>> > > >>> > > >>> thanks and regards,Mahesh Pujari > > >> > > >> > > >> > > >> > > >> > > > > > > From erik.joelsson at oracle.com Fri May 15 12:46:14 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 May 2015 14:46:14 +0200 Subject: vs2010+cygwin build failure jdk9/dev, char cannot be represented in current code page In-Reply-To: <5553712F.4080100@oracle.com> References: <5553712F.4080100@oracle.com> Message-ID: <5555EA96.8090404@oracle.com> Hello Max, I just synced up my jdk9/dev on Windows and built successfully using VS2010. I doubt changing compilers will have any effect. /Erik On 2015-05-13 17:43, Weijun Wang wrote: > I have just synced my local jdk9/dev repos and today I see this build > error: > > c:/cygwin/space/repos/jdk9/dev/jdk/src/java.desktop/share/native/liblcms/cmscgats.c > : error C2220: warning treated as error - no 'object' file generated > c:/cygwin/space/repos/jdk9/dev/jdk/src/java.desktop/share/native/liblcms/cmscgats.c > : warning C4819: The file contains a character that cannot be > represented in the current code page (936). Save the file in Unicode > format to prevent data loss > > Same in > src/closed/java.desktop/share/native/libt2k/t2k/ttHints/FntDebug.c. > > Looks like there are several <0x93> <0x94> or (c) chars there. Must I > upgrade to VS2013? Or is there something else go wrong? > > Thanks > Max > > From weijun.wang at oracle.com Fri May 15 12:58:42 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 15 May 2015 20:58:42 +0800 Subject: vs2010+cygwin build failure jdk9/dev, char cannot be represented in current code page In-Reply-To: <5555EA96.8090404@oracle.com> References: <5553712F.4080100@oracle.com> <5555EA96.8090404@oracle.com> Message-ID: <5555ED82.2070604@oracle.com> On 5/15/2015 8:46 PM, Erik Joelsson wrote: > Hello Max, > > I just synced up my jdk9/dev on Windows and built successfully using > VS2010. I doubt changing compilers will have any effect. I guess it's related to my Windows being Chinese. I've since changed to English (US) and haven't seen the problem. --Max > > /Erik > > On 2015-05-13 17:43, Weijun Wang wrote: >> I have just synced my local jdk9/dev repos and today I see this build >> error: >> >> c:/cygwin/space/repos/jdk9/dev/jdk/src/java.desktop/share/native/liblcms/cmscgats.c >> : error C2220: warning treated as error - no 'object' file generated >> c:/cygwin/space/repos/jdk9/dev/jdk/src/java.desktop/share/native/liblcms/cmscgats.c >> : warning C4819: The file contains a character that cannot be >> represented in the current code page (936). Save the file in Unicode >> format to prevent data loss >> >> Same in >> src/closed/java.desktop/share/native/libt2k/t2k/ttHints/FntDebug.c. >> >> Looks like there are several <0x93> <0x94> or (c) chars there. Must I >> upgrade to VS2013? Or is there something else go wrong? >> >> Thanks >> Max >> >> > From magnus.ihse.bursie at oracle.com Mon May 18 07:02:19 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 May 2015 09:02:19 +0200 Subject: vs2010+cygwin build failure jdk9/dev, char cannot be represented in current code page In-Reply-To: <5555ED82.2070604@oracle.com> References: <5553712F.4080100@oracle.com> <5555EA96.8090404@oracle.com> <5555ED82.2070604@oracle.com> Message-ID: <55598E7B.4070609@oracle.com> On 2015-05-15 14:58, Weijun Wang wrote: > > > On 5/15/2015 8:46 PM, Erik Joelsson wrote: >> Hello Max, >> >> I just synced up my jdk9/dev on Windows and built successfully using >> VS2010. I doubt changing compilers will have any effect. > > I guess it's related to my Windows being Chinese. I've since changed > to English (US) and haven't seen the problem. Unfortunately locale issues is harder to correct in the build system on Windows, since there's no way to locally change the locate (like LC_ALL on unixes). With that said, it's unfortunate that these files contains odd characters. These do not display properly in my (linux) editor as well. Normally, I'd say "fix it!" but these files are imported from upstream, so a change is more complicated. Probably not worth the effort. /Magnus From weijun.wang at oracle.com Mon May 18 08:27:29 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 18 May 2015 16:27:29 +0800 Subject: vs2010+cygwin build failure jdk9/dev, char cannot be represented in current code page In-Reply-To: <55598E7B.4070609@oracle.com> References: <5553712F.4080100@oracle.com> <5555EA96.8090404@oracle.com> <5555ED82.2070604@oracle.com> <55598E7B.4070609@oracle.com> Message-ID: <5559A271.6020606@oracle.com> Or not treating this warning as error? This is not a stopper for me now since I am already using English locale now. But it still feels uncomfortable. --Max On 5/18/2015 3:02 PM, Magnus Ihse Bursie wrote: > On 2015-05-15 14:58, Weijun Wang wrote: >> >> >> On 5/15/2015 8:46 PM, Erik Joelsson wrote: >>> Hello Max, >>> >>> I just synced up my jdk9/dev on Windows and built successfully using >>> VS2010. I doubt changing compilers will have any effect. >> >> I guess it's related to my Windows being Chinese. I've since changed >> to English (US) and haven't seen the problem. > > Unfortunately locale issues is harder to correct in the build system on > Windows, since there's no way to locally change the locate (like LC_ALL > on unixes). > > With that said, it's unfortunate that these files contains odd > characters. These do not display properly in my (linux) editor as well. > Normally, I'd say "fix it!" but these files are imported from upstream, > so a change is more complicated. Probably not worth the effort. > > /Magnus From brian.toal at gmail.com Mon May 18 16:48:03 2015 From: brian.toal at gmail.com (Brian Toal) Date: Mon, 18 May 2015 09:48:03 -0700 Subject: Building OpenJDK that matches OracleJDK update Message-ID: I'm trying to figure out how to build the OpenJDK so that it's at parity with the OracleJDK version. For example I want to build OpenJDK that is the equivalent of 8u45. Appreciate if someone could point me into the correct direction to any literature that explains how this is done. I've see it's possible to clone 8u40, but not 8u45 hg clone http://hg.openjdk.java.net/jdk8u/jdk8u40 jdk8u40 as I get 404's when trying to clone. From sean.coffey at oracle.com Mon May 18 19:01:48 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 18 May 2015 20:01:48 +0100 Subject: Building OpenJDK that matches OracleJDK update In-Reply-To: References: Message-ID: <555A371C.1000806@oracle.com> 8u45 was a Critical Patch Update (CPU) release and such releases are not worked via the OpenJDK forests. You won't be able to build the equivalent of Oracle JDK from OpenJDK sources given that the Oracle JDK contains extra features like plugin and installer bundles. The Oracle JDK is built on top of the OpenJDK sources. The tags in each repo indicate the sources which they were built from. The best scenario for you might be to update your repos to the tag level corresponding to the Oracle JDK of which you wish to reach parity with. For 8u45, the GA build number was b14 - i.e. tag jdk8u45-b14 Regards, Sean. On 18/05/2015 17:48, Brian Toal wrote: > I'm trying to figure out how to build the OpenJDK so that it's at parity > with the OracleJDK version. > > For example I want to build OpenJDK that is the equivalent of 8u45. > Appreciate if someone could point me into the correct direction to any > literature that explains how this is done. > > I've see it's possible to clone 8u40, but not 8u45 > > hg clone http://hg.openjdk.java.net/jdk8u/jdk8u40 jdk8u40 > > as I get 404's when trying to clone. From brian.toal at gmail.com Mon May 18 20:00:16 2015 From: brian.toal at gmail.com (Brian Toal) Date: Mon, 18 May 2015 13:00:16 -0700 Subject: Building OpenJDK that matches OracleJDK update In-Reply-To: <555A371C.1000806@oracle.com> References: <555A371C.1000806@oracle.com> Message-ID: Thanks Sean, I ended up doing something similar to what you mention. hg clone -u jdk8u45-b14 http://hg.openjdk.java.net/jdk8u/jdk8u jdk8u45-b14 cd jdk8u45-b14 bash ./get_source.sh bash ./make/scripts/hgforest.sh update jdk8u45-b14 On Mon, May 18, 2015 at 12:01 PM, Se?n Coffey wrote: > 8u45 was a Critical Patch Update (CPU) release and such releases are not > worked via the OpenJDK forests. You won't be able to build the equivalent > of Oracle JDK from OpenJDK sources given that the Oracle JDK contains extra > features like plugin and installer bundles. > > The Oracle JDK is built on top of the OpenJDK sources. The tags in each > repo indicate the sources which they were built from. The best scenario for > you might be to update your repos to the tag level corresponding to the > Oracle JDK of which you wish to reach parity with. For 8u45, the GA build > number was b14 - i.e. tag jdk8u45-b14 > > Regards, > Sean. > > > On 18/05/2015 17:48, Brian Toal wrote: > >> I'm trying to figure out how to build the OpenJDK so that it's at parity >> with the OracleJDK version. >> >> For example I want to build OpenJDK that is the equivalent of 8u45. >> Appreciate if someone could point me into the correct direction to any >> literature that explains how this is done. >> >> I've see it's possible to clone 8u40, but not 8u45 >> >> hg clone http://hg.openjdk.java.net/jdk8u/jdk8u40 jdk8u40 >> >> as I get 404's when trying to clone. >> > > From brian.toal at gmail.com Mon May 18 20:19:12 2015 From: brian.toal at gmail.com (Brian Toal) Date: Mon, 18 May 2015 13:19:12 -0700 Subject: distinguishing my jdk derivative by setting java_runtime_name Message-ID: I'd like to be able to distinguish my openjdk build from others, by setting java_runtime_name to something that signifies my openjdk derivative. Is it possible to set java_runtime_name that's used in .//jdk/src/share/classes/sun/misc/Version.java.template via configure? How do others typically do this? From magnus.ihse.bursie at oracle.com Mon May 18 22:08:36 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 19 May 2015 00:08:36 +0200 Subject: RFR: JDK-8080630 Stop doing sed manipulation of manifest files in SetupJavaCompilation Message-ID: <555A62E4.7000704@oracle.com> We're currently breaking abstraction barriers by doing a sed replacement of $(RELEASE) and $(COMPANY_NAME) in SetupJavaCompilation. This replacement should be moved to a more proper place. Unfortunately there were no shared dependencies between jrtfs-jar and demos, apart from buildtools. :( I tried adding it to the buildtools generation (which felt hackish anyway) but that broke since we include Tools.gmk multiple times which caused races with the generation of the manifest file. :-( We should probably do something about this (this will likely require a split of Tools.gmk into generation of tools and definition of command lines) but that was outside the scope for this fix, which is prompted by the version string changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8080630 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8080630-no-sed-on-manifest/webrev.01 /Magnus From david.holmes at oracle.com Mon May 18 23:31:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 May 2015 09:31:04 +1000 Subject: distinguishing my jdk derivative by setting java_runtime_name In-Reply-To: References: Message-ID: <555A7638.4090405@oracle.com> On 19/05/2015 6:19 AM, Brian Toal wrote: > I'd like to be able to distinguish my openjdk build from others, by > setting java_runtime_name to something that signifies my openjdk > derivative. Is it possible to set java_runtime_name that's used > in .//jdk/src/share/classes/sun/misc/Version.java.template via configure? I think you just edit common/autoconf/version-numbers David > How do others typically do this? > From erik.joelsson at oracle.com Tue May 19 07:47:08 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 May 2015 09:47:08 +0200 Subject: RFR: JDK-8080630 Stop doing sed manipulation of manifest files in SetupJavaCompilation In-Reply-To: <555A62E4.7000704@oracle.com> References: <555A62E4.7000704@oracle.com> Message-ID: <555AEA7C.1020806@oracle.com> Looks good to me. Regarding Tools.gmk, that has annoyed me for a long time, but not quite taken me to the point of doing something about it. /Erik On 2015-05-19 00:08, Magnus Ihse Bursie wrote: > We're currently breaking abstraction barriers by doing a sed > replacement of $(RELEASE) and $(COMPANY_NAME) in SetupJavaCompilation. > This replacement should be moved to a more proper place. > > Unfortunately there were no shared dependencies between jrtfs-jar and > demos, apart from buildtools. :( I tried adding it to the buildtools > generation (which felt hackish anyway) but that broke since we include > Tools.gmk multiple times which caused races with the generation of the > manifest file. :-( We should probably do something about this (this > will likely require a split of Tools.gmk into generation of tools and > definition of command lines) but that was outside the scope for this > fix, which is prompted by the version string changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8080630 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8080630-no-sed-on-manifest/webrev.01 > > /Magnus From volker.simonis at gmail.com Wed May 20 09:50:09 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 May 2015 11:50:09 +0200 Subject: RFR: JDK-8074859 Turn on warnings as error In-Reply-To: <554D8D74.4030505@oracle.com> References: <55310207.9050207@oracle.com> <5534A475.2090909@oracle.com> <554C6C7E.9000309@oracle.com> <554C7494.40209@oracle.com> <554D8D74.4030505@oracle.com> Message-ID: Hi, I'm a little confused about this change. I finally found some time to look at it, because it makes most of our nightly jdk9/dev builds fail. Now I've looked at the 'simplest possible failure' which happens on linux/amd64. The failure is the following: /net/usr.work/openjdk/nb/linuxx86_64/nightly/jdk9/jdk/src/java.base/share/native/libjava/jdk_util.c:79:5: error: comparison of unsigned expression >= 0 is always true [-Werror=type-limits] First I thought this is because we are using a different version of GCC but I've just verified that this warning which is now turned into an error happens with all version of GCC starting from at least 4.3 up to 4.8. So do you do your regular builds on linux/amd64 by default with "--disable-warnings-as-errors" now? Reading you first mail, the code should compile fine on the build systems used internally at Oracle and according to https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms they should use gcc 4.8.2. So what's the problem here or am I doing something wrong? Thank you and best regards, Volker On Sat, May 9, 2015 at 6:30 AM, Tim Bell wrote: > Magnus: > > Looks good to me as well. > > Tim > > > On 05/08/15 01:32, Erik Joelsson wrote: >> >> Looks good. >> >> /Erik >> >> On 2015-05-08 09:57, Magnus Ihse Bursie wrote: >>> >>> On 2015-04-20 09:02, Erik Joelsson wrote: >>>> >>>> Looks good to me. >>> >>> Thanks Erik. >>> >>> Unfortunately, I never got round to pushing this. In the meantime, the >>> codebase evolved, and I had to add a couple of more disabled warnings. I >>> also modified the help text on a failed build slightly. >>> >>> Here's the updated webrev: >>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors/webrev.01 >>> >>> /Magnus >>> >>> >>>> >>>> /Erik >>>> >>>> On 2015-04-17 14:52, Magnus Ihse Bursie wrote: >>>>> >>>>> With JDK-8074096, the number of warnings in the product was reduced to >>>>> a minimum. This enables the next step, which is turning on the respective >>>>> compiler flags that turns warnings into errors. In the long run, this is the >>>>> only way to keep the warnings from creeping back. >>>>> >>>>> Even with JDK-8074096, the product does not build 100% warning free. >>>>> This is due to some warnings that cannot be disabled, or (in one case) where >>>>> C and C++ code is mixed, and warnings for both languages cannot be used. A >>>>> system similar to the one introduced in JDK-8074096 is therefore needed, in >>>>> which individual libraries can be exempted from this flag, until such >>>>> warnings are fixed. A library can thus disable warnings as errors with >>>>> WARNINGS_AS_ERRORS := false, or (better) use a toolchain-specific version, >>>>> e.g WARNINGS_AS_ERRORS_gcc := false. This is intended as a temporary >>>>> measure, though. The long-term solution is reasonably to fix the warnings >>>>> and remove that argument. >>>>> >>>>> Also, different versions of compilers can generate a different set of >>>>> warnings. It is therefore necessary to be able to turn off this globally. >>>>> Therefor a new flag for configure is introduced: >>>>> --disable-warnings-as-errors. >>>>> >>>>> While the code compiles without errors on the build systems used >>>>> internally at Oracle, this might not be the case on other combinations of >>>>> operating system versions and toolchain versions. To facilitate for >>>>> unexpecting developers, a help message is added if the build fails, that >>>>> suggests using --disable-warnings-as-errors. This solution was chosen as a >>>>> compromise between the "hard core" solution of turning on warnings as errors >>>>> by default for anyone, and the cowar... erm, conservative solution of >>>>> checking if the compiler versions exactly match what's used inside Oracle >>>>> (and therefore regularly tested), and only turn it on in that case. >>>>> >>>>> Similarly to JDK-8074096, I intend to file follow-up bugs for each >>>>> individual library that got a WARNINGS_AS_ERRORS_* := false. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074859 >>>>> WebRev for top: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-top/webrev.01 >>>>> WebRev for jdk: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-jdk/webrev.01 >>>>> >>>>> Some comments: >>>>> >>>>> * I needed to add a few more DISABLED_WARNINGS. For windows, this is >>>>> most likely due to the recent compiler change. For other libraries, I'm not >>>>> sure, but it might well be the result of recent changes that has introduced >>>>> new warnings. If so, it highlights the need of this patch to keep the build >>>>> warning free. >>>>> >>>>> * For a few libraries and toolchains, there is *both* >>>>> WARNINGS_AS_ERRORS := false and a DISABLED_WARNINGS list. This is the case >>>>> if not all warnings are possible to disable. >>>>> >>>>> * I have removed some incorrect uses of SHARED_LIBRARY_FLAGS. This is >>>>> included in our JDK LDFLAGS, so it should not be set separately, and >>>>> definitely not as CFLAGS. (This caused compiler warnings, which now turned >>>>> into errors.) However, a more suitable long-term solution is probably to >>>>> move the knowledge of how to create shared libraries more specifically into >>>>> SetupNativeCompilation, and not set it as part of the JDK flags. >>>>> >>>>> /Magnus >>>> >>>> >>> >> > From david.holmes at oracle.com Wed May 20 10:03:21 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 May 2015 20:03:21 +1000 Subject: RFR: JDK-8074859 Turn on warnings as error In-Reply-To: References: <55310207.9050207@oracle.com> <5534A475.2090909@oracle.com> <554C6C7E.9000309@oracle.com> <554C7494.40209@oracle.com> <554D8D74.4030505@oracle.com> Message-ID: <555C5BE9.3060507@oracle.com> Hi Volker, On 20/05/2015 7:50 PM, Volker Simonis wrote: > Hi, > > I'm a little confused about this change. I finally found some time to > look at it, because it makes most of our nightly jdk9/dev builds fail. > Now I've looked at the 'simplest possible failure' which happens on > linux/amd64. The failure is the following: > > /net/usr.work/openjdk/nb/linuxx86_64/nightly/jdk9/jdk/src/java.base/share/native/libjava/jdk_util.c:79:5: > error: comparison of unsigned expression >= 0 is always true > [-Werror=type-limits] > > First I thought this is because we are using a different version of > GCC but I've just verified that this warning which is now turned into > an error happens with all version of GCC starting from at least 4.3 up > to 4.8. > > So do you do your regular builds on linux/amd64 by default with > "--disable-warnings-as-errors" now? In jdk/make/lib/CoreLibraries.gmk there should be this fragment: $(eval $(call SetupNativeCompilation,BUILD_LIBJAVA, \ LIBRARY := java, \ OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ SRC := $(LIBJAVA_SRC_DIRS), \ OPTIMIZATION := HIGH, \ CFLAGS := $(CFLAGS_JDKLIB) \ $(LIBJAVA_CFLAGS), \ DISABLED_WARNINGS_gcc := type-limits format-nonliteral, \ which disables the warning you are seeing. David ----- > Reading you first mail, the code should compile fine on the build > systems used internally at Oracle and according to > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > they should use gcc 4.8.2. > > So what's the problem here or am I doing something wrong? > > Thank you and best regards, > Volker > > > On Sat, May 9, 2015 at 6:30 AM, Tim Bell wrote: >> Magnus: >> >> Looks good to me as well. >> >> Tim >> >> >> On 05/08/15 01:32, Erik Joelsson wrote: >>> >>> Looks good. >>> >>> /Erik >>> >>> On 2015-05-08 09:57, Magnus Ihse Bursie wrote: >>>> >>>> On 2015-04-20 09:02, Erik Joelsson wrote: >>>>> >>>>> Looks good to me. >>>> >>>> Thanks Erik. >>>> >>>> Unfortunately, I never got round to pushing this. In the meantime, the >>>> codebase evolved, and I had to add a couple of more disabled warnings. I >>>> also modified the help text on a failed build slightly. >>>> >>>> Here's the updated webrev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors/webrev.01 >>>> >>>> /Magnus >>>> >>>> >>>>> >>>>> /Erik >>>>> >>>>> On 2015-04-17 14:52, Magnus Ihse Bursie wrote: >>>>>> >>>>>> With JDK-8074096, the number of warnings in the product was reduced to >>>>>> a minimum. This enables the next step, which is turning on the respective >>>>>> compiler flags that turns warnings into errors. In the long run, this is the >>>>>> only way to keep the warnings from creeping back. >>>>>> >>>>>> Even with JDK-8074096, the product does not build 100% warning free. >>>>>> This is due to some warnings that cannot be disabled, or (in one case) where >>>>>> C and C++ code is mixed, and warnings for both languages cannot be used. A >>>>>> system similar to the one introduced in JDK-8074096 is therefore needed, in >>>>>> which individual libraries can be exempted from this flag, until such >>>>>> warnings are fixed. A library can thus disable warnings as errors with >>>>>> WARNINGS_AS_ERRORS := false, or (better) use a toolchain-specific version, >>>>>> e.g WARNINGS_AS_ERRORS_gcc := false. This is intended as a temporary >>>>>> measure, though. The long-term solution is reasonably to fix the warnings >>>>>> and remove that argument. >>>>>> >>>>>> Also, different versions of compilers can generate a different set of >>>>>> warnings. It is therefore necessary to be able to turn off this globally. >>>>>> Therefor a new flag for configure is introduced: >>>>>> --disable-warnings-as-errors. >>>>>> >>>>>> While the code compiles without errors on the build systems used >>>>>> internally at Oracle, this might not be the case on other combinations of >>>>>> operating system versions and toolchain versions. To facilitate for >>>>>> unexpecting developers, a help message is added if the build fails, that >>>>>> suggests using --disable-warnings-as-errors. This solution was chosen as a >>>>>> compromise between the "hard core" solution of turning on warnings as errors >>>>>> by default for anyone, and the cowar... erm, conservative solution of >>>>>> checking if the compiler versions exactly match what's used inside Oracle >>>>>> (and therefore regularly tested), and only turn it on in that case. >>>>>> >>>>>> Similarly to JDK-8074096, I intend to file follow-up bugs for each >>>>>> individual library that got a WARNINGS_AS_ERRORS_* := false. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074859 >>>>>> WebRev for top: >>>>>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-top/webrev.01 >>>>>> WebRev for jdk: >>>>>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-jdk/webrev.01 >>>>>> >>>>>> Some comments: >>>>>> >>>>>> * I needed to add a few more DISABLED_WARNINGS. For windows, this is >>>>>> most likely due to the recent compiler change. For other libraries, I'm not >>>>>> sure, but it might well be the result of recent changes that has introduced >>>>>> new warnings. If so, it highlights the need of this patch to keep the build >>>>>> warning free. >>>>>> >>>>>> * For a few libraries and toolchains, there is *both* >>>>>> WARNINGS_AS_ERRORS := false and a DISABLED_WARNINGS list. This is the case >>>>>> if not all warnings are possible to disable. >>>>>> >>>>>> * I have removed some incorrect uses of SHARED_LIBRARY_FLAGS. This is >>>>>> included in our JDK LDFLAGS, so it should not be set separately, and >>>>>> definitely not as CFLAGS. (This caused compiler warnings, which now turned >>>>>> into errors.) However, a more suitable long-term solution is probably to >>>>>> move the knowledge of how to create shared libraries more specifically into >>>>>> SetupNativeCompilation, and not set it as part of the JDK flags. >>>>>> >>>>>> /Magnus >>>>> >>>>> >>>> >>> >> From magnus.ihse.bursie at oracle.com Wed May 20 12:16:35 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 20 May 2015 14:16:35 +0200 Subject: RFR: JDK-8074859 Turn on warnings as error In-Reply-To: References: <55310207.9050207@oracle.com> <5534A475.2090909@oracle.com> <554C6C7E.9000309@oracle.com> <554C7494.40209@oracle.com> <554D8D74.4030505@oracle.com> Message-ID: <555C7B23.7070101@oracle.com> On 2015-05-20 11:50, Volker Simonis wrote: > Hi, > > I'm a little confused about this change. I finally found some time to > look at it, because it makes most of our nightly jdk9/dev builds fail. > Now I've looked at the 'simplest possible failure' which happens on > linux/amd64. The failure is the following: > > /net/usr.work/openjdk/nb/linuxx86_64/nightly/jdk9/jdk/src/java.base/share/native/libjava/jdk_util.c:79:5: > error: comparison of unsigned expression >= 0 is always true > [-Werror=type-limits] > > First I thought this is because we are using a different version of > GCC but I've just verified that this warning which is now turned into > an error happens with all version of GCC starting from at least 4.3 up > to 4.8. > > So do you do your regular builds on linux/amd64 by default with > "--disable-warnings-as-errors" now? > > Reading you first mail, the code should compile fine on the build > systems used internally at Oracle and according to > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > they should use gcc 4.8.2. > > So what's the problem here or am I doing something wrong? As David says, this warning should have been disabled. Can you paste the entire command line for the gcc compilation of jdk_util.c? It should contain a -Wno-type-limits. /Magnus From ingemar.aberg at oracle.com Wed May 20 12:22:27 2015 From: ingemar.aberg at oracle.com (Ingemar Aberg) Date: Wed, 20 May 2015 14:22:27 +0200 Subject: RFR: 8080758 test/lib/Makefile leaves artifacts in the source tree Message-ID: <555C7C83.7040905@oracle.com> Hi, Please review this change of test/lib/Makefile New features: 1) allow the Makefile to put artifacts/temporaries in a user-specified directory instead of in the source tree 2) split the build directories to allow parallel builds without risking one target messing with files used by another bug: https://bugs.openjdk.java.net/browse/JDK-8080758 webrev: http://cr.openjdk.java.net/~iaberg/JDK-8080758/main.00/ /Ingemar From erik.joelsson at oracle.com Wed May 20 12:32:54 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 May 2015 14:32:54 +0200 Subject: [8u60] Request for review and approval: JDK-8074523: Java.net bundle has incorrect file version for jre/jdk Message-ID: <555C7EF6.1010208@oracle.com> Please review and approve this fix for 8u60. On windows, native libraries and executables have version numbers embedded into them. These can be seen when right-clicking the binary in explorer, on the Details tab, as "Product version". Currently in 8 update releases, these versions strings are inconsistent. An example: in 8u45 b09 we have: bin\client\jvm.dll: 8.0.0.9 bin\decora_sse.dll: 8.0.45.09 bin\deploy.dll: 8.0.450.9 bin\java.exe: 8.0.45.9 These differences fall into 4 different categories. 1. jvm.dll in hotspot is not picking up the update version at all. This is due to a bug in the build-infra makefile rewrite that wasn't discovered in JDK 8 because it didn't have an update version. 2. decora_sse.dll is part of javafx. Fixing their version scheme is out of scope of this fix. A separate bug for javafx would be needed. 3. deploy.dll is actually the correct one. Historically we have encoded the update version with an extra digit for a potential letter at the end of the string. 4. java.exe, and the rest of the binaries from the jdk repository lost their extra 0 in the build-infra makefile rewrite and it wasn't discovered in JDK 8. Since we no longer use letters in update version strings, we could fix this by removing the extra 0. However, we have already released 8 updates where some binaries have the extra 0. Removing it would mean releasing 8u60 with binaries having version numbers lower than previous updates. For this reason I propose fixing this by adding the 0 for JDK and Hotspot binaries again, and of course by supplying the correct variable to the hotspot makefiles so that it even gets the update version in there. For clarity, with this patch, the above will log like this: bin\client\jvm.dll: 8.0.450.9 bin\decora_sse.dll: 8.0.45.09 bin\deploy.dll: 8.0.450.9 bin\java.exe: 8.0.450.9 Note that in JDK 9, the version number scheme is being completely reworked so this will not be an issue. Bug: https://bugs.openjdk.java.net/browse/JDK-8074523 Webrev: http://cr.openjdk.java.net/~erikj/8074523/webrev.01/index.html /Erik From volker.simonis at gmail.com Wed May 20 12:37:28 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 May 2015 14:37:28 +0200 Subject: RFR: JDK-8074859 Turn on warnings as error In-Reply-To: <555C7B23.7070101@oracle.com> References: <55310207.9050207@oracle.com> <5534A475.2090909@oracle.com> <554C6C7E.9000309@oracle.com> <554C7494.40209@oracle.com> <554D8D74.4030505@oracle.com> <555C7B23.7070101@oracle.com> Message-ID: On Wed, May 20, 2015 at 2:16 PM, Magnus Ihse Bursie wrote: > On 2015-05-20 11:50, Volker Simonis wrote: >> >> Hi, >> >> I'm a little confused about this change. I finally found some time to >> look at it, because it makes most of our nightly jdk9/dev builds fail. >> Now I've looked at the 'simplest possible failure' which happens on >> linux/amd64. The failure is the following: >> >> >> /net/usr.work/openjdk/nb/linuxx86_64/nightly/jdk9/jdk/src/java.base/share/native/libjava/jdk_util.c:79:5: >> error: comparison of unsigned expression >= 0 is always true >> [-Werror=type-limits] >> >> First I thought this is because we are using a different version of >> GCC but I've just verified that this warning which is now turned into >> an error happens with all version of GCC starting from at least 4.3 up >> to 4.8. >> >> So do you do your regular builds on linux/amd64 by default with >> "--disable-warnings-as-errors" now? >> >> Reading you first mail, the code should compile fine on the build >> systems used internally at Oracle and according to >> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms >> they should use gcc 4.8.2. >> >> So what's the problem here or am I doing something wrong? > > > As David says, this warning should have been disabled. Can you paste the > entire command line for the gcc compilation of jdk_util.c? It should contain > a -Wno-type-limits. > It doesn't and I'm just investigating why... > /Magnus From magnus.ihse.bursie at oracle.com Wed May 20 12:39:51 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 20 May 2015 14:39:51 +0200 Subject: RFR: 8080758 test/lib/Makefile leaves artifacts in the source tree In-Reply-To: <555C7C83.7040905@oracle.com> References: <555C7C83.7040905@oracle.com> Message-ID: <555C8097.2010600@oracle.com> On 2015-05-20 14:22, Ingemar Aberg wrote: > Hi, > > Please review this change of test/lib/Makefile > > New features: > 1) allow the Makefile to put artifacts/temporaries in a user-specified > directory instead of in the source tree > 2) split the build directories to allow parallel builds without > risking one target messing with files used by another > > bug: https://bugs.openjdk.java.net/browse/JDK-8080758 > > webrev: http://cr.openjdk.java.net/~iaberg/JDK-8080758/main.00/ I'm not really happy with the lack of integration of the build of the testlib with the rest of the product. :-( However, that is not relevant for this fix. The changes look good. /Magnus From sean.coffey at oracle.com Wed May 20 12:49:37 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 20 May 2015 13:49:37 +0100 Subject: [8u60] Request for review and approval: JDK-8074523: Java.net bundle has incorrect file version for jre/jdk In-Reply-To: <555C7EF6.1010208@oracle.com> References: <555C7EF6.1010208@oracle.com> Message-ID: <555C82E1.6010606@oracle.com> It might be good to edit the bug synopsis before pushing the change. I don't think this issue is specific to java.net bundles. Might also be useful to use the noreg-sqe label rather than noreg-build given that SQE team do appear to have test code for this area. Approved pending code review. Regards, Sean. On 20/05/15 13:32, Erik Joelsson wrote: > Please review and approve this fix for 8u60. > > On windows, native libraries and executables have version numbers > embedded into them. These can be seen when right-clicking the binary > in explorer, on the Details tab, as "Product version". Currently in 8 > update releases, these versions strings are inconsistent. An example: > > in 8u45 b09 we have: > > bin\client\jvm.dll: 8.0.0.9 > bin\decora_sse.dll: 8.0.45.09 > bin\deploy.dll: 8.0.450.9 > bin\java.exe: 8.0.45.9 > > These differences fall into 4 different categories. > > 1. jvm.dll in hotspot is not picking up the update version at all. > This is due to a bug in the build-infra makefile rewrite that wasn't > discovered in JDK 8 because it didn't have an update version. > > 2. decora_sse.dll is part of javafx. Fixing their version scheme is > out of scope of this fix. A separate bug for javafx would be needed. > > 3. deploy.dll is actually the correct one. Historically we have > encoded the update version with an extra digit for a potential letter > at the end of the string. > > 4. java.exe, and the rest of the binaries from the jdk repository lost > their extra 0 in the build-infra makefile rewrite and it wasn't > discovered in JDK 8. > > Since we no longer use letters in update version strings, we could fix > this by removing the extra 0. However, we have already released 8 > updates where some binaries have the extra 0. Removing it would mean > releasing 8u60 with binaries having version numbers lower than > previous updates. For this reason I propose fixing this by adding the > 0 for JDK and Hotspot binaries again, and of course by supplying the > correct variable to the hotspot makefiles so that it even gets the > update version in there. For clarity, with this patch, the above will > log like this: > > bin\client\jvm.dll: 8.0.450.9 > bin\decora_sse.dll: 8.0.45.09 > bin\deploy.dll: 8.0.450.9 > bin\java.exe: 8.0.450.9 > > Note that in JDK 9, the version number scheme is being completely > reworked so this will not be an issue. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074523 > Webrev: http://cr.openjdk.java.net/~erikj/8074523/webrev.01/index.html > > /Erik From semyon.sadetsky at oracle.com Wed May 20 13:23:47 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 20 May 2015 16:23:47 +0300 Subject: Ubuntu jdk9 build error Message-ID: <555C8AE3.20307@oracle.com> Hi, Could somebody advise what can be the reason for the next build error: Compiling 161 files for BUILD_TOOLS_JDK Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. GensrcMisc.gmk:63: *** You have to specify LANG for native compilation BUILD_GENSRC_SOR_EXE. Stop. make[2]: *** [java.base-gensrc-jdk] Error 1 make[1]: *** [main] Error 1 make: *** [default] Error 2 setting LANG to C affects nothing. Thank you. --Semyon Sadetsky From erik.joelsson at oracle.com Wed May 20 14:06:49 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 May 2015 16:06:49 +0200 Subject: Ubuntu jdk9 build error In-Reply-To: <555C8AE3.20307@oracle.com> References: <555C8AE3.20307@oracle.com> Message-ID: <555C94F9.5000209@oracle.com> It looks like your repositories are out of sync with each other. Specifically your jdk repository has been updated later than your root repository. /Erik On 2015-05-20 15:23, Semyon Sadetsky wrote: > Hi, > > Could somebody advise what can be the reason for the next build error: > > Compiling 161 files for BUILD_TOOLS_JDK > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > GensrcMisc.gmk:63: *** You have to specify LANG for native compilation > BUILD_GENSRC_SOR_EXE. Stop. > make[2]: *** [java.base-gensrc-jdk] Error 1 > make[1]: *** [main] Error 1 > make: *** [default] Error 2 > > setting LANG to C affects nothing. > > Thank you. > --Semyon Sadetsky > From erik.joelsson at oracle.com Wed May 20 14:09:40 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 May 2015 16:09:40 +0200 Subject: [8u60] Request for review and approval: JDK-8074523: Windows native binaries have inconsistent "Product version" In-Reply-To: <555C82E1.6010606@oracle.com> References: <555C7EF6.1010208@oracle.com> <555C82E1.6010606@oracle.com> Message-ID: <555C95A4.5010801@oracle.com> Thanks, changed to: Windows native binaries have inconsistent "Product version" Changed the label. /Erik On 2015-05-20 14:49, Se?n Coffey wrote: > It might be good to edit the bug synopsis before pushing the change. I > don't think this issue is specific to java.net bundles. Might also be > useful to use the noreg-sqe label rather than noreg-build given that > SQE team do appear to have test code for this area. > > Approved pending code review. > > Regards, > Sean. > > On 20/05/15 13:32, Erik Joelsson wrote: >> Please review and approve this fix for 8u60. >> >> On windows, native libraries and executables have version numbers >> embedded into them. These can be seen when right-clicking the binary >> in explorer, on the Details tab, as "Product version". Currently in 8 >> update releases, these versions strings are inconsistent. An example: >> >> in 8u45 b09 we have: >> >> bin\client\jvm.dll: 8.0.0.9 >> bin\decora_sse.dll: 8.0.45.09 >> bin\deploy.dll: 8.0.450.9 >> bin\java.exe: 8.0.45.9 >> >> These differences fall into 4 different categories. >> >> 1. jvm.dll in hotspot is not picking up the update version at all. >> This is due to a bug in the build-infra makefile rewrite that wasn't >> discovered in JDK 8 because it didn't have an update version. >> >> 2. decora_sse.dll is part of javafx. Fixing their version scheme is >> out of scope of this fix. A separate bug for javafx would be needed. >> >> 3. deploy.dll is actually the correct one. Historically we have >> encoded the update version with an extra digit for a potential letter >> at the end of the string. >> >> 4. java.exe, and the rest of the binaries from the jdk repository >> lost their extra 0 in the build-infra makefile rewrite and it wasn't >> discovered in JDK 8. >> >> Since we no longer use letters in update version strings, we could >> fix this by removing the extra 0. However, we have already released 8 >> updates where some binaries have the extra 0. Removing it would mean >> releasing 8u60 with binaries having version numbers lower than >> previous updates. For this reason I propose fixing this by adding the >> 0 for JDK and Hotspot binaries again, and of course by supplying the >> correct variable to the hotspot makefiles so that it even gets the >> update version in there. For clarity, with this patch, the above will >> log like this: >> >> bin\client\jvm.dll: 8.0.450.9 >> bin\decora_sse.dll: 8.0.45.09 >> bin\deploy.dll: 8.0.450.9 >> bin\java.exe: 8.0.450.9 >> >> Note that in JDK 9, the version number scheme is being completely >> reworked so this will not be an issue. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074523 >> Webrev: http://cr.openjdk.java.net/~erikj/8074523/webrev.01/index.html >> >> /Erik > From yekaterina.kantserova at oracle.com Wed May 20 12:29:23 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 20 May 2015 14:29:23 +0200 Subject: RFR: 8080758 test/lib/Makefile leaves artifacts in the source tree In-Reply-To: <555C7C83.7040905@oracle.com> References: <555C7C83.7040905@oracle.com> Message-ID: <555C7E23.6070901@oracle.com> Looks good to me! // Katja (not a reviewer) On 05/20/2015 02:22 PM, Ingemar Aberg wrote: > Hi, > > Please review this change of test/lib/Makefile > > New features: > 1) allow the Makefile to put artifacts/temporaries in a user-specified > directory instead of in the source tree > 2) split the build directories to allow parallel builds without > risking one target messing with files used by another > > bug: https://bugs.openjdk.java.net/browse/JDK-8080758 > > webrev: http://cr.openjdk.java.net/~iaberg/JDK-8080758/main.00/ > > /Ingemar > From erik.joelsson at oracle.com Wed May 20 15:15:57 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 May 2015 17:15:57 +0200 Subject: make[2]: *** No rule to make target..'/home/*/...needed by jtreg_tests In-Reply-To: References: Message-ID: <555CA52D.7010308@oracle.com> It seems jdk/test/Makefile is still looking for j2sdk-image as a fallback default, but it has been changed to be just images/jdk. If you run tests from the top level that shouldn't happen. Alternatively you can specify PRODUCT_HOME=/path/to/your/jdk/image. You could of course also fix the bug in jdk/test/Makefile. /Erik On 2015-04-26 22:44, Kingsley Osime wrote: > I am trying to build openjdk and everything seems to have gone ok except > when I test i get make[2]: *** No rule to make target > `/home/hellofadude/dev/openjdk/jdk9/build/linux-x86_64-normal-server-release/images/j2sdk-image', > needed by `jtreg_tests'. > > I also notice my build does not produce the j2sdk-image directory even > after several tries and can not understand why? > > Perhaps someone can cast an expert eye over my build log ? > > Thanks > > Compiling 5 files for BUILD_GENMODULESLIST > Compiling 8 files for BUILD_TOOLS_LANGTOOLS > Compiling 20 properties into resource bundles for jdk.compiler > Parsing 1 properties into enum-like class for jdk.compiler > Compiling 5 properties into resource bundles for jdk.dev > Compiling 10 properties into resource bundles for jdk.javadoc > Compiling 821 files for BUILD_INTERIM_LANGTOOLS > Creating buildtools/interim_langtools.jar > Compiling 23 files for BUILD_INTERIM_JIMAGE > Compiling 161 files for BUILD_TOOLS_JDK > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Creating sun/util/locale/provider/EnLocaleDataMetaInfo.java from 424 found > resources. > Generating sun/misc/Version.java > Creating genSocketOptionRegistry from 1 file(s) > Creating genUnixConstants from 1 file(s) > Generating buffer classes > Generating exceptions classes > Compiling 11 properties into resource bundles for java.base > Compiling 22 properties into resource bundles for java.base > Compiling 2752 files for java.base > Compiling 1814 files for java.xml > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Compiling 13 files for java.prefs > Compiling 131 files for jdk.charsets > Compiling 16 files for java.datatransfer > Compiling 11 properties into resource bundles for java.logging > Compiling 32 files for java.logging > Generating icon classes > Generating X11 wrapper (64-bit version) > Verifying > /home/hellofadude/dev/openjdk/jdk9/build/linux-x86_64-normal-server-release/support/gensrc/java.desktop/_x11wrappers/sizes.64.verification.tmp > to > /home/hellofadude/dev/openjdk/jdk9/build/linux-x86_64-normal-server-release/support/gensrc/java.desktop/_x11wrappers/sizes.64 > Generating beaninfo > Generating Nimbus source files > Compiling 100 properties into resource bundles for java.desktop > Compiling 2755 files for java.desktop > Compiling 24 files for java.activation > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Compiling 5 files for java.annotations.common > Compiling 4 files for BUILD_BREAKITERATOR > Generating blacklisted certs > Creating support/jce/policy/unlimited/US_export_policy.jar > Creating support/jce/policy/limited/local_policy.jar > Creating support/jce/policy/unlimited/local_policy.jar > Generating java.security > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Warning: generation and use of skeletons and static stubs for JRMP > is deprecated. Skeletons are unnecessary, and static stubs have > been superseded by dynamically generated stubs. Users are > encouraged to migrate away from using rmic to generate skeletons and static > stubs. See the documentation for java.rmi.server.UnicastRemoteObject. > All done. > Generating linux_amd64_docs/jvmti.html > Creating libverify.so from 2 file(s) > Creating libjava.so from 60 file(s) > Creating libfdlibm.a from 62 file(s) > Creating libzip.so from 21 file(s) > Creating libjli.so from 15 file(s) > Creating libnet.so from 21 file(s) > Creating libnio.so from 25 file(s) > Creating java from 1 file(s) > Creating keytool from 1 file(s) > Creating jexec from 1 file(s) > Compiling 114 files for java.compiler > Compiling 141 files for BUILD_IDLJ > Note: > /home/hellofadude/dev/openjdk/jdk9/corba/src/java.corba/share/classes/com/sun/tools/corba/se/idl/som/idlemit/MetaPragma.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Compiling 6 files for BUILD_TOOLS_CORBA > Compiling 133 files for java.rmi > Compiling 3 files for java.transaction > Compiling 29 files for java.security.sasl > Compiling 191 files for java.naming > Compiling 1476 files for java.corba > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Creating idlj from 1 file(s) > Creating orbd from 1 file(s) > Creating servertool from 1 file(s) > Creating tnameserv from 1 file(s) > Generating HTML DTD file > [Parsed DTD html32 in 897ms] > Creating libmlib_image.so from 55 file(s) > Creating libawt.so from 72 file(s) > Creating libawt_xawt.so from 53 file(s) > /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/unix/native/common/awt/awt_Font.c: > In function ?awtJNI_GetFontData?: > /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/unix/native/common/awt/awt_Font.c:643:23: > warning: comparison between pointer and integer [enabled by default] > if (xfont == (Font) NULL || xfont->ascent < 0) { > ^ > /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:69:0: > warning: "MIN" redefined [enabled by default] > #define MIN(a, b) (((a) < (b)) ? (a) : (b)) > ^ > In file included from > /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.base/unix/native/include/jvm_md.h:35:0, > from > /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:33: > /usr/include/x86_64-linux-gnu/sys/param.h:99:0: note: this is the location > of the previous definition > #define MIN(a,b) (((a)<(b))?(a):(b)) > ^ > Creating liblcms.so from 26 file(s) > Creating libjavajpeg.so from 46 file(s) > Creating libawt_headless.so from 26 file(s) > Creating libfontmanager.so from 94 file(s) > cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++ > but not for C [enabled by default] > cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is valid > for C++/ObjC++ but not for C [enabled by default] > cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++ > but not for C [enabled by default] > cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is valid > for C++/ObjC++ but not for C [enabled by default] > cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++ > but not for C [enabled by default] > cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is valid > for C++/ObjC++ but not for C [enabled by default] > cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++ > but not for C [enabled by default] > cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is valid > for C++/ObjC++ but not for C [enabled by default] > cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++ > but not for C [enabled by default] > cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is valid > for C++/ObjC++ but not for C [enabled by default] > /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/share/native/libfontmanager/sunFont.c: > In function ?freeLayoutTableCache?: > /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/share/native/libfontmanager/sunFont.c:357:7: > warning: passing argument 1 of ?free? discards ?const? qualifier from > pointer target type [enabled by default] > if(ltc->entries[i].ptr) free (ltc->entries[i].ptr); > ^ > In file included from > /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/share/native/libfontmanager/sunFont.c:26:0: > /usr/include/stdlib.h:483:13: note: expected ?void *? but argument is of > type ?const void *? > extern void free (void *__ptr) __THROW; > ^ > Creating libjawt.so from 1 file(s) > Creating libsplashscreen.so from 84 file(s) > Creating libjsound.so from 2 file(s) > Creating libjsoundalsa.so from 17 file(s) > Creating appletviewer from 1 file(s) > Compiling 7 files for java.instrument > Creating libinstrument.so from 12 file(s) > Compiling 11 properties into resource bundles for java.management > Compiling 393 files for java.management > Compiling 1688 files for BUILD_INTERIM_CORBA > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Creating buildtools/interim_corba.jar > Compiling 198 files for BUILD_INTERIM_RMIC > Warning: generation and use of skeletons and static stubs for JRMP > is deprecated. Skeletons are unnecessary, and static stubs have > been superseded by dynamically generated stubs. Users are > encouraged to migrate away from using rmic to generate skeletons and > static > stubs. See the documentation for java.rmi.server.UnicastRemoteObject. > Warning: generation and use of skeletons and static stubs for JRMP > is deprecated. Skeletons are unnecessary, and static stubs have > been superseded by dynamically generated stubs. Users are > encouraged to migrate away from using rmic to generate skeletons and > static > stubs. See the documentation for java.rmi.server.UnicastRemoteObject. > Creating libmanagement.so from 16 file(s) > Creating libprefs.so from 1 file(s) > Warning: generation and use of skeletons and static stubs for JRMP > is deprecated. Skeletons are unnecessary, and static stubs have > been superseded by dynamically generated stubs. Users are > encouraged to migrate away from using rmic to generate skeletons and > static > stubs. See the documentation for java.rmi.server.UnicastRemoteObject. > Warning: generation and use of skeletons and static stubs for JRMP > is deprecated. Skeletons are unnecessary, and static stubs have > been superseded by dynamically generated stubs. Users are > encouraged to migrate away from using rmic to generate skeletons and > static > stubs. See the documentation for java.rmi.server.UnicastRemoteObject. > Creating rmid from 1 file(s) > Creating rmiregistry from 1 file(s) > Compiling 13 files for java.scripting > Creating jrunscript from 1 file(s) > Compiling 211 files for java.security.jgss > Creating libj2gss.so from 3 file(s) > Compiling 20 files for java.smartcardio > Creating libj2pcsc.so from 2 file(s) > Compiling 72 files for java.sql > Compiling 50 files for java.sql.rowset > Compiling 745 files for java.xml.bind > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Compiling 281 files for java.xml.crypto > Compiling 43 files for jdk.httpserver > Compiling 1224 files for java.xml.ws > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Compiling 17 files for jdk.accessibility > Compiling 68 files for jdk.jvmstat > Compiling 14 files for jdk.attach > Creating libattach.so from 1 file(s) > Compiling 442 files for jdk.compiler > Creating javac from 1 file(s) > Creating javah from 1 file(s) > Creating javap from 1 file(s) > Creating serialver from 1 file(s) > Compiling 8 files for jdk.crypto.ec > Creating libsunec.so from 28 file(s) > Compiling 66 files for jdk.crypto.pkcs11 > Creating libj2pkcs11.so from 14 file(s) > Compiling 1 properties into resource bundles for jdk.dev > Compiling 90 files for jdk.dev > Compiling 1 files for jdk.hprof.agent > Compiling 11 properties into resource bundles for jdk.jartool > Compiling 25 files for jdk.jartool > Compiling 252 files for jdk.javadoc > Compiling 36 files for jdk.jcmd > Compiling 63 files for jdk.jconsole > Compiling 3 properties into resource bundles for jdk.jdi > Compiling 246 files for jdk.jdi > Creating sun/util/resources/provider/NonEnLocaleDataMetaInfo.java from 424 > found resources. > Compiling 209 properties into resource bundles for jdk.localedata > Compiling 1569 files for jdk.localedata > Compiling 16 files for jdk.naming.dns > Compiling 6 files for jdk.naming.rmi > Compiling 13 files for jdk.policytool > Compiling 226 files for jdk.rmic > Note: > /home/hellofadude/dev/openjdk/jdk9/corba/src/jdk.rmic/share/classes/sun/rmi/rmic/iiop/DirectoryLoader.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Compiling 605 files for BUILD_NASHORN > Compiling 111 files for BUILD_NASGEN > Running nasgen > Creating version.properties > Compiling 32 files for jdk.sctp > Compiling 36 files for jdk.security.auth > Compiling 12 files for jdk.security.jgss > Compiling 777 files for jdk.xml.bind > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Compiling 89 files for jdk.xml.dom > Compiling 234 files for jdk.xml.ws > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Compiling 12 files for jdk.zipfs > Warning: generation and use of skeletons and static stubs for JRMP > is deprecated. Skeletons are unnecessary, and static stubs have > been superseded by dynamically generated stubs. Users are > encouraged to migrate away from using rmic to generate skeletons and > static > stubs. See the documentation for java.rmi.server.UnicastRemoteObject. > Creating jdeps from 1 file(s) > Creating jimage from 1 file(s) > Creating jhat from 1 file(s) > Creating native2ascii from 1 file(s) > Creating jsadebugd from 1 file(s) > Creating libhprof.so from 26 file(s) > Creating libjava_crw_demo.so from 1 file(s) > Creating jar from 1 file(s) > Creating jarsigner from 1 file(s) > Creating javadoc from 1 file(s) > Creating jinfo from 1 file(s) > Creating jmap from 1 file(s) > Creating jps from 1 file(s) > Creating jstack from 1 file(s) > Creating jstat from 1 file(s) > Creating jcmd from 1 file(s) > Creating jconsole from 1 file(s) > Creating jdb from 1 file(s) > Creating libdt_socket.so from 2 file(s) > Creating libjdwp.so from 41 file(s) > Creating jstatd from 1 file(s) > Creating libunpack.so from 7 file(s) > Creating pack200 from 1 file(s) > Creating unpack200 from 7 file(s) > /home/hellofadude/dev/openjdk/jdk9/jdk/src/jdk.pack200/share/native/unpack200/main.cpp: > In static member function ?static int unpacker::run(int, char**)?: > /home/hellofadude/dev/openjdk/jdk9/jdk/src/jdk.pack200/share/native/unpack200/main.cpp:438:55: > warning: ignoring return value of ?size_t fread(void*, size_t, size_t, > FILE*)?, declared with attribute warn_unused_result [-Wunused-result] > fread(&filecrc, sizeof(filecrc), 1, u.infileptr); > ^ > Creating policytool from 1 file(s) > Creating rmic from 1 file(s) > Creating jjs from 1 file(s) > Creating libsctp.so from 3 file(s) > Creating libjaas_unix.so from 1 file(s) > Creating schemagen from 1 file(s) > Creating xjc from 1 file(s) > Creating wsgen from 1 file(s) > Creating wsimport from 1 file(s) > Updating support/src.zip > Compiling 1 files for BUILD_DEMO_APPLET_ArcTest > Compiling 1 files for BUILD_DEMO_APPLET_BarChart > Compiling 1 files for BUILD_DEMO_APPLET_Blink > Compiling 1 files for BUILD_DEMO_APPLET_CardTest > Compiling 1 files for BUILD_DEMO_APPLET_Clock > Compiling 1 files for BUILD_DEMO_APPLET_DitherTest > Compiling 1 files for BUILD_DEMO_APPLET_DrawTest > Compiling 1 files for BUILD_DEMO_APPLET_Fractal > Compiling 2 files for BUILD_DEMO_APPLET_GraphicsTest > Compiling 1 files for BUILD_DEMO_APPLET_NervousText > Compiling 1 files for BUILD_DEMO_APPLET_SimpleGraph > Compiling 5 files for BUILD_DEMO_APPLET_SortDemo > Compiling 1 files for BUILD_DEMO_APPLET_SpreadSheet > Compiling 3 files for BUILD_DEMO_CodePointIM > Creating support/demo/image/jfc/CodePointIM/src.zip > Updating support/demo/image/jfc/CodePointIM/src.zip > Compiling 2 files for BUILD_DEMO_MoleculeViewer > Creating support/demo/image/applets/MoleculeViewer/src.zip > Updating support/demo/image/applets/MoleculeViewer/src.zip > Compiling 2 files for BUILD_DEMO_WireFrame > Creating support/demo/image/applets/WireFrame/src.zip > Updating support/demo/image/applets/WireFrame/src.zip > Compiling 1 files for BUILD_DEMO_SwingApplet > Creating support/demo/image/jfc/SwingApplet/src.zip > Updating support/demo/image/jfc/SwingApplet/src.zip > Compiling 3 files for BUILD_DEMO_FileChooserDemo > Note: > /home/hellofadude/dev/openjdk/jdk9/jdk/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Creating support/demo/image/jfc/FileChooserDemo/src.zip > Updating support/demo/image/jfc/FileChooserDemo/src.zip > Compiling 4 files for BUILD_DEMO_Font2DTest > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Creating support/demo/image/jfc/Font2DTest/src.zip > Updating support/demo/image/jfc/Font2DTest/src.zip > Compiling 15 files for BUILD_DEMO_Metalworks > Note: > /home/hellofadude/dev/openjdk/jdk9/jdk/src/demo/share/jfc/Metalworks/MetalworksPrefs.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Creating support/demo/image/jfc/Metalworks/src.zip > Updating support/demo/image/jfc/Metalworks/src.zip > Compiling 2 files for BUILD_DEMO_Notepad > Creating support/demo/image/jfc/Notepad/src.zip > Updating support/demo/image/jfc/Notepad/src.zip > Compiling 5 files for BUILD_DEMO_SampleTree > Creating support/demo/image/jfc/SampleTree/src.zip > Updating support/demo/image/jfc/SampleTree/src.zip > Compiling 8 files for BUILD_DEMO_TableExample > Note: > /home/hellofadude/dev/openjdk/jdk9/jdk/src/demo/share/jfc/TableExample/TableExample4.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Creating support/demo/image/jfc/TableExample/src.zip > Updating support/demo/image/jfc/TableExample/src.zip > Compiling 1 files for BUILD_DEMO_TransparentRuler > Creating support/demo/image/jfc/TransparentRuler/src.zip > Updating support/demo/image/jfc/TransparentRuler/src.zip > Compiling 3 files for BUILD_DEMO_jconsole-plugin > Creating support/demo/image/scripting/jconsole-plugin/src.zip > Updating support/demo/image/scripting/jconsole-plugin/src.zip > Compiling 3 files for BUILD_DEMO_FullThreadDump > Creating support/demo/image/management/FullThreadDump/src.zip > Updating support/demo/image/management/FullThreadDump/src.zip > Compiling 2 files for BUILD_DEMO_JTop > Creating support/demo/image/management/JTop/src.zip > Updating support/demo/image/management/JTop/src.zip > Compiling 1 files for BUILD_DEMO_MemoryMonitor > Creating support/demo/image/management/MemoryMonitor/src.zip > Updating support/demo/image/management/MemoryMonitor/src.zip > Compiling 2 files for BUILD_DEMO_VerboseGC > Creating support/demo/image/management/VerboseGC/src.zip > Updating support/demo/image/management/VerboseGC/src.zip > Creating libcompiledMethodLoad.so from 2 file(s) > Updating support/demo/image/jvmti/compiledMethodLoad/src.zip > Creating libgctest.so from 2 file(s) > Updating support/demo/image/jvmti/gctest/src.zip > Compiling 1 files for BUILD_DEMO_JVMTI_heapTracker_JAVA > Creating support/demo/image/jvmti/heapTracker/heapTracker.jar > Creating libheapTracker.so from 3 file(s) > Updating support/demo/image/jvmti/heapTracker/src.zip > Creating libheapViewer.so from 2 file(s) > Updating support/demo/image/jvmti/heapViewer/src.zip > Compiling 1 files for BUILD_DEMO_JVMTI_minst_JAVA > Creating support/demo/image/jvmti/minst/minst.jar > Creating libminst.so from 3 file(s) > Updating support/demo/image/jvmti/minst/src.zip > Compiling 1 files for BUILD_DEMO_JVMTI_mtrace_JAVA > Creating support/demo/image/jvmti/mtrace/mtrace.jar > Creating libmtrace.so from 3 file(s) > Updating support/demo/image/jvmti/mtrace/src.zip > Creating libwaiters.so from 5 file(s) > Updating support/demo/image/jvmti/waiters/src.zip > Creating libversionCheck.so from 2 file(s) > Updating support/demo/image/jvmti/versionCheck/src.zip > Creating support/jrt-fs.jar > Creating jre jimage > Creating jdk jimage > duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", > skipping > Updating images/sec-bin.zip > ## Starting verify-modules > Checking dependencies across JDK modules > Access verification succeeded. > ## Finished verify-modules (build time 00:01:33) > > ----- Build times ------- > Start 2015-04-25 16:14:07 > End 2015-04-25 21:54:24 > 00:01:33 verify-modules > 05:40:17 TOTAL > ------------------------- > Finished building targets 'clean images' in configuration > 'linux-x86_64-normal-server-release' From ioi.lam at oracle.com Wed May 20 18:15:41 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 20 May 2015 11:15:41 -0700 Subject: Excessive rebuilds of modules Message-ID: <555CCF4D.20301@oracle.com> If I change a line of code in the java.base module, every Java module is rebuilt. However, my change does not change any of the APIs or the module info. I think this means none of the other modules would be affected. If this is true, maybe we can modify the build system to check this and avoid the excessive rebuilds? Thanks - Ioi From joe.darcy at oracle.com Wed May 20 20:10:36 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 20 May 2015 13:10:36 -0700 Subject: Excessive rebuilds of modules In-Reply-To: <555CCF4D.20301@oracle.com> References: <555CCF4D.20301@oracle.com> Message-ID: <555CEA3C.7040107@oracle.com> On 5/20/2015 11:15 AM, Ioi Lam wrote: > If I change a line of code in the java.base module, every Java module > is rebuilt. However, my change does not change any of the APIs or the > module info. > > I think this means none of the other modules would be affected. If > this is true, maybe we can modify the build system to check this and > avoid the excessive rebuilds? > > Thanks > - Ioi From just a module dependency perspective, since everything depends on the base module, everything should rebuilt. The sjavac feature intends to provide the finer-level dependency tracking and rebuilding you're asking for. Cheers, -Joe From Roger.Riggs at Oracle.com Wed May 20 20:12:18 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 20 May 2015 16:12:18 -0400 Subject: Excessive rebuilds of modules In-Reply-To: <555CEA3C.7040107@oracle.com> References: <555CCF4D.20301@oracle.com> <555CEA3C.7040107@oracle.com> Message-ID: <555CEAA2.2040100@Oracle.com> Ioi, You can rebuild just the contents of a single module: % make java.base java.base-libs java.base-launchers Roger On 5/20/2015 4:10 PM, joe darcy wrote: > On 5/20/2015 11:15 AM, Ioi Lam wrote: >> If I change a line of code in the java.base module, every Java module >> is rebuilt. However, my change does not change any of the APIs or the >> module info. >> >> I think this means none of the other modules would be affected. If >> this is true, maybe we can modify the build system to check this and >> avoid the excessive rebuilds? >> >> Thanks >> - Ioi > > From just a module dependency perspective, since everything depends on > the base module, everything should rebuilt. > > The sjavac feature intends to provide the finer-level dependency > tracking and rebuilding you're asking for. > > Cheers, > > -Joe From Alan.Bateman at oracle.com Wed May 20 20:39:21 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 May 2015 21:39:21 +0100 Subject: Excessive rebuilds of modules In-Reply-To: <555CEAA2.2040100@Oracle.com> References: <555CCF4D.20301@oracle.com> <555CEA3C.7040107@oracle.com> <555CEAA2.2040100@Oracle.com> Message-ID: <555CF0F9.3090308@oracle.com> On 20/05/2015 21:12, Roger Riggs wrote: > Ioi, > > You can rebuild just the contents of a single module: > > % make java.base java.base-libs java.base-launchers > Yes, and this works great when you are using an exploded build. It's possible that Ioi is looking for an images build of course. In general then this needs sjavac as Joe brings up. -Alan From peter.brunet at oracle.com Thu May 21 05:33:50 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 21 May 2015 00:33:50 -0500 Subject: RfR JDK-8077296 RE build fails on non-Win builds when attempting to build Win only javadoc Message-ID: <555D6E3E.5030806@oracle.com> Please review the following change for 8u: http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/ Background: - As part of the open sourcing of the JAB and Java Accessibility Utilities (JAU) the JAU Javadoc was setup to be added to the build. - Due to a 8u build issue (it uses source bundles) the Javadoc had to be temporarily disabled: JDK-8076552 - The issue was caused by JAU code being in windows instead of share. - For 9 the JAU code is in jdk.accessibility/share/classes/com/sun/java/accessibility/util (and the JAB code under jdk.accessibility/windows). - For 8u both the JAU and JAB code is in jdk/src/windows. - The problem on 8u is with non-windows builds; the 8 Javadoc build process doesn't find the JAU files because they are in a windows directory. - The fix is to refactor so 8u is like 9 with the JAU files in share; then the javadoc build process will find the source for all build platforms. - Make has been changed so jaccess.jar is built for all platforms - Some obsolete files have been removed as they were causing build problems. They were removed from 9 earlier but not from 8u. These are com/sun/java/accessibility/util/java/awt/ChoiceTranslator.java and all the files in com/sun/java/accessibility/extensions. Thanks, Pete From jan.lahoda at oracle.com Thu May 21 07:01:32 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 21 May 2015 09:01:32 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version Message-ID: <555D82CC.9070105@oracle.com> Hi, This is a patch adding a new option, -platform, to javac. Patch for the top-level repository is here: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ Patch for the langtools repository is here: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ These changes also require additional langtools changes as their prerequisite: http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ Overall, one can imagine '-platform N' to have the same effect as '-source N -target N -bootclasspath '. The possible values for 'N' are pluggable in a limited way, though (see langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). Note that this patch only introduces N=7 and N=8, which correspond to Open JDK 7 and 8 GA. A tricky problem to solve is where to get the APIs for platform N. The proposal is to include history data in the textual format inside the OpenJDK repositories (the input data), process them at build time and create a lib/ct.sym file holding the data in the JDK image. javac running with the -platform option then compiles against the lib/ct.sym file. The input history data are placed /make/data/symbols (the sym.txt files). This patches only includes data for OpenJDK 7 and 8, and only for public APIs (more or less Java SE and JDK @Exported APIs). The size of the history data is currently ~6MB in the JDK checkout and ~650kB inside the .hg directory (the size could change significantly if additional classes/elements, like non-public API classes, would need to be included). The lib/ct.sym file is currently ~4.5MB. The ct.sym file is a zip file containing signature files. The signature files are similar to classfiles (so javac can read them as classfiles), but are missing some attributes, most notably the Code attribute. On the top-level, the ct.sym contains directories named "7", "78" and "8". When compiling for version 'N', the bootclasspath for that version is obtained by using directories which have 'N' in their name. The sigfiles for ct.sym are created by /make/tools/symbolgenerator/CreateSymbols.java. The same file can also be used to construct the sym.txt files. Concise instructions are part of the CreateSymbols.java. I am sending this as one review, as the changes together make one feature, but the langtools and top-level changes are independent to a great degree: the langtools changes add the "-platform" javac; and the top-level changes add the history data and ability to build the ct.sym file. If desired, these could be pushed and/or reviewed independently. Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan Bateman and others who have provided advices and help on the matter before. Any insights/comments are wholeheartedly welcome. Thanks, Jan From erik.joelsson at oracle.com Thu May 21 07:05:12 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 May 2015 09:05:12 +0200 Subject: Excessive rebuilds of modules In-Reply-To: <555CF0F9.3090308@oracle.com> References: <555CCF4D.20301@oracle.com> <555CEA3C.7040107@oracle.com> <555CEAA2.2040100@Oracle.com> <555CF0F9.3090308@oracle.com> Message-ID: <555D83A8.4030001@oracle.com> On 2015-05-20 22:39, Alan Bateman wrote: > > > On 20/05/2015 21:12, Roger Riggs wrote: >> Ioi, >> >> You can rebuild just the contents of a single module: >> >> % make java.base java.base-libs java.base-launchers >> > Yes, and this works great when you are using an exploded build. It's > possible that Ioi is looking for an images build of course. In general > then this needs sjavac as Joe brings up. > If you have a full image build, make a change to something in java.base, you could do something like this to avoid unnecessary rebuilds: $ make java.base && make images-only Note that if you put the *-only target on the same make command line, the results will be unpredictable as -only deactivates dependencies, so images would start running before java.base was properly done. A note on sjavac, I do believe it currently works (to some extent) in jdk9. /Erik From erik.joelsson at oracle.com Thu May 21 07:11:00 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 May 2015 09:11:00 +0200 Subject: RfR JDK-8077296 RE build fails on non-Win builds when attempting to build Win only javadoc In-Reply-To: <555D6E3E.5030806@oracle.com> References: <555D6E3E.5030806@oracle.com> Message-ID: <555D8504.2030800@oracle.com> Hello Pete, This looks good to me. /Erik On 2015-05-21 07:33, Pete Brunet wrote: > Please review the following change for 8u: > http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/ > > Background: > > - As part of the open sourcing of the JAB and Java Accessibility > Utilities (JAU) the JAU Javadoc was setup to be added to the build. > - Due to a 8u build issue (it uses source bundles) the Javadoc had to be > temporarily disabled: JDK-8076552 > - The issue was caused by JAU code being in windows instead of share. > - For 9 the JAU code is in > jdk.accessibility/share/classes/com/sun/java/accessibility/util (and the > JAB code under jdk.accessibility/windows). > - For 8u both the JAU and JAB code is in jdk/src/windows. > - The problem on 8u is with non-windows builds; the 8 Javadoc build > process doesn't find the JAU files because they are in a windows directory. > - The fix is to refactor so 8u is like 9 with the JAU files in share; > then the javadoc build process will find the source for all build platforms. > - Make has been changed so jaccess.jar is built for all platforms > - Some obsolete files have been removed as they were causing build > problems. They were removed from 9 earlier but not from 8u. These are > com/sun/java/accessibility/util/java/awt/ChoiceTranslator.java and all > the files in com/sun/java/accessibility/extensions. > > Thanks, Pete From erik.joelsson at oracle.com Thu May 21 09:42:36 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 May 2015 11:42:36 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555D82CC.9070105@oracle.com> References: <555D82CC.9070105@oracle.com> Message-ID: <555DA88C.1080206@oracle.com> Hello Jan, On the build changes there are some things I would like to change. * The creation of the ct.sym file should be done in a separate file, with a separate top level target. The images target should just be about linking and pulling things together, not actual building/compiling of things. * The calls to MakeDir are not needed. * There are missing prerequisites in the rule for creating the symbols. * The jar file creation should use the SetupArchive macro. * Intermediate build files should be put into the $(SUPPORT_OUTPUTDIR). * I think it makes sense to have the ct.sym file be part of the exploded-image. Since this was quite a lot of changes, I took the liberty of implementing them. Here is a webrev with my suggestion for build changes: http://cr.openjdk.java.net/~erikj/8072480/webrev.01/ /Erik On 2015-05-21 09:01, Jan Lahoda wrote: > Hi, > > This is a patch adding a new option, -platform, to javac. > > Patch for the top-level repository is here: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ > > Patch for the langtools repository is here: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ > > These changes also require additional langtools changes as their > prerequisite: > http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ > > Overall, one can imagine '-platform N' to have the same effect as > '-source N -target N -bootclasspath '. The possible values > for 'N' are pluggable in a limited way, though (see > langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). > Note that this patch only introduces N=7 and N=8, which correspond to > Open JDK 7 and 8 GA. > > A tricky problem to solve is where to get the APIs for platform N. The > proposal is to include history data in the textual format inside the > OpenJDK repositories (the input data), process them at build time and > create a lib/ct.sym file holding the data in the JDK image. javac > running with the -platform option then compiles against the lib/ct.sym > file. The input history data are placed > /make/data/symbols (the sym.txt files). This > patches only includes data for OpenJDK 7 and 8, and only for public > APIs (more or less Java SE and JDK @Exported APIs). > > The size of the history data is currently ~6MB in the JDK checkout and > ~650kB inside the .hg directory (the size could change significantly > if additional classes/elements, like non-public API classes, would > need to be included). The lib/ct.sym file is currently ~4.5MB. > > The ct.sym file is a zip file containing signature files. The > signature files are similar to classfiles (so javac can read them as > classfiles), but are missing some attributes, most notably the Code > attribute. On the top-level, the ct.sym contains directories named > "7", "78" and "8". When compiling for version 'N', the bootclasspath > for that version is obtained by using directories which have 'N' in > their name. > > The sigfiles for ct.sym are created by > /make/tools/symbolgenerator/CreateSymbols.java. > The same file can also be used to construct the sym.txt files. Concise > instructions are part of the CreateSymbols.java. > > I am sending this as one review, as the changes together make one > feature, but the langtools and top-level changes are independent to a > great degree: the langtools changes add the "-platform" javac; and the > top-level changes add the history data and ability to build the ct.sym > file. If desired, these could be pushed and/or reviewed independently. > > Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan > Bateman and others who have provided advices and help on the matter > before. > > Any insights/comments are wholeheartedly welcome. > > Thanks, > Jan From jan.lahoda at oracle.com Thu May 21 10:19:20 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 21 May 2015 12:19:20 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555DA88C.1080206@oracle.com> References: <555D82CC.9070105@oracle.com> <555DA88C.1080206@oracle.com> Message-ID: <555DB128.2030609@oracle.com> Hello Eric, Thanks a lot for your feedback and changes! I'll fold them into the patch. Thanks, Jan On 21.5.2015 11:42, Erik Joelsson wrote: > Hello Jan, > > On the build changes there are some things I would like to change. > > * The creation of the ct.sym file should be done in a separate file, > with a separate top level target. The images target should just be about > linking and pulling things together, not actual building/compiling of > things. > * The calls to MakeDir are not needed. > * There are missing prerequisites in the rule for creating the symbols. > * The jar file creation should use the SetupArchive macro. > * Intermediate build files should be put into the $(SUPPORT_OUTPUTDIR). > * I think it makes sense to have the ct.sym file be part of the > exploded-image. > > Since this was quite a lot of changes, I took the liberty of > implementing them. Here is a webrev with my suggestion for build changes: > > http://cr.openjdk.java.net/~erikj/8072480/webrev.01/ > > /Erik > > On 2015-05-21 09:01, Jan Lahoda wrote: >> Hi, >> >> This is a patch adding a new option, -platform, to javac. >> >> Patch for the top-level repository is here: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >> >> Patch for the langtools repository is here: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >> >> These changes also require additional langtools changes as their >> prerequisite: >> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >> >> Overall, one can imagine '-platform N' to have the same effect as >> '-source N -target N -bootclasspath '. The possible values >> for 'N' are pluggable in a limited way, though (see >> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >> Note that this patch only introduces N=7 and N=8, which correspond to >> Open JDK 7 and 8 GA. >> >> A tricky problem to solve is where to get the APIs for platform N. The >> proposal is to include history data in the textual format inside the >> OpenJDK repositories (the input data), process them at build time and >> create a lib/ct.sym file holding the data in the JDK image. javac >> running with the -platform option then compiles against the lib/ct.sym >> file. The input history data are placed >> /make/data/symbols (the sym.txt files). This >> patches only includes data for OpenJDK 7 and 8, and only for public >> APIs (more or less Java SE and JDK @Exported APIs). >> >> The size of the history data is currently ~6MB in the JDK checkout and >> ~650kB inside the .hg directory (the size could change significantly >> if additional classes/elements, like non-public API classes, would >> need to be included). The lib/ct.sym file is currently ~4.5MB. >> >> The ct.sym file is a zip file containing signature files. The >> signature files are similar to classfiles (so javac can read them as >> classfiles), but are missing some attributes, most notably the Code >> attribute. On the top-level, the ct.sym contains directories named >> "7", "78" and "8". When compiling for version 'N', the bootclasspath >> for that version is obtained by using directories which have 'N' in >> their name. >> >> The sigfiles for ct.sym are created by >> /make/tools/symbolgenerator/CreateSymbols.java. >> The same file can also be used to construct the sym.txt files. Concise >> instructions are part of the CreateSymbols.java. >> >> I am sending this as one review, as the changes together make one >> feature, but the langtools and top-level changes are independent to a >> great degree: the langtools changes add the "-platform" javac; and the >> top-level changes add the history data and ability to build the ct.sym >> file. If desired, these could be pushed and/or reviewed independently. >> >> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >> Bateman and others who have provided advices and help on the matter >> before. >> >> Any insights/comments are wholeheartedly welcome. >> >> Thanks, >> Jan > From maurizio.cimadamore at oracle.com Thu May 21 10:31:53 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 21 May 2015 11:31:53 +0100 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555D82CC.9070105@oracle.com> References: <555D82CC.9070105@oracle.com> Message-ID: <555DB419.6020301@oracle.com> Hi Jan, great work - couple of comments below: * it seems like some of the routines in Arguments can be simplified using lambdas - especially lookupPlatformProvider and checkOptionAllowed * Why JDKPlatformProvider is not called JDKPlatformProvider*Factory* ? * JavacProcessingEnvironment.JoiningIterator seems to have commonalities with CompoundScopeIterator - any chance that we might refactor this a bit? * What's the rationale for giving an error if -platform is specified and a non-StandardFileManager is provided? Can't we simply swallow that, ignore the platform settings and issue a Lint 'options' warning? * Would it make sense for some of the classfile generation logic in CreateSymbols to be moved under the classfile API ? * I had hard time reconciling some of the comments in CreateSymbols with how the files were laid out. I think in the end, what you mean is that if you have platforms 7, 8, 9 - you should pick one baseline (i.e. 8) and then generate diffs for 9 and 7 against the 8 one. If that's the use case, I think the command line can be simplified a bit in order to explicitly state which of the platform is the baseline one, and the remaining parameters can be inferred from the tool (as the seem to be typically all identical but one which is set to - the one for the baseline). Maybe the inference logic should be different (i.e. use 8 as a baseline for 7 and 7 as a baseline for 6) - but - whatever the logic, I think it should be chosen once and for all, and live implicitly in the tool? Or are there reasons as to why it might be handy to customize the baselines? Maurizio On 21/05/15 08:01, Jan Lahoda wrote: > Hi, > > This is a patch adding a new option, -platform, to javac. > > Patch for the top-level repository is here: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ > > Patch for the langtools repository is here: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ > > These changes also require additional langtools changes as their > prerequisite: > http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ > > Overall, one can imagine '-platform N' to have the same effect as > '-source N -target N -bootclasspath '. The possible values > for 'N' are pluggable in a limited way, though (see > langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). > Note that this patch only introduces N=7 and N=8, which correspond to > Open JDK 7 and 8 GA. > > A tricky problem to solve is where to get the APIs for platform N. The > proposal is to include history data in the textual format inside the > OpenJDK repositories (the input data), process them at build time and > create a lib/ct.sym file holding the data in the JDK image. javac > running with the -platform option then compiles against the lib/ct.sym > file. The input history data are placed > /make/data/symbols (the sym.txt files). This > patches only includes data for OpenJDK 7 and 8, and only for public > APIs (more or less Java SE and JDK @Exported APIs). > > The size of the history data is currently ~6MB in the JDK checkout and > ~650kB inside the .hg directory (the size could change significantly > if additional classes/elements, like non-public API classes, would > need to be included). The lib/ct.sym file is currently ~4.5MB. > > The ct.sym file is a zip file containing signature files. The > signature files are similar to classfiles (so javac can read them as > classfiles), but are missing some attributes, most notably the Code > attribute. On the top-level, the ct.sym contains directories named > "7", "78" and "8". When compiling for version 'N', the bootclasspath > for that version is obtained by using directories which have 'N' in > their name. > > The sigfiles for ct.sym are created by > /make/tools/symbolgenerator/CreateSymbols.java. > The same file can also be used to construct the sym.txt files. Concise > instructions are part of the CreateSymbols.java. > > I am sending this as one review, as the changes together make one > feature, but the langtools and top-level changes are independent to a > great degree: the langtools changes add the "-platform" javac; and the > top-level changes add the history data and ability to build the ct.sym > file. If desired, these could be pushed and/or reviewed independently. > > Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan > Bateman and others who have provided advices and help on the matter > before. > > Any insights/comments are wholeheartedly welcome. > > Thanks, > Jan From magnus.ihse.bursie at oracle.com Thu May 21 11:21:25 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 21 May 2015 13:21:25 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555DA88C.1080206@oracle.com> References: <555D82CC.9070105@oracle.com> <555DA88C.1080206@oracle.com> Message-ID: <555DBFB5.4090206@oracle.com> Hi Erik and Jan, Erik's modifications look much better to me. I'm just not entirerly satisfied with how this new symbolgenerator tool fits int our model. It's really a buildtool, similar to the other buildtools we have. First of all, the location is not really ideal. Compare with how the java build tools are stored, e.g. jdk/make/src/classes/build/tools/charsetmapping. Correspondingly, I believe the symbolgenerator should live in $TOP/make/src/classes/build/tools/symbolgenerator. This makes it clear that it's source code, leaves room for native build tools, and sets up a common package prefix (while build.tools. might not be ideal, it's the same as in the JDK build tools, so let's keep it). Second, and this is more of a open question, mostly directed at Erik, shouldn't we build the symbolgenerator tool at the buildtools phase? It might require slightly more work to adapt the buildtools system for the top level, but I believe it is much more in line with what we got. /Magnus On 2015-05-21 11:42, Erik Joelsson wrote: > Hello Jan, > > On the build changes there are some things I would like to change. > > * The creation of the ct.sym file should be done in a separate file, > with a separate top level target. The images target should just be > about linking and pulling things together, not actual > building/compiling of things. > * The calls to MakeDir are not needed. > * There are missing prerequisites in the rule for creating the symbols. > * The jar file creation should use the SetupArchive macro. > * Intermediate build files should be put into the $(SUPPORT_OUTPUTDIR). > * I think it makes sense to have the ct.sym file be part of the > exploded-image. > > Since this was quite a lot of changes, I took the liberty of > implementing them. Here is a webrev with my suggestion for build changes: > > http://cr.openjdk.java.net/~erikj/8072480/webrev.01/ > > /Erik > > On 2015-05-21 09:01, Jan Lahoda wrote: >> Hi, >> >> This is a patch adding a new option, -platform, to javac. >> >> Patch for the top-level repository is here: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >> >> Patch for the langtools repository is here: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >> >> These changes also require additional langtools changes as their >> prerequisite: >> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >> >> Overall, one can imagine '-platform N' to have the same effect as >> '-source N -target N -bootclasspath '. The possible >> values for 'N' are pluggable in a limited way, though (see >> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >> Note that this patch only introduces N=7 and N=8, which correspond to >> Open JDK 7 and 8 GA. >> >> A tricky problem to solve is where to get the APIs for platform N. >> The proposal is to include history data in the textual format inside >> the OpenJDK repositories (the input data), process them at build time >> and create a lib/ct.sym file holding the data in the JDK image. javac >> running with the -platform option then compiles against the >> lib/ct.sym file. The input history data are placed >> /make/data/symbols (the sym.txt files). This >> patches only includes data for OpenJDK 7 and 8, and only for public >> APIs (more or less Java SE and JDK @Exported APIs). >> >> The size of the history data is currently ~6MB in the JDK checkout >> and ~650kB inside the .hg directory (the size could change >> significantly if additional classes/elements, like non-public API >> classes, would need to be included). The lib/ct.sym file is currently >> ~4.5MB. >> >> The ct.sym file is a zip file containing signature files. The >> signature files are similar to classfiles (so javac can read them as >> classfiles), but are missing some attributes, most notably the Code >> attribute. On the top-level, the ct.sym contains directories named >> "7", "78" and "8". When compiling for version 'N', the bootclasspath >> for that version is obtained by using directories which have 'N' in >> their name. >> >> The sigfiles for ct.sym are created by >> /make/tools/symbolgenerator/CreateSymbols.java. >> The same file can also be used to construct the sym.txt files. >> Concise instructions are part of the CreateSymbols.java. >> >> I am sending this as one review, as the changes together make one >> feature, but the langtools and top-level changes are independent to a >> great degree: the langtools changes add the "-platform" javac; and >> the top-level changes add the history data and ability to build the >> ct.sym file. If desired, these could be pushed and/or reviewed >> independently. >> >> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >> Bateman and others who have provided advices and help on the matter >> before. >> >> Any insights/comments are wholeheartedly welcome. >> >> Thanks, >> Jan > From erik.joelsson at oracle.com Thu May 21 11:47:41 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 May 2015 13:47:41 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555DBFB5.4090206@oracle.com> References: <555D82CC.9070105@oracle.com> <555DA88C.1080206@oracle.com> <555DBFB5.4090206@oracle.com> Message-ID: <555DC5DD.2020607@oracle.com> On 2015-05-21 13:21, Magnus Ihse Bursie wrote: > Hi Erik and Jan, > > Erik's modifications look much better to me. > > I'm just not entirerly satisfied with how this new symbolgenerator > tool fits int our model. It's really a buildtool, similar to the other > buildtools we have. > > First of all, the location is not really ideal. Compare with how the > java build tools are stored, e.g. > jdk/make/src/classes/build/tools/charsetmapping. Correspondingly, I > believe the symbolgenerator should live in > $TOP/make/src/classes/build/tools/symbolgenerator. This makes it clear > that it's source code, leaves room for native build tools, and sets up > a common package prefix (while build.tools. might not be ideal, > it's the same as in the JDK build tools, so let's keep it). > I agree with this. > Second, and this is more of a open question, mostly directed at Erik, > shouldn't we build the symbolgenerator tool at the buildtools phase? > It might require slightly more work to adapt the buildtools system for > the top level, but I believe it is much more in line with what we got. > We had an offline discussion and concluded that the build tools building needs to be redone in some better way, for this new tool and for all the existing ones. Until this happens, we will accept the current solution here. /Erik > /Magnus > > On 2015-05-21 11:42, Erik Joelsson wrote: >> Hello Jan, >> >> On the build changes there are some things I would like to change. >> >> * The creation of the ct.sym file should be done in a separate file, >> with a separate top level target. The images target should just be >> about linking and pulling things together, not actual >> building/compiling of things. >> * The calls to MakeDir are not needed. >> * There are missing prerequisites in the rule for creating the symbols. >> * The jar file creation should use the SetupArchive macro. >> * Intermediate build files should be put into the $(SUPPORT_OUTPUTDIR). >> * I think it makes sense to have the ct.sym file be part of the >> exploded-image. >> >> Since this was quite a lot of changes, I took the liberty of >> implementing them. Here is a webrev with my suggestion for build >> changes: >> >> http://cr.openjdk.java.net/~erikj/8072480/webrev.01/ >> >> /Erik >> >> On 2015-05-21 09:01, Jan Lahoda wrote: >>> Hi, >>> >>> This is a patch adding a new option, -platform, to javac. >>> >>> Patch for the top-level repository is here: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>> >>> Patch for the langtools repository is here: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>> >>> These changes also require additional langtools changes as their >>> prerequisite: >>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>> >>> Overall, one can imagine '-platform N' to have the same effect as >>> '-source N -target N -bootclasspath '. The possible >>> values for 'N' are pluggable in a limited way, though (see >>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>> Note that this patch only introduces N=7 and N=8, which correspond >>> to Open JDK 7 and 8 GA. >>> >>> A tricky problem to solve is where to get the APIs for platform N. >>> The proposal is to include history data in the textual format inside >>> the OpenJDK repositories (the input data), process them at build >>> time and create a lib/ct.sym file holding the data in the JDK image. >>> javac running with the -platform option then compiles against the >>> lib/ct.sym file. The input history data are placed >>> /make/data/symbols (the sym.txt files). This >>> patches only includes data for OpenJDK 7 and 8, and only for public >>> APIs (more or less Java SE and JDK @Exported APIs). >>> >>> The size of the history data is currently ~6MB in the JDK checkout >>> and ~650kB inside the .hg directory (the size could change >>> significantly if additional classes/elements, like non-public API >>> classes, would need to be included). The lib/ct.sym file is >>> currently ~4.5MB. >>> >>> The ct.sym file is a zip file containing signature files. The >>> signature files are similar to classfiles (so javac can read them as >>> classfiles), but are missing some attributes, most notably the Code >>> attribute. On the top-level, the ct.sym contains directories named >>> "7", "78" and "8". When compiling for version 'N', the bootclasspath >>> for that version is obtained by using directories which have 'N' in >>> their name. >>> >>> The sigfiles for ct.sym are created by >>> /make/tools/symbolgenerator/CreateSymbols.java. The >>> same file can also be used to construct the sym.txt files. Concise >>> instructions are part of the CreateSymbols.java. >>> >>> I am sending this as one review, as the changes together make one >>> feature, but the langtools and top-level changes are independent to >>> a great degree: the langtools changes add the "-platform" javac; and >>> the top-level changes add the history data and ability to build the >>> ct.sym file. If desired, these could be pushed and/or reviewed >>> independently. >>> >>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >>> Bateman and others who have provided advices and help on the matter >>> before. >>> >>> Any insights/comments are wholeheartedly welcome. >>> >>> Thanks, >>> Jan >> > From jan.lahoda at oracle.com Thu May 21 11:48:33 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 21 May 2015 13:48:33 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555DB419.6020301@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> Message-ID: <555DC611.5000702@oracle.com> Hi Maurizio, Thanks for the comments. On 21.5.2015 12:31, Maurizio Cimadamore wrote: > Hi Jan, > great work - couple of comments below: > > * it seems like some of the routines in Arguments can be simplified > using lambdas - especially lookupPlatformProvider and checkOptionAllowed Yes, I'll take a look. > * Why JDKPlatformProvider is not called JDKPlatformProvider*Factory* ? A remnant of history, I'll fix that. > * JavacProcessingEnvironment.JoiningIterator seems to have commonalities > with CompoundScopeIterator - any chance that we might refactor this a bit? I'll take a look. > * What's the rationale for giving an error if -platform is specified and > a non-StandardFileManager is provided? Can't we simply swallow that, > ignore the platform settings and issue a Lint 'options' warning? If the bootclasspath cannot be set for -platform N, javac would be compiling against the current version of the API, not against the N's APIs. And so the result may not be able to run on N. So it seemed more appropriate to me to refuse to continue rather than continue and produce a potentially wrong result. > * Would it make sense for some of the classfile generation logic in > CreateSymbols to be moved under the classfile API ? Possibly - the Classfile API could be made more friendly to create classes from scratch. I'd prefer to keep that separate from this effort, though. > * I had hard time reconciling some of the comments in CreateSymbols with > how the files were laid out. I think in the end, what you mean is that Ok - I'll work on making the comments more comprehensible. > if you have platforms 7, 8, 9 - you should pick one baseline (i.e. 8) > and then generate diffs for 9 and 7 against the 8 one. If that's the use > case, I think the command line can be simplified a bit in order to > explicitly state which of the platform is the baseline one, and the > remaining parameters can be inferred from the tool (as the > seem to be typically all identical > but one which is set to - the one for the baseline). Maybe the > inference logic should be different (i.e. use 8 as a baseline for 7 and > 7 as a baseline for 6) - but - whatever the logic, I think it should be > chosen once and for all, and live implicitly in the tool? Or are there > reasons as to why it might be handy to customize the baselines? As an example, consider we would be currently storing data for 6, 7 and 8. We could have full 8 APIs stored, and then 8->7 diff and 7->6 diff. So the baseline for 7 would be 8 and the baseline for 6 would be 7. When the data for 9 would be added(*), we could keep the full APIs for 8 (to avoid wasting space in the repository), and then store 8->9 and 8->7 diffs (and drop 6). So 8 would be the baseline for both 7 and 9. So, some flexibility may be useful here. Does this make some sense? (*) For JDK 9, there are no history data stored for 9, -platform 9 uses the real JDK 9's bootclasspath (for JDK 9, -platform 9 is mostly a no-op). We would presumably add the history data for 9 when JDK 9 is finished. Thanks! Jan > > Maurizio > > On 21/05/15 08:01, Jan Lahoda wrote: >> Hi, >> >> This is a patch adding a new option, -platform, to javac. >> >> Patch for the top-level repository is here: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >> >> Patch for the langtools repository is here: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >> >> These changes also require additional langtools changes as their >> prerequisite: >> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >> >> Overall, one can imagine '-platform N' to have the same effect as >> '-source N -target N -bootclasspath '. The possible values >> for 'N' are pluggable in a limited way, though (see >> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >> Note that this patch only introduces N=7 and N=8, which correspond to >> Open JDK 7 and 8 GA. >> >> A tricky problem to solve is where to get the APIs for platform N. The >> proposal is to include history data in the textual format inside the >> OpenJDK repositories (the input data), process them at build time and >> create a lib/ct.sym file holding the data in the JDK image. javac >> running with the -platform option then compiles against the lib/ct.sym >> file. The input history data are placed >> /make/data/symbols (the sym.txt files). This >> patches only includes data for OpenJDK 7 and 8, and only for public >> APIs (more or less Java SE and JDK @Exported APIs). >> >> The size of the history data is currently ~6MB in the JDK checkout and >> ~650kB inside the .hg directory (the size could change significantly >> if additional classes/elements, like non-public API classes, would >> need to be included). The lib/ct.sym file is currently ~4.5MB. >> >> The ct.sym file is a zip file containing signature files. The >> signature files are similar to classfiles (so javac can read them as >> classfiles), but are missing some attributes, most notably the Code >> attribute. On the top-level, the ct.sym contains directories named >> "7", "78" and "8". When compiling for version 'N', the bootclasspath >> for that version is obtained by using directories which have 'N' in >> their name. >> >> The sigfiles for ct.sym are created by >> /make/tools/symbolgenerator/CreateSymbols.java. >> The same file can also be used to construct the sym.txt files. Concise >> instructions are part of the CreateSymbols.java. >> >> I am sending this as one review, as the changes together make one >> feature, but the langtools and top-level changes are independent to a >> great degree: the langtools changes add the "-platform" javac; and the >> top-level changes add the history data and ability to build the ct.sym >> file. If desired, these could be pushed and/or reviewed independently. >> >> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >> Bateman and others who have provided advices and help on the matter >> before. >> >> Any insights/comments are wholeheartedly welcome. >> >> Thanks, >> Jan > From jan.lahoda at oracle.com Thu May 21 11:58:27 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 21 May 2015 13:58:27 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555DBFB5.4090206@oracle.com> References: <555D82CC.9070105@oracle.com> <555DA88C.1080206@oracle.com> <555DBFB5.4090206@oracle.com> Message-ID: <555DC863.4050703@oracle.com> Hi Magnus, On 21.5.2015 13:21, Magnus Ihse Bursie wrote: > Hi Erik and Jan, > > Erik's modifications look much better to me. > > I'm just not entirerly satisfied with how this new symbolgenerator tool > fits int our model. It's really a buildtool, similar to the other > buildtools we have. > > First of all, the location is not really ideal. Compare with how the > java build tools are stored, e.g. > jdk/make/src/classes/build/tools/charsetmapping. Correspondingly, I > believe the symbolgenerator should live in > $TOP/make/src/classes/build/tools/symbolgenerator. This makes it clear > that it's source code, leaves room for native build tools, and sets up a > common package prefix (while build.tools. might not be ideal, it's > the same as in the JDK build tools, so let's keep it). Sure - I'll move it. Thanks, Jan > > Second, and this is more of a open question, mostly directed at Erik, > shouldn't we build the symbolgenerator tool at the buildtools phase? It > might require slightly more work to adapt the buildtools system for the > top level, but I believe it is much more in line with what we got. > > /Magnus > > On 2015-05-21 11:42, Erik Joelsson wrote: >> Hello Jan, >> >> On the build changes there are some things I would like to change. >> >> * The creation of the ct.sym file should be done in a separate file, >> with a separate top level target. The images target should just be >> about linking and pulling things together, not actual >> building/compiling of things. >> * The calls to MakeDir are not needed. >> * There are missing prerequisites in the rule for creating the symbols. >> * The jar file creation should use the SetupArchive macro. >> * Intermediate build files should be put into the $(SUPPORT_OUTPUTDIR). >> * I think it makes sense to have the ct.sym file be part of the >> exploded-image. >> >> Since this was quite a lot of changes, I took the liberty of >> implementing them. Here is a webrev with my suggestion for build changes: >> >> http://cr.openjdk.java.net/~erikj/8072480/webrev.01/ >> >> /Erik >> >> On 2015-05-21 09:01, Jan Lahoda wrote: >>> Hi, >>> >>> This is a patch adding a new option, -platform, to javac. >>> >>> Patch for the top-level repository is here: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>> >>> Patch for the langtools repository is here: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>> >>> These changes also require additional langtools changes as their >>> prerequisite: >>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>> >>> Overall, one can imagine '-platform N' to have the same effect as >>> '-source N -target N -bootclasspath '. The possible >>> values for 'N' are pluggable in a limited way, though (see >>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>> Note that this patch only introduces N=7 and N=8, which correspond to >>> Open JDK 7 and 8 GA. >>> >>> A tricky problem to solve is where to get the APIs for platform N. >>> The proposal is to include history data in the textual format inside >>> the OpenJDK repositories (the input data), process them at build time >>> and create a lib/ct.sym file holding the data in the JDK image. javac >>> running with the -platform option then compiles against the >>> lib/ct.sym file. The input history data are placed >>> /make/data/symbols (the sym.txt files). This >>> patches only includes data for OpenJDK 7 and 8, and only for public >>> APIs (more or less Java SE and JDK @Exported APIs). >>> >>> The size of the history data is currently ~6MB in the JDK checkout >>> and ~650kB inside the .hg directory (the size could change >>> significantly if additional classes/elements, like non-public API >>> classes, would need to be included). The lib/ct.sym file is currently >>> ~4.5MB. >>> >>> The ct.sym file is a zip file containing signature files. The >>> signature files are similar to classfiles (so javac can read them as >>> classfiles), but are missing some attributes, most notably the Code >>> attribute. On the top-level, the ct.sym contains directories named >>> "7", "78" and "8". When compiling for version 'N', the bootclasspath >>> for that version is obtained by using directories which have 'N' in >>> their name. >>> >>> The sigfiles for ct.sym are created by >>> /make/tools/symbolgenerator/CreateSymbols.java. >>> The same file can also be used to construct the sym.txt files. >>> Concise instructions are part of the CreateSymbols.java. >>> >>> I am sending this as one review, as the changes together make one >>> feature, but the langtools and top-level changes are independent to a >>> great degree: the langtools changes add the "-platform" javac; and >>> the top-level changes add the history data and ability to build the >>> ct.sym file. If desired, these could be pushed and/or reviewed >>> independently. >>> >>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >>> Bateman and others who have provided advices and help on the matter >>> before. >>> >>> Any insights/comments are wholeheartedly welcome. >>> >>> Thanks, >>> Jan >> > From maurizio.cimadamore at oracle.com Thu May 21 12:14:19 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 21 May 2015 13:14:19 +0100 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555DC611.5000702@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555DC611.5000702@oracle.com> Message-ID: <555DCC1B.4030902@oracle.com> On 21/05/15 12:48, Jan Lahoda wrote: > As an example, consider we would be currently storing data for 6, 7 > and 8. We could have full 8 APIs stored, and then 8->7 diff and 7->6 > diff. So the baseline for 7 would be 8 and the baseline for 6 would be 7. > > When the data for 9 would be added(*), we could keep the full APIs for > 8 (to avoid wasting space in the repository), and then store 8->9 and > 8->7 diffs (and drop 6). So 8 would be the baseline for both 7 and 9. > So, some flexibility may be useful here. > > Does this make some sense? It seems to me that versions form a total order. If you pick N to be your baseline, you should generate a full API for that K, and then generate incremental diffs for K < N and K > N - example: case 1: platforms: { 6, 7, 8 } baseline = 8 files: 8, 8->7, 7->6 case 2: platforms { 7, 8, 9 } baseline = 8 files: 8->9, 8, 8->7 So, can't we just assume that there's a set of platforms (which can be sorted), and a baseline K pointing at one of them? Then it's easy to figure out how you should generate diffs: sym(N) := , where N == K sym(N) := diff between sym(N-1) and N, where N > K sym(N) := diff between N and sym(N + 1), where N < K Maurizio From jan.lahoda at oracle.com Thu May 21 13:14:47 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 21 May 2015 15:14:47 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555DCC1B.4030902@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555DC611.5000702@oracle.com> <555DCC1B.4030902@oracle.com> Message-ID: <555DDA47.9060403@oracle.com> On 21.5.2015 14:14, Maurizio Cimadamore wrote: > > > On 21/05/15 12:48, Jan Lahoda wrote: >> As an example, consider we would be currently storing data for 6, 7 >> and 8. We could have full 8 APIs stored, and then 8->7 diff and 7->6 >> diff. So the baseline for 7 would be 8 and the baseline for 6 would be 7. >> >> When the data for 9 would be added(*), we could keep the full APIs for >> 8 (to avoid wasting space in the repository), and then store 8->9 and >> 8->7 diffs (and drop 6). So 8 would be the baseline for both 7 and 9. >> So, some flexibility may be useful here. >> >> Does this make some sense? > It seems to me that versions form a total order. If you pick N to be > your baseline, you should generate a full API for that K, and then > generate incremental diffs for K < N and K > N - example: > > case 1: > > platforms: { 6, 7, 8 } > baseline = 8 > > files: 8, 8->7, 7->6 > > case 2: > > platforms { 7, 8, 9 } > baseline = 8 > > files: 8->9, 8, 8->7 > > So, can't we just assume that there's a set of platforms (which can be > sorted), and a baseline K pointing at one of them? Then it's easy to > figure out how you should generate diffs: > > sym(N) := , where N == K > sym(N) := diff between sym(N-1) and N, where N > K > sym(N) := diff between N and sym(N + 1), where N < K For 6, 7, 8, ... we could assume there is an ordering. But seems to me that the flexibility of being able to specify the baseline (rather than having the chosen automatically based on the version number) is not bad. But I can change it to automatic baseline per the design above, if you prefer. Thanks, Jan > > Maurizio From maurizio.cimadamore at oracle.com Thu May 21 17:38:52 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 21 May 2015 18:38:52 +0100 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555DDA47.9060403@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555DC611.5000702@oracle.com> <555DCC1B.4030902@oracle.com> <555DDA47.9060403@oracle.com> Message-ID: <555E182C.1050806@oracle.com> On 21/05/15 14:14, Jan Lahoda wrote: > For 6, 7, 8, ... we could assume there is an ordering. But seems to me > that the flexibility of being able to specify the baseline (rather > than having the chosen automatically based on the version number) is > not bad. But I can change it to automatic baseline per the design > above, if you prefer. I guess it would be nice (as discussed privately) if a side-effect of this effort was also to specify which diff files are generated and how given a set of available platforms. Maurizio From mark.reinhold at oracle.com Thu May 21 19:59:41 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 21 May 2015 12:59:41 -0700 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555D82CC.9070105@oracle.com> References: <555D82CC.9070105@oracle.com> Message-ID: <20150521125941.1758@eggemoggin.niobe.net> 2015/5/21 12:01 -0700, jan.lahoda at oracle.com: > This is a patch adding a new option, -platform, to javac. > > Patch for the top-level repository is here: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ > > Patch for the langtools repository is here: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ > > These changes also require additional langtools changes as their > prerequisite: > http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ Nice work -- I'm glad to see this coming in. What's the rationale for putting the symbol generator and all its data in the top-level repo? That'll add quite a bit of heft to a repo that's always been intended to remain fairly lightweight. Wouldn't it make more sense for this code and data to be placed in the langtools repo? Or is there some sort of build-bootstrapping issue here? - Mark From Roger.Riggs at Oracle.com Thu May 21 21:09:48 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 21 May 2015 17:09:48 -0400 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava Message-ID: <555E499C.6020300@Oracle.com> Please review these native code and build changes to clear compilation warnings. Most are due to mixing unsigned types with signed types or providing the correct type to an invoked function. Webrev: http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-fix-all-warnings-8074818/ Issues: 8074818: Resolve disabled warnings for libjava 8080007: Stop ignoring warnings for libjava JPRT in progress for product and fastdebug builds on solaris, linux, macosx, windows, and embedded. Thanks, Roger From Roger.Riggs at Oracle.com Fri May 22 00:42:04 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 21 May 2015 20:42:04 -0400 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava In-Reply-To: <555E7999.8000207@oracle.com> References: <555E499C.6020300@Oracle.com> <555E7999.8000207@oracle.com> Message-ID: <555E7B5C.6020603@Oracle.com> Oops, got the wrong host: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-fix-all-warnings-8074818/ Issues: 8074818: Resolve disabled warnings for libjava 8080007: Stop ignoring warnings for libjava Thanks, Roger On 5/21/15 8:34 PM, Ivan Gerasimov wrote: > Hi Roger > > On 22.05.2015 0:09, Roger Riggs wrote: >> Please review these native code and build changes to clear >> compilation warnings. >> Most are due to mixing unsigned types with signed types or providing >> the correct type to an invoked function. >> > The code changes look good! > >> Webrev: >> http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-fix-all-warnings-8074818/ >> >> > I guess, this link may not be accessible from outside Oracle. > > Sincerely yours, > Ivan > >> Issues: >> 8074818: Resolve disabled warnings for libjava >> 8080007: Stop ignoring warnings for libjava >> >> JPRT in progress for product and fastdebug builds on solaris, linux, >> macosx, windows, >> and embedded. >> >> Thanks, Roger >> >> >> > From ivan.gerasimov at oracle.com Fri May 22 00:34:33 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 22 May 2015 03:34:33 +0300 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava In-Reply-To: <555E499C.6020300@Oracle.com> References: <555E499C.6020300@Oracle.com> Message-ID: <555E7999.8000207@oracle.com> Hi Roger On 22.05.2015 0:09, Roger Riggs wrote: > Please review these native code and build changes to clear compilation > warnings. > Most are due to mixing unsigned types with signed types or providing > the correct type to an invoked function. > The code changes look good! > Webrev: > http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-fix-all-warnings-8074818/ > > I guess, this link may not be accessible from outside Oracle. Sincerely yours, Ivan > Issues: > 8074818: Resolve disabled warnings for libjava > 8080007: Stop ignoring warnings for libjava > > JPRT in progress for product and fastdebug builds on solaris, linux, > macosx, windows, > and embedded. > > Thanks, Roger > > > From mandy.chung at oracle.com Fri May 22 00:46:58 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 21 May 2015 17:46:58 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <555E5623.3020900@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> Message-ID: I?m including build-dev and we need to ask for Erik and Magnus advice what?s the best way to work around this. Erik, Magnus, Security providers now become service providers. They are provided from 11 different modules, 3 of them are os-specific. The current image builder doesn?t merge duplicate resources and we currently work around it in the build doing the merge as it?s temporary until the module system is moving further. Gensrc-jdk.jdi.gmk is the example. Valerie has a patch attempting to concatenate them and it turns out that it might not be straight forward I have thought. http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/make/gensrc/Gensrc-java.naming.gmk.html As we can?t say which one image builder will pick, it needs to copy gensrc (merged version) to all modules/$MODULE/META-INF/services/java.security.Provider config files. I wonder if it?s quicker to hack ImageBuilder to special case the service config file and merge them. Any thought? > On May 21, 2015, at 3:03 PM, Valerie Peng wrote: > > Mandy, > > Please find comments in line. > > On 5/20/2015 10:39 PM, Mandy Chung wrote: >> >> A quick comment on the META-INF/services config files and the makefile. Merging the service config files is temporary until the module system is moving further along. >> >> src/jdk.crypto.ucrypto/solaris/classes/META-INF/services/java.security.Provider.html >> and other os-specific service configuration: >> 1 #[solaris]com.oracle.security.ucrypto.UcryptoProvider >> >> - why is this commented out? Does the makefile uncomment it? It should be simple >> concatenation with > > In an example that I found through another makefile, it would uncomment the entry start with "#[OS]" (and process/remove this prefix) when the OS matches. We need OS-specific file processing when concatenate these files. Ah? that?s from Gensrc-jdk.jdi.gmk. The service config file contains a mixture of cross-neutral and os-specific providers. That?s not the example to copy. define process-provider $(MKDIR) -p $(@D) $(CAT) $^ > $@ endef > > What decides if it's appropriate or not? These are not just crypto providers that we are defining here, but all classes which extend from java.security.Provider. I recall using jdk.crypto.ec as the gensrc module as you suggested initially. But when testing it, it doesn't seem to work as expected. I ended up using java.naming as that's the one ended up in the final image instead of the concatenated one under jdk.crypto.ec. Could there be some alphabetic ordering when processing/building these modules? > > Well, since this is really a hack and only temporary, does it really matter whether it's under java.naming or jdk.crypto.ec? Both contains providers for the java.security provider list. The key thing is that the resulting image works Mandy From ioi.lam at oracle.com Fri May 22 04:53:02 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 21 May 2015 21:53:02 -0700 Subject: Excessive rebuilds of modules In-Reply-To: <555D83A8.4030001@oracle.com> References: <555CCF4D.20301@oracle.com> <555CEA3C.7040107@oracle.com> <555CEAA2.2040100@Oracle.com> <555CF0F9.3090308@oracle.com> <555D83A8.4030001@oracle.com> Message-ID: <555EB62E.7020703@oracle.com> On 5/21/15 12:05 AM, Erik Joelsson wrote: > > On 2015-05-20 22:39, Alan Bateman wrote: >> >> >> On 20/05/2015 21:12, Roger Riggs wrote: >>> Ioi, >>> >>> You can rebuild just the contents of a single module: >>> >>> % make java.base java.base-libs java.base-launchers >>> >> Yes, and this works great when you are using an exploded build. It's >> possible that Ioi is looking for an images build of course. In >> general then this needs sjavac as Joe brings up. >> > If you have a full image build, make a change to something in > java.base, you could do something like this to avoid unnecessary > rebuilds: > > $ make java.base && make images-only Thanks for the information. I tried this on my machine (32-way Xeon E5-2665 0 @ 2.40GHz), but it still takes one minute if I change a single file in java.base :-( The making of java.base alone took about 30 seconds. $ time sh -c 'make JOBS=29 java.base && make images-only' Building target 'java.base' in configuration '/home/iklam/jdk/bld/' Compiling 2759 files for java.base Finished building target 'java.base' in configuration '/home/iklam/jdk/bld/' Building target 'images-only' in configuration '/home/iklam/jdk/bld/' Creating jdk server jimage Creating jdk jimage Creating jre jimage duplicate resource "META-INF/services/sun.management.spi.PlatformMBeanProvider", skipping duplicate resource "META-INF/services/sun.management.spi.PlatformMBeanProvider", skipping duplicate resource "META-INF/services/sun.management.spi.PlatformMBeanProvider", skipping Unzipping jdk/src/closed/db/db-derby-10.10.2.0-bin.zip duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", skipping Unzipping jdk/src/closed/db/db-derby-10.10.2.0-bin.zip Updating images/sec-bin.zip ## Starting verify-modules Checking dependencies across JDK modules Access verification succeeded. ## Finished verify-modules (build time 00:00:16) Is there any way to make this faster? I used to have a script that compiles the exact set of .java files that I touched, and patch rt.jar. It would complete the build in a second or so. I guess I could update the script to work with modules and jimage, but would be happier if I didn't have to. Thanks - Ioi > Note that if you put the *-only target on the same make command line, > the results will be unpredictable as -only deactivates dependencies, > so images would start running before java.base was properly done. > > A note on sjavac, I do believe it currently works (to some extent) in > jdk9. > > /Erik From erik.joelsson at oracle.com Fri May 22 06:49:47 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 May 2015 08:49:47 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <20150521125941.1758@eggemoggin.niobe.net> References: <555D82CC.9070105@oracle.com> <20150521125941.1758@eggemoggin.niobe.net> Message-ID: <555ED18B.8060802@oracle.com> On 2015-05-21 21:59, mark.reinhold at oracle.com wrote: > 2015/5/21 12:01 -0700, jan.lahoda at oracle.com: >> This is a patch adding a new option, -platform, to javac. >> >> Patch for the top-level repository is here: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >> >> Patch for the langtools repository is here: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >> >> These changes also require additional langtools changes as their >> prerequisite: >> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ > Nice work -- I'm glad to see this coming in. > > What's the rationale for putting the symbol generator and all its data > in the top-level repo? That'll add quite a bit of heft to a repo that's > always been intended to remain fairly lightweight. Wouldn't it make > more sense for this code and data to be placed in the langtools repo? > Or is there some sort of build-bootstrapping issue here? Technically these files could go in any repo, it's only a question of where they best fit from a logical/maintaining point of view. I had not thought about the langtools repo before, I just thought that it didn't fit in the jdk repo so better put it in the top as it applies to all modules. But the user of this data is the compiler so langtools does make sense. /Erik From erik.joelsson at oracle.com Fri May 22 06:52:23 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 May 2015 08:52:23 +0200 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava In-Reply-To: <555E7B5C.6020603@Oracle.com> References: <555E499C.6020300@Oracle.com> <555E7999.8000207@oracle.com> <555E7B5C.6020603@Oracle.com> Message-ID: <555ED227.3060905@oracle.com> The build change looks fine, thanks for fixing this! /Erik On 2015-05-22 02:42, Roger Riggs wrote: > Oops, got the wrong host: > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-fix-all-warnings-8074818/ > > Issues: > 8074818: Resolve disabled warnings for libjava > 8080007: Stop ignoring warnings for libjava > > Thanks, Roger > > > > > On 5/21/15 8:34 PM, Ivan Gerasimov wrote: >> Hi Roger >> >> On 22.05.2015 0:09, Roger Riggs wrote: >>> Please review these native code and build changes to clear >>> compilation warnings. >>> Most are due to mixing unsigned types with signed types or providing >>> the correct type to an invoked function. >>> >> The code changes look good! >> >>> Webrev: >>> http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-fix-all-warnings-8074818/ >>> >>> >> I guess, this link may not be accessible from outside Oracle. >> >> Sincerely yours, >> Ivan >> >>> Issues: >>> 8074818: Resolve disabled warnings for libjava >>> 8080007: Stop ignoring warnings for libjava >>> >>> JPRT in progress for product and fastdebug builds on solaris, linux, >>> macosx, windows, >>> and embedded. >>> >>> Thanks, Roger >>> >>> >>> >> > From Alan.Bateman at oracle.com Fri May 22 06:55:08 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 May 2015 07:55:08 +0100 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava In-Reply-To: <555E7B5C.6020603@Oracle.com> References: <555E499C.6020300@Oracle.com> <555E7999.8000207@oracle.com> <555E7B5C.6020603@Oracle.com> Message-ID: <555ED2CC.3080308@oracle.com> On 22/05/2015 01:42, Roger Riggs wrote: > Oops, got the wrong host: > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-fix-all-warnings-8074818/ > > Issues: > 8074818: Resolve disabled warnings for libjava > 8080007: Stop ignoring warnings for libjava > > Thanks, Roger In JDK_GetVersionInfo0 then I wonder if we should change this assert to be a fatal error on product builds. Periodically people set the build to numbers > 255 and often only see issues when they use a fastdebug build. Th rest looks okay to me. I don't particularly like the IOE_FORMAT in ProcessImpl.c but I think other areas have done similar to deal with this warning. ConcurrentPReader_md.c is being removed in another patch under review at the moment so might be gone before you push. -Alan. From erik.joelsson at oracle.com Fri May 22 06:58:13 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 May 2015 08:58:13 +0200 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> Message-ID: <555ED385.80508@oracle.com> On 2015-05-22 02:46, Mandy Chung wrote: > I?m including build-dev and we need to ask for Erik and Magnus advice what?s the best way to work around this. > > Erik, Magnus, > Security providers now become service providers. They are provided from 11 different modules, 3 of them are os-specific. The current image builder doesn?t merge duplicate resources and we currently work around it in the build doing the merge as it?s temporary until the module system is moving further. Gensrc-jdk.jdi.gmk is the example. > > Valerie has a patch attempting to concatenate them and it turns out that it might not be straight forward I have thought. > http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/make/gensrc/Gensrc-java.naming.gmk.html > > As we can?t say which one image builder will pick, it needs to copy gensrc (merged version) to all modules/$MODULE/META-INF/services/java.security.Provider config files. > > I wonder if it?s quicker to hack ImageBuilder to special case the service config file and merge them. > > Any thought? I could certainly make this work in the makefile, but it is getting a bit tedious to keep these hacks going there. How hard would it be to change the ImageBuilder, which is just a temporary solution anyway, to identify and merge all service provider files with the same name that it finds? With that solution, the makefiles do not need to change as much when the module system is introduced and taking care of this properly. /Erik > >> On May 21, 2015, at 3:03 PM, Valerie Peng wrote: >> >> Mandy, >> >> Please find comments in line. >> >> On 5/20/2015 10:39 PM, Mandy Chung wrote: >>> A quick comment on the META-INF/services config files and the makefile. Merging the service config files is temporary until the module system is moving further along. >>> >>> src/jdk.crypto.ucrypto/solaris/classes/META-INF/services/java.security.Provider.html >>> and other os-specific service configuration: >>> 1 #[solaris]com.oracle.security.ucrypto.UcryptoProvider >>> >>> - why is this commented out? Does the makefile uncomment it? It should be simple >>> concatenation with >> In an example that I found through another makefile, it would uncomment the entry start with "#[OS]" (and process/remove this prefix) when the OS matches. We need OS-specific file processing when concatenate these files. > > Ah? that?s from Gensrc-jdk.jdi.gmk. The service config file contains a mixture of cross-neutral and os-specific providers. That?s not the example to copy. > > define process-provider > $(MKDIR) -p $(@D) > $(CAT) $^ > $@ > endef > > >> What decides if it's appropriate or not? These are not just crypto providers that we are defining here, but all classes which extend from java.security.Provider. I recall using jdk.crypto.ec as the gensrc module as you suggested initially. But when testing it, it doesn't seem to work as expected. I ended up using java.naming as that's the one ended up in the final image instead of the concatenated one under jdk.crypto.ec. Could there be some alphabetic ordering when processing/building these modules? >> >> Well, since this is really a hack and only temporary, does it really matter whether it's under java.naming or jdk.crypto.ec? Both contains providers for the java.security provider list. The key thing is that the resulting image works > Mandy From erik.joelsson at oracle.com Fri May 22 07:05:06 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 May 2015 09:05:06 +0200 Subject: Excessive rebuilds of modules In-Reply-To: <555EB62E.7020703@oracle.com> References: <555CCF4D.20301@oracle.com> <555CEA3C.7040107@oracle.com> <555CEAA2.2040100@Oracle.com> <555CF0F9.3090308@oracle.com> <555D83A8.4030001@oracle.com> <555EB62E.7020703@oracle.com> Message-ID: <555ED522.1000804@oracle.com> If you want a script/hack solution, you should be able to do something like this: make java.base-java-only JDK_FILTER=package/that/you/changed && make jimages-only That's likely the best I can do. If you need a real image, it has to be linked from scratch each time. If the exploded image is good enough, it's considerably faster to just build that. If you are on Windows, Cygwin adds some overhead that we can't get around. It could be worth trying 64bit cygwin and see if you get better performance. I've had mixed results, but on one machine, at least configure runs twice as fast with 64bit cygwin. /Erik On 2015-05-22 06:53, Ioi Lam wrote: > > > On 5/21/15 12:05 AM, Erik Joelsson wrote: >> >> On 2015-05-20 22:39, Alan Bateman wrote: >>> >>> >>> On 20/05/2015 21:12, Roger Riggs wrote: >>>> Ioi, >>>> >>>> You can rebuild just the contents of a single module: >>>> >>>> % make java.base java.base-libs java.base-launchers >>>> >>> Yes, and this works great when you are using an exploded build. It's >>> possible that Ioi is looking for an images build of course. In >>> general then this needs sjavac as Joe brings up. >>> >> If you have a full image build, make a change to something in >> java.base, you could do something like this to avoid unnecessary >> rebuilds: >> >> $ make java.base && make images-only > Thanks for the information. > > I tried this on my machine (32-way Xeon E5-2665 0 @ 2.40GHz), but it > still takes one minute if I change a single file in java.base :-( > > The making of java.base alone took about 30 seconds. > > $ time sh -c 'make JOBS=29 java.base && make images-only' > Building target 'java.base' in configuration '/home/iklam/jdk/bld/' > Compiling 2759 files for java.base > Finished building target 'java.base' in configuration > '/home/iklam/jdk/bld/' > Building target 'images-only' in configuration '/home/iklam/jdk/bld/' > Creating jdk server jimage > Creating jdk jimage > Creating jre jimage > duplicate resource > "META-INF/services/sun.management.spi.PlatformMBeanProvider", skipping > duplicate resource > "META-INF/services/sun.management.spi.PlatformMBeanProvider", skipping > duplicate resource > "META-INF/services/sun.management.spi.PlatformMBeanProvider", skipping > Unzipping jdk/src/closed/db/db-derby-10.10.2.0-bin.zip > duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", > skipping > Unzipping jdk/src/closed/db/db-derby-10.10.2.0-bin.zip > Updating images/sec-bin.zip > ## Starting verify-modules > Checking dependencies across JDK modules > Access verification succeeded. > ## Finished verify-modules (build time 00:00:16) > > Is there any way to make this faster? > > I used to have a script that compiles the exact set of .java files > that I touched, and patch rt.jar. It would complete the build in a > second or so. I guess I could update the script to work with modules > and jimage, but would be happier if I didn't have to. > > Thanks > - Ioi > > >> Note that if you put the *-only target on the same make command line, >> the results will be unpredictable as -only deactivates dependencies, >> so images would start running before java.base was properly done. >> >> A note on sjavac, I do believe it currently works (to some extent) in >> jdk9. >> >> /Erik > From jan.lahoda at oracle.com Fri May 22 07:20:16 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 22 May 2015 09:20:16 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555ED18B.8060802@oracle.com> References: <555D82CC.9070105@oracle.com> <20150521125941.1758@eggemoggin.niobe.net> <555ED18B.8060802@oracle.com> Message-ID: <555ED8B0.2030409@oracle.com> On 22.5.2015 08:49, Erik Joelsson wrote: > > On 2015-05-21 21:59, mark.reinhold at oracle.com wrote: >> 2015/5/21 12:01 -0700, jan.lahoda at oracle.com: >>> This is a patch adding a new option, -platform, to javac. >>> >>> Patch for the top-level repository is here: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>> >>> Patch for the langtools repository is here: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>> >>> These changes also require additional langtools changes as their >>> prerequisite: >>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >> Nice work -- I'm glad to see this coming in. >> >> What's the rationale for putting the symbol generator and all its data >> in the top-level repo? That'll add quite a bit of heft to a repo that's >> always been intended to remain fairly lightweight. Wouldn't it make >> more sense for this code and data to be placed in the langtools repo? >> Or is there some sort of build-bootstrapping issue here? > Technically these files could go in any repo, it's only a question of > where they best fit from a logical/maintaining point of view. I had not > thought about the langtools repo before, I just thought that it didn't > fit in the jdk repo so better put it in the top as it applies to all > modules. But the user of this data is the compiler so langtools does > make sense. There has been a brief discussion on which repo to use some time ago, and top-level repo seemed reasonable. I am personally fine with the langtools repo, if that's preferred. (Langtools repo is often cloned and used standalone, so these standalone checkouts would be bigger, but probably not a big problem.) Thanks, Jan > > /Erik > From jan.lahoda at oracle.com Fri May 22 12:38:06 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 22 May 2015 14:38:06 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555DB419.6020301@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> Message-ID: <555F232E.1060105@oracle.com> Hi, I've uploaded a new iteration of the patch(es): top-level repository: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ langtools: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ (besides full webrevs, there are also webrevs showing the differences between .00 and .01 available - see the "Delta webrev" link under "Author's comments") Summary of changes: -applied Eric's build changes -moved CreateSymbols into make/src/classes/build/tools/symbolgenerator -tried to improve the specification of base platforms in CreateSymbols, per Maurizio's comment -other cleanup in langtools per Maurizio's comments. Thanks, Jan On 21.5.2015 12:31, Maurizio Cimadamore wrote: > Hi Jan, > great work - couple of comments below: > > * it seems like some of the routines in Arguments can be simplified > using lambdas - especially lookupPlatformProvider and checkOptionAllowed > * Why JDKPlatformProvider is not called JDKPlatformProvider*Factory* ? > * JavacProcessingEnvironment.JoiningIterator seems to have commonalities > with CompoundScopeIterator - any chance that we might refactor this a bit? > * What's the rationale for giving an error if -platform is specified and > a non-StandardFileManager is provided? Can't we simply swallow that, > ignore the platform settings and issue a Lint 'options' warning? > * Would it make sense for some of the classfile generation logic in > CreateSymbols to be moved under the classfile API ? > * I had hard time reconciling some of the comments in CreateSymbols with > how the files were laid out. I think in the end, what you mean is that > if you have platforms 7, 8, 9 - you should pick one baseline (i.e. 8) > and then generate diffs for 9 and 7 against the 8 one. If that's the use > case, I think the command line can be simplified a bit in order to > explicitly state which of the platform is the baseline one, and the > remaining parameters can be inferred from the tool (as the > seem to be typically all identical > but one which is set to - the one for the baseline). Maybe the > inference logic should be different (i.e. use 8 as a baseline for 7 and > 7 as a baseline for 6) - but - whatever the logic, I think it should be > chosen once and for all, and live implicitly in the tool? Or are there > reasons as to why it might be handy to customize the baselines? > > Maurizio > > On 21/05/15 08:01, Jan Lahoda wrote: >> Hi, >> >> This is a patch adding a new option, -platform, to javac. >> >> Patch for the top-level repository is here: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >> >> Patch for the langtools repository is here: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >> >> These changes also require additional langtools changes as their >> prerequisite: >> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >> >> Overall, one can imagine '-platform N' to have the same effect as >> '-source N -target N -bootclasspath '. The possible values >> for 'N' are pluggable in a limited way, though (see >> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >> Note that this patch only introduces N=7 and N=8, which correspond to >> Open JDK 7 and 8 GA. >> >> A tricky problem to solve is where to get the APIs for platform N. The >> proposal is to include history data in the textual format inside the >> OpenJDK repositories (the input data), process them at build time and >> create a lib/ct.sym file holding the data in the JDK image. javac >> running with the -platform option then compiles against the lib/ct.sym >> file. The input history data are placed >> /make/data/symbols (the sym.txt files). This >> patches only includes data for OpenJDK 7 and 8, and only for public >> APIs (more or less Java SE and JDK @Exported APIs). >> >> The size of the history data is currently ~6MB in the JDK checkout and >> ~650kB inside the .hg directory (the size could change significantly >> if additional classes/elements, like non-public API classes, would >> need to be included). The lib/ct.sym file is currently ~4.5MB. >> >> The ct.sym file is a zip file containing signature files. The >> signature files are similar to classfiles (so javac can read them as >> classfiles), but are missing some attributes, most notably the Code >> attribute. On the top-level, the ct.sym contains directories named >> "7", "78" and "8". When compiling for version 'N', the bootclasspath >> for that version is obtained by using directories which have 'N' in >> their name. >> >> The sigfiles for ct.sym are created by >> /make/tools/symbolgenerator/CreateSymbols.java. >> The same file can also be used to construct the sym.txt files. Concise >> instructions are part of the CreateSymbols.java. >> >> I am sending this as one review, as the changes together make one >> feature, but the langtools and top-level changes are independent to a >> great degree: the langtools changes add the "-platform" javac; and the >> top-level changes add the history data and ability to build the ct.sym >> file. If desired, these could be pushed and/or reviewed independently. >> >> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >> Bateman and others who have provided advices and help on the matter >> before. >> >> Any insights/comments are wholeheartedly welcome. >> >> Thanks, >> Jan > From maurizio.cimadamore at oracle.com Fri May 22 12:52:34 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 22 May 2015 13:52:34 +0100 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555F232E.1060105@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> Message-ID: <555F2692.5030002@oracle.com> Excellent work. I think the comment in CreateSymbols could be made clearer w.r.t. Probe - i.e. that Probe should be ran on top of the JDK N - i.e. /bin/java Probe --> classes-8 /bin/java Probe --> classes-7 /bin/java Probe --> classes-7 etc. Maurizio On 22/05/15 13:38, Jan Lahoda wrote: > Hi, > > I've uploaded a new iteration of the patch(es): > top-level repository: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ > langtools: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ > > (besides full webrevs, there are also webrevs showing the differences > between .00 and .01 available - see the "Delta webrev" link under > "Author's comments") > > Summary of changes: > -applied Eric's build changes > -moved CreateSymbols into make/src/classes/build/tools/symbolgenerator > -tried to improve the specification of base platforms in > CreateSymbols, per Maurizio's comment > -other cleanup in langtools per Maurizio's comments. > > Thanks, > Jan > > On 21.5.2015 12:31, Maurizio Cimadamore wrote: >> Hi Jan, >> great work - couple of comments below: >> >> * it seems like some of the routines in Arguments can be simplified >> using lambdas - especially lookupPlatformProvider and checkOptionAllowed >> * Why JDKPlatformProvider is not called JDKPlatformProvider*Factory* ? >> * JavacProcessingEnvironment.JoiningIterator seems to have commonalities >> with CompoundScopeIterator - any chance that we might refactor this a >> bit? >> * What's the rationale for giving an error if -platform is specified and >> a non-StandardFileManager is provided? Can't we simply swallow that, >> ignore the platform settings and issue a Lint 'options' warning? >> * Would it make sense for some of the classfile generation logic in >> CreateSymbols to be moved under the classfile API ? >> * I had hard time reconciling some of the comments in CreateSymbols with >> how the files were laid out. I think in the end, what you mean is that >> if you have platforms 7, 8, 9 - you should pick one baseline (i.e. 8) >> and then generate diffs for 9 and 7 against the 8 one. If that's the use >> case, I think the command line can be simplified a bit in order to >> explicitly state which of the platform is the baseline one, and the >> remaining parameters can be inferred from the tool (as the >> seem to be typically all identical >> but one which is set to - the one for the baseline). Maybe the >> inference logic should be different (i.e. use 8 as a baseline for 7 and >> 7 as a baseline for 6) - but - whatever the logic, I think it should be >> chosen once and for all, and live implicitly in the tool? Or are there >> reasons as to why it might be handy to customize the baselines? >> >> Maurizio >> >> On 21/05/15 08:01, Jan Lahoda wrote: >>> Hi, >>> >>> This is a patch adding a new option, -platform, to javac. >>> >>> Patch for the top-level repository is here: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>> >>> Patch for the langtools repository is here: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>> >>> These changes also require additional langtools changes as their >>> prerequisite: >>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>> >>> Overall, one can imagine '-platform N' to have the same effect as >>> '-source N -target N -bootclasspath '. The possible values >>> for 'N' are pluggable in a limited way, though (see >>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>> >>> Note that this patch only introduces N=7 and N=8, which correspond to >>> Open JDK 7 and 8 GA. >>> >>> A tricky problem to solve is where to get the APIs for platform N. The >>> proposal is to include history data in the textual format inside the >>> OpenJDK repositories (the input data), process them at build time and >>> create a lib/ct.sym file holding the data in the JDK image. javac >>> running with the -platform option then compiles against the lib/ct.sym >>> file. The input history data are placed >>> /make/data/symbols (the sym.txt files). This >>> patches only includes data for OpenJDK 7 and 8, and only for public >>> APIs (more or less Java SE and JDK @Exported APIs). >>> >>> The size of the history data is currently ~6MB in the JDK checkout and >>> ~650kB inside the .hg directory (the size could change significantly >>> if additional classes/elements, like non-public API classes, would >>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>> >>> The ct.sym file is a zip file containing signature files. The >>> signature files are similar to classfiles (so javac can read them as >>> classfiles), but are missing some attributes, most notably the Code >>> attribute. On the top-level, the ct.sym contains directories named >>> "7", "78" and "8". When compiling for version 'N', the bootclasspath >>> for that version is obtained by using directories which have 'N' in >>> their name. >>> >>> The sigfiles for ct.sym are created by >>> /make/tools/symbolgenerator/CreateSymbols.java. >>> The same file can also be used to construct the sym.txt files. Concise >>> instructions are part of the CreateSymbols.java. >>> >>> I am sending this as one review, as the changes together make one >>> feature, but the langtools and top-level changes are independent to a >>> great degree: the langtools changes add the "-platform" javac; and the >>> top-level changes add the history data and ability to build the ct.sym >>> file. If desired, these could be pushed and/or reviewed independently. >>> >>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >>> Bateman and others who have provided advices and help on the matter >>> before. >>> >>> Any insights/comments are wholeheartedly welcome. >>> >>> Thanks, >>> Jan >> From chris.hegarty at oracle.com Fri May 22 12:55:26 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 22 May 2015 13:55:26 +0100 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <555ED385.80508@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> Message-ID: <555F273E.9010203@oracle.com> On 22/05/15 07:58, Erik Joelsson wrote: > > On 2015-05-22 02:46, Mandy Chung wrote: >> I?m including build-dev and we need to ask for Erik and Magnus advice >> what?s the best way to work around this. >> >> Erik, Magnus, >> Security providers now become service providers. They are >> provided from 11 different modules, 3 of them are os-specific. The >> current image builder doesn?t merge duplicate resources and we >> currently work around it in the build doing the merge as it?s >> temporary until the module system is moving further. >> Gensrc-jdk.jdi.gmk is the example. >> >> Valerie has a patch attempting to concatenate them and it turns out >> that it might not be straight forward I have thought. >> >> http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/make/gensrc/Gensrc-java.naming.gmk.html >> >> >> As we can?t say which one image builder will pick, it needs to copy >> gensrc (merged version) to all >> modules/$MODULE/META-INF/services/java.security.Provider config files. >> >> I wonder if it?s quicker to hack ImageBuilder to special case the >> service config file and merge them. >> >> Any thought? > I could certainly make this work in the makefile, but it is getting a > bit tedious to keep these hacks going there. How hard would it be to > change the ImageBuilder, which is just a temporary solution anyway, to > identify and merge all service provider files with the same name that it > finds? With that solution, the makefiles do not need to change as much > when the module system is introduced and taking care of this properly. I think it could be done either way. -Chris. > /Erik >> >>> On May 21, 2015, at 3:03 PM, Valerie Peng >>> wrote: >>> >>> Mandy, >>> >>> Please find comments in line. >>> >>> On 5/20/2015 10:39 PM, Mandy Chung wrote: >>>> A quick comment on the META-INF/services config files and the >>>> makefile. Merging the service config files is temporary until the >>>> module system is moving further along. >>>> >>>> src/jdk.crypto.ucrypto/solaris/classes/META-INF/services/java.security.Provider.html >>>> >>>> and other os-specific service configuration: >>>> 1 #[solaris]com.oracle.security.ucrypto.UcryptoProvider >>>> >>>> - why is this commented out? Does the makefile uncomment it? It >>>> should be simple >>>> concatenation with >>> In an example that I found through another makefile, it would >>> uncomment the entry start with "#[OS]" (and process/remove this >>> prefix) when the OS matches. We need OS-specific file processing when >>> concatenate these files. >> >> Ah? that?s from Gensrc-jdk.jdi.gmk. The service config file contains >> a mixture of cross-neutral and os-specific providers. That?s not the >> example to copy. >> >> define process-provider >> $(MKDIR) -p $(@D) >> $(CAT) $^ > $@ >> endef >> >> >>> What decides if it's appropriate or not? These are not just crypto >>> providers that we are defining here, but all classes which extend >>> from java.security.Provider. I recall using jdk.crypto.ec as the >>> gensrc module as you suggested initially. But when testing it, it >>> doesn't seem to work as expected. I ended up using java.naming as >>> that's the one ended up in the final image instead of the >>> concatenated one under jdk.crypto.ec. Could there be some alphabetic >>> ordering when processing/building these modules? >>> >>> Well, since this is really a hack and only temporary, does it really >>> matter whether it's under java.naming or jdk.crypto.ec? Both contains >>> providers for the java.security provider list. The key thing is that >>> the resulting image works >> Mandy > From jan.lahoda at oracle.com Fri May 22 13:22:39 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 22 May 2015 15:22:39 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555F2692.5030002@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> Message-ID: <555F2D9F.2090505@oracle.com> On 22.5.2015 14:52, Maurizio Cimadamore wrote: > Excellent work. > > I think the comment in CreateSymbols could be made clearer w.r.t. Probe > - i.e. that Probe should be ran on top of the JDK N - i.e. > > /bin/java Probe --> classes-8 > /bin/java Probe --> classes-7 > /bin/java Probe --> classes-7 > > etc. Sure, will do. I'll also look at generating the make/data/symbols/symbols descriptions automatically, per our offline discussion. Thanks! Jan > > Maurizio > > On 22/05/15 13:38, Jan Lahoda wrote: >> Hi, >> >> I've uploaded a new iteration of the patch(es): >> top-level repository: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >> langtools: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >> >> (besides full webrevs, there are also webrevs showing the differences >> between .00 and .01 available - see the "Delta webrev" link under >> "Author's comments") >> >> Summary of changes: >> -applied Eric's build changes >> -moved CreateSymbols into make/src/classes/build/tools/symbolgenerator >> -tried to improve the specification of base platforms in >> CreateSymbols, per Maurizio's comment >> -other cleanup in langtools per Maurizio's comments. >> >> Thanks, >> Jan >> >> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>> Hi Jan, >>> great work - couple of comments below: >>> >>> * it seems like some of the routines in Arguments can be simplified >>> using lambdas - especially lookupPlatformProvider and checkOptionAllowed >>> * Why JDKPlatformProvider is not called JDKPlatformProvider*Factory* ? >>> * JavacProcessingEnvironment.JoiningIterator seems to have commonalities >>> with CompoundScopeIterator - any chance that we might refactor this a >>> bit? >>> * What's the rationale for giving an error if -platform is specified and >>> a non-StandardFileManager is provided? Can't we simply swallow that, >>> ignore the platform settings and issue a Lint 'options' warning? >>> * Would it make sense for some of the classfile generation logic in >>> CreateSymbols to be moved under the classfile API ? >>> * I had hard time reconciling some of the comments in CreateSymbols with >>> how the files were laid out. I think in the end, what you mean is that >>> if you have platforms 7, 8, 9 - you should pick one baseline (i.e. 8) >>> and then generate diffs for 9 and 7 against the 8 one. If that's the use >>> case, I think the command line can be simplified a bit in order to >>> explicitly state which of the platform is the baseline one, and the >>> remaining parameters can be inferred from the tool (as the >>> seem to be typically all identical >>> but one which is set to - the one for the baseline). Maybe the >>> inference logic should be different (i.e. use 8 as a baseline for 7 and >>> 7 as a baseline for 6) - but - whatever the logic, I think it should be >>> chosen once and for all, and live implicitly in the tool? Or are there >>> reasons as to why it might be handy to customize the baselines? >>> >>> Maurizio >>> >>> On 21/05/15 08:01, Jan Lahoda wrote: >>>> Hi, >>>> >>>> This is a patch adding a new option, -platform, to javac. >>>> >>>> Patch for the top-level repository is here: >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>> >>>> Patch for the langtools repository is here: >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>> >>>> These changes also require additional langtools changes as their >>>> prerequisite: >>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>> >>>> Overall, one can imagine '-platform N' to have the same effect as >>>> '-source N -target N -bootclasspath '. The possible values >>>> for 'N' are pluggable in a limited way, though (see >>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>> >>>> Note that this patch only introduces N=7 and N=8, which correspond to >>>> Open JDK 7 and 8 GA. >>>> >>>> A tricky problem to solve is where to get the APIs for platform N. The >>>> proposal is to include history data in the textual format inside the >>>> OpenJDK repositories (the input data), process them at build time and >>>> create a lib/ct.sym file holding the data in the JDK image. javac >>>> running with the -platform option then compiles against the lib/ct.sym >>>> file. The input history data are placed >>>> /make/data/symbols (the sym.txt files). This >>>> patches only includes data for OpenJDK 7 and 8, and only for public >>>> APIs (more or less Java SE and JDK @Exported APIs). >>>> >>>> The size of the history data is currently ~6MB in the JDK checkout and >>>> ~650kB inside the .hg directory (the size could change significantly >>>> if additional classes/elements, like non-public API classes, would >>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>> >>>> The ct.sym file is a zip file containing signature files. The >>>> signature files are similar to classfiles (so javac can read them as >>>> classfiles), but are missing some attributes, most notably the Code >>>> attribute. On the top-level, the ct.sym contains directories named >>>> "7", "78" and "8". When compiling for version 'N', the bootclasspath >>>> for that version is obtained by using directories which have 'N' in >>>> their name. >>>> >>>> The sigfiles for ct.sym are created by >>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>> The same file can also be used to construct the sym.txt files. Concise >>>> instructions are part of the CreateSymbols.java. >>>> >>>> I am sending this as one review, as the changes together make one >>>> feature, but the langtools and top-level changes are independent to a >>>> great degree: the langtools changes add the "-platform" javac; and the >>>> top-level changes add the history data and ability to build the ct.sym >>>> file. If desired, these could be pushed and/or reviewed independently. >>>> >>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >>>> Bateman and others who have provided advices and help on the matter >>>> before. >>>> >>>> Any insights/comments are wholeheartedly welcome. >>>> >>>> Thanks, >>>> Jan >>> > From Roger.Riggs at Oracle.com Fri May 22 14:02:47 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 22 May 2015 10:02:47 -0400 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava In-Reply-To: <555ED2CC.3080308@oracle.com> References: <555E499C.6020300@Oracle.com> <555E7999.8000207@oracle.com> <555E7B5C.6020603@Oracle.com> <555ED2CC.3080308@oracle.com> Message-ID: <555F3707.1030003@Oracle.com> Hi Alan, The change to make the assert about the build numbers in getVersionInfo should be a different issue. Perhaps it makes sense to do that as part of the JEP 223: New Version-String Scheme that is specific to the Oracle JDK. Thanks, Roger On 5/22/2015 2:55 AM, Alan Bateman wrote: > > > On 22/05/2015 01:42, Roger Riggs wrote: >> Oops, got the wrong host: >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-fix-all-warnings-8074818/ >> >> Issues: >> 8074818: Resolve disabled warnings for libjava >> 8080007: Stop ignoring warnings for libjava >> >> Thanks, Roger > In JDK_GetVersionInfo0 then I wonder if we should change this assert > to be a fatal error on product builds. Periodically people set the > build to numbers > 255 and often only see issues when they use a > fastdebug build. > > Th rest looks okay to me. I don't particularly like the IOE_FORMAT in > ProcessImpl.c but I think other areas have done similar to deal with > this warning. ConcurrentPReader_md.c is being removed in another patch > under review at the moment so might be gone before you push. > > -Alan. From Alan.Bateman at oracle.com Fri May 22 15:09:24 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 May 2015 16:09:24 +0100 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <555F273E.9010203@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> <555F273E.9010203@oracle.com> Message-ID: <555F46A4.8040704@oracle.com> On 22/05/2015 13:55, Chris Hegarty wrote: > : > I think it could be done either way. Valerie - have you considered not pushing the services configuration files with this change? With the change then the java.security configuration is still class names, not provider names, so the fallback should just work. This is what we've done in a few other areas (like JNDI for example). -Alan From daniel.smith at oracle.com Fri May 22 15:47:25 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 22 May 2015 09:47:25 -0600 Subject: Status of ccache Message-ID: JDK-8027584 disabled ccache by default, I gather because it doesn't work in Cygwin, and secondarily because of vague general problems with it. The documentation (README-builds.html) still unambiguously endorses it, although doesn't say anything about how to turn it on (configure with --enable-ccache). I'm curious about the current state of affairs, and suggest updating the documentation to reflect the answer. ?Dan From martinrb at google.com Fri May 22 16:14:25 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 May 2015 09:14:25 -0700 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava In-Reply-To: <555E499C.6020300@Oracle.com> References: <555E499C.6020300@Oracle.com> Message-ID: I plan to have review comments later today. On Thu, May 21, 2015 at 2:09 PM, Roger Riggs wrote: > Please review these native code and build changes to clear compilation > warnings. > Most are due to mixing unsigned types with signed types or providing > the correct type to an invoked function. > > Webrev: > > http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-fix-all-warnings-8074818/ > > Issues: > 8074818: Resolve disabled warnings for libjava > 8080007: Stop ignoring warnings for libjava > > JPRT in progress for product and fastdebug builds on solaris, linux, > macosx, windows, > and embedded. > > Thanks, Roger > > From mandy.chung at oracle.com Fri May 22 16:53:25 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 May 2015 09:53:25 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <555F46A4.8040704@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> <555F273E.9010203@oracle.com> <555F46A4.8040704@oracle.com> Message-ID: <555F5F05.503@oracle.com> On 05/22/2015 08:09 AM, Alan Bateman wrote: > > On 22/05/2015 13:55, Chris Hegarty wrote: >> : >> I think it could be done either way. > > Valerie - have you considered not pushing the services configuration > files with this change? With the change then the java.security > configuration is still class names, not provider names, so the > fallback should just work. This is what we've done in a few other > areas (like JNDI for example). I wasn't aware of the other areas that move to service provider but remain being loaded with the fallback Class.forName. I would prefer java.security should convert to use the provider names as an example and also exercise the code path using service providers. If this causes much work to workaround it temporarily, I won't object the security providers are not truly service providers (no META-INF/services and java.security lists class name instead) Another option to workaround this: we only need to merge the service config files for generating the image. Can we have do the concatenation of jdk/modules/*/META-INF/services file and output to supports/image_gensrc before the images target and have the image builder to exclude all jdk/modules/*/META-INF/services files and take the supports/image_gensrc instead? This will remove the process-provider logic from Gensrc-*.gmk files. Would this be a better alternative? Mandy From martinrb at google.com Fri May 22 17:47:54 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 May 2015 10:47:54 -0700 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava In-Reply-To: References: <555E499C.6020300@Oracle.com> Message-ID: It's a good idea to order include statements by system dependencies, jdk dependencies, implementation helpers, BUT order of include statements should never ever matter. If it does, then we have a bug that should be fixed. Every header file should be independently includable, and C files should only Include What They Use. It would be good for us to test some of that, e.g. can you compile each .h file as its own translation unit? +#include +#include + #include "jni.h" #include "jni_util.h" #include "jlong.h" @@ -32,9 +35,6 @@ #include "java_io_FileInputStream.h" -#include -#include - From martinrb at google.com Fri May 22 17:54:47 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 May 2015 10:54:47 -0700 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava In-Reply-To: References: <555E499C.6020300@Oracle.com> Message-ID: I agree it's a good idea to increase safety by replacing calls to *printf with calls to *nprintf, BUT when we do so we should also add debugging assertions that the message fits into the buffer. - sprintf(errmsg, format, errnum, detail); + snprintf(errmsg, fmtsize, IOE_FORMAT, errnum, detail); How about int needed = snprintf(...) assert(needed <= fmtsize); From martinrb at google.com Fri May 22 18:00:52 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 May 2015 11:00:52 -0700 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava In-Reply-To: References: <555E499C.6020300@Oracle.com> Message-ID: The double assignment to i is stupid (a "dead store") - remove one of them. 63 size_t i = 0; 64 for (i = 1; i < len; i++) { From christos at zoulas.com Fri May 22 18:03:24 2015 From: christos at zoulas.com (Christos Zoulas) Date: Fri, 22 May 2015 14:03:24 -0400 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava In-Reply-To: from Martin Buchholz (May 22, 10:54am) Message-ID: <20150522180324.3909D17FDA8@rebar.astron.com> On May 22, 10:54am, martinrb at google.com (Martin Buchholz) wrote: -- Subject: Re: RFR 9: 8074818: Resolve disabled warnings for libjava | I agree it's a good idea to increase safety by replacing calls to *printf | with calls to *nprintf, BUT when we do so we should also add debugging | assertions that the message fits into the buffer. | | - sprintf(errmsg, format, errnum, detail); | + snprintf(errmsg, fmtsize, IOE_FORMAT, errnum, detail); | | How about | | int needed = snprintf(...) | assert(needed <= fmtsize); This only works if fmtsize is unsigned (which I hope it is) when snprintf returns < 0. It will also produce a warning with -Wsign-compare. For safety you could do: assert((size_t)needed <= fmtsize) christos From magnus.ihse.bursie at oracle.com Mon May 25 07:38:29 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 25 May 2015 09:38:29 +0200 Subject: make[2]: *** No rule to make target..'/home/*/...needed by jtreg_tests In-Reply-To: <555CA52D.7010308@oracle.com> References: <555CA52D.7010308@oracle.com> Message-ID: <5562D175.3090302@oracle.com> On 2015-05-20 17:15, Erik Joelsson wrote: > It seems jdk/test/Makefile is still looking for j2sdk-image as a > fallback default, but it has been changed to be just images/jdk. If > you run tests from the top level that shouldn't happen. Alternatively > you can specify PRODUCT_HOME=/path/to/your/jdk/image. You could of > course also fix the bug in jdk/test/Makefile. Or run the test using the top-level Makefile instead. That way, you'll get a proper configuration. make test TEST="jtreg_tests" instead of "cd test && make jtreg_tests" /Magnus > > /Erik > > On 2015-04-26 22:44, Kingsley Osime wrote: >> I am trying to build openjdk and everything seems to have gone ok except >> when I test i get make[2]: *** No rule to make target >> `/home/hellofadude/dev/openjdk/jdk9/build/linux-x86_64-normal-server-release/images/j2sdk-image', >> >> needed by `jtreg_tests'. >> >> I also notice my build does not produce the j2sdk-image directory even >> after several tries and can not understand why? >> >> Perhaps someone can cast an expert eye over my build log ? >> >> Thanks >> >> Compiling 5 files for BUILD_GENMODULESLIST >> Compiling 8 files for BUILD_TOOLS_LANGTOOLS >> Compiling 20 properties into resource bundles for jdk.compiler >> Parsing 1 properties into enum-like class for jdk.compiler >> Compiling 5 properties into resource bundles for jdk.dev >> Compiling 10 properties into resource bundles for jdk.javadoc >> Compiling 821 files for BUILD_INTERIM_LANGTOOLS >> Creating buildtools/interim_langtools.jar >> Compiling 23 files for BUILD_INTERIM_JIMAGE >> Compiling 161 files for BUILD_TOOLS_JDK >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Creating sun/util/locale/provider/EnLocaleDataMetaInfo.java from 424 >> found >> resources. >> Generating sun/misc/Version.java >> Creating genSocketOptionRegistry from 1 file(s) >> Creating genUnixConstants from 1 file(s) >> Generating buffer classes >> Generating exceptions classes >> Compiling 11 properties into resource bundles for java.base >> Compiling 22 properties into resource bundles for java.base >> Compiling 2752 files for java.base >> Compiling 1814 files for java.xml >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Compiling 13 files for java.prefs >> Compiling 131 files for jdk.charsets >> Compiling 16 files for java.datatransfer >> Compiling 11 properties into resource bundles for java.logging >> Compiling 32 files for java.logging >> Generating icon classes >> Generating X11 wrapper (64-bit version) >> Verifying >> /home/hellofadude/dev/openjdk/jdk9/build/linux-x86_64-normal-server-release/support/gensrc/java.desktop/_x11wrappers/sizes.64.verification.tmp >> >> to >> /home/hellofadude/dev/openjdk/jdk9/build/linux-x86_64-normal-server-release/support/gensrc/java.desktop/_x11wrappers/sizes.64 >> >> Generating beaninfo >> Generating Nimbus source files >> Compiling 100 properties into resource bundles for java.desktop >> Compiling 2755 files for java.desktop >> Compiling 24 files for java.activation >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Compiling 5 files for java.annotations.common >> Compiling 4 files for BUILD_BREAKITERATOR >> Generating blacklisted certs >> Creating support/jce/policy/unlimited/US_export_policy.jar >> Creating support/jce/policy/limited/local_policy.jar >> Creating support/jce/policy/unlimited/local_policy.jar >> Generating java.security >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Warning: generation and use of skeletons and static stubs for JRMP >> is deprecated. Skeletons are unnecessary, and static stubs have >> been superseded by dynamically generated stubs. Users are >> encouraged to migrate away from using rmic to generate skeletons and >> static >> stubs. See the documentation for java.rmi.server.UnicastRemoteObject. >> All done. >> Generating linux_amd64_docs/jvmti.html >> Creating libverify.so from 2 file(s) >> Creating libjava.so from 60 file(s) >> Creating libfdlibm.a from 62 file(s) >> Creating libzip.so from 21 file(s) >> Creating libjli.so from 15 file(s) >> Creating libnet.so from 21 file(s) >> Creating libnio.so from 25 file(s) >> Creating java from 1 file(s) >> Creating keytool from 1 file(s) >> Creating jexec from 1 file(s) >> Compiling 114 files for java.compiler >> Compiling 141 files for BUILD_IDLJ >> Note: >> /home/hellofadude/dev/openjdk/jdk9/corba/src/java.corba/share/classes/com/sun/tools/corba/se/idl/som/idlemit/MetaPragma.java >> >> uses or overrides a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Compiling 6 files for BUILD_TOOLS_CORBA >> Compiling 133 files for java.rmi >> Compiling 3 files for java.transaction >> Compiling 29 files for java.security.sasl >> Compiling 191 files for java.naming >> Compiling 1476 files for java.corba >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Creating idlj from 1 file(s) >> Creating orbd from 1 file(s) >> Creating servertool from 1 file(s) >> Creating tnameserv from 1 file(s) >> Generating HTML DTD file >> [Parsed DTD html32 in 897ms] >> Creating libmlib_image.so from 55 file(s) >> Creating libawt.so from 72 file(s) >> Creating libawt_xawt.so from 53 file(s) >> /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/unix/native/common/awt/awt_Font.c: >> >> In function ?awtJNI_GetFontData?: >> /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/unix/native/common/awt/awt_Font.c:643:23: >> >> warning: comparison between pointer and integer [enabled by default] >> if (xfont == (Font) NULL || xfont->ascent < 0) { >> ^ >> /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:69:0: >> >> warning: "MIN" redefined [enabled by default] >> #define MIN(a, b) (((a) < (b)) ? (a) : (b)) >> ^ >> In file included from >> /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.base/unix/native/include/jvm_md.h:35:0, >> >> from >> /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:33: >> >> /usr/include/x86_64-linux-gnu/sys/param.h:99:0: note: this is the >> location >> of the previous definition >> #define MIN(a,b) (((a)<(b))?(a):(b)) >> ^ >> Creating liblcms.so from 26 file(s) >> Creating libjavajpeg.so from 46 file(s) >> Creating libawt_headless.so from 26 file(s) >> Creating libfontmanager.so from 94 file(s) >> cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++ >> but not for C [enabled by default] >> cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is >> valid >> for C++/ObjC++ but not for C [enabled by default] >> cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++ >> but not for C [enabled by default] >> cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is >> valid >> for C++/ObjC++ but not for C [enabled by default] >> cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++ >> but not for C [enabled by default] >> cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is >> valid >> for C++/ObjC++ but not for C [enabled by default] >> cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++ >> but not for C [enabled by default] >> cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is >> valid >> for C++/ObjC++ but not for C [enabled by default] >> cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++ >> but not for C [enabled by default] >> cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is >> valid >> for C++/ObjC++ but not for C [enabled by default] >> /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/share/native/libfontmanager/sunFont.c: >> >> In function ?freeLayoutTableCache?: >> /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/share/native/libfontmanager/sunFont.c:357:7: >> >> warning: passing argument 1 of ?free? discards ?const? qualifier from >> pointer target type [enabled by default] >> if(ltc->entries[i].ptr) free (ltc->entries[i].ptr); >> ^ >> In file included from >> /home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/share/native/libfontmanager/sunFont.c:26:0: >> >> /usr/include/stdlib.h:483:13: note: expected ?void *? but argument is of >> type ?const void *? >> extern void free (void *__ptr) __THROW; >> ^ >> Creating libjawt.so from 1 file(s) >> Creating libsplashscreen.so from 84 file(s) >> Creating libjsound.so from 2 file(s) >> Creating libjsoundalsa.so from 17 file(s) >> Creating appletviewer from 1 file(s) >> Compiling 7 files for java.instrument >> Creating libinstrument.so from 12 file(s) >> Compiling 11 properties into resource bundles for java.management >> Compiling 393 files for java.management >> Compiling 1688 files for BUILD_INTERIM_CORBA >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Creating buildtools/interim_corba.jar >> Compiling 198 files for BUILD_INTERIM_RMIC >> Warning: generation and use of skeletons and static stubs for JRMP >> is deprecated. Skeletons are unnecessary, and static stubs have >> been superseded by dynamically generated stubs. Users are >> encouraged to migrate away from using rmic to generate skeletons and >> static >> stubs. See the documentation for java.rmi.server.UnicastRemoteObject. >> Warning: generation and use of skeletons and static stubs for JRMP >> is deprecated. Skeletons are unnecessary, and static stubs have >> been superseded by dynamically generated stubs. Users are >> encouraged to migrate away from using rmic to generate skeletons and >> static >> stubs. See the documentation for java.rmi.server.UnicastRemoteObject. >> Creating libmanagement.so from 16 file(s) >> Creating libprefs.so from 1 file(s) >> Warning: generation and use of skeletons and static stubs for JRMP >> is deprecated. Skeletons are unnecessary, and static stubs have >> been superseded by dynamically generated stubs. Users are >> encouraged to migrate away from using rmic to generate skeletons and >> static >> stubs. See the documentation for java.rmi.server.UnicastRemoteObject. >> Warning: generation and use of skeletons and static stubs for JRMP >> is deprecated. Skeletons are unnecessary, and static stubs have >> been superseded by dynamically generated stubs. Users are >> encouraged to migrate away from using rmic to generate skeletons and >> static >> stubs. See the documentation for java.rmi.server.UnicastRemoteObject. >> Creating rmid from 1 file(s) >> Creating rmiregistry from 1 file(s) >> Compiling 13 files for java.scripting >> Creating jrunscript from 1 file(s) >> Compiling 211 files for java.security.jgss >> Creating libj2gss.so from 3 file(s) >> Compiling 20 files for java.smartcardio >> Creating libj2pcsc.so from 2 file(s) >> Compiling 72 files for java.sql >> Compiling 50 files for java.sql.rowset >> Compiling 745 files for java.xml.bind >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Compiling 281 files for java.xml.crypto >> Compiling 43 files for jdk.httpserver >> Compiling 1224 files for java.xml.ws >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Compiling 17 files for jdk.accessibility >> Compiling 68 files for jdk.jvmstat >> Compiling 14 files for jdk.attach >> Creating libattach.so from 1 file(s) >> Compiling 442 files for jdk.compiler >> Creating javac from 1 file(s) >> Creating javah from 1 file(s) >> Creating javap from 1 file(s) >> Creating serialver from 1 file(s) >> Compiling 8 files for jdk.crypto.ec >> Creating libsunec.so from 28 file(s) >> Compiling 66 files for jdk.crypto.pkcs11 >> Creating libj2pkcs11.so from 14 file(s) >> Compiling 1 properties into resource bundles for jdk.dev >> Compiling 90 files for jdk.dev >> Compiling 1 files for jdk.hprof.agent >> Compiling 11 properties into resource bundles for jdk.jartool >> Compiling 25 files for jdk.jartool >> Compiling 252 files for jdk.javadoc >> Compiling 36 files for jdk.jcmd >> Compiling 63 files for jdk.jconsole >> Compiling 3 properties into resource bundles for jdk.jdi >> Compiling 246 files for jdk.jdi >> Creating sun/util/resources/provider/NonEnLocaleDataMetaInfo.java >> from 424 >> found resources. >> Compiling 209 properties into resource bundles for jdk.localedata >> Compiling 1569 files for jdk.localedata >> Compiling 16 files for jdk.naming.dns >> Compiling 6 files for jdk.naming.rmi >> Compiling 13 files for jdk.policytool >> Compiling 226 files for jdk.rmic >> Note: >> /home/hellofadude/dev/openjdk/jdk9/corba/src/jdk.rmic/share/classes/sun/rmi/rmic/iiop/DirectoryLoader.java >> >> uses or overrides a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Compiling 605 files for BUILD_NASHORN >> Compiling 111 files for BUILD_NASGEN >> Running nasgen >> Creating version.properties >> Compiling 32 files for jdk.sctp >> Compiling 36 files for jdk.security.auth >> Compiling 12 files for jdk.security.jgss >> Compiling 777 files for jdk.xml.bind >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Compiling 89 files for jdk.xml.dom >> Compiling 234 files for jdk.xml.ws >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Compiling 12 files for jdk.zipfs >> Warning: generation and use of skeletons and static stubs for JRMP >> is deprecated. Skeletons are unnecessary, and static stubs have >> been superseded by dynamically generated stubs. Users are >> encouraged to migrate away from using rmic to generate skeletons and >> static >> stubs. See the documentation for java.rmi.server.UnicastRemoteObject. >> Creating jdeps from 1 file(s) >> Creating jimage from 1 file(s) >> Creating jhat from 1 file(s) >> Creating native2ascii from 1 file(s) >> Creating jsadebugd from 1 file(s) >> Creating libhprof.so from 26 file(s) >> Creating libjava_crw_demo.so from 1 file(s) >> Creating jar from 1 file(s) >> Creating jarsigner from 1 file(s) >> Creating javadoc from 1 file(s) >> Creating jinfo from 1 file(s) >> Creating jmap from 1 file(s) >> Creating jps from 1 file(s) >> Creating jstack from 1 file(s) >> Creating jstat from 1 file(s) >> Creating jcmd from 1 file(s) >> Creating jconsole from 1 file(s) >> Creating jdb from 1 file(s) >> Creating libdt_socket.so from 2 file(s) >> Creating libjdwp.so from 41 file(s) >> Creating jstatd from 1 file(s) >> Creating libunpack.so from 7 file(s) >> Creating pack200 from 1 file(s) >> Creating unpack200 from 7 file(s) >> /home/hellofadude/dev/openjdk/jdk9/jdk/src/jdk.pack200/share/native/unpack200/main.cpp: >> >> In static member function ?static int unpacker::run(int, char**)?: >> /home/hellofadude/dev/openjdk/jdk9/jdk/src/jdk.pack200/share/native/unpack200/main.cpp:438:55: >> >> warning: ignoring return value of ?size_t fread(void*, size_t, size_t, >> FILE*)?, declared with attribute warn_unused_result [-Wunused-result] >> fread(&filecrc, sizeof(filecrc), 1, u.infileptr); >> ^ >> Creating policytool from 1 file(s) >> Creating rmic from 1 file(s) >> Creating jjs from 1 file(s) >> Creating libsctp.so from 3 file(s) >> Creating libjaas_unix.so from 1 file(s) >> Creating schemagen from 1 file(s) >> Creating xjc from 1 file(s) >> Creating wsgen from 1 file(s) >> Creating wsimport from 1 file(s) >> Updating support/src.zip >> Compiling 1 files for BUILD_DEMO_APPLET_ArcTest >> Compiling 1 files for BUILD_DEMO_APPLET_BarChart >> Compiling 1 files for BUILD_DEMO_APPLET_Blink >> Compiling 1 files for BUILD_DEMO_APPLET_CardTest >> Compiling 1 files for BUILD_DEMO_APPLET_Clock >> Compiling 1 files for BUILD_DEMO_APPLET_DitherTest >> Compiling 1 files for BUILD_DEMO_APPLET_DrawTest >> Compiling 1 files for BUILD_DEMO_APPLET_Fractal >> Compiling 2 files for BUILD_DEMO_APPLET_GraphicsTest >> Compiling 1 files for BUILD_DEMO_APPLET_NervousText >> Compiling 1 files for BUILD_DEMO_APPLET_SimpleGraph >> Compiling 5 files for BUILD_DEMO_APPLET_SortDemo >> Compiling 1 files for BUILD_DEMO_APPLET_SpreadSheet >> Compiling 3 files for BUILD_DEMO_CodePointIM >> Creating support/demo/image/jfc/CodePointIM/src.zip >> Updating support/demo/image/jfc/CodePointIM/src.zip >> Compiling 2 files for BUILD_DEMO_MoleculeViewer >> Creating support/demo/image/applets/MoleculeViewer/src.zip >> Updating support/demo/image/applets/MoleculeViewer/src.zip >> Compiling 2 files for BUILD_DEMO_WireFrame >> Creating support/demo/image/applets/WireFrame/src.zip >> Updating support/demo/image/applets/WireFrame/src.zip >> Compiling 1 files for BUILD_DEMO_SwingApplet >> Creating support/demo/image/jfc/SwingApplet/src.zip >> Updating support/demo/image/jfc/SwingApplet/src.zip >> Compiling 3 files for BUILD_DEMO_FileChooserDemo >> Note: >> /home/hellofadude/dev/openjdk/jdk9/jdk/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java >> >> uses unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Creating support/demo/image/jfc/FileChooserDemo/src.zip >> Updating support/demo/image/jfc/FileChooserDemo/src.zip >> Compiling 4 files for BUILD_DEMO_Font2DTest >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Creating support/demo/image/jfc/Font2DTest/src.zip >> Updating support/demo/image/jfc/Font2DTest/src.zip >> Compiling 15 files for BUILD_DEMO_Metalworks >> Note: >> /home/hellofadude/dev/openjdk/jdk9/jdk/src/demo/share/jfc/Metalworks/MetalworksPrefs.java >> >> uses unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Creating support/demo/image/jfc/Metalworks/src.zip >> Updating support/demo/image/jfc/Metalworks/src.zip >> Compiling 2 files for BUILD_DEMO_Notepad >> Creating support/demo/image/jfc/Notepad/src.zip >> Updating support/demo/image/jfc/Notepad/src.zip >> Compiling 5 files for BUILD_DEMO_SampleTree >> Creating support/demo/image/jfc/SampleTree/src.zip >> Updating support/demo/image/jfc/SampleTree/src.zip >> Compiling 8 files for BUILD_DEMO_TableExample >> Note: >> /home/hellofadude/dev/openjdk/jdk9/jdk/src/demo/share/jfc/TableExample/TableExample4.java >> >> uses unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Creating support/demo/image/jfc/TableExample/src.zip >> Updating support/demo/image/jfc/TableExample/src.zip >> Compiling 1 files for BUILD_DEMO_TransparentRuler >> Creating support/demo/image/jfc/TransparentRuler/src.zip >> Updating support/demo/image/jfc/TransparentRuler/src.zip >> Compiling 3 files for BUILD_DEMO_jconsole-plugin >> Creating support/demo/image/scripting/jconsole-plugin/src.zip >> Updating support/demo/image/scripting/jconsole-plugin/src.zip >> Compiling 3 files for BUILD_DEMO_FullThreadDump >> Creating support/demo/image/management/FullThreadDump/src.zip >> Updating support/demo/image/management/FullThreadDump/src.zip >> Compiling 2 files for BUILD_DEMO_JTop >> Creating support/demo/image/management/JTop/src.zip >> Updating support/demo/image/management/JTop/src.zip >> Compiling 1 files for BUILD_DEMO_MemoryMonitor >> Creating support/demo/image/management/MemoryMonitor/src.zip >> Updating support/demo/image/management/MemoryMonitor/src.zip >> Compiling 2 files for BUILD_DEMO_VerboseGC >> Creating support/demo/image/management/VerboseGC/src.zip >> Updating support/demo/image/management/VerboseGC/src.zip >> Creating libcompiledMethodLoad.so from 2 file(s) >> Updating support/demo/image/jvmti/compiledMethodLoad/src.zip >> Creating libgctest.so from 2 file(s) >> Updating support/demo/image/jvmti/gctest/src.zip >> Compiling 1 files for BUILD_DEMO_JVMTI_heapTracker_JAVA >> Creating support/demo/image/jvmti/heapTracker/heapTracker.jar >> Creating libheapTracker.so from 3 file(s) >> Updating support/demo/image/jvmti/heapTracker/src.zip >> Creating libheapViewer.so from 2 file(s) >> Updating support/demo/image/jvmti/heapViewer/src.zip >> Compiling 1 files for BUILD_DEMO_JVMTI_minst_JAVA >> Creating support/demo/image/jvmti/minst/minst.jar >> Creating libminst.so from 3 file(s) >> Updating support/demo/image/jvmti/minst/src.zip >> Compiling 1 files for BUILD_DEMO_JVMTI_mtrace_JAVA >> Creating support/demo/image/jvmti/mtrace/mtrace.jar >> Creating libmtrace.so from 3 file(s) >> Updating support/demo/image/jvmti/mtrace/src.zip >> Creating libwaiters.so from 5 file(s) >> Updating support/demo/image/jvmti/waiters/src.zip >> Creating libversionCheck.so from 2 file(s) >> Updating support/demo/image/jvmti/versionCheck/src.zip >> Creating support/jrt-fs.jar >> Creating jre jimage >> Creating jdk jimage >> duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", >> skipping >> Updating images/sec-bin.zip >> ## Starting verify-modules >> Checking dependencies across JDK modules >> Access verification succeeded. >> ## Finished verify-modules (build time 00:01:33) >> >> ----- Build times ------- >> Start 2015-04-25 16:14:07 >> End 2015-04-25 21:54:24 >> 00:01:33 verify-modules >> 05:40:17 TOTAL >> ------------------------- >> Finished building targets 'clean images' in configuration >> 'linux-x86_64-normal-server-release' > From magnus.ihse.bursie at oracle.com Mon May 25 07:44:26 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 25 May 2015 09:44:26 +0200 Subject: Status of ccache In-Reply-To: References: Message-ID: <5562D2DA.3040005@oracle.com> On 2015-05-22 17:47, Dan Smith wrote: > JDK-8027584 disabled ccache by default, I gather because it doesn't work in Cygwin, and secondarily because of vague general problems with it. > > The documentation (README-builds.html) still unambiguously endorses it, although doesn't say anything about how to turn it on (configure with --enable-ccache). > > I'm curious about the current state of affairs, and suggest updating the documentation to reflect the answer. Ccache is an improvement in some situation, but most often not. Especially the hotspot build performance can be affected by ccache presense or absense. There are two major knobs to turn for tuning hotspot build performance: precompiled headers, and ccache. The only general rule I can give is: 1) do not use both at the same time, that is more or less always a loss 2) you need to test both for your specific workflow, and measure, to see which is best for you Factors affecting the performance include: 1) Your typical workflow: do you recompile often? From different repos? Do you typically do incremental rebuilds or builds from scratch (like a Hudson build server)? 2) Your OS 3) Your hardware, and not just like "x86 system" but very specific hardware aspects of CPU, bus, memory and disk can alter the performance conditions. In short: since ccache does not give everyone a performance benefit all the time, and carries with it risk of complication, we default by having it turned off. Precompiled headers are currently on by default, but there are discussions in the hotspot team to change that default as well. The build documentation is sadly outdated in several aspects. :-( /Magnus From magnus.ihse.bursie at oracle.com Mon May 25 07:51:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 25 May 2015 09:51:20 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555F232E.1060105@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> Message-ID: <5562D478.3000806@oracle.com> On 2015-05-22 14:38, Jan Lahoda wrote: > Hi, > > I've uploaded a new iteration of the patch(es): > top-level repository: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ > langtools: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ > > (besides full webrevs, there are also webrevs showing the differences > between .00 and .01 available - see the "Delta webrev" link under > "Author's comments") > > Summary of changes: > -applied Eric's build changes > -moved CreateSymbols into make/src/classes/build/tools/symbolgenerator > -tried to improve the specification of base platforms in > CreateSymbols, per Maurizio's comment > -other cleanup in langtools per Maurizio's comments. Looks good to me! Copyright year in CreateSymbols.java says 2014, maybe time to update it? :-) /Magnus > > Thanks, > Jan > > On 21.5.2015 12:31, Maurizio Cimadamore wrote: >> Hi Jan, >> great work - couple of comments below: >> >> * it seems like some of the routines in Arguments can be simplified >> using lambdas - especially lookupPlatformProvider and checkOptionAllowed >> * Why JDKPlatformProvider is not called JDKPlatformProvider*Factory* ? >> * JavacProcessingEnvironment.JoiningIterator seems to have commonalities >> with CompoundScopeIterator - any chance that we might refactor this a >> bit? >> * What's the rationale for giving an error if -platform is specified and >> a non-StandardFileManager is provided? Can't we simply swallow that, >> ignore the platform settings and issue a Lint 'options' warning? >> * Would it make sense for some of the classfile generation logic in >> CreateSymbols to be moved under the classfile API ? >> * I had hard time reconciling some of the comments in CreateSymbols with >> how the files were laid out. I think in the end, what you mean is that >> if you have platforms 7, 8, 9 - you should pick one baseline (i.e. 8) >> and then generate diffs for 9 and 7 against the 8 one. If that's the use >> case, I think the command line can be simplified a bit in order to >> explicitly state which of the platform is the baseline one, and the >> remaining parameters can be inferred from the tool (as the >> seem to be typically all identical >> but one which is set to - the one for the baseline). Maybe the >> inference logic should be different (i.e. use 8 as a baseline for 7 and >> 7 as a baseline for 6) - but - whatever the logic, I think it should be >> chosen once and for all, and live implicitly in the tool? Or are there >> reasons as to why it might be handy to customize the baselines? >> >> Maurizio >> >> On 21/05/15 08:01, Jan Lahoda wrote: >>> Hi, >>> >>> This is a patch adding a new option, -platform, to javac. >>> >>> Patch for the top-level repository is here: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>> >>> Patch for the langtools repository is here: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>> >>> These changes also require additional langtools changes as their >>> prerequisite: >>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>> >>> Overall, one can imagine '-platform N' to have the same effect as >>> '-source N -target N -bootclasspath '. The possible values >>> for 'N' are pluggable in a limited way, though (see >>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>> >>> Note that this patch only introduces N=7 and N=8, which correspond to >>> Open JDK 7 and 8 GA. >>> >>> A tricky problem to solve is where to get the APIs for platform N. The >>> proposal is to include history data in the textual format inside the >>> OpenJDK repositories (the input data), process them at build time and >>> create a lib/ct.sym file holding the data in the JDK image. javac >>> running with the -platform option then compiles against the lib/ct.sym >>> file. The input history data are placed >>> /make/data/symbols (the sym.txt files). This >>> patches only includes data for OpenJDK 7 and 8, and only for public >>> APIs (more or less Java SE and JDK @Exported APIs). >>> >>> The size of the history data is currently ~6MB in the JDK checkout and >>> ~650kB inside the .hg directory (the size could change significantly >>> if additional classes/elements, like non-public API classes, would >>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>> >>> The ct.sym file is a zip file containing signature files. The >>> signature files are similar to classfiles (so javac can read them as >>> classfiles), but are missing some attributes, most notably the Code >>> attribute. On the top-level, the ct.sym contains directories named >>> "7", "78" and "8". When compiling for version 'N', the bootclasspath >>> for that version is obtained by using directories which have 'N' in >>> their name. >>> >>> The sigfiles for ct.sym are created by >>> /make/tools/symbolgenerator/CreateSymbols.java. >>> The same file can also be used to construct the sym.txt files. Concise >>> instructions are part of the CreateSymbols.java. >>> >>> I am sending this as one review, as the changes together make one >>> feature, but the langtools and top-level changes are independent to a >>> great degree: the langtools changes add the "-platform" javac; and the >>> top-level changes add the history data and ability to build the ct.sym >>> file. If desired, these could be pushed and/or reviewed independently. >>> >>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >>> Bateman and others who have provided advices and help on the matter >>> before. >>> >>> Any insights/comments are wholeheartedly welcome. >>> >>> Thanks, >>> Jan >> From magnus.ihse.bursie at oracle.com Mon May 25 07:52:58 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 25 May 2015 09:52:58 +0200 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava In-Reply-To: <555F3707.1030003@Oracle.com> References: <555E499C.6020300@Oracle.com> <555E7999.8000207@oracle.com> <555E7B5C.6020603@Oracle.com> <555ED2CC.3080308@oracle.com> <555F3707.1030003@Oracle.com> Message-ID: <5562D4DA.1010607@oracle.com> On 2015-05-22 16:02, Roger Riggs wrote: > Hi Alan, > > The change to make the assert about the build numbers in > getVersionInfo should be a different issue. > Perhaps it makes sense to do that as part of the JEP 223: New > Version-String Scheme > that is specific to the Oracle JDK. The current JEP-223 sandbox does indeed have a check in configure that build numbers cannot exceed 255. /Magnus > > Thanks, Roger > > > > On 5/22/2015 2:55 AM, Alan Bateman wrote: >> >> >> On 22/05/2015 01:42, Roger Riggs wrote: >>> Oops, got the wrong host: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-fix-all-warnings-8074818/ >>> >>> Issues: >>> 8074818: Resolve disabled warnings for libjava >>> 8080007: Stop ignoring warnings for libjava >>> >>> Thanks, Roger >> In JDK_GetVersionInfo0 then I wonder if we should change this assert >> to be a fatal error on product builds. Periodically people set the >> build to numbers > 255 and often only see issues when they use a >> fastdebug build. >> >> Th rest looks okay to me. I don't particularly like the IOE_FORMAT in >> ProcessImpl.c but I think other areas have done similar to deal with >> this warning. ConcurrentPReader_md.c is being removed in another >> patch under review at the moment so might be gone before you push. >> >> -Alan. > From erik.joelsson at oracle.com Mon May 25 08:38:28 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 May 2015 10:38:28 +0200 Subject: Status of ccache In-Reply-To: References: Message-ID: <5562DF84.1010309@oracle.com> On 2015-05-22 17:47, Dan Smith wrote: > JDK-8027584 disabled ccache by default, I gather because it doesn't work in Cygwin, and secondarily because of vague general problems with it. > > The documentation (README-builds.html) still unambiguously endorses it, although doesn't say anything about how to turn it on (configure with --enable-ccache). > > I'm curious about the current state of affairs, and suggest updating the documentation to reflect the answer. > > ?Dan From README-builds.html in jdk9:

Building with ccache

The OpenJDK build supports building with ccache when using gcc or clang. Using ccache can radically speed up compilation of native code if you often rebuild the same sources. Your milage may vary however so we recommend evaluating it for yourself. To enable it, make sure it's on the path and configure with --enable-ccache.

I wouldn't say that's endorsing ccache, but rather reflects the current state of things. It can be a great speed improvement, but it certainly varies. Especially in hotspot, if you touch a header file, you invalidate most of the cache, so it won't help the development usecase much. It doesn't play very well with precompiled headers as Magnus says, but I did fix the worst of that a while back so it's far from as bad as it used to be. I would not discourage trying them both together at this point. In JDK 8, the documentation and defaults are probably still bad. On a related note, a while back I experimented with modifications to ccache to make it work with Solaris Studio. I believe I got it to work, but it would certainly need more testing before we could trust it. /Erik From erik.joelsson at oracle.com Mon May 25 08:42:20 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 May 2015 10:42:20 +0200 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <555F5F05.503@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> <555F273E.9010203@oracle.com> <555F46A4.8040704@oracle.com> <555F5F05.503@oracle.com> Message-ID: <5562E06C.105@oracle.com> On 2015-05-22 18:53, Mandy Chung wrote: > > > On 05/22/2015 08:09 AM, Alan Bateman wrote: >> >> On 22/05/2015 13:55, Chris Hegarty wrote: >>> : >>> I think it could be done either way. >> >> Valerie - have you considered not pushing the services configuration >> files with this change? With the change then the java.security >> configuration is still class names, not provider names, so the >> fallback should just work. This is what we've done in a few other >> areas (like JNDI for example). > > I wasn't aware of the other areas that move to service provider but > remain being loaded with the fallback Class.forName. > > I would prefer java.security should convert to use the provider names > as an example and also exercise the code path using service > providers. If this causes much work to workaround it temporarily, I > won't object the security providers are not truly service providers > (no META-INF/services and java.security lists class name instead) > > Another option to workaround this: > > we only need to merge the service config files for generating the > image. Can we have do the concatenation of > jdk/modules/*/META-INF/services file and output to > supports/image_gensrc before the images target and have the image > builder to exclude all jdk/modules/*/META-INF/services files and take > the supports/image_gensrc instead? > > This will remove the process-provider logic from Gensrc-*.gmk files. > Would this be a better alternative? > Maybe, I'm not sure. I still think solving this in java code in the ImageBuilder is the right thing to do. /Erik From chris.hegarty at oracle.com Mon May 25 08:42:58 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 25 May 2015 09:42:58 +0100 Subject: Status of ccache In-Reply-To: <5562DF84.1010309@oracle.com> References: <5562DF84.1010309@oracle.com> Message-ID: <5562E092.3070701@oracle.com> On 25/05/15 09:38, Erik Joelsson wrote: > > On 2015-05-22 17:47, Dan Smith wrote: >> JDK-8027584 disabled ccache by default, I gather because it doesn't >> work in Cygwin, and secondarily because of vague general problems with >> it. >> >> The documentation (README-builds.html) still unambiguously endorses >> it, although doesn't say anything about how to turn it on (configure >> with --enable-ccache). >> >> I'm curious about the current state of affairs, and suggest updating >> the documentation to reflect the answer. >> >> ?Dan > From README-builds.html in jdk9: > >

Building with ccache

> >

The OpenJDK build supports building with ccache > when using gcc or clang. Using ccache can > radically speed up compilation of native code if > you often rebuild the same sources. Your milage > may vary however so we recommend evaluating it for > yourself. To enable it, make sure it's on the path > and configure with --enable-ccache.

> > I wouldn't say that's endorsing ccache, but rather reflects the current > state of things. It can be a great speed improvement, but it certainly > varies. Right. For those of us that work in the libraries area, and only build hotspot because it is part of the product, and on Linux, ccache is invaluable. -Chris. > Especially in hotspot, if you touch a header file, you > invalidate most of the cache, so it won't help the development usecase > much. It doesn't play very well with precompiled headers as Magnus says, > but I did fix the worst of that a while back so it's far from as bad as > it used to be. I would not discourage trying them both together at this > point. > > In JDK 8, the documentation and defaults are probably still bad. > > On a related note, a while back I experimented with modifications to > ccache to make it work with Solaris Studio. I believe I got it to work, > but it would certainly need more testing before we could trust it. > > /Erik From chris.hegarty at oracle.com Mon May 25 08:53:07 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 25 May 2015 09:53:07 +0100 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <5562E06C.105@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> <555F273E.9010203@oracle.com> <555F46A4.8040704@oracle.com> <555F5F05.503@oracle.com> <5562E06C.105@oracle.com> Message-ID: <5562E2F3.1040307@oracle.com> On 25/05/15 09:42, Erik Joelsson wrote: > > On 2015-05-22 18:53, Mandy Chung wrote: >> >> >> On 05/22/2015 08:09 AM, Alan Bateman wrote: >>> >>> On 22/05/2015 13:55, Chris Hegarty wrote: >>>> : >>>> I think it could be done either way. >>> >>> Valerie - have you considered not pushing the services configuration >>> files with this change? With the change then the java.security >>> configuration is still class names, not provider names, so the >>> fallback should just work. This is what we've done in a few other >>> areas (like JNDI for example). >> >> I wasn't aware of the other areas that move to service provider but >> remain being loaded with the fallback Class.forName. URL protocol handlers, and JDNI initial context, fall back to Class.forName for built-in handlers/implementations, and do not expose the implementation as services. >> I would prefer java.security should convert to use the provider names >> as an example and also exercise the code path using service I think URL protocol handlers works well as an example too. It is a minimal new service type, easy to understand. You can write your own Foo handler in a few lines of code. >> providers. If this causes much work to workaround it temporarily, I >> won't object the security providers are not truly service providers >> (no META-INF/services and java.security lists class name instead) >> >> Another option to workaround this: >> >> we only need to merge the service config files for generating the >> image. Can we have do the concatenation of >> jdk/modules/*/META-INF/services file and output to >> supports/image_gensrc before the images target and have the image >> builder to exclude all jdk/modules/*/META-INF/services files and take >> the supports/image_gensrc instead? >> >> This will remove the process-provider logic from Gensrc-*.gmk files. >> Would this be a better alternative? >> > Maybe, I'm not sure. I still think solving this in java code in the > ImageBuilder is the right thing to do. If it is agreed that these files are needed, then I can look at expanding the ImageBuilder to do concatenate them. -Chris. > /Erik From Alan.Bateman at oracle.com Mon May 25 10:00:49 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 May 2015 11:00:49 +0100 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <5562E2F3.1040307@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> <555F273E.9010203@oracle.com> <555F46A4.8040704@oracle.com> <555F5F05.503@oracle.com> <5562E06C.105@oracle.com> <5562E2F3.1040307@oracle.com> Message-ID: <5562F2D1.5080103@oracle.com> On 25/05/2015 09:53, Chris Hegarty wrote: > > If it is agreed that these files are needed, then I can look at > expanding the ImageBuilder to do concatenate them. I agree with Mandy's point that java.security should be change to list the provider name rather than the class name. If that happens then it means that the service configuration files will be required. I don't have a strong view on whether the concatenation is done via make files or the image builder as it's all just temporary and will go away once resources are keyed by a module. One thing about rev'ing the image builder is that we should probably let the jimage refresh get into jdk9/dev first. I don't think we want to delay that due to merge conflicts. -Alan From erik.joelsson at oracle.com Mon May 25 10:17:31 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 May 2015 12:17:31 +0200 Subject: RFR: libdt_socket: Build failed with VS2013 SP4 Message-ID: <5562F6BB.3090105@oracle.com> Hello, In Visual Studio 2013 SP4, MS decided to deprecate gethostbyname in favor of getaddrinfo(). We now have two different libraries using this function. In JDK-8077422 I added a workaround for libhprof. Now we also have the problem in libdt_socket. This time I've opted to add the preprocessor macro to the general CFLAGS for all jdk libraries in configure. I will create a followup bug for fixing the usage of deprecated functions. Bug: https://bugs.openjdk.java.net/browse/JDK-8080983 Patch: diff -r 9d388c0d9872 common/autoconf/flags.m4 --- a/common/autoconf/flags.m4 +++ b/common/autoconf/flags.m4 @@ -559,6 +559,7 @@ -Zi -MD -Zc:wchar_t- -W3 -wd4800 \ -DWIN32_LEAN_AND_MEAN \ -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE \ + -D_WINSOCK_DEPRECATED_NO_WARNINGS \ -DWIN32 -DIAL" if test "x$OPENJDK_TARGET_CPU" = xx86_64; then COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK -D_AMD64_ -Damd64" diff -r 9d388c0d9872 common/autoconf/generated-configure.sh --- a/common/autoconf/generated-configure.sh +++ b/common/autoconf/generated-configure.sh @@ -4366,7 +4366,7 @@ #CUSTOM_AUTOCONF_INCLUDE # Do not change or remove the following line, it is needed for consistency checks: Also removing the old fix from JDK-8077422 as it is no longer needed: diff -r 8f8d35d97f82 make/lib/Lib-jdk.hprof.agent.gmk --- a/make/lib/Lib-jdk.hprof.agent.gmk +++ b/make/lib/Lib-jdk.hprof.agent.gmk @@ -49,7 +49,6 @@ CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \ $(BUILD_LIBHPROF_CFLAGS), \ CFLAGS_debug := -DHPROF_LOGGING, \ - CFLAGS_windows := -D_WINSOCK_DEPRECATED_NO_WARNINGS, \ MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \ LDFLAGS := $(LDFLAGS_JDKLIB) \ $(call SET_SHARED_LIBRARY_ORIGIN), \ /Erik From staffan.larsen at oracle.com Mon May 25 10:19:34 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 May 2015 12:19:34 +0200 Subject: RFR: libdt_socket: Build failed with VS2013 SP4 In-Reply-To: <5562F6BB.3090105@oracle.com> References: <5562F6BB.3090105@oracle.com> Message-ID: <75787D6C-EE22-47A7-8055-4A2961C8647E@oracle.com> Looks good! Thanks, /Staffan > On 25 maj 2015, at 12:17, Erik Joelsson wrote: > > Hello, > > In Visual Studio 2013 SP4, MS decided to deprecate gethostbyname in favor of getaddrinfo(). We now have two different libraries using this function. In JDK-8077422 I added a workaround for libhprof. Now we also have the problem in libdt_socket. This time I've opted to add the preprocessor macro to the general CFLAGS for all jdk libraries in configure. I will create a followup bug for fixing the usage of deprecated functions. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8080983 > > Patch: > diff -r 9d388c0d9872 common/autoconf/flags.m4 > --- a/common/autoconf/flags.m4 > +++ b/common/autoconf/flags.m4 > @@ -559,6 +559,7 @@ > -Zi -MD -Zc:wchar_t- -W3 -wd4800 \ > -DWIN32_LEAN_AND_MEAN \ > -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE \ > + -D_WINSOCK_DEPRECATED_NO_WARNINGS \ > -DWIN32 -DIAL" > if test "x$OPENJDK_TARGET_CPU" = xx86_64; then > COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK -D_AMD64_ -Damd64" > diff -r 9d388c0d9872 common/autoconf/generated-configure.sh > --- a/common/autoconf/generated-configure.sh > +++ b/common/autoconf/generated-configure.sh > @@ -4366,7 +4366,7 @@ > #CUSTOM_AUTOCONF_INCLUDE > > # Do not change or remove the following line, it is needed for consistency checks: > > > Also removing the old fix from JDK-8077422 as it is no longer needed: > diff -r 8f8d35d97f82 make/lib/Lib-jdk.hprof.agent.gmk > --- a/make/lib/Lib-jdk.hprof.agent.gmk > +++ b/make/lib/Lib-jdk.hprof.agent.gmk > @@ -49,7 +49,6 @@ > CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \ > $(BUILD_LIBHPROF_CFLAGS), \ > CFLAGS_debug := -DHPROF_LOGGING, \ > - CFLAGS_windows := -D_WINSOCK_DEPRECATED_NO_WARNINGS, \ > MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \ > LDFLAGS := $(LDFLAGS_JDKLIB) \ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > /Erik From magnus.ihse.bursie at oracle.com Mon May 25 12:11:54 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 25 May 2015 14:11:54 +0200 Subject: RFR: libdt_socket: Build failed with VS2013 SP4 In-Reply-To: <5562F6BB.3090105@oracle.com> References: <5562F6BB.3090105@oracle.com> Message-ID: <5563118A.1000804@oracle.com> On 2015-05-25 12:17, Erik Joelsson wrote: > Hello, > > In Visual Studio 2013 SP4, MS decided to deprecate gethostbyname in > favor of getaddrinfo(). We now have two different libraries using this > function. In JDK-8077422 I added a workaround for libhprof. Now we > also have the problem in libdt_socket. This time I've opted to add the > preprocessor macro to the general CFLAGS for all jdk libraries in > configure. I will create a followup bug for fixing the usage of > deprecated functions. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8080983 Looks good to me. /Magnus > > Patch: > diff -r 9d388c0d9872 common/autoconf/flags.m4 > --- a/common/autoconf/flags.m4 > +++ b/common/autoconf/flags.m4 > @@ -559,6 +559,7 @@ > -Zi -MD -Zc:wchar_t- -W3 -wd4800 \ > -DWIN32_LEAN_AND_MEAN \ > -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE \ > + -D_WINSOCK_DEPRECATED_NO_WARNINGS \ > -DWIN32 -DIAL" > if test "x$OPENJDK_TARGET_CPU" = xx86_64; then > COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK -D_AMD64_ -Damd64" > diff -r 9d388c0d9872 common/autoconf/generated-configure.sh > --- a/common/autoconf/generated-configure.sh > +++ b/common/autoconf/generated-configure.sh > @@ -4366,7 +4366,7 @@ > #CUSTOM_AUTOCONF_INCLUDE > > # Do not change or remove the following line, it is needed for > consistency checks: > > > Also removing the old fix from JDK-8077422 as it is no longer needed: > diff -r 8f8d35d97f82 make/lib/Lib-jdk.hprof.agent.gmk > --- a/make/lib/Lib-jdk.hprof.agent.gmk > +++ b/make/lib/Lib-jdk.hprof.agent.gmk > @@ -49,7 +49,6 @@ > CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \ > $(BUILD_LIBHPROF_CFLAGS), \ > CFLAGS_debug := -DHPROF_LOGGING, \ > - CFLAGS_windows := -D_WINSOCK_DEPRECATED_NO_WARNINGS, \ > MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \ > LDFLAGS := $(LDFLAGS_JDKLIB) \ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > /Erik From tim.bell at oracle.com Mon May 25 13:41:56 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 25 May 2015 06:41:56 -0700 Subject: RFR: libdt_socket: Build failed with VS2013 SP4 In-Reply-To: <5563118A.1000804@oracle.com> References: <5562F6BB.3090105@oracle.com> <5563118A.1000804@oracle.com> Message-ID: <556326A4.4090608@oracle.com> Erik: On 05/25/15 05:11, Magnus Ihse Bursie wrote: > On 2015-05-25 12:17, Erik Joelsson wrote: >> Hello, >> >> In Visual Studio 2013 SP4, MS decided to deprecate gethostbyname in >> favor of getaddrinfo(). We now have two different libraries using >> this function. In JDK-8077422 I added a workaround for libhprof. Now >> we also have the problem in libdt_socket. This time I've opted to add >> the preprocessor macro to the general CFLAGS for all jdk libraries in >> configure. I will create a followup bug for fixing the usage of >> deprecated functions. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8080983 > > Looks good to me. > > /Magnus On 05/25/15 03:19, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan Looks good to me as well. /Tim > >> >> Patch: >> diff -r 9d388c0d9872 common/autoconf/flags.m4 >> --- a/common/autoconf/flags.m4 >> +++ b/common/autoconf/flags.m4 >> @@ -559,6 +559,7 @@ >> -Zi -MD -Zc:wchar_t- -W3 -wd4800 \ >> -DWIN32_LEAN_AND_MEAN \ >> -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE \ >> + -D_WINSOCK_DEPRECATED_NO_WARNINGS \ >> -DWIN32 -DIAL" >> if test "x$OPENJDK_TARGET_CPU" = xx86_64; then >> COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK -D_AMD64_ -Damd64" >> diff -r 9d388c0d9872 common/autoconf/generated-configure.sh >> --- a/common/autoconf/generated-configure.sh >> +++ b/common/autoconf/generated-configure.sh >> @@ -4366,7 +4366,7 @@ >> #CUSTOM_AUTOCONF_INCLUDE >> >> # Do not change or remove the following line, it is needed for >> consistency checks: >> >> >> Also removing the old fix from JDK-8077422 as it is no longer needed: >> diff -r 8f8d35d97f82 make/lib/Lib-jdk.hprof.agent.gmk >> --- a/make/lib/Lib-jdk.hprof.agent.gmk >> +++ b/make/lib/Lib-jdk.hprof.agent.gmk >> @@ -49,7 +49,6 @@ >> CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \ >> $(BUILD_LIBHPROF_CFLAGS), \ >> CFLAGS_debug := -DHPROF_LOGGING, \ >> - CFLAGS_windows := -D_WINSOCK_DEPRECATED_NO_WARNINGS, \ >> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \ >> LDFLAGS := $(LDFLAGS_JDKLIB) \ >> $(call SET_SHARED_LIBRARY_ORIGIN), \ >> >> /Erik > From mandy.chung at oracle.com Mon May 25 15:33:45 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 May 2015 08:33:45 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader, In-Reply-To: <5562F2D1.5080103@oracle.com> References: <555D5D32.9010908@oracle.com> <69BD6B3C-3C85-419F-A7F0-27D1DD9078C6@oracle.com> <555E5623.3020900@oracle.com> <555ED385.80508@oracle.com> <555F273E.9010203@oracle.com> <555F46A4.8040704@oracle.com> <555F5F05.503@oracle.com> <5562E06C.105@oracle.com> <5562E2F3.1040307@oracle.com> <5562F2D1.5080103@oracle.com> Message-ID: > On May 25, 2015, at 3:00 AM, Alan Bateman wrote: > > On 25/05/2015 09:53, Chris Hegarty wrote: >> >> If it is agreed that these files are needed, then I can look at expanding the ImageBuilder to do concatenate them. > I agree with Mandy's point that java.security should be change to list the provider name rather than the class name. If that happens then it means that the service configuration files will be required. > > I don't have a strong view on whether the concatenation is done via make files or the image builder as it's all just temporary and will go away once resources are keyed by a module. One thing about rev'ing the image builder is that we should probably let the jimage refresh get into jdk9/dev first. I don't think we want to delay that due to merge conflicts. Right this is all temporary. One benefit of having the concatenation done by image builder will get the makefile cleaned up and get ready for the resources keyed for a module as long as the work required is small. Good point about image refresh and any image builder change should come after jimage refresh to avoid causing any merge conflict. Depending on when the image refresh and this security provider change are ready to push to jdk9/dev, I can work with Valerie to determine whether to wait or phase it. thanks Mandy From erik.joelsson at oracle.com Tue May 26 10:24:41 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 May 2015 12:24:41 +0200 Subject: [8u60] Request for review and approval: JDK-8074523: Windows native binaries have inconsistent "Product version" In-Reply-To: <555C95A4.5010801@oracle.com> References: <555C7EF6.1010208@oracle.com> <555C82E1.6010606@oracle.com> <555C95A4.5010801@oracle.com> Message-ID: <556449E9.9040807@oracle.com> Any chance I could get a review on this? /Erik On 2015-05-20 16:09, Erik Joelsson wrote: > Thanks, changed to: Windows native binaries have inconsistent "Product > version" > > Changed the label. > > /Erik > > On 2015-05-20 14:49, Se?n Coffey wrote: >> It might be good to edit the bug synopsis before pushing the change. >> I don't think this issue is specific to java.net bundles. Might also >> be useful to use the noreg-sqe label rather than noreg-build given >> that SQE team do appear to have test code for this area. >> >> Approved pending code review. >> >> Regards, >> Sean. >> >> On 20/05/15 13:32, Erik Joelsson wrote: >>> Please review and approve this fix for 8u60. >>> >>> On windows, native libraries and executables have version numbers >>> embedded into them. These can be seen when right-clicking the binary >>> in explorer, on the Details tab, as "Product version". Currently in >>> 8 update releases, these versions strings are inconsistent. An example: >>> >>> in 8u45 b09 we have: >>> >>> bin\client\jvm.dll: 8.0.0.9 >>> bin\decora_sse.dll: 8.0.45.09 >>> bin\deploy.dll: 8.0.450.9 >>> bin\java.exe: 8.0.45.9 >>> >>> These differences fall into 4 different categories. >>> >>> 1. jvm.dll in hotspot is not picking up the update version at all. >>> This is due to a bug in the build-infra makefile rewrite that wasn't >>> discovered in JDK 8 because it didn't have an update version. >>> >>> 2. decora_sse.dll is part of javafx. Fixing their version scheme is >>> out of scope of this fix. A separate bug for javafx would be needed. >>> >>> 3. deploy.dll is actually the correct one. Historically we have >>> encoded the update version with an extra digit for a potential >>> letter at the end of the string. >>> >>> 4. java.exe, and the rest of the binaries from the jdk repository >>> lost their extra 0 in the build-infra makefile rewrite and it wasn't >>> discovered in JDK 8. >>> >>> Since we no longer use letters in update version strings, we could >>> fix this by removing the extra 0. However, we have already released >>> 8 updates where some binaries have the extra 0. Removing it would >>> mean releasing 8u60 with binaries having version numbers lower than >>> previous updates. For this reason I propose fixing this by adding >>> the 0 for JDK and Hotspot binaries again, and of course by supplying >>> the correct variable to the hotspot makefiles so that it even gets >>> the update version in there. For clarity, with this patch, the above >>> will log like this: >>> >>> bin\client\jvm.dll: 8.0.450.9 >>> bin\decora_sse.dll: 8.0.45.09 >>> bin\deploy.dll: 8.0.450.9 >>> bin\java.exe: 8.0.450.9 >>> >>> Note that in JDK 9, the version number scheme is being completely >>> reworked so this will not be an issue. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074523 >>> Webrev: http://cr.openjdk.java.net/~erikj/8074523/webrev.01/index.html >>> >>> /Erik >> > From philip.race at oracle.com Tue May 26 19:21:53 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 26 May 2015 12:21:53 -0700 Subject: RfR JDK-8077296 RE build fails on non-Win builds when attempting to build Win only javadoc In-Reply-To: <555D8504.2030800@oracle.com> References: <555D6E3E.5030806@oracle.com> <555D8504.2030800@oracle.com> Message-ID: <5564C7D1.7080705@oracle.com> +1 -phil. On 05/21/2015 12:11 AM, Erik Joelsson wrote: > Hello Pete, > > This looks good to me. > > /Erik > > On 2015-05-21 07:33, Pete Brunet wrote: >> Please review the following change for 8u: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/ >> >> Background: >> >> - As part of the open sourcing of the JAB and Java Accessibility >> Utilities (JAU) the JAU Javadoc was setup to be added to the build. >> - Due to a 8u build issue (it uses source bundles) the Javadoc had to be >> temporarily disabled: JDK-8076552 >> - The issue was caused by JAU code being in windows instead of share. >> - For 9 the JAU code is in >> jdk.accessibility/share/classes/com/sun/java/accessibility/util (and the >> JAB code under jdk.accessibility/windows). >> - For 8u both the JAU and JAB code is in jdk/src/windows. >> - The problem on 8u is with non-windows builds; the 8 Javadoc build >> process doesn't find the JAU files because they are in a windows >> directory. >> - The fix is to refactor so 8u is like 9 with the JAU files in share; >> then the javadoc build process will find the source for all build >> platforms. >> - Make has been changed so jaccess.jar is built for all platforms >> - Some obsolete files have been removed as they were causing build >> problems. They were removed from 9 earlier but not from 8u. These are >> com/sun/java/accessibility/util/java/awt/ChoiceTranslator.java and all >> the files in com/sun/java/accessibility/extensions. >> >> Thanks, Pete > From Roger.Riggs at Oracle.com Wed May 27 02:52:07 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 26 May 2015 22:52:07 -0400 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava In-Reply-To: References: <555E499C.6020300@Oracle.com> Message-ID: <55653157.1040202@Oracle.com> Hi, Sadly, but not entirely unexpectedly there is an anomaly in the include files: It seems that Windows does not define O_SYNC and O_DSYNC. To make up for the absence jdk/src/java.base/share/native/libjava/io_util.h conditionally defines them. There is no problem if the system include files appear first, but in the other order, fcntl.h tries to re-define it. In the recommended order, there is no issue. Roger On 5/22/15 1:47 PM, Martin Buchholz wrote: > It's a good idea to order include statements by system dependencies, > jdk dependencies, implementation helpers, BUT order of include > statements should never ever matter. If it does, then we have a bug > that should be fixed. Every header file should be independently > includable, and C files should only Include What They Use. It would > be good for us to test some of that, e.g. can you compile each .h file > as its own translation unit? > > +#include > +#include > + > #include "jni.h" > #include "jni_util.h" > #include "jlong.h" > @@ -32,9 +35,6 @@ > #include "java_io_FileInputStream.h" > -#include > -#include > - > From martinrb at google.com Wed May 27 06:59:29 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 26 May 2015 23:59:29 -0700 Subject: RFR 9: 8074818: Resolve disabled warnings for libjava In-Reply-To: <55653157.1040202@Oracle.com> References: <555E499C.6020300@Oracle.com> <55653157.1040202@Oracle.com> Message-ID: On Tue, May 26, 2015 at 7:52 PM, Roger Riggs wrote: > Hi, > > Sadly, but not entirely unexpectedly there is an anomaly in the include > files: > It seems that Windows does not define O_SYNC and O_DSYNC. > To make up for the absence > jdk/src/java.base/share/native/libjava/io_util.h > conditionally defines them. There is no problem if the system include > files appear > first, but in the other order, fcntl.h tries to re-define it. > In the recommended order, there is no issue. > We should work hard to remove order dependencies in include files. I see that io_util.h includes , but only on BSD. Why not include it wherever it is available, (which may be all supported platforms!) before trying to define O_SYNC and D_SYNC? From jan.lahoda at oracle.com Wed May 27 09:37:49 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 27 May 2015 11:37:49 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <555F2D9F.2090505@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> Message-ID: <5565906D.1050400@oracle.com> Hi, I've uploaded another iteration, with these changes: -the "symbols" file is now generated automatically (for the typical OpenJDK case). -fixed a minor issue in CreateSymbols that could cause putting class description into wrong a file (the "break" -> "break OUTER;" change). -jdk.management module has been split out from java.management recently, so splitting the corresponding .sym.txt files into java.management and jdk.management as well. -updating the copyright year in CreateSymbols, as noted by Magnus. Webrevs: -top-level: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ -langtools (no changes against the last webrev): http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ Delta webrevs against the previous iteration are included under "Author comments". Thanks for the comments so far! Jan On 22.5.2015 15:22, Jan Lahoda wrote: > On 22.5.2015 14:52, Maurizio Cimadamore wrote: >> Excellent work. >> >> I think the comment in CreateSymbols could be made clearer w.r.t. Probe >> - i.e. that Probe should be ran on top of the JDK N - i.e. >> >> /bin/java Probe --> classes-8 >> /bin/java Probe --> classes-7 >> /bin/java Probe --> classes-7 >> >> etc. > > Sure, will do. > > I'll also look at generating the make/data/symbols/symbols descriptions > automatically, per our offline discussion. > > Thanks! > > Jan > >> >> Maurizio >> >> On 22/05/15 13:38, Jan Lahoda wrote: >>> Hi, >>> >>> I've uploaded a new iteration of the patch(es): >>> top-level repository: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>> langtools: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>> >>> (besides full webrevs, there are also webrevs showing the differences >>> between .00 and .01 available - see the "Delta webrev" link under >>> "Author's comments") >>> >>> Summary of changes: >>> -applied Eric's build changes >>> -moved CreateSymbols into make/src/classes/build/tools/symbolgenerator >>> -tried to improve the specification of base platforms in >>> CreateSymbols, per Maurizio's comment >>> -other cleanup in langtools per Maurizio's comments. >>> >>> Thanks, >>> Jan >>> >>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>> Hi Jan, >>>> great work - couple of comments below: >>>> >>>> * it seems like some of the routines in Arguments can be simplified >>>> using lambdas - especially lookupPlatformProvider and >>>> checkOptionAllowed >>>> * Why JDKPlatformProvider is not called JDKPlatformProvider*Factory* ? >>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>> commonalities >>>> with CompoundScopeIterator - any chance that we might refactor this a >>>> bit? >>>> * What's the rationale for giving an error if -platform is specified >>>> and >>>> a non-StandardFileManager is provided? Can't we simply swallow that, >>>> ignore the platform settings and issue a Lint 'options' warning? >>>> * Would it make sense for some of the classfile generation logic in >>>> CreateSymbols to be moved under the classfile API ? >>>> * I had hard time reconciling some of the comments in CreateSymbols >>>> with >>>> how the files were laid out. I think in the end, what you mean is that >>>> if you have platforms 7, 8, 9 - you should pick one baseline (i.e. 8) >>>> and then generate diffs for 9 and 7 against the 8 one. If that's the >>>> use >>>> case, I think the command line can be simplified a bit in order to >>>> explicitly state which of the platform is the baseline one, and the >>>> remaining parameters can be inferred from the tool (as the >>>> seem to be typically all >>>> identical >>>> but one which is set to - the one for the baseline). Maybe the >>>> inference logic should be different (i.e. use 8 as a baseline for 7 and >>>> 7 as a baseline for 6) - but - whatever the logic, I think it should be >>>> chosen once and for all, and live implicitly in the tool? Or are there >>>> reasons as to why it might be handy to customize the baselines? >>>> >>>> Maurizio >>>> >>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> This is a patch adding a new option, -platform, to javac. >>>>> >>>>> Patch for the top-level repository is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>> >>>>> Patch for the langtools repository is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>> >>>>> These changes also require additional langtools changes as their >>>>> prerequisite: >>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>> >>>>> Overall, one can imagine '-platform N' to have the same effect as >>>>> '-source N -target N -bootclasspath '. The possible values >>>>> for 'N' are pluggable in a limited way, though (see >>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>> >>>>> >>>>> Note that this patch only introduces N=7 and N=8, which correspond to >>>>> Open JDK 7 and 8 GA. >>>>> >>>>> A tricky problem to solve is where to get the APIs for platform N. The >>>>> proposal is to include history data in the textual format inside the >>>>> OpenJDK repositories (the input data), process them at build time and >>>>> create a lib/ct.sym file holding the data in the JDK image. javac >>>>> running with the -platform option then compiles against the lib/ct.sym >>>>> file. The input history data are placed >>>>> /make/data/symbols (the sym.txt files). This >>>>> patches only includes data for OpenJDK 7 and 8, and only for public >>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>> >>>>> The size of the history data is currently ~6MB in the JDK checkout and >>>>> ~650kB inside the .hg directory (the size could change significantly >>>>> if additional classes/elements, like non-public API classes, would >>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>> >>>>> The ct.sym file is a zip file containing signature files. The >>>>> signature files are similar to classfiles (so javac can read them as >>>>> classfiles), but are missing some attributes, most notably the Code >>>>> attribute. On the top-level, the ct.sym contains directories named >>>>> "7", "78" and "8". When compiling for version 'N', the bootclasspath >>>>> for that version is obtained by using directories which have 'N' in >>>>> their name. >>>>> >>>>> The sigfiles for ct.sym are created by >>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>> The same file can also be used to construct the sym.txt files. Concise >>>>> instructions are part of the CreateSymbols.java. >>>>> >>>>> I am sending this as one review, as the changes together make one >>>>> feature, but the langtools and top-level changes are independent to a >>>>> great degree: the langtools changes add the "-platform" javac; and the >>>>> top-level changes add the history data and ability to build the ct.sym >>>>> file. If desired, these could be pushed and/or reviewed independently. >>>>> >>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >>>>> Bateman and others who have provided advices and help on the matter >>>>> before. >>>>> >>>>> Any insights/comments are wholeheartedly welcome. >>>>> >>>>> Thanks, >>>>> Jan >>>> >> From maurizio.cimadamore at oracle.com Wed May 27 09:59:38 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 May 2015 10:59:38 +0100 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <5565906D.1050400@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> Message-ID: <5565958A.1040807@oracle.com> Looks great. The only nitpick is that the comments in CreateSymbols don't mention the fact that a side effect of the sym.txt generation is the mentioned earlier in the same comments (so one might wonder where does that come from). Maurizio On 27/05/15 10:37, Jan Lahoda wrote: > Hi, > > I've uploaded another iteration, with these changes: > -the "symbols" file is now generated automatically (for the typical > OpenJDK case). > -fixed a minor issue in CreateSymbols that could cause putting class > description into wrong a file (the "break" -> "break OUTER;" change). > -jdk.management module has been split out from java.management > recently, so splitting the corresponding .sym.txt files into > java.management and jdk.management as well. > -updating the copyright year in CreateSymbols, as noted by Magnus. > > Webrevs: > -top-level: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ > -langtools (no changes against the last webrev): > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ > > Delta webrevs against the previous iteration are included under > "Author comments". > > Thanks for the comments so far! > > Jan > > On 22.5.2015 15:22, Jan Lahoda wrote: >> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>> Excellent work. >>> >>> I think the comment in CreateSymbols could be made clearer w.r.t. Probe >>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>> >>> /bin/java Probe --> classes-8 >>> /bin/java Probe --> classes-7 >>> /bin/java Probe --> classes-7 >>> >>> etc. >> >> Sure, will do. >> >> I'll also look at generating the make/data/symbols/symbols descriptions >> automatically, per our offline discussion. >> >> Thanks! >> >> Jan >> >>> >>> Maurizio >>> >>> On 22/05/15 13:38, Jan Lahoda wrote: >>>> Hi, >>>> >>>> I've uploaded a new iteration of the patch(es): >>>> top-level repository: >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>> langtools: >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>> >>>> (besides full webrevs, there are also webrevs showing the differences >>>> between .00 and .01 available - see the "Delta webrev" link under >>>> "Author's comments") >>>> >>>> Summary of changes: >>>> -applied Eric's build changes >>>> -moved CreateSymbols into make/src/classes/build/tools/symbolgenerator >>>> -tried to improve the specification of base platforms in >>>> CreateSymbols, per Maurizio's comment >>>> -other cleanup in langtools per Maurizio's comments. >>>> >>>> Thanks, >>>> Jan >>>> >>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>> Hi Jan, >>>>> great work - couple of comments below: >>>>> >>>>> * it seems like some of the routines in Arguments can be simplified >>>>> using lambdas - especially lookupPlatformProvider and >>>>> checkOptionAllowed >>>>> * Why JDKPlatformProvider is not called >>>>> JDKPlatformProvider*Factory* ? >>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>> commonalities >>>>> with CompoundScopeIterator - any chance that we might refactor this a >>>>> bit? >>>>> * What's the rationale for giving an error if -platform is specified >>>>> and >>>>> a non-StandardFileManager is provided? Can't we simply swallow that, >>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>> * Would it make sense for some of the classfile generation logic in >>>>> CreateSymbols to be moved under the classfile API ? >>>>> * I had hard time reconciling some of the comments in CreateSymbols >>>>> with >>>>> how the files were laid out. I think in the end, what you mean is >>>>> that >>>>> if you have platforms 7, 8, 9 - you should pick one baseline (i.e. 8) >>>>> and then generate diffs for 9 and 7 against the 8 one. If that's the >>>>> use >>>>> case, I think the command line can be simplified a bit in order to >>>>> explicitly state which of the platform is the baseline one, and the >>>>> remaining parameters can be inferred from the tool (as the >>>>> seem to be typically all >>>>> identical >>>>> but one which is set to - the one for the baseline). Maybe the >>>>> inference logic should be different (i.e. use 8 as a baseline for >>>>> 7 and >>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>> should be >>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>> there >>>>> reasons as to why it might be handy to customize the baselines? >>>>> >>>>> Maurizio >>>>> >>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> This is a patch adding a new option, -platform, to javac. >>>>>> >>>>>> Patch for the top-level repository is here: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>> >>>>>> Patch for the langtools repository is here: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>> >>>>>> These changes also require additional langtools changes as their >>>>>> prerequisite: >>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>> >>>>>> Overall, one can imagine '-platform N' to have the same effect as >>>>>> '-source N -target N -bootclasspath '. The possible >>>>>> values >>>>>> for 'N' are pluggable in a limited way, though (see >>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>> >>>>>> >>>>>> >>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>> correspond to >>>>>> Open JDK 7 and 8 GA. >>>>>> >>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>> N. The >>>>>> proposal is to include history data in the textual format inside the >>>>>> OpenJDK repositories (the input data), process them at build time >>>>>> and >>>>>> create a lib/ct.sym file holding the data in the JDK image. javac >>>>>> running with the -platform option then compiles against the >>>>>> lib/ct.sym >>>>>> file. The input history data are placed >>>>>> /make/data/symbols (the sym.txt files). This >>>>>> patches only includes data for OpenJDK 7 and 8, and only for public >>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>> >>>>>> The size of the history data is currently ~6MB in the JDK >>>>>> checkout and >>>>>> ~650kB inside the .hg directory (the size could change significantly >>>>>> if additional classes/elements, like non-public API classes, would >>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>> >>>>>> The ct.sym file is a zip file containing signature files. The >>>>>> signature files are similar to classfiles (so javac can read them as >>>>>> classfiles), but are missing some attributes, most notably the Code >>>>>> attribute. On the top-level, the ct.sym contains directories named >>>>>> "7", "78" and "8". When compiling for version 'N', the bootclasspath >>>>>> for that version is obtained by using directories which have 'N' in >>>>>> their name. >>>>>> >>>>>> The sigfiles for ct.sym are created by >>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>> >>>>>> The same file can also be used to construct the sym.txt files. >>>>>> Concise >>>>>> instructions are part of the CreateSymbols.java. >>>>>> >>>>>> I am sending this as one review, as the changes together make one >>>>>> feature, but the langtools and top-level changes are independent >>>>>> to a >>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>> and the >>>>>> top-level changes add the history data and ability to build the >>>>>> ct.sym >>>>>> file. If desired, these could be pushed and/or reviewed >>>>>> independently. >>>>>> >>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >>>>>> Bateman and others who have provided advices and help on the matter >>>>>> before. >>>>>> >>>>>> Any insights/comments are wholeheartedly welcome. >>>>>> >>>>>> Thanks, >>>>>> Jan >>>>> >>> From jan.lahoda at oracle.com Wed May 27 12:23:12 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 27 May 2015 14:23:12 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <5565958A.1040807@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> Message-ID: <5565B730.5030602@oracle.com> Ah, yes, I did not realize that. Thanks, will fix. Thanks, Jan On 27.5.2015 11:59, Maurizio Cimadamore wrote: > Looks great. The only nitpick is that the comments in CreateSymbols > don't mention the fact that a side effect of the sym.txt generation is > the mentioned earlier in the same comments > (so one might wonder where does that come from). > > Maurizio > > On 27/05/15 10:37, Jan Lahoda wrote: >> Hi, >> >> I've uploaded another iteration, with these changes: >> -the "symbols" file is now generated automatically (for the typical >> OpenJDK case). >> -fixed a minor issue in CreateSymbols that could cause putting class >> description into wrong a file (the "break" -> "break OUTER;" change). >> -jdk.management module has been split out from java.management >> recently, so splitting the corresponding .sym.txt files into >> java.management and jdk.management as well. >> -updating the copyright year in CreateSymbols, as noted by Magnus. >> >> Webrevs: >> -top-level: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >> -langtools (no changes against the last webrev): >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >> >> Delta webrevs against the previous iteration are included under >> "Author comments". >> >> Thanks for the comments so far! >> >> Jan >> >> On 22.5.2015 15:22, Jan Lahoda wrote: >>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>> Excellent work. >>>> >>>> I think the comment in CreateSymbols could be made clearer w.r.t. Probe >>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>> >>>> /bin/java Probe --> classes-8 >>>> /bin/java Probe --> classes-7 >>>> /bin/java Probe --> classes-7 >>>> >>>> etc. >>> >>> Sure, will do. >>> >>> I'll also look at generating the make/data/symbols/symbols descriptions >>> automatically, per our offline discussion. >>> >>> Thanks! >>> >>> Jan >>> >>>> >>>> Maurizio >>>> >>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> I've uploaded a new iteration of the patch(es): >>>>> top-level repository: >>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>> langtools: >>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>> >>>>> (besides full webrevs, there are also webrevs showing the differences >>>>> between .00 and .01 available - see the "Delta webrev" link under >>>>> "Author's comments") >>>>> >>>>> Summary of changes: >>>>> -applied Eric's build changes >>>>> -moved CreateSymbols into make/src/classes/build/tools/symbolgenerator >>>>> -tried to improve the specification of base platforms in >>>>> CreateSymbols, per Maurizio's comment >>>>> -other cleanup in langtools per Maurizio's comments. >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>> Hi Jan, >>>>>> great work - couple of comments below: >>>>>> >>>>>> * it seems like some of the routines in Arguments can be simplified >>>>>> using lambdas - especially lookupPlatformProvider and >>>>>> checkOptionAllowed >>>>>> * Why JDKPlatformProvider is not called >>>>>> JDKPlatformProvider*Factory* ? >>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>> commonalities >>>>>> with CompoundScopeIterator - any chance that we might refactor this a >>>>>> bit? >>>>>> * What's the rationale for giving an error if -platform is specified >>>>>> and >>>>>> a non-StandardFileManager is provided? Can't we simply swallow that, >>>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>>> * Would it make sense for some of the classfile generation logic in >>>>>> CreateSymbols to be moved under the classfile API ? >>>>>> * I had hard time reconciling some of the comments in CreateSymbols >>>>>> with >>>>>> how the files were laid out. I think in the end, what you mean is >>>>>> that >>>>>> if you have platforms 7, 8, 9 - you should pick one baseline (i.e. 8) >>>>>> and then generate diffs for 9 and 7 against the 8 one. If that's the >>>>>> use >>>>>> case, I think the command line can be simplified a bit in order to >>>>>> explicitly state which of the platform is the baseline one, and the >>>>>> remaining parameters can be inferred from the tool (as the >>>>>> seem to be typically all >>>>>> identical >>>>>> but one which is set to - the one for the baseline). Maybe the >>>>>> inference logic should be different (i.e. use 8 as a baseline for >>>>>> 7 and >>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>> should be >>>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>>> there >>>>>> reasons as to why it might be handy to customize the baselines? >>>>>> >>>>>> Maurizio >>>>>> >>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>> >>>>>>> Patch for the top-level repository is here: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>> >>>>>>> Patch for the langtools repository is here: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>> >>>>>>> These changes also require additional langtools changes as their >>>>>>> prerequisite: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>> >>>>>>> Overall, one can imagine '-platform N' to have the same effect as >>>>>>> '-source N -target N -bootclasspath '. The possible >>>>>>> values >>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>> >>>>>>> >>>>>>> >>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>> correspond to >>>>>>> Open JDK 7 and 8 GA. >>>>>>> >>>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>>> N. The >>>>>>> proposal is to include history data in the textual format inside the >>>>>>> OpenJDK repositories (the input data), process them at build time >>>>>>> and >>>>>>> create a lib/ct.sym file holding the data in the JDK image. javac >>>>>>> running with the -platform option then compiles against the >>>>>>> lib/ct.sym >>>>>>> file. The input history data are placed >>>>>>> /make/data/symbols (the sym.txt files). This >>>>>>> patches only includes data for OpenJDK 7 and 8, and only for public >>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>> >>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>> checkout and >>>>>>> ~650kB inside the .hg directory (the size could change significantly >>>>>>> if additional classes/elements, like non-public API classes, would >>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>> >>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>> signature files are similar to classfiles (so javac can read them as >>>>>>> classfiles), but are missing some attributes, most notably the Code >>>>>>> attribute. On the top-level, the ct.sym contains directories named >>>>>>> "7", "78" and "8". When compiling for version 'N', the bootclasspath >>>>>>> for that version is obtained by using directories which have 'N' in >>>>>>> their name. >>>>>>> >>>>>>> The sigfiles for ct.sym are created by >>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>> >>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>> Concise >>>>>>> instructions are part of the CreateSymbols.java. >>>>>>> >>>>>>> I am sending this as one review, as the changes together make one >>>>>>> feature, but the langtools and top-level changes are independent >>>>>>> to a >>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>> and the >>>>>>> top-level changes add the history data and ability to build the >>>>>>> ct.sym >>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>> independently. >>>>>>> >>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >>>>>>> Bateman and others who have provided advices and help on the matter >>>>>>> before. >>>>>>> >>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>> >>>>>>> Thanks, >>>>>>> Jan >>>>>> >>>> > From magnus.ihse.bursie at oracle.com Wed May 27 14:05:15 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 May 2015 16:05:15 +0200 Subject: [8u60] Request for review and approval: JDK-8074523: Windows native binaries have inconsistent "Product version" In-Reply-To: <556449E9.9040807@oracle.com> References: <555C7EF6.1010208@oracle.com> <555C82E1.6010606@oracle.com> <555C95A4.5010801@oracle.com> <556449E9.9040807@oracle.com> Message-ID: <5565CF1B.1030407@oracle.com> On 2015-05-26 12:24, Erik Joelsson wrote: > Any chance I could get a review on this? Yeah, if you ask nicely, with sugar on top. ;-) Fix looks good to me. Thanks for taking care of this. /Magnus > > /Erik > > On 2015-05-20 16:09, Erik Joelsson wrote: >> Thanks, changed to: Windows native binaries have inconsistent >> "Product version" >> >> Changed the label. >> >> /Erik >> >> On 2015-05-20 14:49, Se?n Coffey wrote: >>> It might be good to edit the bug synopsis before pushing the change. >>> I don't think this issue is specific to java.net bundles. Might also >>> be useful to use the noreg-sqe label rather than noreg-build given >>> that SQE team do appear to have test code for this area. >>> >>> Approved pending code review. >>> >>> Regards, >>> Sean. >>> >>> On 20/05/15 13:32, Erik Joelsson wrote: >>>> Please review and approve this fix for 8u60. >>>> >>>> On windows, native libraries and executables have version numbers >>>> embedded into them. These can be seen when right-clicking the >>>> binary in explorer, on the Details tab, as "Product version". >>>> Currently in 8 update releases, these versions strings are >>>> inconsistent. An example: >>>> >>>> in 8u45 b09 we have: >>>> >>>> bin\client\jvm.dll: 8.0.0.9 >>>> bin\decora_sse.dll: 8.0.45.09 >>>> bin\deploy.dll: 8.0.450.9 >>>> bin\java.exe: 8.0.45.9 >>>> >>>> These differences fall into 4 different categories. >>>> >>>> 1. jvm.dll in hotspot is not picking up the update version at all. >>>> This is due to a bug in the build-infra makefile rewrite that >>>> wasn't discovered in JDK 8 because it didn't have an update version. >>>> >>>> 2. decora_sse.dll is part of javafx. Fixing their version scheme is >>>> out of scope of this fix. A separate bug for javafx would be needed. >>>> >>>> 3. deploy.dll is actually the correct one. Historically we have >>>> encoded the update version with an extra digit for a potential >>>> letter at the end of the string. >>>> >>>> 4. java.exe, and the rest of the binaries from the jdk repository >>>> lost their extra 0 in the build-infra makefile rewrite and it >>>> wasn't discovered in JDK 8. >>>> >>>> Since we no longer use letters in update version strings, we could >>>> fix this by removing the extra 0. However, we have already released >>>> 8 updates where some binaries have the extra 0. Removing it would >>>> mean releasing 8u60 with binaries having version numbers lower than >>>> previous updates. For this reason I propose fixing this by adding >>>> the 0 for JDK and Hotspot binaries again, and of course by >>>> supplying the correct variable to the hotspot makefiles so that it >>>> even gets the update version in there. For clarity, with this >>>> patch, the above will log like this: >>>> >>>> bin\client\jvm.dll: 8.0.450.9 >>>> bin\decora_sse.dll: 8.0.45.09 >>>> bin\deploy.dll: 8.0.450.9 >>>> bin\java.exe: 8.0.450.9 >>>> >>>> Note that in JDK 9, the version number scheme is being completely >>>> reworked so this will not be an issue. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074523 >>>> Webrev: http://cr.openjdk.java.net/~erikj/8074523/webrev.01/index.html >>>> >>>> /Erik >>> >> > From voron.alexander at gmail.com Wed May 27 19:14:18 2015 From: voron.alexander at gmail.com (Alexander Voron) Date: Wed, 27 May 2015 22:14:18 +0300 Subject: Why isn't 8u45 release listed on OpenJDK site? Message-ID: I'm going to update OpenJRE to the version which contains Oracle April CPU fixes. According to the repo tags, I suppose, I should use jdk8u45-b14 I have 2 questions: 1. Is jdk8u45-b14 an official release branch for OpenJDK? 2. If it so - why wasn't 8u45 listed on OpenJDK 8 update releases page? http://openjdk.java.net/projects/jdk8u/ From valerie.peng at oracle.com Wed May 27 22:29:27 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 27 May 2015 15:29:27 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader Message-ID: <55664547.7050002@oracle.com> Hi, build experts, Can you please review the make file related change, i.e. the new file || *make/gensrc/Gensrc-java.naming.gmk*, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. The rest of source code changes are reviewed by my team already. Thanks, Valerie (Java Security Team) From mandy.chung at oracle.com Wed May 27 22:42:27 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 May 2015 15:42:27 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <55664547.7050002@oracle.com> References: <55664547.7050002@oracle.com> Message-ID: Valerie, Did you see my comment yesterday? http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let?s remove the META-INF files in the first push and the build change. The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. I?ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev. Mandy > On May 27, 2015, at 3:29 PM, Valerie Peng wrote: > > Hi, build experts, > > Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: > http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ > > This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. > > The rest of source code changes are reviewed by my team already. > Thanks, > Valerie > (Java Security Team) From mandy.chung at oracle.com Thu May 28 00:07:41 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 May 2015 17:07:41 -0700 Subject: RfR JDK-8077296 RE build fails on non-Win builds when attempting to build Win only javadoc In-Reply-To: <5564C7D1.7080705@oracle.com> References: <555D6E3E.5030806@oracle.com> <555D8504.2030800@oracle.com> <5564C7D1.7080705@oracle.com> Message-ID: <94D45306-CA55-49F0-A579-2B2D06BC828D@oracle.com> >> >> On 2015-05-21 07:33, Pete Brunet wrote: >>> Please review the following change for 8u: >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/ I only skimmed through the change. package-info.java should have @jdk.Exported. Mandy >>> >>> Background: >>> >>> - As part of the open sourcing of the JAB and Java Accessibility >>> Utilities (JAU) the JAU Javadoc was setup to be added to the build. >>> - Due to a 8u build issue (it uses source bundles) the Javadoc had to be >>> temporarily disabled: JDK-8076552 >>> - The issue was caused by JAU code being in windows instead of share. >>> - For 9 the JAU code is in >>> jdk.accessibility/share/classes/com/sun/java/accessibility/util (and the >>> JAB code under jdk.accessibility/windows). >>> - For 8u both the JAU and JAB code is in jdk/src/windows. >>> - The problem on 8u is with non-windows builds; the 8 Javadoc build >>> process doesn't find the JAU files because they are in a windows directory. >>> - The fix is to refactor so 8u is like 9 with the JAU files in share; >>> then the javadoc build process will find the source for all build platforms. >>> - Make has been changed so jaccess.jar is built for all platforms >>> - Some obsolete files have been removed as they were causing build >>> problems. They were removed from 9 earlier but not from 8u. These are >>> com/sun/java/accessibility/util/java/awt/ChoiceTranslator.java and all >>> the files in com/sun/java/accessibility/extensions. >>> >>> Thanks, Pete >> > From Alan.Bateman at oracle.com Thu May 28 11:35:06 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 May 2015 12:35:06 +0100 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: References: <55664547.7050002@oracle.com> Message-ID: <5566FD6A.5040201@oracle.com> On 27/05/2015 23:42, Mandy Chung wrote: > Valerie, > > Did you see my comment yesterday? > http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html > > Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let?s remove the META-INF files in the first push and the build change. > > The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. > > I?ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev. > I think that's the best approach and this will also allow the temporary image build tool to be updated to merge the configuration files. -Alan From yekaterina.kantserova at oracle.com Thu May 28 14:45:04 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 28 May 2015 16:45:04 +0200 Subject: RFR(S): 8081037: serviceability/sa/ tests time out on Windows In-Reply-To: <5565C048.4050801@oracle.com> References: <5565C048.4050801@oracle.com> Message-ID: <556729F0.70703@oracle.com> Hi, due to https://bugs.openjdk.java.net/browse/JDK-8081381 I wasn't able to push this fix. The problem is LingeredApp.java contains JDK 9 feature java.lang.Process.getPid() but the test library is compiled with JDK 8 today. This issue is not trivial to solve so I suggest a temporary fix to test/lib/Makefile. webrev root: http://cr.openjdk.java.net/~ykantser/8081037/webrev.01 Thanks, Katja On 05/27/2015 03:02 PM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8081037 > webrev root: http://cr.openjdk.java.net/~ykantser/8081037/webrev.00 > webrev jdk: http://cr.openjdk.java.net/~ykantser/8081037.jdk/webrev.00 > webrev hotspot: > http://cr.openjdk.java.net/~ykantser/8081037.hotspot/webrev.00 > > From the bug: > "The problem is most likely that SA will pause the target process > while it is running. In this case, the target process is the same as > the process that launched SA. That process is also handling the output > from SA over a pipe, but when that pipe fills up the process cannot > empty it and the SA process is blocked because it cannot write any > more output. Deadlock." > > The solutions is to start a separate target process. Dmitry Samersoff > has already created a test application for such cases so I've decided > to move it on the top level library instead of duplicating it. The > test application will reside under > test/lib/share/classes/jdk/test/lib/apps and the test under > test/lib-test/jdk/test/lib/apps. > > Thanks, > Katja From valerie.peng at oracle.com Thu May 28 22:10:19 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 28 May 2015 15:10:19 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: References: <55664547.7050002@oracle.com> Message-ID: <5567924B.5030604@oracle.com> Please find comments in line... On 5/27/2015 3:42 PM, Mandy Chung wrote: > Valerie, > > Did you see my comment yesterday? > http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html Yes, we exchanged emails after this above one. I will follow up your latest one later today. > > Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let?s remove the META-INF files in the first push and the build change. > > The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. Sure, I can remove the META-INF files so the providers are loaded through the legacyLoad(). Hmm, the ProviderLoader.load() method is used by java.security file provider loading. Since the current list still uses class name, it should take class name when checking for matches while iterating through the list returned by ServiceLoader. This way, when changes are sync'ed into Jake, no extra change required and the providers will be loaded through ProviderLoader.load() automatically with the current list. > I?ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev Ok. Thanks, Valerie > . > > Mandy > >> On May 27, 2015, at 3:29 PM, Valerie Peng wrote: >> >> Hi, build experts, >> >> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >> >> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >> >> The rest of source code changes are reviewed by my team already. >> Thanks, >> Valerie >> (Java Security Team) From daniel.smith at oracle.com Thu May 28 23:24:05 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 28 May 2015 17:24:05 -0600 Subject: Status of ccache In-Reply-To: <5562DF84.1010309@oracle.com> References: <5562DF84.1010309@oracle.com> Message-ID: <6BD320FF-BD75-4323-8CDF-51C3D747985A@oracle.com> > On May 25, 2015, at 2:38 AM, Erik Joelsson wrote: > > On 2015-05-22 17:47, Dan Smith wrote: >> JDK-8027584 disabled ccache by default, I gather because it doesn't work in Cygwin, and secondarily because of vague general problems with it. >> >> The documentation (README-builds.html) still unambiguously endorses it, although doesn't say anything about how to turn it on (configure with --enable-ccache). >> >> I'm curious about the current state of affairs, and suggest updating the documentation to reflect the answer. >> >> ?Dan > From README-builds.html in jdk9: > >

Building with ccache

> >

The OpenJDK build supports building with ccache > when using gcc or clang. Using ccache can > radically speed up compilation of native code if > you often rebuild the same sources. Your milage > may vary however so we recommend evaluating it for > yourself. To enable it, make sure it's on the path > and configure with --enable-ccache.

> > I wouldn't say that's endorsing ccache, but rather reflects the current state of things. Sorry! Didn't see that updated text. Yeah, that's exactly what I was looking for. When I read the readme, I was jumping around to different points in the history, so I must have read a stale version. ?Dan From gnu.andrew at redhat.com Fri May 29 02:24:04 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 28 May 2015 22:24:04 -0400 (EDT) Subject: RFR: 8081447: System JPEG builds include in-tree jpeglib.h, resulting in build failure In-Reply-To: <183469517.7327364.1432865930046.JavaMail.zimbra@redhat.com> Message-ID: <844575377.7327957.1432866244163.JavaMail.zimbra@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8081447 Webrev: http://cr.openjdk.java.net/~andrew/8081447/webrev.01/ In testing a fix for [0], I found that system jpeg support seems to have bitrotted. Due to the movement of makefiles, it's hard to trace where this change occurred, but we have the conditional code: ifeq ($(USE_EXTERNAL_LIBJPEG), true) BUILD_LIBJAVAJPEG_HEADERS := else BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC)) endif but then BUILD_LIBJAVAJPEG_HEADERS is not used and instead $(addprefix -I, $(LIBJAVAJPEG_SRC)) is hardcoded in BUILD_LIBJAVAJPEG: CFLAGS := $(CFLAGS_JDKLIB) $(addprefix -I, $(LIBJAVAJPEG_SRC)) \ When building using the system libjpeg, this means that the jpeglib.h from the in-tree copy of libjpeg is used to build jpegdecoder.o. This leads to references to symbols that don't exist in the system version and a failure to link libjavajpeg.so The simple fix for this is to use BUILD_LIBJAVAJPEG_HEADERS again, as in the listed webrev. Ok to push to client? Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Fri May 29 02:25:42 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 28 May 2015 22:25:42 -0400 (EDT) Subject: RFR: 8081447: System JPEG builds include in-tree jpeglib.h, resulting in build failure In-Reply-To: <844575377.7327957.1432866244163.JavaMail.zimbra@redhat.com> References: <844575377.7327957.1432866244163.JavaMail.zimbra@redhat.com> Message-ID: <1063513720.7328094.1432866342041.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Bug: https://bugs.openjdk.java.net/browse/JDK-8081447 > Webrev: http://cr.openjdk.java.net/~andrew/8081447/webrev.01/ > > In testing a fix for [0], I found that system jpeg support seems > to have bitrotted. Due to the movement of makefiles, it's hard > to trace where this change occurred, but we have the conditional > code: > > ifeq ($(USE_EXTERNAL_LIBJPEG), true) > BUILD_LIBJAVAJPEG_HEADERS := > else > BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC)) > endif > > but then BUILD_LIBJAVAJPEG_HEADERS is not used and > instead $(addprefix -I, $(LIBJAVAJPEG_SRC)) is hardcoded in > BUILD_LIBJAVAJPEG: > > CFLAGS := $(CFLAGS_JDKLIB) $(addprefix -I, $(LIBJAVAJPEG_SRC)) \ > > When building using the system libjpeg, this means that the jpeglib.h > from the in-tree copy of libjpeg is used to build jpegdecoder.o. This > leads to references to symbols that don't exist in the system version > and a failure to link libjavajpeg.so > > The simple fix for this is to use BUILD_LIBJAVAJPEG_HEADERS again, > as in the listed webrev. > > Ok to push to client? > > Thanks, Reference should have been: [0] https://bugs.openjdk.java.net/browse/JDK-8081315 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From philip.race at oracle.com Fri May 29 04:41:06 2015 From: philip.race at oracle.com (Phil Race) Date: Thu, 28 May 2015 21:41:06 -0700 Subject: RFR: 8081447: System JPEG builds include in-tree jpeglib.h, resulting in build failure In-Reply-To: <1063513720.7328094.1432866342041.JavaMail.zimbra@redhat.com> References: <844575377.7327957.1432866244163.JavaMail.zimbra@redhat.com> <1063513720.7328094.1432866342041.JavaMail.zimbra@redhat.com> Message-ID: <5567EDE2.10300@oracle.com> Looks OK to me. I've added 2d-dev (owner of the lib). I don't think this will cause any issue for closed builds but we'll address it if it does. -phil. On 5/28/15 7:25 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Bug: https://bugs.openjdk.java.net/browse/JDK-8081447 >> Webrev: http://cr.openjdk.java.net/~andrew/8081447/webrev.01/ >> >> In testing a fix for [0], I found that system jpeg support seems >> to have bitrotted. Due to the movement of makefiles, it's hard >> to trace where this change occurred, but we have the conditional >> code: >> >> ifeq ($(USE_EXTERNAL_LIBJPEG), true) >> BUILD_LIBJAVAJPEG_HEADERS := >> else >> BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC)) >> endif >> >> but then BUILD_LIBJAVAJPEG_HEADERS is not used and >> instead $(addprefix -I, $(LIBJAVAJPEG_SRC)) is hardcoded in >> BUILD_LIBJAVAJPEG: >> >> CFLAGS := $(CFLAGS_JDKLIB) $(addprefix -I, $(LIBJAVAJPEG_SRC)) \ >> >> When building using the system libjpeg, this means that the jpeglib.h >> from the in-tree copy of libjpeg is used to build jpegdecoder.o. This >> leads to references to symbols that don't exist in the system version >> and a failure to link libjavajpeg.so >> >> The simple fix for this is to use BUILD_LIBJAVAJPEG_HEADERS again, >> as in the listed webrev. >> >> Ok to push to client? >> >> Thanks, > Reference should have been: > > [0] https://bugs.openjdk.java.net/browse/JDK-8081315 From magnus.ihse.bursie at oracle.com Fri May 29 09:15:11 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 29 May 2015 11:15:11 +0200 Subject: RFR: JDK-8081471 Allow SetupTestFilesCompilation to set LDFLAGS for individual tests Message-ID: <55682E1F.3090106@oracle.com> A request have been made to be able to set specific LDFLAGS for individual tests/libraries in SetupTestFilesCompilation, similar to the CFLAGS_filename construct in SetupNativeCompilation, e.g. LDFLAGS_libFooBar := -lfooflag It is trivial to also add CFLAGS functionality in a similar manner. This functionality will be used to resolve a test problem in hotspot, so it is possible that I will push this fix to a hotspot forest instead of jdk9/dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8081471 WebRev inline: diff --git a/make/common/TestFilesCompilation.gmk b/make/common/TestFilesCompilation.gmk --- a/make/common/TestFilesCompilation.gmk +++ b/make/common/TestFilesCompilation.gmk @@ -86,8 +86,8 @@ OBJECT_DIR := $$($1_OUTPUT_DIR)/support/$$($1_PREFIX)$$(name), \ OUTPUT_DIR := $$($1_OUTPUT_DIR)/$$($1_OUTPUT_SUBDIR), \ LANG := C, \ - CFLAGS := $$($1_CFLAGS), \ - LDFLAGS := $$($1_LDFLAGS), \ + CFLAGS := $$($1_CFLAGS) $$($1_CFLAGS_$$($1_PREFIX)$$(name)), \ + LDFLAGS := $$($1_LDFLAGS) $$($1_LDFLAGS_$$($1_PREFIX)$$(name)), \ OPTIMIZATION := LOW, \ DEBUG_SYMBOLS := true)) \ $$(eval $1 += $$(BUILD_TEST_$$(name)) ) \ /Magnus From stefan.sarne at oracle.com Fri May 29 11:37:38 2015 From: stefan.sarne at oracle.com (=?UTF-8?B?U3RlZmFuIFPDpHJuZQ==?=) Date: Fri, 29 May 2015 13:37:38 +0200 Subject: RFR: JDK-8081471 Allow SetupTestFilesCompilation to set LDFLAGS for individual tests In-Reply-To: <55682E1F.3090106@oracle.com> References: <55682E1F.3090106@oracle.com> Message-ID: <55684F82.9020000@oracle.com> Thanks Magnus for adding the support so quickly. The best would indeed be to bring it in via the hs-rt forest. /Stefan Magnus Ihse Bursie skrev den 2015-05-29 11:15: > A request have been made to be able to set specific LDFLAGS for > individual tests/libraries in SetupTestFilesCompilation, similar to > the CFLAGS_filename construct in SetupNativeCompilation, > e.g. > LDFLAGS_libFooBar := -lfooflag > > It is trivial to also add CFLAGS functionality in a similar manner. > > This functionality will be used to resolve a test problem in hotspot, > so it is possible that I will push this fix to a hotspot forest > instead of jdk9/dev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8081471 > WebRev inline: > > diff --git a/make/common/TestFilesCompilation.gmk > b/make/common/TestFilesCompilation.gmk > --- a/make/common/TestFilesCompilation.gmk > +++ b/make/common/TestFilesCompilation.gmk > @@ -86,8 +86,8 @@ > OBJECT_DIR := $$($1_OUTPUT_DIR)/support/$$($1_PREFIX)$$(name), \ > OUTPUT_DIR := $$($1_OUTPUT_DIR)/$$($1_OUTPUT_SUBDIR), \ > LANG := C, \ > - CFLAGS := $$($1_CFLAGS), \ > - LDFLAGS := $$($1_LDFLAGS), \ > + CFLAGS := $$($1_CFLAGS) $$($1_CFLAGS_$$($1_PREFIX)$$(name)), \ > + LDFLAGS := $$($1_LDFLAGS) > $$($1_LDFLAGS_$$($1_PREFIX)$$(name)), \ > OPTIMIZATION := LOW, \ > DEBUG_SYMBOLS := true)) \ > $$(eval $1 += $$(BUILD_TEST_$$(name)) ) \ > > /Magnus > From gnu.andrew at redhat.com Fri May 29 17:40:41 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 29 May 2015 13:40:41 -0400 (EDT) Subject: RFR: 8081447: System JPEG builds include in-tree jpeglib.h, resulting in build failure In-Reply-To: <556818CB.6040400@oracle.com> References: <844575377.7327957.1432866244163.JavaMail.zimbra@redhat.com> <556818CB.6040400@oracle.com> Message-ID: <2074812326.7807337.1432921241873.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 2015-05-29 04:24, Andrew Hughes wrote: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8081447 Webrev: > http://cr.openjdk.java.net/~andrew/8081447/webrev.01/ In testing a fix for > [0], I found that system jpeg support seems > to have bitrotted. Due to the movement of makefiles, it's hard > to trace where this change occurred, but we have the conditional > code: > > It was a casualty of JDK-8054834 (Modular Source Code ). > Yes, I traced it to that changeset, but it wasn't clear if it was actually changed there or the file was simply moved then. > Thanks for the fix, it looks good to me. My thanks to yourself and Phil. I've pushed the fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/6f87fd2df0d6 > > /Magnus > > > > > ifeq ($(USE_EXTERNAL_LIBJPEG), true) > BUILD_LIBJAVAJPEG_HEADERS := > else > BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC)) > endif > > but then BUILD_LIBJAVAJPEG_HEADERS is not used and > instead $(addprefix -I, $(LIBJAVAJPEG_SRC)) is hardcoded in > BUILD_LIBJAVAJPEG: > > CFLAGS := $(CFLAGS_JDKLIB) $(addprefix -I, $(LIBJAVAJPEG_SRC)) \ > > When building using the system libjpeg, this means that the jpeglib.h > from the in-tree copy of libjpeg is used to build jpegdecoder.o. This > leads to references to symbols that don't exist in the system version > and a failure to link libjavajpeg.so > > The simple fix for this is to use BUILD_LIBJAVAJPEG_HEADERS again, > as in the listed webrev. > > Ok to push to client? > > Thanks, > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07