From david.holmes at oracle.com Mon Nov 3 02:32:01 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Nov 2014 12:32:01 +1000 Subject: RFR 8u40: 8062635: Enable custom CompileJavaClasses.gmk In-Reply-To: <5453AC23.1030208@oracle.com> References: <5453AC23.1030208@oracle.com> Message-ID: <5456E921.6030602@oracle.com> Looks good. David On 1/11/2014 1:34 AM, roger riggs wrote: > Please review a change to include CompileJavaClasses.gmk from the > CUSTOM_MAKE_DIR. > > Please verify the change from ":=" to "+=" at line 61, it was > overwriting instead of appending. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-custom-compile-java/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8062635 > > Thanks, Roger > From magnus.ihse.bursie at oracle.com Tue Nov 4 10:09:45 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 04 Nov 2014 11:09:45 +0100 Subject: RFR: JDK-8062806 Remove unused build/make files Message-ID: <5458A5E9.9050309@oracle.com> Some files have been left in the build system, even though they are not used (anymore). common/bin/boot_cycle.sh common/bin/compare-objects.sh is not needed anymore. The first was a crude replacement for the bootcycle-images target, and the second was only at use while the modern build system was developed. common/autoconf/config.h.in and common/autoconf/spec.sh.in both generate files in the $BUILD top directory which is not used. config.h was never used at all, and spec.sh was support for compare-objects.sh. Bug: https://bugs.openjdk.java.net/browse/JDK-8062806 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8062806-remove-unused-build-files/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 4 10:34:41 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 04 Nov 2014 11:34:41 +0100 Subject: RFR: JDK-8062806 Remove unused build/make files In-Reply-To: <5458A5E9.9050309@oracle.com> References: <5458A5E9.9050309@oracle.com> Message-ID: <5458ABC1.3010905@oracle.com> On 2014-11-04 11:09, Magnus Ihse Bursie wrote: > Some files have been left in the build system, even though they are > not used (anymore). > > common/bin/boot_cycle.sh common/bin/compare-objects.sh is not needed > anymore. The first was a crude replacement for the bootcycle-images > target, and the second was only at use while the modern build system > was developed. > > common/autoconf/config.h.in and common/autoconf/spec.sh.in both > generate files in the $BUILD top directory which is not used. config.h > was never used at all, and spec.sh was support for compare-objects.sh. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8062806 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8062806-remove-unused-build-files/webrev.01 > > /Magnus I noticed that I had missed to remove a reference to spec.sh in Main.gmk. Harmless, but it should go away. Updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8062806-remove-unused-build-files/webrev.02 /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 4 13:10:39 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 04 Nov 2014 14:10:39 +0100 Subject: Yosemite problems with FreeType In-Reply-To: <1C2918D5-4CD4-491B-9009-62C5A9AFDD90@oracle.com> References: <6E2EC74E-FE78-4D37-90F4-C0AF800F79CC@oracle.com> <82B39EBC-A4FA-434B-A5B2-F105419A407B@oracle.com> <1C2918D5-4CD4-491B-9009-62C5A9AFDD90@oracle.com> Message-ID: <5458D04F.1040500@oracle.com> On 2014-10-22 19:50, Dan Smith wrote: > Well, I take that back. Tried installing 2.7.5 just in case, and now it works fine. > > Summary: > - Yosemite installer breaks XQuartz configuration (probably something trivial like removing a symbolic link) There does indeed seem to be a missing symbolic link. In previous versions, I can find a symlink from libfreetype.6.dylib to libfreetype.dylib in /usr/X11/lib. In Yosemite, this is missing. This causes configure to fail. I tried some ways to work around this in configure by using freetype.6 as library name instead of freetype, but I kept running into one silly problem after another and decided it didn't really seemed worth it. Instead of installing a different version of XQuartz, a workaround should probably be to: cd /usr/X11/lib ln -s libfreetype.6.dylib libfreetype.dylib (but I have not tested this). I think this will break other apps as well that want to use freetype, so a bug should probably be filed with Apple. /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 4 14:14:27 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 04 Nov 2014 15:14:27 +0100 Subject: Yosemite problems with FreeType In-Reply-To: <5458D04F.1040500@oracle.com> References: <6E2EC74E-FE78-4D37-90F4-C0AF800F79CC@oracle.com> <82B39EBC-A4FA-434B-A5B2-F105419A407B@oracle.com> <1C2918D5-4CD4-491B-9009-62C5A9AFDD90@oracle.com> <5458D04F.1040500@oracle.com> Message-ID: <5458DF43.1080901@oracle.com> On 2014-11-04 14:10, Magnus Ihse Bursie wrote: > On 2014-10-22 19:50, Dan Smith wrote: >> Well, I take that back. Tried installing 2.7.5 just in case, and now >> it works fine. >> >> Summary: >> - Yosemite installer breaks XQuartz configuration (probably something >> trivial like removing a symbolic link) > > There does indeed seem to be a missing symbolic link. In previous > versions, I can find a symlink from libfreetype.6.dylib to > libfreetype.dylib in /usr/X11/lib. In Yosemite, this is missing. This > causes configure to fail. > > I tried some ways to work around this in configure by using freetype.6 > as library name instead of freetype, but I kept running into one silly > problem after another and decided it didn't really seemed worth it. In the end, I actually got it sorted out and I do now have a patch that I believe will work well. Webrev coming up shortly... /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 4 14:33:45 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 04 Nov 2014 15:33:45 +0100 Subject: RFR: JDK-8062816 Configure fails to detect freetype on macosx Yosemite Message-ID: <5458E3C9.3020102@oracle.com> Beginning with macosx Yosemite, changes has been made to freetype which causes the build to fail in configure, even though freetype is present. Bug: https://bugs.openjdk.java.net/browse/JDK-8062816 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8062816-fix-freetype-on-yosemite/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 4 14:50:40 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 04 Nov 2014 15:50:40 +0100 Subject: RFR: JDK-8062661 Do not perform X11 checks in configure when X11 is not needed Message-ID: <5458E7C0.6070600@oracle.com> Configure has been testing for X11 even though it was not needed (on macosx and windows). This never caused any failures (since we ignore any results indicating that X11 is missing), but it looks silly. Bug: https://bugs.openjdk.java.net/browse/JDK-8062661 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8062661-dont-check-X11-if-not-needed/webrev.01 /Magnus From tim.bell at oracle.com Tue Nov 4 16:03:38 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 04 Nov 2014 08:03:38 -0800 Subject: RFR: JDK-8062806 Remove unused build/make files In-Reply-To: <5458ABC1.3010905@oracle.com> References: <5458A5E9.9050309@oracle.com> <5458ABC1.3010905@oracle.com> Message-ID: <5458F8DA.2040107@oracle.com> Hi Magnus: > Some files have been left in the build system, even though they are > not used (anymore). >> >> common/bin/boot_cycle.sh common/bin/compare-objects.sh is not needed >> anymore. The first was a crude replacement for the bootcycle-images >> target, and the second was only at use while the modern build system >> was developed. >> >> common/autoconf/config.h.in and common/autoconf/spec.sh.in both >> generate files in the $BUILD top directory which is not used. >> config.h was never used at all, and spec.sh was support for >> compare-objects.sh. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8062806 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8062806-remove-unused-build-files/webrev.01 >> >> /Magnus > > I noticed that I had missed to remove a reference to spec.sh in > Main.gmk. Harmless, but it should go away. Updated webrev: > > http://cr.openjdk.java.net/~ihse/JDK-8062806-remove-unused-build-files/webrev.02 > Looks good to me. Tim From tim.bell at oracle.com Tue Nov 4 16:03:52 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 04 Nov 2014 08:03:52 -0800 Subject: RFR: JDK-8062816 Configure fails to detect freetype on macosx Yosemite In-Reply-To: <5458E3C9.3020102@oracle.com> References: <5458E3C9.3020102@oracle.com> Message-ID: <5458F8E8.3050708@oracle.com> Hi Magnus: > Beginning with macosx Yosemite, changes has been made to freetype > which causes the build to fail in configure, even though freetype is > present. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8062816 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8062816-fix-freetype-on-yosemite/webrev.01 Looks good to me. Tim From tim.bell at oracle.com Tue Nov 4 16:07:01 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 04 Nov 2014 08:07:01 -0800 Subject: RFR: JDK-8062661 Do not perform X11 checks in configure when X11 is not needed In-Reply-To: <5458E7C0.6070600@oracle.com> References: <5458E7C0.6070600@oracle.com> Message-ID: <5458F9A5.7030704@oracle.com> Magnus: > Configure has been testing for X11 even though it was not needed (on > macosx and windows). This never caused any failures (since we ignore > any results indicating that X11 is missing), but it looks silly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8062661 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8062661-dont-check-X11-if-not-needed/webrev.01 Looks good to me. Tim From david.holmes at oracle.com Wed Nov 5 11:21:17 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Nov 2014 21:21:17 +1000 Subject: Windows build failure in JDK8 with --disable-zip-debug-info Message-ID: <545A082D.1000001@oracle.com> If I set --disable-zip-debug-info in JDK8u and do a windows build it fails with: make[2]: *** No rule to make target `/cygdrive/c/jprt/T/P1/031627.daholme/s/build/windows-x86-normal-clientANDserver-release/jdk/bin/verify.map', needed by `all'. Stop. This doesn't happen in JDK 9. Any suggestions? Thanks, David From magnus.ihse.bursie at oracle.com Wed Nov 5 12:25:34 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 05 Nov 2014 13:25:34 +0100 Subject: Windows build failure in JDK8 with --disable-zip-debug-info In-Reply-To: <545A082D.1000001@oracle.com> References: <545A082D.1000001@oracle.com> Message-ID: <545A173E.8060908@oracle.com> On 2014-11-05 12:21, David Holmes wrote: > If I set > > --disable-zip-debug-info > > in JDK8u and do a windows build it fails with: > > make[2]: *** No rule to make target > `/cygdrive/c/jprt/T/P1/031627.daholme/s/build/windows-x86-normal-clientANDserver-release/jdk/bin/verify.map', > needed by `all'. Stop. > > This doesn't happen in JDK 9. > > Any suggestions? The map files are special since they are produced as a side-effect of the compilation. The makefiles in jdk8 (this piece of code has been modified serveral times in jdk9) does not have a rule ??? -> ?.map, instead the rule is ??? -> ?.dll, and the map file gets produced at the same time, without make knowning about it. I'm not sure why something started to depend on the .map file, but you could probably add a rule from *.map to *.dll in make/common/NativeCompilation.gmk. Something like this pseudo code: if os==windows $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb: $$($1_TARGET) endif I even have a vague memory of a fix along these lines in jdk9. If that's correct, it's probably due for backporting. I'll see if I can locate it. /Magnus From magnus.ihse.bursie at oracle.com Wed Nov 5 12:27:43 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 05 Nov 2014 13:27:43 +0100 Subject: Windows build failure in JDK8 with --disable-zip-debug-info In-Reply-To: <545A173E.8060908@oracle.com> References: <545A082D.1000001@oracle.com> <545A173E.8060908@oracle.com> Message-ID: <545A17BF.7090705@oracle.com> On 2014-11-05 13:25, Magnus Ihse Bursie wrote: > I even have a vague memory of a fix along these lines in jdk9. If > that's correct, it's probably due for backporting. I'll see if I can > locate it. https://bugs.openjdk.java.net/browse/JDK-8025936 It might be some work backporting it though, the comments in the bug says it needed to be substantially rewritten due to changes in JDK9. /Magnus From david.holmes at oracle.com Wed Nov 5 13:00:54 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Nov 2014 23:00:54 +1000 Subject: Windows build failure in JDK8 with --disable-zip-debug-info In-Reply-To: <545A17BF.7090705@oracle.com> References: <545A082D.1000001@oracle.com> <545A173E.8060908@oracle.com> <545A17BF.7090705@oracle.com> Message-ID: <545A1F86.3090301@oracle.com> On 5/11/2014 10:27 PM, Magnus Ihse Bursie wrote: > On 2014-11-05 13:25, Magnus Ihse Bursie wrote: >> I even have a vague memory of a fix along these lines in jdk9. If >> that's correct, it's probably due for backporting. I'll see if I can >> locate it. > > https://bugs.openjdk.java.net/browse/JDK-8025936 > > It might be some work backporting it though, the comments in the bug > says it needed to be substantially rewritten due to changes in JDK9. Thanks Magnus. Seems this is unlikely to be fixed then - which means I can't test what I'm working on for the case where we don't zip the debuginfo files :( David > /Magnus From magnus.ihse.bursie at oracle.com Wed Nov 5 13:04:10 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 05 Nov 2014 14:04:10 +0100 Subject: RFR: JDK-8058631 Rename posix to unix in build system to match file name changes In-Reply-To: <5422BB6E.1000500@oracle.com> References: <5422BB6E.1000500@oracle.com> Message-ID: <545A204A.4080301@oracle.com> On 2014-09-24 14:39, Magnus Ihse Bursie wrote: > After Jigsaw M1, there is a new common "unix" directory structure. We > have used "posix" in the build system for the same purpose, but this > leads to unnecessary conversations. Instead, we should use "unix" all > way through in the build system. > > Also, this means that OS_API is slightly misleading -- we're not > actually checking for an API such as POSIX, but the general category > of OSes. I'll rename the *_OS_API to *_OS_TYPE instead. The "winapi" > OS_API was never used, and is removed -- we only need to check for > "windows", there's no need to introduce an abstract "winapi" category. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8058631 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8058631-rename-posix-to-unix/webrev.01 This fix got stuck far down the priority list... It was pointed out to me that OS_API_SRC_DIRS should change name as well, to match OS_TYPE. This updated webrev contain that fix. I have also double-checked that no other name changes are needed to keep the code consistent. Updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8058631-rename-posix-to-unix/webrev.02/ /Magnus From volker.simonis at gmail.com Wed Nov 5 16:13:42 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 5 Nov 2014 17:13:42 +0100 Subject: RFR: JDK-8058631 Rename posix to unix in build system to match file name changes In-Reply-To: <545A204A.4080301@oracle.com> References: <5422BB6E.1000500@oracle.com> <545A204A.4080301@oracle.com> Message-ID: Hi Magnus, I've looked at the change and I think it looks good. For any case I've also run an AIX build with your change applied and didn't encounter any problems. So thumbs up from me! Regards, Volker PS: how did you produce a webrev from two repositories - do you have a special version of webrev? And what's the best way to import such a change into mercurial (apart from 'patch'). I manually edited the patch file to make 'compatible' with 'qimport' but maybe there's a better way? On Wed, Nov 5, 2014 at 2:04 PM, Magnus Ihse Bursie wrote: > On 2014-09-24 14:39, Magnus Ihse Bursie wrote: >> >> After Jigsaw M1, there is a new common "unix" directory structure. We have >> used "posix" in the build system for the same purpose, but this leads to >> unnecessary conversations. Instead, we should use "unix" all way through in >> the build system. >> >> Also, this means that OS_API is slightly misleading -- we're not actually >> checking for an API such as POSIX, but the general category of OSes. I'll >> rename the *_OS_API to *_OS_TYPE instead. The "winapi" OS_API was never >> used, and is removed -- we only need to check for "windows", there's no need >> to introduce an abstract "winapi" category. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8058631 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8058631-rename-posix-to-unix/webrev.01 > > > This fix got stuck far down the priority list... > > It was pointed out to me that OS_API_SRC_DIRS should change name as well, to > match OS_TYPE. This updated webrev contain that fix. I have also > double-checked that no other name changes are needed to keep the code > consistent. > > Updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8058631-rename-posix-to-unix/webrev.02/ > > /Magnus > From david.holmes at oracle.com Thu Nov 6 08:30:07 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Nov 2014 18:30:07 +1000 Subject: Building openjdk 8 on Mac OS X In-Reply-To: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> References: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> Message-ID: <545B318F.3090805@oracle.com> Re-directing to build-dev - please don't respond further on the discuss list. David On 6/11/2014 3:48 PM, Manas Thakur wrote: > I have tried building openjdk8 on mac os x yosemite by trying all means available on net. I made xcode4.6.3 as the default one; configure is fine, but I get several errors while making the hotspot images in FSEvents.h and NSUserNotification.h. > I tried following some suggestions regarding commenting some lines, but that doesn?t work as well. > > - Manas > > > > > From magnus.ihse.bursie at oracle.com Thu Nov 6 09:13:32 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 6 Nov 2014 10:13:32 +0100 Subject: Building openjdk 8 on Mac OS X In-Reply-To: <545B318F.3090805@oracle.com> References: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> <545B318F.3090805@oracle.com> Message-ID: The short answer is that building jdk8 on Yosemite is not supported. A longer answer is that we're currently working on getting jdk9 to compile on Yosemite. When that is successful, the patches needed might get ported to jdk8. If you post more extensive log extracts to build-dev, we can possibly help you find a work-around in the meantime. /Magnus 6 nov 2014 kl. 09:30 skrev David Holmes : > Re-directing to build-dev - please don't respond further on the discuss list. > > David > > On 6/11/2014 3:48 PM, Manas Thakur wrote: >> I have tried building openjdk8 on mac os x yosemite by trying all means available on net. I made xcode4.6.3 as the default one; configure is fine, but I get several errors while making the hotspot images in FSEvents.h and NSUserNotification.h. >> I tried following some suggestions regarding commenting some lines, but that doesn?t work as well. >> >> - Manas >> >> >> >> >> From manasthakur17 at gmail.com Thu Nov 6 11:45:05 2014 From: manasthakur17 at gmail.com (Manas Thakur) Date: Thu, 6 Nov 2014 17:15:05 +0530 Subject: Building openjdk 8 on Mac OS X Message-ID: <322D21DC-A8EC-4054-9B29-5EB6B8DB8754@gmail.com> Thanks for the reply Magnus. Here are the error logs that get generated: Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp Making signal interposition lib... couldn't understand kern.osversion `14.0.0' warning: (x86_64) /var/folders/16/5m_yzyd961b3l31crzg2hsl40000gp/T//ccEmbC6U.o unable to open object file warning: no debug symbols in executable (-arch x86_64) Making SA debugger back-end... couldn't understand kern.osversion `14.0.0' In file included from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:55, from /System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12, from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:80, from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:262: error: expected ?,? or ?}? before ?__attribute__? /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:414: error: expected ?,? or ?}? before ?__attribute__? In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:119, from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: /System/Library/Frameworks/Foundation.framework/Headers/NSUserActivity.h:55: error: expected a property attribute before ?weak? Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/runtime/vm_version.cpp In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:171, from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error: expected ?,? or ?}? before ?__attribute__? make[8]: *** [libsaproc.dylib] Error 1 make[8]: *** Waiting for unfinished jobs.... make[7]: *** [the_vm] Error 2 make[6]: *** [product] Error 2 make[5]: *** [generic_build2] Error 2 make[4]: *** [product] Error 2 make[3]: *** [all_product_universal] Error 2 make[2]: *** [universal_product] Error 2 make[1]: *** [/Users/manas/Desktop/Software/openjdk/sources/openjdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 make: *** [hotspot-only] Error 2 Can you suggest me some workaround(s)? - Manas From staffan.larsen at oracle.com Thu Nov 6 19:39:54 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 6 Nov 2014 20:39:54 +0100 Subject: Building openjdk 8 on Mac OS X In-Reply-To: <322D21DC-A8EC-4054-9B29-5EB6B8DB8754@gmail.com> References: <322D21DC-A8EC-4054-9B29-5EB6B8DB8754@gmail.com> Message-ID: <78ABBB16-75D7-4F95-9364-0996FAAA7E22@oracle.com> From which exact branch is the code cloned? I know there were some issues with #includes in MacosxDebuggerLocal.m, but they should have been cleaned up in jdk8u-dev by now /Staffan > On 6 nov 2014, at 12:45, Manas Thakur wrote: > > Thanks for the reply Magnus. Here are the error logs that get generated: > > Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp > Making signal interposition lib... > couldn't understand kern.osversion `14.0.0' > warning: (x86_64) /var/folders/16/5m_yzyd961b3l31crzg2hsl40000gp/T//ccEmbC6U.o unable to open object file > warning: no debug symbols in executable (-arch x86_64) > Making SA debugger back-end... > couldn't understand kern.osversion `14.0.0' > In file included from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:55, > from /System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12, > from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:80, > from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: > /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:262: error: expected ?,? or ?}? before ?__attribute__? > /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:414: error: expected ?,? or ?}? before ?__attribute__? > In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:119, > from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: > /System/Library/Frameworks/Foundation.framework/Headers/NSUserActivity.h:55: error: expected a property attribute before ?weak? > Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/runtime/vm_version.cpp > In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:171, > from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: > /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error: expected ?,? or ?}? before ?__attribute__? > make[8]: *** [libsaproc.dylib] Error 1 > make[8]: *** Waiting for unfinished jobs.... > make[7]: *** [the_vm] Error 2 > make[6]: *** [product] Error 2 > make[5]: *** [generic_build2] Error 2 > make[4]: *** [product] Error 2 > make[3]: *** [all_product_universal] Error 2 > make[2]: *** [universal_product] Error 2 > make[1]: *** [/Users/manas/Desktop/Software/openjdk/sources/openjdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 > make: *** [hotspot-only] Error 2 > > Can you suggest me some workaround(s)? > > - Manas From manasthakur17 at gmail.com Fri Nov 7 03:51:34 2014 From: manasthakur17 at gmail.com (Manas Thakur) Date: Fri, 7 Nov 2014 09:21:34 +0530 Subject: Building openjdk 8 on Mac OS X In-Reply-To: <78ABBB16-75D7-4F95-9364-0996FAAA7E22@oracle.com> References: <322D21DC-A8EC-4054-9B29-5EB6B8DB8754@gmail.com> <78ABBB16-75D7-4F95-9364-0996FAAA7E22@oracle.com> Message-ID: <161D9D20-03E6-400F-A6F1-B05F065CB903@gmail.com> Hi Staffan Sure, I will try for jdk8u; the current errors were for jdk8. Regards, Manas > On 07-Nov-2014, at 1:09 am, Staffan Larsen wrote: > > From which exact branch is the code cloned? I know there were some issues with #includes in MacosxDebuggerLocal.m, but they should have been cleaned up in jdk8u-dev by now > > /Staffan > >> On 6 nov 2014, at 12:45, Manas Thakur wrote: >> >> Thanks for the reply Magnus. Here are the error logs that get generated: >> >> Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp >> Making signal interposition lib... >> couldn't understand kern.osversion `14.0.0' >> warning: (x86_64) /var/folders/16/5m_yzyd961b3l31crzg2hsl40000gp/T//ccEmbC6U.o unable to open object file >> warning: no debug symbols in executable (-arch x86_64) >> Making SA debugger back-end... >> couldn't understand kern.osversion `14.0.0' >> In file included from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:55, >> from /System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12, >> from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:80, >> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >> /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:262: error: expected ?,? or ?}? before ?__attribute__? >> /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:414: error: expected ?,? or ?}? before ?__attribute__? >> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:119, >> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >> /System/Library/Frameworks/Foundation.framework/Headers/NSUserActivity.h:55: error: expected a property attribute before ?weak? >> Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/runtime/vm_version.cpp >> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:171, >> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >> /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error: expected ?,? or ?}? before ?__attribute__? >> make[8]: *** [libsaproc.dylib] Error 1 >> make[8]: *** Waiting for unfinished jobs.... >> make[7]: *** [the_vm] Error 2 >> make[6]: *** [product] Error 2 >> make[5]: *** [generic_build2] Error 2 >> make[4]: *** [product] Error 2 >> make[3]: *** [all_product_universal] Error 2 >> make[2]: *** [universal_product] Error 2 >> make[1]: *** [/Users/manas/Desktop/Software/openjdk/sources/openjdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 >> make: *** [hotspot-only] Error 2 >> >> Can you suggest me some workaround(s)? >> >> - Manas > From manasthakur17 at gmail.com Fri Nov 7 04:43:24 2014 From: manasthakur17 at gmail.com (Manas Thakur) Date: Fri, 7 Nov 2014 10:13:24 +0530 Subject: Building openjdk 8 on Mac OS X In-Reply-To: <78ABBB16-75D7-4F95-9364-0996FAAA7E22@oracle.com> References: <322D21DC-A8EC-4054-9B29-5EB6B8DB8754@gmail.com> <78ABBB16-75D7-4F95-9364-0996FAAA7E22@oracle.com> Message-ID: I get the same error(s) for jdk8u20 as well. - Manas > On 07-Nov-2014, at 1:09 am, Staffan Larsen wrote: > > From which exact branch is the code cloned? I know there were some issues with #includes in MacosxDebuggerLocal.m, but they should have been cleaned up in jdk8u-dev by now > > /Staffan > >> On 6 nov 2014, at 12:45, Manas Thakur wrote: >> >> Thanks for the reply Magnus. Here are the error logs that get generated: >> >> Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp >> Making signal interposition lib... >> couldn't understand kern.osversion `14.0.0' >> warning: (x86_64) /var/folders/16/5m_yzyd961b3l31crzg2hsl40000gp/T//ccEmbC6U.o unable to open object file >> warning: no debug symbols in executable (-arch x86_64) >> Making SA debugger back-end... >> couldn't understand kern.osversion `14.0.0' >> In file included from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:55, >> from /System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12, >> from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:80, >> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >> /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:262: error: expected ?,? or ?}? before ?__attribute__? >> /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:414: error: expected ?,? or ?}? before ?__attribute__? >> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:119, >> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >> /System/Library/Frameworks/Foundation.framework/Headers/NSUserActivity.h:55: error: expected a property attribute before ?weak? >> Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/runtime/vm_version.cpp >> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:171, >> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >> /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error: expected ?,? or ?}? before ?__attribute__? >> make[8]: *** [libsaproc.dylib] Error 1 >> make[8]: *** Waiting for unfinished jobs.... >> make[7]: *** [the_vm] Error 2 >> make[6]: *** [product] Error 2 >> make[5]: *** [generic_build2] Error 2 >> make[4]: *** [product] Error 2 >> make[3]: *** [all_product_universal] Error 2 >> make[2]: *** [universal_product] Error 2 >> make[1]: *** [/Users/manas/Desktop/Software/openjdk/sources/openjdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 >> make: *** [hotspot-only] Error 2 >> >> Can you suggest me some workaround(s)? >> >> - Manas > From magnus.ihse.bursie at oracle.com Fri Nov 7 08:52:55 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 07 Nov 2014 09:52:55 +0100 Subject: RFR: JDK-8058631 Rename posix to unix in build system to match file name changes In-Reply-To: References: <5422BB6E.1000500@oracle.com> <545A204A.4080301@oracle.com> Message-ID: <545C8867.1060606@oracle.com> On 2014-11-05 17:13, Volker Simonis wrote: > Hi Magnus, > > I've looked at the change and I think it looks good. > For any case I've also run an AIX build with your change applied and > didn't encounter any problems. > So thumbs up from me! Thanks! > > Regards, > Volker > > PS: how did you produce a webrev from two repositories - do you have a > special version of webrev? No special version, just the latest from the webrev repo. Use the -f switch to include sub-repos. For historical reasons it's named "-f", for forest, but it is now converted to use the tree extension. (I did ran into an issue with the new tree extension support since I used nawk instead of gawk; a patch for that is under review.) > And what's the best way to import such a change into mercurial (apart > from 'patch'). I manually edited the patch file to make 'compatible' > with 'qimport' but maybe there's a better way? I have no idea. :-) I think you'll need to use patch, since mercurial do not know about subrepos internally. Is there a problem with using patch? Maybe the trees extensions will need to implement a timport..? /Magnus From vladimir.kozlov at oracle.com Fri Nov 7 17:34:08 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 07 Nov 2014 09:34:08 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <545CFFA9.4070107@redhat.com> References: <545CFFA9.4070107@redhat.com> Message-ID: <545D0290.5080307@oracle.com> CCing to build-dev and JDK9-dev since it is top level changes. Note, it will go into staging aarch64 repo. Vladimir On 11/7/14 9:21 AM, Andrew Haley wrote: > The first patch: top-level build machinery changes. > > http://cr.openjdk.java.net/~aph/8064357-rev-1/ > > Andrew. > From christian.thalinger at oracle.com Fri Nov 7 17:42:08 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 7 Nov 2014 09:42:08 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <545CFFA9.4070107@redhat.com> References: <545CFFA9.4070107@redhat.com> Message-ID: <6313454D-6690-4119-B55C-DBB356E4B3AC@oracle.com> > On Nov 7, 2014, at 9:21 AM, Andrew Haley wrote: > > The first patch: top-level build machinery changes. > > http://cr.openjdk.java.net/~aph/8064357-rev-1/ common/autoconf/flags.m4 + aarch64) + ZERO_ARCHFLAG="" + ;; Why is this required on aarch64 but not all the other architectures? Otherwise this looks good. > > Andrew. From aph at redhat.com Fri Nov 7 17:55:26 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 07 Nov 2014 17:55:26 +0000 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <6313454D-6690-4119-B55C-DBB356E4B3AC@oracle.com> References: <545CFFA9.4070107@redhat.com> <6313454D-6690-4119-B55C-DBB356E4B3AC@oracle.com> Message-ID: <545D078E.2090509@redhat.com> On 11/07/2014 05:42 PM, Christian Thalinger wrote: > >> On Nov 7, 2014, at 9:21 AM, Andrew Haley wrote: >> >> The first patch: top-level build machinery changes. >> >> http://cr.openjdk.java.net/~aph/8064357-rev-1/ > > common/autoconf/flags.m4 > > + aarch64) > + ZERO_ARCHFLAG="" > + ;; > > Why is this required on aarch64 but not all the other architectures? I think it's because GCC rejects "-m64". Andrew. From volker.simonis at gmail.com Fri Nov 7 18:00:37 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 7 Nov 2014 19:00:37 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <545D0290.5080307@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> Message-ID: The changes look good besides the ones to common/autoconf/build-aux/config.sub When we did our initial check-in there have been objections to modify autoconf-config.guess because that one was "copied directly from the autoconf project and should not be modified". I think the same applies to config.sub as well. But on the other side, we have an OpenJDK specific wrapper for autoconf-config.guess (i.e. config.guess) but there's no such wrapper for config.sub where we could fix-up things. So we have three possibilities: 1. make your change as suggested (which breaks the rule of not editing upstream files) 2. create a wrapper for config.sub, i.e. move config.sub to autoconf-config.sub and call it from config.sub which can contain arbitrary fix-up coding (which seems a little over-engineered IMHO) 3. pull in the new version of config.guess and config.sub from [1] which already seem to have the changes you need. I'm all in favour of point three which would also allow us to get rid of some of the hacks which are currently in config.guess. And now, as we're still early in the jdk9 development the risk of doing this seems minimal, but let's see what the build-dev guy say? Regards, Volker [1] http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD On Fri, Nov 7, 2014 at 6:34 PM, Vladimir Kozlov wrote: > CCing to build-dev and JDK9-dev since it is top level changes. > > Note, it will go into staging aarch64 repo. > > Vladimir > > > On 11/7/14 9:21 AM, Andrew Haley wrote: >> >> The first patch: top-level build machinery changes. >> >> http://cr.openjdk.java.net/~aph/8064357-rev-1/ >> >> Andrew. >> > From christian.thalinger at oracle.com Fri Nov 7 18:10:39 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 7 Nov 2014 10:10:39 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <545D078E.2090509@redhat.com> References: <545CFFA9.4070107@redhat.com> <6313454D-6690-4119-B55C-DBB356E4B3AC@oracle.com> <545D078E.2090509@redhat.com> Message-ID: > On Nov 7, 2014, at 9:55 AM, Andrew Haley wrote: > > On 11/07/2014 05:42 PM, Christian Thalinger wrote: >> >>> On Nov 7, 2014, at 9:21 AM, Andrew Haley wrote: >>> >>> The first patch: top-level build machinery changes. >>> >>> http://cr.openjdk.java.net/~aph/8064357-rev-1/ >> >> common/autoconf/flags.m4 >> >> + aarch64) >> + ZERO_ARCHFLAG="" >> + ;; >> >> Why is this required on aarch64 but not all the other architectures? > > I think it's because GCC rejects "-m64?. That?s interesting. I thought -m is some kind of common flag that works on all architectures. Can someone verify this? > > Andrew. > From aph at redhat.com Fri Nov 7 18:19:31 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 07 Nov 2014 18:19:31 +0000 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: References: <545CFFA9.4070107@redhat.com> <6313454D-6690-4119-B55C-DBB356E4B3AC@oracle.com> <545D078E.2090509@redhat.com> Message-ID: <545D0D33.70400@redhat.com> On 11/07/2014 06:10 PM, Christian Thalinger wrote: > >> On Nov 7, 2014, at 9:55 AM, Andrew Haley wrote: >> >> On 11/07/2014 05:42 PM, Christian Thalinger wrote: >>> >>>> On Nov 7, 2014, at 9:21 AM, Andrew Haley wrote: >>>> >>>> The first patch: top-level build machinery changes. >>>> >>>> http://cr.openjdk.java.net/~aph/8064357-rev-1/ >>> >>> common/autoconf/flags.m4 >>> >>> + aarch64) >>> + ZERO_ARCHFLAG="" >>> + ;; >>> >>> Why is this required on aarch64 but not all the other architectures? >> >> I think it's because GCC rejects "-m64?. > > That?s interesting. I thought -m is some kind of common > flag that works on all architectures. No, all the "-m" stuff is target-dependent. > Can someone verify this? mustang-01:~ $ gcc -m64 hello.c gcc: error: unrecognized command line option '-m64' mustang-01:~ $ gcc --version gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Andrew. From christian.thalinger at oracle.com Fri Nov 7 18:21:31 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 7 Nov 2014 10:21:31 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: References: <545CFFA9.4070107@redhat.com> <6313454D-6690-4119-B55C-DBB356E4B3AC@oracle.com> <545D078E.2090509@redhat.com> Message-ID: <9C88630B-54EC-47A2-869D-0C2F5E507ECB@oracle.com> > On Nov 7, 2014, at 10:10 AM, Christian Thalinger wrote: > >> >> On Nov 7, 2014, at 9:55 AM, Andrew Haley wrote: >> >> On 11/07/2014 05:42 PM, Christian Thalinger wrote: >>> >>>> On Nov 7, 2014, at 9:21 AM, Andrew Haley wrote: >>>> >>>> The first patch: top-level build machinery changes. >>>> >>>> http://cr.openjdk.java.net/~aph/8064357-rev-1/ >>> >>> common/autoconf/flags.m4 >>> >>> + aarch64) >>> + ZERO_ARCHFLAG="" >>> + ;; >>> >>> Why is this required on aarch64 but not all the other architectures? >> >> I think it's because GCC rejects "-m64?. > > That?s interesting. I thought -m is some kind of common flag that works on all architectures. Can someone verify this? This page doesn?t list it (while x86, SPARC, and PowerPC pages do): https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html I guess it?s good then. > >> >> Andrew. From christian.thalinger at oracle.com Fri Nov 7 18:21:56 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 7 Nov 2014 10:21:56 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <545D0D33.70400@redhat.com> References: <545CFFA9.4070107@redhat.com> <6313454D-6690-4119-B55C-DBB356E4B3AC@oracle.com> <545D078E.2090509@redhat.com> <545D0D33.70400@redhat.com> Message-ID: <7E34D2EE-A7D8-4B2D-BF47-627C566C8992@oracle.com> > On Nov 7, 2014, at 10:19 AM, Andrew Haley wrote: > > On 11/07/2014 06:10 PM, Christian Thalinger wrote: >> >>> On Nov 7, 2014, at 9:55 AM, Andrew Haley wrote: >>> >>> On 11/07/2014 05:42 PM, Christian Thalinger wrote: >>>> >>>>> On Nov 7, 2014, at 9:21 AM, Andrew Haley wrote: >>>>> >>>>> The first patch: top-level build machinery changes. >>>>> >>>>> http://cr.openjdk.java.net/~aph/8064357-rev-1/ >>>> >>>> common/autoconf/flags.m4 >>>> >>>> + aarch64) >>>> + ZERO_ARCHFLAG="" >>>> + ;; >>>> >>>> Why is this required on aarch64 but not all the other architectures? >>> >>> I think it's because GCC rejects "-m64?. >> >> That?s interesting. I thought -m is some kind of common >> flag that works on all architectures. > > No, all the "-m" stuff is target-dependent. > >> Can someone verify this? > > mustang-01:~ $ gcc -m64 hello.c > gcc: error: unrecognized command line option '-m64' > mustang-01:~ $ gcc --version > gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Thanks :-) > > Andrew. From aph at redhat.com Fri Nov 7 18:53:03 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 07 Nov 2014 18:53:03 +0000 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> Message-ID: <545D150F.0@redhat.com> On 11/07/2014 06:00 PM, Volker Simonis wrote: > 3. pull in the new version of config.guess and config.sub from [1] > which already seem to have the changes you need. > > I'm all in favour of point three which would also allow us to get rid > of some of the hacks which are currently in config.guess. And now, as > we're still early in the jdk9 development the risk of doing this seems > minimal, but let's see what the build-dev guy say? So am I. build-dev people, do you want me to import config.guess from upstream? I can create a new issue. Andrew. From emr at ccil.org Fri Nov 7 22:15:51 2014 From: emr at ccil.org (Eric Reischer) Date: Fri, 7 Nov 2014 17:15:51 -0500 (EST) Subject: adjust-mflags mangles paths into arguments Message-ID: Steps to reproduce: $ hg clone http://hg.openjdk.java.net/jdk8u/jdk8u jdk8u $ cd jdk8u $ sh get_source.sh $ sh configure --with-freetype-include=/usr/include/freetype2 --with-freetype-lib=/usr/lib/x86_64-linux-gnu --with-debug-level=slowdebug $ LOG=trace JOBS=1 make all {....} + echo /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug /home/emr/jdk8u/hotspot/make/linux/makefiles/top.make:91: Building ad_stuff (from /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/platform.current) (/home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/platform.current /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/adjust-mflags newer) ++ pwd + echo /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug /home/emr/jdk8u/hotspot/make/linux/makefiles/top.make:91: Building ad_stuff (from /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/platform.current) (/home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/platform.current /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/adjust-mflags newer) ++ /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/adjust-mflags '-rRw -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common' 1 + /usr/bin/make VERBOSE= LOG_LEVEL=trace -R -I /home/emr/jdk8u/make/common -f adlc.make -r -rRw -I/home/emr/ -j1 -dk8u/make/common -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common /usr/bin/make: invalid option -- '8' /usr/bin/make: invalid option -- 'u' /usr/bin/make: invalid option -- '/' /usr/bin/make: invalid option -- 'a' /usr/bin/make: invalid option -- '/' /usr/bin/make: invalid option -- 'c' Usage: make [options] [target] ... Options: -b, -m Ignored for compatibility. {....} As you can see, "adjust-mflags" is taking the path /home/emr/jdk8u/make/common and incorrectly converting it into /home/emr/ -j1 -dk8u/make/common Naturally, everything is boned from that point on. This occurs when the "all" target gets to building hotspot. From erik.joelsson at oracle.com Mon Nov 10 07:55:39 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Nov 2014 08:55:39 +0100 Subject: adjust-mflags mangles paths into arguments In-Reply-To: References: Message-ID: <54606F7B.7020109@oracle.com> Hello Eric, Thanks for the detailed report. This looks like https://bugs.openjdk.java.net/browse/JDK-8028407 which probably needs to be backported to 8u as gnu make 4.0 is only going to get more common going forward. /Erik On 2014-11-07 23:15, Eric Reischer wrote: > Steps to reproduce: > > $ hg clone http://hg.openjdk.java.net/jdk8u/jdk8u jdk8u > $ cd jdk8u > $ sh get_source.sh > $ sh configure --with-freetype-include=/usr/include/freetype2 > --with-freetype-lib=/usr/lib/x86_64-linux-gnu > --with-debug-level=slowdebug > $ LOG=trace JOBS=1 make all > > > {....} > + echo > /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug > /home/emr/jdk8u/hotspot/make/linux/makefiles/top.make:91: Building > ad_stuff (from > /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/platform.current) > (/home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/platform.current > /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/adjust-mflags > newer) > ++ pwd > + echo > /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug > /home/emr/jdk8u/hotspot/make/linux/makefiles/top.make:91: Building > ad_stuff (from > /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/platform.current) > (/home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/platform.current > /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/adjust-mflags > newer) > ++ > /home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/adjust-mflags > '-rRw -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common > -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common > -I/home/emr/jdk8u/make/common' 1 > + /usr/bin/make VERBOSE= LOG_LEVEL=trace -R -I > /home/emr/jdk8u/make/common -f adlc.make -r -rRw -I/home/emr/ -j1 > -dk8u/make/common -I/home/emr/jdk8u/make/common > -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common > -I/home/emr/jdk8u/make/common > /usr/bin/make: invalid option -- '8' > /usr/bin/make: invalid option -- 'u' > /usr/bin/make: invalid option -- '/' > /usr/bin/make: invalid option -- 'a' > /usr/bin/make: invalid option -- '/' > /usr/bin/make: invalid option -- 'c' > Usage: make [options] [target] ... > Options: > -b, -m Ignored for compatibility. > {....} > > As you can see, "adjust-mflags" is taking the path > /home/emr/jdk8u/make/common > and incorrectly converting it into > /home/emr/ -j1 -dk8u/make/common > > Naturally, everything is boned from that point on. This occurs when > the "all" target gets to building hotspot. From erik.joelsson at oracle.com Mon Nov 10 08:08:41 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Nov 2014 09:08:41 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <545D150F.0@redhat.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> Message-ID: <54607289.9090002@oracle.com> Hello, I would certainly like to have these files updated, but unfortunately the license on these files changed from GPL2 to GPL3. This essentially means that the switch is non trivial from a legal perspective and the impression I've received when I last inquired about updating these files was that it's unlikely to ever happen unless a very strong case can be presented for why it's needed. So the reason we have the over engineered solution for config.guess is simply that it's much easier than getting legal approval for updating these files. /Erik On 2014-11-07 19:53, Andrew Haley wrote: > On 11/07/2014 06:00 PM, Volker Simonis wrote: >> 3. pull in the new version of config.guess and config.sub from [1] >> which already seem to have the changes you need. >> >> I'm all in favour of point three which would also allow us to get rid >> of some of the hacks which are currently in config.guess. And now, as >> we're still early in the jdk9 development the risk of doing this seems >> minimal, but let's see what the build-dev guy say? > So am I. build-dev people, do you want me to import config.guess from > upstream? I can create a new issue. > > Andrew. > From aph at redhat.com Mon Nov 10 08:54:03 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 10 Nov 2014 08:54:03 +0000 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <54607289.9090002@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> Message-ID: <54607D2B.3060007@redhat.com> On 10/11/14 08:08, Erik Joelsson wrote: > I would certainly like to have these files updated, but > unfortunately the license on these files changed from GPL2 to > GPL3. This essentially means that the switch is non trivial from a > legal perspective and the impression I've received when I last > inquired about updating these files was that it's unlikely to ever > happen unless a very strong case can be presented for why it's > needed. > > So the reason we have the over engineered solution for config.guess > is simply that it's much easier than getting legal approval for > updating these files. I see. That suggests to me that my simple one-liner is the way to go. Andrew. From volker.simonis at gmail.com Mon Nov 10 09:27:20 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 10 Nov 2014 10:27:20 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <54607289.9090002@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> Message-ID: On Mon, Nov 10, 2014 at 9:08 AM, Erik Joelsson wrote: > Hello, > > I would certainly like to have these files updated, but unfortunately the > license on these files changed from GPL2 to GPL3. This essentially means > that the switch is non trivial from a legal perspective and the impression > I've received when I last inquired about updating these files was that it's > unlikely to ever happen unless a very strong case can be presented for why > it's needed. > > So the reason we have the over engineered solution for config.guess is > simply that it's much easier than getting legal approval for updating these > files. OK, but in that case I don't see any reason for keeping this "over-engineered" solution at all. If there will not be any pulls from upstream anyway then there's no reason for keeping these file untouched. I'd propose then to just remove the wrappers and do all the chenges right in the corresponding files (of course that's not the topic of this change but should be done separately). Regards, Volker > > /Erik > > > On 2014-11-07 19:53, Andrew Haley wrote: >> >> On 11/07/2014 06:00 PM, Volker Simonis wrote: >>> >>> 3. pull in the new version of config.guess and config.sub from [1] >>> which already seem to have the changes you need. >>> >>> I'm all in favour of point three which would also allow us to get rid >>> of some of the hacks which are currently in config.guess. And now, as >>> we're still early in the jdk9 development the risk of doing this seems >>> minimal, but let's see what the build-dev guy say? >> >> So am I. build-dev people, do you want me to import config.guess from >> upstream? I can create a new issue. >> >> Andrew. >> > From erik.joelsson at oracle.com Mon Nov 10 09:42:00 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Nov 2014 10:42:00 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> Message-ID: <54608868.3010108@oracle.com> On 2014-11-10 10:27, Volker Simonis wrote: > On Mon, Nov 10, 2014 at 9:08 AM, Erik Joelsson wrote: >> Hello, >> >> I would certainly like to have these files updated, but unfortunately the >> license on these files changed from GPL2 to GPL3. This essentially means >> that the switch is non trivial from a legal perspective and the impression >> I've received when I last inquired about updating these files was that it's >> unlikely to ever happen unless a very strong case can be presented for why >> it's needed. >> >> So the reason we have the over engineered solution for config.guess is >> simply that it's much easier than getting legal approval for updating these >> files. > OK, but in that case I don't see any reason for keeping this > "over-engineered" solution at all. If there will not be any pulls from > upstream anyway then there's no reason for keeping these file > untouched. I'd propose then to just remove the wrappers and do all the > chenges right in the corresponding files (of course that's not the > topic of this change but should be done separately). And again, the reason we didn't change the existing file but instead wrapped it, was that we don't have explicit legal approval for doing derivative work for these 3rd party files. Maybe it's ok, maybe it's not, I will not be the person saying it is ok. /Erik > Regards, > Volker > >> /Erik >> >> >> On 2014-11-07 19:53, Andrew Haley wrote: >>> On 11/07/2014 06:00 PM, Volker Simonis wrote: >>>> 3. pull in the new version of config.guess and config.sub from [1] >>>> which already seem to have the changes you need. >>>> >>>> I'm all in favour of point three which would also allow us to get rid >>>> of some of the hacks which are currently in config.guess. And now, as >>>> we're still early in the jdk9 development the risk of doing this seems >>>> minimal, but let's see what the build-dev guy say? >>> So am I. build-dev people, do you want me to import config.guess from >>> upstream? I can create a new issue. >>> >>> Andrew. >>> From volker.simonis at gmail.com Mon Nov 10 10:32:35 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 10 Nov 2014 11:32:35 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <54608868.3010108@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> Message-ID: On Mon, Nov 10, 2014 at 10:42 AM, Erik Joelsson wrote: > > On 2014-11-10 10:27, Volker Simonis wrote: >> >> On Mon, Nov 10, 2014 at 9:08 AM, Erik Joelsson >> wrote: >>> >>> Hello, >>> >>> I would certainly like to have these files updated, but unfortunately the >>> license on these files changed from GPL2 to GPL3. This essentially means >>> that the switch is non trivial from a legal perspective and the >>> impression >>> I've received when I last inquired about updating these files was that >>> it's >>> unlikely to ever happen unless a very strong case can be presented for >>> why >>> it's needed. >>> >>> So the reason we have the over engineered solution for config.guess is >>> simply that it's much easier than getting legal approval for updating >>> these >>> files. >> >> OK, but in that case I don't see any reason for keeping this >> "over-engineered" solution at all. If there will not be any pulls from >> upstream anyway then there's no reason for keeping these file >> untouched. I'd propose then to just remove the wrappers and do all the >> chenges right in the corresponding files (of course that's not the >> topic of this change but should be done separately). > > And again, the reason we didn't change the existing file but instead wrapped > it, was that we don't have explicit legal approval for doing derivative work > for these 3rd party files. Maybe it's ok, maybe it's not, I will not be the > person saying it is ok. > OK, now I got it. I thought we just use the wrappers because we want to easily integrate the upstream versions. But instead it is only because we don't want to edit these files because of legal uncertainties. So in that case that means we're also not allowed to edit 'config.sub' and have to create a wrapper for it, right? Volker > /Erik > >> Regards, >> Volker >> >>> /Erik >>> >>> >>> On 2014-11-07 19:53, Andrew Haley wrote: >>>> >>>> On 11/07/2014 06:00 PM, Volker Simonis wrote: >>>>> >>>>> 3. pull in the new version of config.guess and config.sub from [1] >>>>> which already seem to have the changes you need. >>>>> >>>>> I'm all in favour of point three which would also allow us to get rid >>>>> of some of the hacks which are currently in config.guess. And now, as >>>>> we're still early in the jdk9 development the risk of doing this seems >>>>> minimal, but let's see what the build-dev guy say? >>>> >>>> So am I. build-dev people, do you want me to import config.guess from >>>> upstream? I can create a new issue. >>>> >>>> Andrew. >>>> > From pointo1d at gmail.com Mon Nov 10 17:28:53 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Mon, 10 Nov 2014 17:28:53 +0000 Subject: sizes files In-Reply-To: <544436E2.6050707@oracle.com> References: <54423C1F.2040500@oracle.com> <5442F71F.6040707@oracle.com> <544436E2.6050707@oracle.com> Message-ID: ?Hi again David , ? ?In addition to changes in the GensrcX11Wrappers.gmk, I can't see any way to get the correct output with also modifying WrapperGenerator.java?, would I be correct in this ? ?TIA & best rgds ,? -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe On 19 October 2014 23:10, David Holmes wrote: > On 20/10/2014 5:35 AM, Dave Pointon wrote: > >> Hi David , >> >> >> TFT, however I get the following compilation error when trying to build >> on s390 (31 bit) hardware ... >> >> gmake[2]: *** No rule to make target >> `/home/foreman/sandbox/jcl-bin/jdk/gensrc_x11wrappers/sizes.31', needed >> by `/home/foreman/sandbox/jcl-bin/jdk/gensrc/_the.generated.x11'. Stop. >> > > Have you created a src/solaris/classes/sun/awt/X11/generator/sizes.31 > file? The build system won't generate the initial file. You need to use the > tool to create it manually and add it to the repo. > > David H. > > ?? > > From omajid at redhat.com Mon Nov 10 17:45:37 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 10 Nov 2014 12:45:37 -0500 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: References: <545CFFA9.4070107@redhat.com> <6313454D-6690-4119-B55C-DBB356E4B3AC@oracle.com> <545D078E.2090509@redhat.com> Message-ID: <20141110174536.GA2885@redhat.com> * Christian Thalinger [2014-11-07 13:11]: > > On Nov 7, 2014, at 9:55 AM, Andrew Haley wrote: > > On 11/07/2014 05:42 PM, Christian Thalinger wrote: > >> common/autoconf/flags.m4 > >> > >> + aarch64) > >> + ZERO_ARCHFLAG="" > >> + ;; > >> > >> Why is this required on aarch64 but not all the other architectures? > > > > I think it's because GCC rejects "-m64?. > > That?s interesting. I thought -m is some kind of common > flag that works on all architectures. Can someone verify this? I had to do a similar fix for zero on arm32: http://hg.openjdk.java.net/jdk8/jdk8/rev/1dfcc874461e#l2.7 Perhaps that can be re-used here? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From david.dehaven at oracle.com Mon Nov 10 17:55:15 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 10 Nov 2014 09:55:15 -0800 Subject: Building openjdk 8 on Mac OS X In-Reply-To: References: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> <545B318F.3090805@oracle.com> Message-ID: Technically even Mavericks, but really it's Xcode 5/6... I never backported my Xcode 5 changes to 8u. It was on my list for a while but never accomplished due to lack of time. Is there interest in doing so? If so, I can try to find the time to scrape up a backport. The final webrevs for JDK9 are still on CR: http://cr.openjdk.java.net/~ddehaven/8043340/v4/ They're also pre-Jigsaw M1 which means they might be easier to backport than what's current in JDK9. -DrD- > The short answer is that building jdk8 on Yosemite is not supported. > > A longer answer is that we're currently working on getting jdk9 to compile on Yosemite. When that is successful, the patches needed might get ported to jdk8. > > If you post more extensive log extracts to build-dev, we can possibly help you find a work-around in the meantime. > > /Magnus > > 6 nov 2014 kl. 09:30 skrev David Holmes : > >> Re-directing to build-dev - please don't respond further on the discuss list. >> >> David >> >> On 6/11/2014 3:48 PM, Manas Thakur wrote: >>> I have tried building openjdk8 on mac os x yosemite by trying all means available on net. I made xcode4.6.3 as the default one; configure is fine, but I get several errors while making the hotspot images in FSEvents.h and NSUserNotification.h. >>> I tried following some suggestions regarding commenting some lines, but that doesn?t work as well. >>> >>> - Manas >>> >>> >>> >>> >>> From daniel.daugherty at oracle.com Tue Nov 11 00:00:41 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 10 Nov 2014 17:00:41 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 Message-ID: <546151A9.1080100@oracle.com> Greetings, I have a Solaris Full Debug Symbols (FDS) fix ready for review. Yes, it is a small fix, but it is in Makefiles so feel free to run screaming from the room... :-) On the plus side the fix does delete two work around source files (Coleen would say that's a Good Thing (TM)!) The fix is to detect the version of GNU objcopy that is being used on the machine and only enable Full Debug Symbols when that version is 2.21.1 or newer. If you don't have the right version, then the build drops back to pre-FDS build configs with a message like this: WARNING: /usr/sfw/bin/gobjcopy --version info: WARNING: GNU objcopy 2.15 WARNING: an objcopy version of 2.21.1 or newer is needed to create valid .debuginfo files. WARNING: ignoring above objcopy command. WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC version. WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 version. WARNING: Solaris 11 Update 1 contains the correct version. INFO: no objcopy cmd found so cannot create .debuginfo files. INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 This work is being tracked by the following bug IDs: JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC https://bugs.openjdk.java.net/browse/JDK-8033602 JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on Solaris X86 https://bugs.openjdk.java.net/browse/JDK-8034005 Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ Testing: - JPRT test jobs to verify that the current JPRT Solaris hosts are happy - local builds on my Solaris 10 X86 machine to verify that the wrong version of GNU objcopy is caught Thanks, in advance, for any comments, questions or suggestions. Dan From weijun.wang at oracle.com Tue Nov 11 02:25:46 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 11 Nov 2014 10:25:46 +0800 Subject: Building openjdk 8 on Mac OS X In-Reply-To: References: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> <545B318F.3090805@oracle.com> Message-ID: > On Nov 6, 2014, at 17:13, Magnus Ihse Bursie wrote: > > A longer answer is that we're currently working on getting jdk9 to compile on Yosemite. Isn't it already compiling? I am on Yosemite and I can compile both openjdk and closedjdk successfully. Of course, I don't compile deploy etc. --Max From dmitry.samersoff at oracle.com Tue Nov 11 08:35:40 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 11 Nov 2014 11:35:40 +0300 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <546151A9.1080100@oracle.com> References: <546151A9.1080100@oracle.com> Message-ID: <5461CA5C.30409@oracle.com> Dan, 1. defs.make: It might be better to join obcopy version check and condition at ll.190 otherwise the user will have a wrong version warning and then misleading message "no objcopy cmd found" 2. Did you consider moving objcopy detection to configure? -Dmitry On 2014-11-11 03:00, Daniel D. Daugherty wrote: > Greetings, > > I have a Solaris Full Debug Symbols (FDS) fix ready for review. > Yes, it is a small fix, but it is in Makefiles so feel free to > run screaming from the room... :-) On the plus side the fix does > delete two work around source files (Coleen would say that's a > Good Thing (TM)!) > > The fix is to detect the version of GNU objcopy that is being > used on the machine and only enable Full Debug Symbols when that > version is 2.21.1 or newer. If you don't have the right version, > then the build drops back to pre-FDS build configs with a message > like this: > > WARNING: /usr/sfw/bin/gobjcopy --version info: > WARNING: GNU objcopy 2.15 > WARNING: an objcopy version of 2.21.1 or newer is needed to create valid > .debuginfo files. > WARNING: ignoring above objcopy command. > WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC > version. > WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 > version. > WARNING: Solaris 11 Update 1 contains the correct version. > INFO: no objcopy cmd found so cannot create .debuginfo files. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 > > This work is being tracked by the following bug IDs: > > JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC > https://bugs.openjdk.java.net/browse/JDK-8033602 > > JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on > Solaris X86 > https://bugs.openjdk.java.net/browse/JDK-8034005 > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ > > Testing: > > - JPRT test jobs to verify that the current JPRT Solaris hosts > are happy > - local builds on my Solaris 10 X86 machine to verify that the > wrong version of GNU objcopy is caught > > Thanks, in advance, for any comments, questions or suggestions. > > Dan -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From daniel.daugherty at oracle.com Tue Nov 11 15:40:32 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 11 Nov 2014 08:40:32 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <5461CA5C.30409@oracle.com> References: <546151A9.1080100@oracle.com> <5461CA5C.30409@oracle.com> Message-ID: <54622DF0.5010800@oracle.com> Dmitry, Thanks for the quick review! Replies embedded below... On 11/11/14 1:35 AM, Dmitry Samersoff wrote: > Dan, > > 1. defs.make: > > It might be better to join obcopy version check and condition at ll.190 I looked at that... The seemingly natural place to put the version check is actually in the else branch on line 194... However, if the version check is bad, then you have to make a second check for a reset OBJCOPY value (along with indenting all the code another level or two). It just looked ugly... it seemed better to keep the version check separate from the other logic. > otherwise the user will have a wrong version warning and then misleading > message "no objcopy cmd found" However, part of that wrong version warning is this line: WARNING: ignoring above objcopy command. so in reality that "no objcopy cmd found" is just confirming that we are indeed ignoring the objcopy cmd that we found... > 2. Did you consider moving objcopy detection to configure? No because this fix has to be backported to JDK8u and JDK7 since we support FDS in those releases... Of course, the build-infra team is always welcome to use a new bug to evolve this code for JDK9 and newer. Again, thanks for the review! Dan > > > -Dmitry > > > On 2014-11-11 03:00, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >> Yes, it is a small fix, but it is in Makefiles so feel free to >> run screaming from the room... :-) On the plus side the fix does >> delete two work around source files (Coleen would say that's a >> Good Thing (TM)!) >> >> The fix is to detect the version of GNU objcopy that is being >> used on the machine and only enable Full Debug Symbols when that >> version is 2.21.1 or newer. If you don't have the right version, >> then the build drops back to pre-FDS build configs with a message >> like this: >> >> WARNING: /usr/sfw/bin/gobjcopy --version info: >> WARNING: GNU objcopy 2.15 >> WARNING: an objcopy version of 2.21.1 or newer is needed to create valid >> .debuginfo files. >> WARNING: ignoring above objcopy command. >> WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC >> version. >> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 >> version. >> WARNING: Solaris 11 Update 1 contains the correct version. >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >> >> This work is being tracked by the following bug IDs: >> >> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >> https://bugs.openjdk.java.net/browse/JDK-8033602 >> >> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on >> Solaris X86 >> https://bugs.openjdk.java.net/browse/JDK-8034005 >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >> >> Testing: >> >> - JPRT test jobs to verify that the current JPRT Solaris hosts >> are happy >> - local builds on my Solaris 10 X86 machine to verify that the >> wrong version of GNU objcopy is caught >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan > From dmitry.samersoff at oracle.com Tue Nov 11 16:21:36 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 11 Nov 2014 19:21:36 +0300 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <54622DF0.5010800@oracle.com> References: <546151A9.1080100@oracle.com> <5461CA5C.30409@oracle.com> <54622DF0.5010800@oracle.com> Message-ID: <54623790.4080103@oracle.com> Dan, Thank you for the explanation. The fix looks good for me. -Dmitry On 2014-11-11 18:40, Daniel D. Daugherty wrote: > Dmitry, > > Thanks for the quick review! > > Replies embedded below... > > > On 11/11/14 1:35 AM, Dmitry Samersoff wrote: >> Dan, >> >> 1. defs.make: >> >> It might be better to join obcopy version check and condition at ll.190 > > I looked at that... The seemingly natural place to put the version check > is actually in the else branch on line 194... However, if the version > check is bad, then you have to make a second check for a reset OBJCOPY > value (along with indenting all the code another level or two). > > It just looked ugly... it seemed better to keep the version check > separate from the other logic. > > >> otherwise the user will have a wrong version warning and then misleading >> message "no objcopy cmd found" > > However, part of that wrong version warning is this line: > > WARNING: ignoring above objcopy command. > > so in reality that "no objcopy cmd found" is just confirming > that we are indeed ignoring the objcopy cmd that we found... > > >> 2. Did you consider moving objcopy detection to configure? > > No because this fix has to be backported to JDK8u and JDK7 since > we support FDS in those releases... > > Of course, the build-infra team is always welcome to use a new > bug to evolve this code for JDK9 and newer. > > Again, thanks for the review! > > Dan > > >> >> >> -Dmitry >> >> >> On 2014-11-11 03:00, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>> Yes, it is a small fix, but it is in Makefiles so feel free to >>> run screaming from the room... :-) On the plus side the fix does >>> delete two work around source files (Coleen would say that's a >>> Good Thing (TM)!) >>> >>> The fix is to detect the version of GNU objcopy that is being >>> used on the machine and only enable Full Debug Symbols when that >>> version is 2.21.1 or newer. If you don't have the right version, >>> then the build drops back to pre-FDS build configs with a message >>> like this: >>> >>> WARNING: /usr/sfw/bin/gobjcopy --version info: >>> WARNING: GNU objcopy 2.15 >>> WARNING: an objcopy version of 2.21.1 or newer is needed to create valid >>> .debuginfo files. >>> WARNING: ignoring above objcopy command. >>> WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC >>> version. >>> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 >>> version. >>> WARNING: Solaris 11 Update 1 contains the correct version. >>> INFO: no objcopy cmd found so cannot create .debuginfo files. >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >>> >>> This work is being tracked by the following bug IDs: >>> >>> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >>> https://bugs.openjdk.java.net/browse/JDK-8033602 >>> >>> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on >>> Solaris X86 >>> https://bugs.openjdk.java.net/browse/JDK-8034005 >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >>> >>> Testing: >>> >>> - JPRT test jobs to verify that the current JPRT Solaris hosts >>> are happy >>> - local builds on my Solaris 10 X86 machine to verify that the >>> wrong version of GNU objcopy is caught >>> >>> Thanks, in advance, for any comments, questions or suggestions. >>> >>> Dan >> > -- 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 david.dehaven at oracle.com Tue Nov 11 16:45:46 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 11 Nov 2014 08:45:46 -0800 Subject: Building openjdk 8 on Mac OS X In-Reply-To: References: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> <545B318F.3090805@oracle.com> Message-ID: >> A longer answer is that we're currently working on getting jdk9 to compile on Yosemite. > > Isn't it already compiling? I am on Yosemite and I can compile both openjdk and closedjdk successfully. Yes, I can compile the whole mess on Yosemite/Xcode 6.1. There was an issue with FreeType when building OpenJDK, but it looks like that's been resolved now. -DrD- From daniel.daugherty at oracle.com Tue Nov 11 17:25:42 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 11 Nov 2014 10:25:42 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <54623790.4080103@oracle.com> References: <546151A9.1080100@oracle.com> <5461CA5C.30409@oracle.com> <54622DF0.5010800@oracle.com> <54623790.4080103@oracle.com> Message-ID: <54624696.2090201@oracle.com> Thanks for closing the loop on this! Dan On 11/11/14 9:21 AM, Dmitry Samersoff wrote: > Dan, > > Thank you for the explanation. > > The fix looks good for me. > > -Dmitry > > On 2014-11-11 18:40, Daniel D. Daugherty wrote: >> Dmitry, >> >> Thanks for the quick review! >> >> Replies embedded below... >> >> >> On 11/11/14 1:35 AM, Dmitry Samersoff wrote: >>> Dan, >>> >>> 1. defs.make: >>> >>> It might be better to join obcopy version check and condition at ll.190 >> I looked at that... The seemingly natural place to put the version check >> is actually in the else branch on line 194... However, if the version >> check is bad, then you have to make a second check for a reset OBJCOPY >> value (along with indenting all the code another level or two). >> >> It just looked ugly... it seemed better to keep the version check >> separate from the other logic. >> >> >>> otherwise the user will have a wrong version warning and then misleading >>> message "no objcopy cmd found" >> However, part of that wrong version warning is this line: >> >> WARNING: ignoring above objcopy command. >> >> so in reality that "no objcopy cmd found" is just confirming >> that we are indeed ignoring the objcopy cmd that we found... >> >> >>> 2. Did you consider moving objcopy detection to configure? >> No because this fix has to be backported to JDK8u and JDK7 since >> we support FDS in those releases... >> >> Of course, the build-infra team is always welcome to use a new >> bug to evolve this code for JDK9 and newer. >> >> Again, thanks for the review! >> >> Dan >> >> >>> >>> -Dmitry >>> >>> >>> On 2014-11-11 03:00, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>>> Yes, it is a small fix, but it is in Makefiles so feel free to >>>> run screaming from the room... :-) On the plus side the fix does >>>> delete two work around source files (Coleen would say that's a >>>> Good Thing (TM)!) >>>> >>>> The fix is to detect the version of GNU objcopy that is being >>>> used on the machine and only enable Full Debug Symbols when that >>>> version is 2.21.1 or newer. If you don't have the right version, >>>> then the build drops back to pre-FDS build configs with a message >>>> like this: >>>> >>>> WARNING: /usr/sfw/bin/gobjcopy --version info: >>>> WARNING: GNU objcopy 2.15 >>>> WARNING: an objcopy version of 2.21.1 or newer is needed to create valid >>>> .debuginfo files. >>>> WARNING: ignoring above objcopy command. >>>> WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC >>>> version. >>>> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 >>>> version. >>>> WARNING: Solaris 11 Update 1 contains the correct version. >>>> INFO: no objcopy cmd found so cannot create .debuginfo files. >>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >>>> >>>> This work is being tracked by the following bug IDs: >>>> >>>> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >>>> https://bugs.openjdk.java.net/browse/JDK-8033602 >>>> >>>> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on >>>> Solaris X86 >>>> https://bugs.openjdk.java.net/browse/JDK-8034005 >>>> >>>> Here is the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >>>> >>>> Testing: >>>> >>>> - JPRT test jobs to verify that the current JPRT Solaris hosts >>>> are happy >>>> - local builds on my Solaris 10 X86 machine to verify that the >>>> wrong version of GNU objcopy is caught >>>> >>>> Thanks, in advance, for any comments, questions or suggestions. >>>> >>>> Dan > From serguei.spitsyn at oracle.com Tue Nov 11 22:04:29 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 11 Nov 2014 14:04:29 -0800 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <546151A9.1080100@oracle.com> References: <546151A9.1080100@oracle.com> Message-ID: <546287ED.9050708@oracle.com> Dan, The fix looks good. Nice cleanup from workarounds: Good Thing (TM)! :) Thanks, Serguei On 11/10/14 4:00 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a Solaris Full Debug Symbols (FDS) fix ready for review. > Yes, it is a small fix, but it is in Makefiles so feel free to > run screaming from the room... :-) On the plus side the fix does > delete two work around source files (Coleen would say that's a > Good Thing (TM)!) > > The fix is to detect the version of GNU objcopy that is being > used on the machine and only enable Full Debug Symbols when that > version is 2.21.1 or newer. If you don't have the right version, > then the build drops back to pre-FDS build configs with a message > like this: > > WARNING: /usr/sfw/bin/gobjcopy --version info: > WARNING: GNU objcopy 2.15 > WARNING: an objcopy version of 2.21.1 or newer is needed to create > valid .debuginfo files. > WARNING: ignoring above objcopy command. > WARNING: patch 149063-01 or newer contains the correct Solaris 10 > SPARC version. > WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 > version. > WARNING: Solaris 11 Update 1 contains the correct version. > INFO: no objcopy cmd found so cannot create .debuginfo files. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 > > This work is being tracked by the following bug IDs: > > JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC > https://bugs.openjdk.java.net/browse/JDK-8033602 > > JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on > Solaris X86 > https://bugs.openjdk.java.net/browse/JDK-8034005 > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ > > Testing: > > - JPRT test jobs to verify that the current JPRT Solaris hosts > are happy > - local builds on my Solaris 10 X86 machine to verify that the > wrong version of GNU objcopy is caught > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From daniel.daugherty at oracle.com Tue Nov 11 23:31:42 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 11 Nov 2014 16:31:42 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <546287ED.9050708@oracle.com> References: <546151A9.1080100@oracle.com> <546287ED.9050708@oracle.com> Message-ID: <54629C5E.8080305@oracle.com> Thanks for the review! On 11/11/14 3:04 PM, serguei.spitsyn at oracle.com wrote: > Dan, > > The fix looks good. Thanks! > Nice cleanup from workarounds: Good Thing (TM)! :) Yes, this has been in the queue for quite a while... :-) Dan > > Thanks, > Serguei > > On 11/10/14 4:00 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >> Yes, it is a small fix, but it is in Makefiles so feel free to >> run screaming from the room... :-) On the plus side the fix does >> delete two work around source files (Coleen would say that's a >> Good Thing (TM)!) >> >> The fix is to detect the version of GNU objcopy that is being >> used on the machine and only enable Full Debug Symbols when that >> version is 2.21.1 or newer. If you don't have the right version, >> then the build drops back to pre-FDS build configs with a message >> like this: >> >> WARNING: /usr/sfw/bin/gobjcopy --version info: >> WARNING: GNU objcopy 2.15 >> WARNING: an objcopy version of 2.21.1 or newer is needed to create >> valid .debuginfo files. >> WARNING: ignoring above objcopy command. >> WARNING: patch 149063-01 or newer contains the correct Solaris 10 >> SPARC version. >> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 >> version. >> WARNING: Solaris 11 Update 1 contains the correct version. >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >> >> This work is being tracked by the following bug IDs: >> >> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >> https://bugs.openjdk.java.net/browse/JDK-8033602 >> >> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on >> Solaris X86 >> https://bugs.openjdk.java.net/browse/JDK-8034005 >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >> >> Testing: >> >> - JPRT test jobs to verify that the current JPRT Solaris hosts >> are happy >> - local builds on my Solaris 10 X86 machine to verify that the >> wrong version of GNU objcopy is caught >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan > From manasthakur17 at gmail.com Wed Nov 12 04:13:07 2014 From: manasthakur17 at gmail.com (Manas Thakur) Date: Wed, 12 Nov 2014 09:43:07 +0530 Subject: Building openjdk 8 on Mac OS X In-Reply-To: References: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> <545B318F.3090805@oracle.com> Message-ID: Hi Wang You were able to compile openjdk8 on Yosemite!! Can you please look into the error faced by me (first post in the thread; posted below as well) and figure out the problem(s)? Regards, Manas > Yes, I can compile the whole mess on Yosemite/Xcode 6.1. There was an issue with FreeType when building OpenJDK, but it looks like that's been resolved now. > > -DrD- > Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp Making signal interposition lib... couldn't understand kern.osversion `14.0.0' warning: (x86_64) /var/folders/16/5m_yzyd961b3l31crzg2hsl40000gp/T//ccEmbC6U.o unable to open object file warning: no debug symbols in executable (-arch x86_64) Making SA debugger back-end... couldn't understand kern.osversion `14.0.0' In file included from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:55, from /System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12, from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:80, from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:262: error: expected ?,? or ?}? before ?__attribute__? /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:414: error: expected ?,? or ?}? before ?__attribute__? In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:119, from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: /System/Library/Frameworks/Foundation.framework/Headers/NSUserActivity.h:55: error: expected a property attribute before ?weak? Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/runtime/vm_version.cpp In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:171, from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error: expected ?,? or ?}? before ?__attribute__? make[8]: *** [libsaproc.dylib] Error 1 make[8]: *** Waiting for unfinished jobs.... make[7]: *** [the_vm] Error 2 make[6]: *** [product] Error 2 make[5]: *** [generic_build2] Error 2 make[4]: *** [product] Error 2 make[3]: *** [all_product_universal] Error 2 make[2]: *** [universal_product] Error 2 make[1]: *** [/Users/manas/Desktop/Software/openjdk/sources/openjdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 make: *** [hotspot-only] Error 2 From weijun.wang at oracle.com Wed Nov 12 05:03:13 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 12 Nov 2014 13:03:13 +0800 Subject: Building openjdk 8 on Mac OS X In-Reply-To: References: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> <545B318F.3090805@oracle.com> Message-ID: <9A2E873A-8B09-4E56-BA0E-40B77CA60D0D@oracle.com> No, I am able to build jdk9, but NOT jdk8. It seems the SDK (those .h files) no longer works with gcc in xcode4. --Max > On Nov 12, 2014, at 12:13, Manas Thakur wrote: > > Hi Wang > > You were able to compile openjdk8 on Yosemite!! Can you please look into the error faced by me (first post in the thread; posted below as well) and figure out the problem(s)? > > Regards, > Manas > > > >> Yes, I can compile the whole mess on Yosemite/Xcode 6.1. There was an issue with FreeType when building OpenJDK, but it looks like that's been resolved now. >> >> -DrD- >> > > Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp > Making signal interposition lib... > couldn't understand kern.osversion `14.0.0' > warning: (x86_64) /var/folders/16/5m_yzyd961b3l31crzg2hsl40000gp/T//ccEmbC6U.o unable to open object file > warning: no debug symbols in executable (-arch x86_64) > Making SA debugger back-end... > couldn't understand kern.osversion `14.0.0' > In file included from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:55, > from /System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12, > from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:80, > from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: > /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:262: error: expected ?,? or ?}? before ?__attribute__? > /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:414: error: expected ?,? or ?}? before ?__attribute__? > In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:119, > from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: > /System/Library/Frameworks/Foundation.framework/Headers/NSUserActivity.h:55: error: expected a property attribute before ?weak? > Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/runtime/vm_version.cpp > In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:171, > from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: > /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error: expected ?,? or ?}? before ?__attribute__? > make[8]: *** [libsaproc.dylib] Error 1 > make[8]: *** Waiting for unfinished jobs.... > make[7]: *** [the_vm] Error 2 > make[6]: *** [product] Error 2 > make[5]: *** [generic_build2] Error 2 > make[4]: *** [product] Error 2 > make[3]: *** [all_product_universal] Error 2 > make[2]: *** [universal_product] Error 2 > make[1]: *** [/Users/manas/Desktop/Software/openjdk/sources/openjdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 > make: *** [hotspot-only] Error 2 > From manasthakur17 at gmail.com Wed Nov 12 05:06:59 2014 From: manasthakur17 at gmail.com (Manas Thakur) Date: Wed, 12 Nov 2014 10:36:59 +0530 Subject: Building openjdk 8 on Mac OS X In-Reply-To: <9A2E873A-8B09-4E56-BA0E-40B77CA60D0D@oracle.com> References: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> <545B318F.3090805@oracle.com> <9A2E873A-8B09-4E56-BA0E-40B77CA60D0D@oracle.com> Message-ID: Okay, thanks. Regards, Manas > On 12-Nov-2014, at 10:33 am, Wang Weijun wrote: > > No, I am able to build jdk9, but NOT jdk8. It seems the SDK (those .h files) no longer works with gcc in xcode4. > > --Max > >> On Nov 12, 2014, at 12:13, Manas Thakur wrote: >> >> Hi Wang >> >> You were able to compile openjdk8 on Yosemite!! Can you please look into the error faced by me (first post in the thread; posted below as well) and figure out the problem(s)? >> >> Regards, >> Manas >> >> >> >>> Yes, I can compile the whole mess on Yosemite/Xcode 6.1. There was an issue with FreeType when building OpenJDK, but it looks like that's been resolved now. >>> >>> -DrD- >>> >> >> Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp >> Making signal interposition lib... >> couldn't understand kern.osversion `14.0.0' >> warning: (x86_64) /var/folders/16/5m_yzyd961b3l31crzg2hsl40000gp/T//ccEmbC6U.o unable to open object file >> warning: no debug symbols in executable (-arch x86_64) >> Making SA debugger back-end... >> couldn't understand kern.osversion `14.0.0' >> In file included from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:55, >> from /System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12, >> from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:80, >> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >> /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:262: error: expected ?,? or ?}? before ?__attribute__? >> /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:414: error: expected ?,? or ?}? before ?__attribute__? >> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:119, >> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >> /System/Library/Frameworks/Foundation.framework/Headers/NSUserActivity.h:55: error: expected a property attribute before ?weak? >> Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/runtime/vm_version.cpp >> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:171, >> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >> /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error: expected ?,? or ?}? before ?__attribute__? >> make[8]: *** [libsaproc.dylib] Error 1 >> make[8]: *** Waiting for unfinished jobs.... >> make[7]: *** [the_vm] Error 2 >> make[6]: *** [product] Error 2 >> make[5]: *** [generic_build2] Error 2 >> make[4]: *** [product] Error 2 >> make[3]: *** [all_product_universal] Error 2 >> make[2]: *** [universal_product] Error 2 >> make[1]: *** [/Users/manas/Desktop/Software/openjdk/sources/openjdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 >> make: *** [hotspot-only] Error 2 >> > From david.holmes at oracle.com Wed Nov 12 09:11:56 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Nov 2014 19:11:56 +1000 Subject: sizes files In-Reply-To: References: <54423C1F.2040500@oracle.com> <5442F71F.6040707@oracle.com> <544436E2.6050707@oracle.com> Message-ID: <5463245C.4090006@oracle.com> Hi Dave, On 11/11/2014 3:28 AM, Dave Pointon wrote: > ?Hi again David , > ? > ?In addition to changes in the GensrcX11Wrappers.gmk, I can't see any > way to get the correct output with also modifying WrapperGenerator.java? > , would I be correct in this ? Certainly looks that way I'm afraid - only 32 and 64 and known bit sizes. David > ?TIA & best rgds ,? > > -- > Dave Pointon FIAP MBCS > > Now I saw, tho' too late, the folly of beginning a work before we count > the cost and before we we judge rightly of our strength to go thro' with > it - Robinson Crusoe > > On 19 October 2014 23:10, David Holmes > wrote: > > On 20/10/2014 5:35 AM, Dave Pointon wrote: > > Hi David , > > > TFT, however I get the following compilation error when trying > to build > on s390 (31 bit) hardware ... > > gmake[2]: *** No rule to make target > `/home/foreman/sandbox/jcl-__bin/jdk/gensrc_x11wrappers/__sizes.31', > needed > by > `/home/foreman/sandbox/jcl-__bin/jdk/gensrc/_the.generated.__x11'. > Stop. > > > Have you created a > src/solaris/classes/sun/awt/__X11/generator/sizes.31 file? The build > system won't generate the initial file. You need to use the tool to > create it manually and add it to the repo. > > David H. > > ?? > > From pointo1d at gmail.com Wed Nov 12 10:20:02 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Wed, 12 Nov 2014 10:20:02 +0000 Subject: sizes files In-Reply-To: <5463245C.4090006@oracle.com> References: <54423C1F.2040500@oracle.com> <5442F71F.6040707@oracle.com> <544436E2.6050707@oracle.com> <5463245C.4090006@oracle.com> Message-ID: TFT David -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe On 12 November 2014 09:11, David Holmes wrote: > Hi Dave, > > On 11/11/2014 3:28 AM, Dave Pointon wrote: > >> ?Hi again David , >> ? >> ?In addition to changes in the GensrcX11Wrappers.gmk, I can't see any >> way to get the correct output with also modifying WrapperGenerator.java? >> , would I be correct in this ? >> > > Certainly looks that way I'm afraid - only 32 and 64 and known bit sizes. > > David > > ?? From david.dehaven at oracle.com Wed Nov 12 17:29:46 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 12 Nov 2014 09:29:46 -0800 Subject: Building openjdk 8 on Mac OS X In-Reply-To: References: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> <545B318F.3090805@oracle.com> Message-ID: <5F78A0ED-DCE6-410D-9471-0732784DCD56@oracle.com> Not 8, 9... -DrD- > Hi Wang > > You were able to compile openjdk8 on Yosemite!! Can you please look into the error faced by me (first post in the thread; posted below as well) and figure out the problem(s)? > > Regards, > Manas > > > >> Yes, I can compile the whole mess on Yosemite/Xcode 6.1. There was an issue with FreeType when building OpenJDK, but it looks like that's been resolved now. >> >> -DrD- >> > > Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp > Making signal interposition lib... > couldn't understand kern.osversion `14.0.0' > warning: (x86_64) /var/folders/16/5m_yzyd961b3l31crzg2hsl40000gp/T//ccEmbC6U.o unable to open object file > warning: no debug symbols in executable (-arch x86_64) > Making SA debugger back-end... > couldn't understand kern.osversion `14.0.0' > In file included from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:55, > from /System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12, > from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:80, > from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: > /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:262: error: expected ?,? or ?}? before ?__attribute__? > /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:414: error: expected ?,? or ?}? before ?__attribute__? > In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:119, > from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: > /System/Library/Frameworks/Foundation.framework/Headers/NSUserActivity.h:55: error: expected a property attribute before ?weak? > Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/runtime/vm_version.cpp > In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:171, > from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: > /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error: expected ?,? or ?}? before ?__attribute__? > make[8]: *** [libsaproc.dylib] Error 1 > make[8]: *** Waiting for unfinished jobs.... > make[7]: *** [the_vm] Error 2 > make[6]: *** [product] Error 2 > make[5]: *** [generic_build2] Error 2 > make[4]: *** [product] Error 2 > make[3]: *** [all_product_universal] Error 2 > make[2]: *** [universal_product] Error 2 > make[1]: *** [/Users/manas/Desktop/Software/openjdk/sources/openjdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 > make: *** [hotspot-only] Error 2 > From patrick at reini.net Wed Nov 12 18:34:19 2014 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 12 Nov 2014 19:34:19 +0100 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> Message-ID: <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> Hi there, I?m updating the Adopt OpenJDK website with build instructions to build the OpenJDK on Windows 8.1. In order to lower the effort of building also the OpenJDK 8 on Windows, myself and some colleges have back ported the build scripts from OpenJDK 9. We also could provide a webrev containing all changes we made. Could someone sponsor this back port? Best regards Patrick From vladimir.kozlov at oracle.com Thu Nov 13 00:14:05 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Nov 2014 16:14:05 -0800 Subject: RFR: AARCH64: 8064594: Top-level JDK changes In-Reply-To: References: Message-ID: <5463F7CD.5080002@oracle.com> Oh. I just replied to the wrong email. Anyway, here it goes again: Maybe we should CC sound-dev (if that?s the correct list)? The new jvm.cfg files should only have a copyright year of 2014. Otherwise this looks good. > On Nov 12, 2014, at 3:48 AM, Andrew Haley wrote: > > The changes for the /jdk subdirectory. > > The missing files problem bit me again. > > New webrev: http://cr.openjdk.java.net/~aph/aarch64-JDK-8064594-1/ > > Apologies, > Andrew. From weijun.wang at oracle.com Thu Nov 13 01:22:11 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 13 Nov 2014 09:22:11 +0800 Subject: visual-studio-community? Message-ID: <6DD8D988-618C-48A4-8CC8-FA4F9F52B3F6@oracle.com> I just read http://www.visualstudio.com/products/visual-studio-community-vs, which has > Here?s how Visual Studio Community can be used in organizations: > ? An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: in a classroom learning environment, for academic research, or for contributing to open source projects. OpenJDK is an open source project, so, we should support it? --Max From david.holmes at oracle.com Thu Nov 13 03:10:34 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Nov 2014 13:10:34 +1000 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <546151A9.1080100@oracle.com> References: <546151A9.1080100@oracle.com> Message-ID: <5464212A.6070504@oracle.com> Hi Dan, If you still need a Reviewer, looks okay to me. Thanks, David On 11/11/2014 10:00 AM, Daniel D. Daugherty wrote: > Greetings, > > I have a Solaris Full Debug Symbols (FDS) fix ready for review. > Yes, it is a small fix, but it is in Makefiles so feel free to > run screaming from the room... :-) On the plus side the fix does > delete two work around source files (Coleen would say that's a > Good Thing (TM)!) > > The fix is to detect the version of GNU objcopy that is being > used on the machine and only enable Full Debug Symbols when that > version is 2.21.1 or newer. If you don't have the right version, > then the build drops back to pre-FDS build configs with a message > like this: > > WARNING: /usr/sfw/bin/gobjcopy --version info: > WARNING: GNU objcopy 2.15 > WARNING: an objcopy version of 2.21.1 or newer is needed to create valid > .debuginfo files. > WARNING: ignoring above objcopy command. > WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC > version. > WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 > version. > WARNING: Solaris 11 Update 1 contains the correct version. > INFO: no objcopy cmd found so cannot create .debuginfo files. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 > > This work is being tracked by the following bug IDs: > > JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC > https://bugs.openjdk.java.net/browse/JDK-8033602 > > JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on > Solaris X86 > https://bugs.openjdk.java.net/browse/JDK-8034005 > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ > > Testing: > > - JPRT test jobs to verify that the current JPRT Solaris hosts > are happy > - local builds on my Solaris 10 X86 machine to verify that the > wrong version of GNU objcopy is caught > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From daniel.daugherty at oracle.com Thu Nov 13 03:54:31 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Nov 2014 20:54:31 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <5464212A.6070504@oracle.com> References: <546151A9.1080100@oracle.com> <5464212A.6070504@oracle.com> Message-ID: <54642B77.3030607@oracle.com> Thanks! I was still in need of a (R)eviewer and a Runtime team member so thanks for covering both... Dan On 11/12/14 8:10 PM, David Holmes wrote: > Hi Dan, > > If you still need a Reviewer, looks okay to me. > > Thanks, > David > > On 11/11/2014 10:00 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >> Yes, it is a small fix, but it is in Makefiles so feel free to >> run screaming from the room... :-) On the plus side the fix does >> delete two work around source files (Coleen would say that's a >> Good Thing (TM)!) >> >> The fix is to detect the version of GNU objcopy that is being >> used on the machine and only enable Full Debug Symbols when that >> version is 2.21.1 or newer. If you don't have the right version, >> then the build drops back to pre-FDS build configs with a message >> like this: >> >> WARNING: /usr/sfw/bin/gobjcopy --version info: >> WARNING: GNU objcopy 2.15 >> WARNING: an objcopy version of 2.21.1 or newer is needed to create valid >> .debuginfo files. >> WARNING: ignoring above objcopy command. >> WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC >> version. >> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 >> version. >> WARNING: Solaris 11 Update 1 contains the correct version. >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >> >> This work is being tracked by the following bug IDs: >> >> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >> https://bugs.openjdk.java.net/browse/JDK-8033602 >> >> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on >> Solaris X86 >> https://bugs.openjdk.java.net/browse/JDK-8034005 >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >> >> Testing: >> >> - JPRT test jobs to verify that the current JPRT Solaris hosts >> are happy >> - local builds on my Solaris 10 X86 machine to verify that the >> wrong version of GNU objcopy is caught >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan From magnus.ihse.bursie at oracle.com Thu Nov 13 13:48:44 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Nov 2014 14:48:44 +0100 Subject: visual-studio-community? In-Reply-To: <6DD8D988-618C-48A4-8CC8-FA4F9F52B3F6@oracle.com> References: <6DD8D988-618C-48A4-8CC8-FA4F9F52B3F6@oracle.com> Message-ID: <5464B6BC.1020308@oracle.com> On 2014-11-13 02:22, Wang Weijun wrote: > I just read http://www.visualstudio.com/products/visual-studio-community-vs, which has > >> Here?s how Visual Studio Community can be used in organizations: >> ? An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: in a classroom learning environment, for academic research, or for contributing to open source projects. > OpenJDK is an open source project, so, we should support it? It sounds like a good idea for the community to support. If it is possible to use for building OpenJDK, I'll happily sponsor patches needed. My guess is that the Visual Studio detection code in common/autoconf needs updating to locate the tools. /Magnus From magnus.ihse.bursie at oracle.com Thu Nov 13 13:50:33 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Nov 2014 14:50:33 +0100 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched In-Reply-To: <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> Message-ID: <5464B729.9090101@oracle.com> On 2014-11-12 19:34, Patrick Reinhart wrote: > Hi there, > > I?m updating the Adopt OpenJDK website with build instructions to build the OpenJDK on Windows 8.1. In order to lower the effort of building also the OpenJDK 8 on Windows, myself and some colleges have back ported the build scripts from OpenJDK 9. We also could provide a webrev containing all changes we made. > > Could someone sponsor this back port? Sure, I can sponsor that! Is the patch straightforward to apply on jdk9 from jdk8? /Magnus From magnus.ihse.bursie at oracle.com Thu Nov 13 14:03:00 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Nov 2014 15:03:00 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <20141110174536.GA2885@redhat.com> References: <545CFFA9.4070107@redhat.com> <6313454D-6690-4119-B55C-DBB356E4B3AC@oracle.com> <545D078E.2090509@redhat.com> <20141110174536.GA2885@redhat.com> Message-ID: <5464BA14.40306@oracle.com> On 2014-11-10 18:45, Omair Majid wrote: > * Christian Thalinger [2014-11-07 13:11]: >>> On Nov 7, 2014, at 9:55 AM, Andrew Haley wrote: >>> On 11/07/2014 05:42 PM, Christian Thalinger wrote: >>>> common/autoconf/flags.m4 >>>> >>>> + aarch64) >>>> + ZERO_ARCHFLAG="" >>>> + ;; >>>> >>>> Why is this required on aarch64 but not all the other architectures? >>> I think it's because GCC rejects "-m64?. >> That?s interesting. I thought -m is some kind of common >> flag that works on all architectures. Can someone verify this? > I had to do a similar fix for zero on arm32: > http://hg.openjdk.java.net/jdk8/jdk8/rev/1dfcc874461e#l2.7 > > Perhaps that can be re-used here? That's a good point. $COMPILER_TARGET_BITS_FLAG is used in several places. All of them ought to be guarded by tests on $COMPILER_SUPPORTS_TARGET_BITS_FLAG, but I don't think they are. But this sounds like such a situation -- what we should be testing for is not so much the platform as if $COMPILER_TARGET_BITS_FLAG is supported. /Magnus From magnus.ihse.bursie at oracle.com Thu Nov 13 14:09:45 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Nov 2014 15:09:45 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> Message-ID: <5464BBA9.1000809@oracle.com> On 2014-11-10 11:32, Volker Simonis wrote: > On Mon, Nov 10, 2014 at 10:42 AM, Erik Joelsson > wrote: >> On 2014-11-10 10:27, Volker Simonis wrote: >>> On Mon, Nov 10, 2014 at 9:08 AM, Erik Joelsson >>> wrote: >>>> Hello, >>>> >>>> I would certainly like to have these files updated, but unfortunately the >>>> license on these files changed from GPL2 to GPL3. This essentially means >>>> that the switch is non trivial from a legal perspective and the >>>> impression >>>> I've received when I last inquired about updating these files was that >>>> it's >>>> unlikely to ever happen unless a very strong case can be presented for >>>> why >>>> it's needed. >>>> >>>> So the reason we have the over engineered solution for config.guess is >>>> simply that it's much easier than getting legal approval for updating >>>> these >>>> files. >>> OK, but in that case I don't see any reason for keeping this >>> "over-engineered" solution at all. If there will not be any pulls from >>> upstream anyway then there's no reason for keeping these file >>> untouched. I'd propose then to just remove the wrappers and do all the >>> chenges right in the corresponding files (of course that's not the >>> topic of this change but should be done separately). >> And again, the reason we didn't change the existing file but instead wrapped >> it, was that we don't have explicit legal approval for doing derivative work >> for these 3rd party files. Maybe it's ok, maybe it's not, I will not be the >> person saying it is ok. >> > OK, now I got it. I thought we just use the wrappers because we want > to easily integrate the upstream versions. But instead it is only > because we don't want to edit these files because of legal > uncertainties. > > So in that case that means we're also not allowed to edit 'config.sub' > and have to create a wrapper for it, right? Yes, you are correct. We cannot modify these files. As far as I understand, the legal reason for including these files are the explicit exception: # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. But this is just a distribution license, not a modification license. From my IANAL point of view, this exception should be enough to disregard if the file is also distributed under GPL2 or GPL3. Unfortunately, as Erik says, our lawyers are apprehensive of GLP3. So while we thought that we could be able to periodically sync these files with upstream (and remove our external "patches" after a while), we have not been able to do so. So, this fix will need to do the same dance with config.sub as for guess.guess. Unfortunately. :( /Magnus From magnus.ihse.bursie at oracle.com Thu Nov 13 14:12:28 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Nov 2014 15:12:28 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <545D0290.5080307@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> Message-ID: <5464BC4C.3050705@oracle.com> On 2014-11-07 18:34, Vladimir Kozlov wrote: > CCing to build-dev and JDK9-dev since it is top level changes. > > Note, it will go into staging aarch64 repo. > > Vladimir > > On 11/7/14 9:21 AM, Andrew Haley wrote: >> The first patch: top-level build machinery changes. >> >> http://cr.openjdk.java.net/~aph/8064357-rev-1/ >> >> Andrew. >> I have a question about the changes in platform.m4. I was a bit surprised to see that VAR_CPU_ARCH is set to "aarch64" and not "arm". The meaning of the CPU_ARCH variable is supposed to cover platforms with similar architecture, regardless of address size. But maybe I'm just too unfamiliar with aarch64, and it is not a trivial 64-bit extension of arm, but more like a separate platform? /Magnus From patrick at reini.net Thu Nov 13 14:15:27 2014 From: patrick at reini.net (Patrick Reinhart) Date: Thu, 13 Nov 2014 15:15:27 +0100 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched In-Reply-To: <5464B729.9090101@oracle.com> References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> <5464B729.9090101@oracle.com> Message-ID: <331C0A42-4ECF-4FC0-8D3E-287BA7EDC50F@reini.net> Hi Magnus, I actually merged down the freetype compilation from the source during the configuration cycle as it?s being done in JDK9 actually. This was not that straightforward but I could sort that out and had a successful compilation afterwards. Here is the link to the webrev: http://reinharts.dyndns.org/buildjdk8win/webrev/ Cheers Patrick > Am 13.11.2014 um 14:50 schrieb Magnus Ihse Bursie : > > On 2014-11-12 19:34, Patrick Reinhart wrote: >> Hi there, >> >> I?m updating the Adopt OpenJDK website with build instructions to build the OpenJDK on Windows 8.1. In order to lower the effort of building also the OpenJDK 8 on Windows, myself and some colleges have back ported the build scripts from OpenJDK 9. We also could provide a webrev containing all changes we made. >> >> Could someone sponsor this back port? > > Sure, I can sponsor that! > > Is the patch straightforward to apply on jdk9 from jdk8? > > /Magnus From aph at redhat.com Thu Nov 13 14:28:10 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 Nov 2014 14:28:10 +0000 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <5464BBA9.1000809@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> Message-ID: <5464BFFA.7050205@redhat.com> On 11/13/2014 02:09 PM, Magnus Ihse Bursie wrote: > From my IANAL point of view, this exception should be enough to > disregard if the file is also distributed under GPL2 or GPL3. > Unfortunately, as Erik says, our lawyers are apprehensive of GLP3. So > while we thought that we could be able to periodically sync these files > with upstream (and remove our external "patches" after a while), we have > not been able to do so. > > So, this fix will need to do the same dance with config.sub as for > guess.guess. Unfortunately. :( Fair enough. If I knew what you wanted me to do, I'd do it. Andrew. From aph at redhat.com Thu Nov 13 14:29:51 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 Nov 2014 14:29:51 +0000 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <5464BC4C.3050705@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <5464BC4C.3050705@oracle.com> Message-ID: <5464C05F.2000706@redhat.com> On 11/13/2014 02:12 PM, Magnus Ihse Bursie wrote: > I was a bit surprised to see that VAR_CPU_ARCH is set to "aarch64" and > not "arm". The meaning of the CPU_ARCH variable is supposed to cover > platforms with similar architecture, regardless of address size. But > maybe I'm just too unfamiliar with aarch64, and it is not a trivial > 64-bit extension of arm, but more like a separate platform? It is a completely new architecture. Almost the only thing it has in common with ARM is that it's from the same company. It is possible to run an AArch64 CPU in ARM mode, but there is no interworking. Andrew. From magnus.ihse.bursie at oracle.com Thu Nov 13 14:44:54 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Nov 2014 15:44:54 +0100 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <546151A9.1080100@oracle.com> References: <546151A9.1080100@oracle.com> Message-ID: <5464C3E6.5000309@oracle.com> On 2014-11-11 01:00, Daniel D. Daugherty wrote: > Greetings, > > I have a Solaris Full Debug Symbols (FDS) fix ready for review. > Yes, it is a small fix, but it is in Makefiles so feel free to > run screaming from the room... :-) On the plus side the fix does > delete two work around source files (Coleen would say that's a > Good Thing (TM)!) ... but you're only deleting the make files? src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c could be deleted as well, right? Good idea for the fix, anyway. I opened https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a similar solution in configure. /Magnus From magnus.ihse.bursie at oracle.com Thu Nov 13 15:00:48 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Nov 2014 16:00:48 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <5464BFFA.7050205@redhat.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> Message-ID: <5464C7A0.4080304@oracle.com> On 2014-11-13 15:28, Andrew Haley wrote: > On 11/13/2014 02:09 PM, Magnus Ihse Bursie wrote: >> From my IANAL point of view, this exception should be enough to >> disregard if the file is also distributed under GPL2 or GPL3. >> Unfortunately, as Erik says, our lawyers are apprehensive of GLP3. So >> while we thought that we could be able to periodically sync these files >> with upstream (and remove our external "patches" after a while), we have >> not been able to do so. >> >> So, this fix will need to do the same dance with config.sub as for >> guess.guess. Unfortunately. :( > Fair enough. If I knew what you wanted me to do, I'd do it. hg mv config.sub autoconf-config.sub hg cp config.guess config.sub and then fix config.sub so that it runs autoconf-config.sub and modifies the output to what you expect it to be from config.sub when running on this particular platform. Or do some other suitable workaround for config.sub. Perhaps it's easier to modify the input parameters rather than the output string, as we did for config.guess. /Magnus From aph at redhat.com Thu Nov 13 15:03:56 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 Nov 2014 15:03:56 +0000 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <5464C7A0.4080304@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> Message-ID: <5464C85C.50908@redhat.com> On 11/13/2014 03:00 PM, Magnus Ihse Bursie wrote: > > hg mv config.sub autoconf-config.sub > hg cp config.guess config.sub > > and then fix config.sub so that it runs autoconf-config.sub and modifies > the output to what you expect it to be from config.sub when running on > this particular platform. OK, I'll do that. Thanks! Andrew. From daniel.daugherty at oracle.com Thu Nov 13 18:18:40 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Nov 2014 11:18:40 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <5464C3E6.5000309@oracle.com> References: <546151A9.1080100@oracle.com> <5464C3E6.5000309@oracle.com> Message-ID: <5464F600.7040601@oracle.com> Magnus, Thanks for the review! Replies embedded below... On 11/13/14 7:44 AM, Magnus Ihse Bursie wrote: > On 2014-11-11 01:00, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >> Yes, it is a small fix, but it is in Makefiles so feel free to >> run screaming from the room... :-) On the plus side the fix does >> delete two work around source files (Coleen would say that's a >> Good Thing (TM)!) > > ... but you're only deleting the make files? Good catch! Looks like when I resurrected this fix from my JDK8 queue I missed a couple of deletes. > src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and > src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c could > be deleted as well, right? Yes, these should be deleted and I'll do that in this fix. Since these are two deletes of files that can no longer be built anyway, I presume I don't need to sent out another webrev... > > Good idea for the fix, anyway. I opened > https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a > similar solution in configure. Sounds good to me. Dan > > /Magnus From christian.thalinger at oracle.com Thu Nov 13 18:33:46 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 13 Nov 2014 10:33:46 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <5464BBA9.1000809@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> Message-ID: <0B65D4AA-B876-4106-9CA0-2F2AF5F43F83@oracle.com> > On Nov 13, 2014, at 6:09 AM, Magnus Ihse Bursie wrote: > > On 2014-11-10 11:32, Volker Simonis wrote: >> On Mon, Nov 10, 2014 at 10:42 AM, Erik Joelsson >> wrote: >>> On 2014-11-10 10:27, Volker Simonis wrote: >>>> On Mon, Nov 10, 2014 at 9:08 AM, Erik Joelsson >>>> wrote: >>>>> Hello, >>>>> >>>>> I would certainly like to have these files updated, but unfortunately the >>>>> license on these files changed from GPL2 to GPL3. This essentially means >>>>> that the switch is non trivial from a legal perspective and the >>>>> impression >>>>> I've received when I last inquired about updating these files was that >>>>> it's >>>>> unlikely to ever happen unless a very strong case can be presented for >>>>> why >>>>> it's needed. >>>>> >>>>> So the reason we have the over engineered solution for config.guess is >>>>> simply that it's much easier than getting legal approval for updating >>>>> these >>>>> files. >>>> OK, but in that case I don't see any reason for keeping this >>>> "over-engineered" solution at all. If there will not be any pulls from >>>> upstream anyway then there's no reason for keeping these file >>>> untouched. I'd propose then to just remove the wrappers and do all the >>>> chenges right in the corresponding files (of course that's not the >>>> topic of this change but should be done separately). >>> And again, the reason we didn't change the existing file but instead wrapped >>> it, was that we don't have explicit legal approval for doing derivative work >>> for these 3rd party files. Maybe it's ok, maybe it's not, I will not be the >>> person saying it is ok. >>> >> OK, now I got it. I thought we just use the wrappers because we want >> to easily integrate the upstream versions. But instead it is only >> because we don't want to edit these files because of legal >> uncertainties. >> >> So in that case that means we're also not allowed to edit 'config.sub' >> and have to create a wrapper for it, right? > > Yes, you are correct. We cannot modify these files. > > As far as I understand, the legal reason for including these files are the explicit exception: > > # As a special exception to the GNU General Public License, if you > # distribute this file as part of a program that contains a > # configuration script generated by Autoconf, you may include it under > # the same distribution terms that you use for the rest of that program. > > But this is just a distribution license, not a modification license. > > From my IANAL point of view, this exception should be enough to disregard if the file is also distributed under GPL2 or GPL3. Unfortunately, as Erik says, our lawyers are apprehensive of GLP3. So while we thought that we could be able to periodically sync these files with upstream (and remove our external "patches" after a while), we have not been able to do so. Why do we have these files in our repository in the first place? > > So, this fix will need to do the same dance with config.sub as for guess.guess. Unfortunately. :( > > /Magnus From david.holmes at oracle.com Fri Nov 14 02:18:59 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Nov 2014 12:18:59 +1000 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched In-Reply-To: <331C0A42-4ECF-4FC0-8D3E-287BA7EDC50F@reini.net> References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> <5464B729.9090101@oracle.com> <331C0A42-4ECF-4FC0-8D3E-287BA7EDC50F@reini.net> Message-ID: <54656693.4090305@oracle.com> Hi Patrick, On 14/11/2014 12:15 AM, Patrick Reinhart wrote: > Hi Magnus, > > I actually merged down the freetype compilation from the source during the configuration cycle as it?s being done in JDK9 actually. This was not that straightforward but I could sort that out and had a successful compilation afterwards. > > Here is the link to the webrev: http://reinharts.dyndns.org/buildjdk8win/webrev/ Please note that patches have to be submitted via OpenJDK infrastructure: cr.openjdk.java.net or email attachment to OpenJDK mailing list. Cheers, David [1] http://openjdk.java.net/legal/tou/ > Cheers > > Patrick > > >> Am 13.11.2014 um 14:50 schrieb Magnus Ihse Bursie : >> >> On 2014-11-12 19:34, Patrick Reinhart wrote: >>> Hi there, >>> >>> I?m updating the Adopt OpenJDK website with build instructions to build the OpenJDK on Windows 8.1. In order to lower the effort of building also the OpenJDK 8 on Windows, myself and some colleges have back ported the build scripts from OpenJDK 9. We also could provide a webrev containing all changes we made. >>> >>> Could someone sponsor this back port? >> >> Sure, I can sponsor that! >> >> Is the patch straightforward to apply on jdk9 from jdk8? >> >> /Magnus > From david.holmes at oracle.com Fri Nov 14 02:20:50 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Nov 2014 12:20:50 +1000 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <5464F600.7040601@oracle.com> References: <546151A9.1080100@oracle.com> <5464C3E6.5000309@oracle.com> <5464F600.7040601@oracle.com> Message-ID: <54656702.4090102@oracle.com> On 14/11/2014 4:18 AM, Daniel D. Daugherty wrote: > Magnus, > > Thanks for the review! > > Replies embedded below... > > On 11/13/14 7:44 AM, Magnus Ihse Bursie wrote: >> On 2014-11-11 01:00, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>> Yes, it is a small fix, but it is in Makefiles so feel free to >>> run screaming from the room... :-) On the plus side the fix does >>> delete two work around source files (Coleen would say that's a >>> Good Thing (TM)!) >> >> ... but you're only deleting the make files? > > Good catch! Looks like when I resurrected this fix from my JDK8 > queue I missed a couple of deletes. > > >> src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and >> src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c could >> be deleted as well, right? > > Yes, these should be deleted and I'll do that in this fix. > Since these are two deletes of files that can no longer be > built anyway, I presume I don't need to sent out another > webrev... I don't need to see an updated webrev :) Thanks, David > >> >> Good idea for the fix, anyway. I opened >> https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a >> similar solution in configure. > > Sounds good to me. > > Dan > > >> >> /Magnus > From steven.loomis at oracle.com Fri Nov 14 06:59:25 2014 From: steven.loomis at oracle.com (Steven R. Loomis) Date: Thu, 13 Nov 2014 22:59:25 -0800 Subject: RFR: JDK-8027584 disable ccache by default In-Reply-To: <52E83DCC.9040809@oracle.com> References: <52E83DCC.9040809@oracle.com> Message-ID: <5465A84D.5090707@oracle.com> Late to the party, but please note that the README-builds.html *still* says that ccache is great and you should install it. Doesn't mention *anything* about ccache being off by default or `--enable-ccache` being needed. In fact, configure actively disables ccache if you use a symlink to ccache for gcc. I'll file a ticket if need be to fix the docs. Bit by this change- ccache does much, much more good than harm for people who are making small changes to big projects. Not going to argue the default, but please keep the capability around if possible. -s (doing an overnight build to prime the ccache pump) On 1/28/2014 3:31 PM, Magnus Ihse Bursie wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8027584 > > While ccache can be used to speed up recompilations, there are also > several issues with ccache. Old versions does not work correctly for > the jdk (we try to detect that). It does not work well on other > platforms than Linux; on Windows it does not work at all. Nevertheless > is ccache enabled on Windows if it is installed, which it apparently > tends to be with Cygwin nowadays, requiring the use of > --disable-ccache to avoid compilation failure. > > In many circumstances ccache also does not provide any performance > benefit. For instance, new compilations gets a performance hit. Only > recompilations benefits. > > It is better to turn this upside down. This patch makes ccache > disabled by default, on all platforms. If you want ccache and are sure > you are in a situation that benefits from it, then you can enable it. > It also removes the output in configure hinting that ccache should be > used. > > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8027584-disable-ccache-by-default/webrev.01 > > /Magnus From patrick at reini.net Fri Nov 14 06:13:25 2014 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 14 Nov 2014 07:13:25 +0100 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched In-Reply-To: <54656693.4090305@oracle.com> References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> <5464B729.9090101@oracle.com> <331C0A42-4ECF-4FC0-8D3E-287BA7EDC50F@reini.net> <54656693.4090305@oracle.com> Message-ID: <8DC3293D-5FEA-4D9C-ACA6-62BE31340A1B@reini.net> Hi David, So I should be able to attach the webrev.zip to the message for the mailing list? Cheers Patrick > Am 14.11.2014 um 03:18 schrieb David Holmes : > > Hi Patrick, > > On 14/11/2014 12:15 AM, Patrick Reinhart wrote: >> Hi Magnus, >> >> I actually merged down the freetype compilation from the source during the configuration cycle as it?s being done in JDK9 actually. This was not that straightforward but I could sort that out and had a successful compilation afterwards. >> >> Here is the link to the webrev: http://reinharts.dyndns.org/buildjdk8win/webrev/ > > Please note that patches have to be submitted via OpenJDK infrastructure: cr.openjdk.java.net or email attachment to OpenJDK mailing list. > > Cheers, > David > > [1] http://openjdk.java.net/legal/tou/ > > > > >> Cheers >> >> Patrick >> >> >>> Am 13.11.2014 um 14:50 schrieb Magnus Ihse Bursie : >>> >>> On 2014-11-12 19:34, Patrick Reinhart wrote: >>>> Hi there, >>>> >>>> I?m updating the Adopt OpenJDK website with build instructions to build the OpenJDK on Windows 8.1. In order to lower the effort of building also the OpenJDK 8 on Windows, myself and some colleges have back ported the build scripts from OpenJDK 9. We also could provide a webrev containing all changes we made. >>>> >>>> Could someone sponsor this back port? >>> >>> Sure, I can sponsor that! >>> >>> Is the patch straightforward to apply on jdk9 from jdk8? >>> >>> /Magnus >> From david.holmes at oracle.com Fri Nov 14 08:01:55 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Nov 2014 18:01:55 +1000 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched In-Reply-To: <6D4AD6B5-7267-4FD0-A258-A9AEA86B7954@reini.net> References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> <5464B729.9090101@oracle.com> <331C0A42-4ECF-4FC0-8D3E-287BA7EDC50F@reini.net> <54656693.4090305@oracle.com> <6D4AD6B5-7267-4FD0-A258-A9AEA86B7954@reini.net> Message-ID: <5465B6F3.70907@oracle.com> On 14/11/2014 5:36 PM, Patrick Reinhart wrote: > An attachment in the email has been found to contain executable code and has been removed. > > File removed : webrev.zip, zip,html,js Unclear what removed the attachment. :( David > ---------------------------------------------------------------------- > Attached the webrev > > > > > >> Am 14.11.2014 um 03:18 schrieb David Holmes : >> >> Hi Patrick, >> >> On 14/11/2014 12:15 AM, Patrick Reinhart wrote: >>> Hi Magnus, >>> >>> I actually merged down the freetype compilation from the source during the configuration cycle as it?s being done in JDK9 actually. This was not that straightforward but I could sort that out and had a successful compilation afterwards. >>> >>> Here is the link to the webrev: http://reinharts.dyndns.org/buildjdk8win/webrev/ >> >> Please note that patches have to be submitted via OpenJDK infrastructure: cr.openjdk.java.net or email attachment to OpenJDK mailing list. >> >> Cheers, >> David >> >> [1] http://openjdk.java.net/legal/tou/ >> >> >> >> >>> Cheers >>> >>> Patrick >>> >>> >>>> Am 13.11.2014 um 14:50 schrieb Magnus Ihse Bursie : >>>> >>>> On 2014-11-12 19:34, Patrick Reinhart wrote: >>>>> Hi there, >>>>> >>>>> I?m updating the Adopt OpenJDK website with build instructions to build the OpenJDK on Windows 8.1. In order to lower the effort of building also the OpenJDK 8 on Windows, myself and some colleges have back ported the build scripts from OpenJDK 9. We also could provide a webrev containing all changes we made. >>>>> >>>>> Could someone sponsor this back port? >>>> >>>> Sure, I can sponsor that! >>>> >>>> Is the patch straightforward to apply on jdk9 from jdk8? >>>> >>>> /Magnus >>> > From patrick at reini.net Fri Nov 14 08:24:13 2014 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 14 Nov 2014 09:24:13 +0100 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched In-Reply-To: <5465B6F3.70907@oracle.com> References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> <5464B729.9090101@oracle.com> <331C0A42-4ECF-4FC0-8D3E-287BA7EDC50F@reini.net> <54656693.4090305@oracle.com> <6D4AD6B5-7267-4FD0-A258-A9AEA86B7954@reini.net> <5465B6F3.70907@oracle.com> Message-ID: <3DDA1BFA-F018-4767-809F-4C048B5BDA52@reini.net> Hi David, I?ve got a mail that the attachment was too big and was held by the moderator approval. I personally would love to put that on cr.openjdk.java.net but to put it there it seems that I fist has to be contributor and in order to be that I had be submit some patches first :-( It seems I?m stuck in a recursive loop somehow ;-) Cheers Patrick PS: I did already contributed two fixes for the 2d printing part in the past. > Am 14.11.2014 um 09:01 schrieb David Holmes : > > On 14/11/2014 5:36 PM, Patrick Reinhart wrote: >> An attachment in the email has been found to contain executable code and has been removed. >> >> File removed : webrev.zip, zip,html,js > > Unclear what removed the attachment. :( > > David > >> ---------------------------------------------------------------------- >> Attached the webrev >> >> >> >> >> >>> Am 14.11.2014 um 03:18 schrieb David Holmes : >>> >>> Hi Patrick, >>> >>> On 14/11/2014 12:15 AM, Patrick Reinhart wrote: >>>> Hi Magnus, >>>> >>>> I actually merged down the freetype compilation from the source during the configuration cycle as it?s being done in JDK9 actually. This was not that straightforward but I could sort that out and had a successful compilation afterwards. >>>> >>>> Here is the link to the webrev: http://reinharts.dyndns.org/buildjdk8win/webrev/ >>> >>> Please note that patches have to be submitted via OpenJDK infrastructure: cr.openjdk.java.net or email attachment to OpenJDK mailing list. >>> >>> Cheers, >>> David >>> >>> [1] http://openjdk.java.net/legal/tou/ >>> >>> >>> >>> >>>> Cheers >>>> >>>> Patrick >>>> >>>> >>>>> Am 13.11.2014 um 14:50 schrieb Magnus Ihse Bursie : >>>>> >>>>> On 2014-11-12 19:34, Patrick Reinhart wrote: >>>>>> Hi there, >>>>>> >>>>>> I?m updating the Adopt OpenJDK website with build instructions to build the OpenJDK on Windows 8.1. In order to lower the effort of building also the OpenJDK 8 on Windows, myself and some colleges have back ported the build scripts from OpenJDK 9. We also could provide a webrev containing all changes we made. >>>>>> >>>>>> Could someone sponsor this back port? >>>>> >>>>> Sure, I can sponsor that! >>>>> >>>>> Is the patch straightforward to apply on jdk9 from jdk8? >>>>> >>>>> /Magnus >>>> >> From magnus.ihse.bursie at oracle.com Fri Nov 14 08:39:36 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Nov 2014 09:39:36 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <0B65D4AA-B876-4106-9CA0-2F2AF5F43F83@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <0B65D4AA-B876-4106-9CA0-2F2AF5F43F83@oracle.com> Message-ID: <62FBBB3A-B1CE-43D8-9D99-3087BDDBDC37@oracle.com> > 13 nov 2014 kl. 19:33 skrev Christian Thalinger : > > >> On Nov 13, 2014, at 6:09 AM, Magnus Ihse Bursie wrote: >> >>> On 2014-11-10 11:32, Volker Simonis wrote: >>> On Mon, Nov 10, 2014 at 10:42 AM, Erik Joelsson >>> wrote: >>>> On 2014-11-10 10:27, Volker Simonis wrote: >>>>> On Mon, Nov 10, 2014 at 9:08 AM, Erik Joelsson >>>>> wrote: >>>>>> Hello, >>>>>> >>>>>> I would certainly like to have these files updated, but unfortunately the >>>>>> license on these files changed from GPL2 to GPL3. This essentially means >>>>>> that the switch is non trivial from a legal perspective and the >>>>>> impression >>>>>> I've received when I last inquired about updating these files was that >>>>>> it's >>>>>> unlikely to ever happen unless a very strong case can be presented for >>>>>> why >>>>>> it's needed. >>>>>> >>>>>> So the reason we have the over engineered solution for config.guess is >>>>>> simply that it's much easier than getting legal approval for updating >>>>>> these >>>>>> files. >>>>> OK, but in that case I don't see any reason for keeping this >>>>> "over-engineered" solution at all. If there will not be any pulls from >>>>> upstream anyway then there's no reason for keeping these file >>>>> untouched. I'd propose then to just remove the wrappers and do all the >>>>> chenges right in the corresponding files (of course that's not the >>>>> topic of this change but should be done separately). >>>> And again, the reason we didn't change the existing file but instead wrapped >>>> it, was that we don't have explicit legal approval for doing derivative work >>>> for these 3rd party files. Maybe it's ok, maybe it's not, I will not be the >>>> person saying it is ok. >>> OK, now I got it. I thought we just use the wrappers because we want >>> to easily integrate the upstream versions. But instead it is only >>> because we don't want to edit these files because of legal >>> uncertainties. >>> >>> So in that case that means we're also not allowed to edit 'config.sub' >>> and have to create a wrapper for it, right? >> >> Yes, you are correct. We cannot modify these files. >> >> As far as I understand, the legal reason for including these files are the explicit exception: >> >> # As a special exception to the GNU General Public License, if you >> # distribute this file as part of a program that contains a >> # configuration script generated by Autoconf, you may include it under >> # the same distribution terms that you use for the rest of that program. >> >> But this is just a distribution license, not a modification license. >> >> From my IANAL point of view, this exception should be enough to disregard if the file is also distributed under GPL2 or GPL3. Unfortunately, as Erik says, our lawyers are apprehensive of GLP3. So while we thought that we could be able to periodically sync these files with upstream (and remove our external "patches" after a while), we have not been able to do so. > > Why do we have these files in our repository in the first place? Because they are needed by the configure script. They are a sort of runtime libraries for configure, but since they are written as shell scripts, the source code form and the executable form is the same. The distribution exception is there exactly since anyone should be able to distribute the files with their configure script. That does not mean that you are allowed to edit it, though. /Magnus > >> >> So, this fix will need to do the same dance with config.sub as for guess.guess. Unfortunately. :( >> >> /Magnus > From magnus.ihse.bursie at oracle.com Fri Nov 14 08:45:08 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Nov 2014 09:45:08 +0100 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched In-Reply-To: <3DDA1BFA-F018-4767-809F-4C048B5BDA52@reini.net> References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> <5464B729.9090101@oracle.com> <331C0A42-4ECF-4FC0-8D3E-287BA7EDC50F@reini.net> <54656693.4090305@oracle.com> <6D4AD6B5-7267-4FD0-A258-A9AEA86B7954@reini.net> <5465B6F3.70907@oracle.com> <3DDA1BFA-F018-4767-809F-4C048B5BDA52@reini.net> Message-ID: <0D9ED57F-70A5-4B99-B873-C0D2AA4C2478@oracle.com> Hi Patrick, I'm sorry for all the trouble you have encountered when trying to help improving OpenJDK. :( Try sending the patch only (not the webrev), as normal inlined text (not an attachment) in a mail to the list. I can create a webrev and put it on cr.openjdk.java.net for you. /Magnus > 14 nov 2014 kl. 09:24 skrev Patrick Reinhart : > > Hi David, > > I?ve got a mail that the attachment was too big and was held by the moderator approval. I personally would love to put that on cr.openjdk.java.net but to put it there it seems that I fist has to be contributor and in order to be that I had be submit some patches first :-( > > It seems I?m stuck in a recursive loop somehow ;-) > > > Cheers Patrick > > PS: I did already contributed two fixes for the 2d printing part in the past. > > >> Am 14.11.2014 um 09:01 schrieb David Holmes : >> >> On 14/11/2014 5:36 PM, Patrick Reinhart wrote: >>> An attachment in the email has been found to contain executable code and has been removed. >>> >>> File removed : webrev.zip, zip,html,js >> >> Unclear what removed the attachment. :( >> >> David >> >>> ---------------------------------------------------------------------- >>> Attached the webrev >>> >>> >>> >>> >>> >>>> Am 14.11.2014 um 03:18 schrieb David Holmes : >>>> >>>> Hi Patrick, >>>> >>>>> On 14/11/2014 12:15 AM, Patrick Reinhart wrote: >>>>> Hi Magnus, >>>>> >>>>> I actually merged down the freetype compilation from the source during the configuration cycle as it?s being done in JDK9 actually. This was not that straightforward but I could sort that out and had a successful compilation afterwards. >>>>> >>>>> Here is the link to the webrev: http://reinharts.dyndns.org/buildjdk8win/webrev/ >>>> >>>> Please note that patches have to be submitted via OpenJDK infrastructure: cr.openjdk.java.net or email attachment to OpenJDK mailing list. >>>> >>>> Cheers, >>>> David >>>> >>>> [1] http://openjdk.java.net/legal/tou/ >>>> >>>> >>>> >>>> >>>>> Cheers >>>>> >>>>> Patrick >>>>> >>>>> >>>>>> Am 13.11.2014 um 14:50 schrieb Magnus Ihse Bursie : >>>>>> >>>>>> On 2014-11-12 19:34, Patrick Reinhart wrote: >>>>>>> Hi there, >>>>>>> >>>>>>> I?m updating the Adopt OpenJDK website with build instructions to build the OpenJDK on Windows 8.1. In order to lower the effort of building also the OpenJDK 8 on Windows, myself and some colleges have back ported the build scripts from OpenJDK 9. We also could provide a webrev containing all changes we made. >>>>>>> >>>>>>> Could someone sponsor this back port? >>>>>> >>>>>> Sure, I can sponsor that! >>>>>> >>>>>> Is the patch straightforward to apply on jdk9 from jdk8? >>>>>> >>>>>> /Magnus > From patrick at reini.net Fri Nov 14 08:54:46 2014 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 14 Nov 2014 09:54:46 +0100 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched In-Reply-To: <0D9ED57F-70A5-4B99-B873-C0D2AA4C2478@oracle.com> References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> <5464B729.9090101@oracle.com> <331C0A42-4ECF-4FC0-8D3E-287BA7EDC50F@reini.net> <54656693.4090305@oracle.com> <6D4AD6B5-7267-4FD0-A258-A9AEA86B7954@reini.net> <5465B6F3.70907@oracle.com> <3DDA1BFA-F018-4767-809F-4C048B5BDA52@reini.net> <0D9ED57F-70A5-4B99-B873-C0D2AA4C2478@oracle.com> Message-ID: <5C5934B6-741C-4EDF-A1AA-4B025F159F57@reini.net> Hi Magnus Unfortunately the patch itself is as big as 2 megabytes and will therefore get removed? Now I?m really stuck. Cheers Patrick > Am 14.11.2014 um 09:45 schrieb Magnus Ihse Bursie : > > Hi Patrick, > > I'm sorry for all the trouble you have encountered when trying to help improving OpenJDK. :( > > Try sending the patch only (not the webrev), as normal inlined text (not an attachment) in a mail to the list. I can create a webrev and put it on cr.openjdk.java.net for you. > > /Magnus > > 14 nov 2014 kl. 09:24 skrev Patrick Reinhart >: > >> Hi David, >> >> I?ve got a mail that the attachment was too big and was held by the moderator approval. I personally would love to put that on cr.openjdk.java.net but to put it there it seems that I fist has to be contributor and in order to be that I had be submit some patches first :-( >> >> It seems I?m stuck in a recursive loop somehow ;-) >> >> >> Cheers Patrick >> >> PS: I did already contributed two fixes for the 2d printing part in the past. >> >> >>> Am 14.11.2014 um 09:01 schrieb David Holmes >: >>> >>> On 14/11/2014 5:36 PM, Patrick Reinhart wrote: >>>> An attachment in the email has been found to contain executable code and has been removed. >>>> >>>> File removed : webrev.zip, zip,html,js >>> >>> Unclear what removed the attachment. :( >>> >>> David >>> >>>> ---------------------------------------------------------------------- >>>> Attached the webrev >>>> >>>> >>>> >>>> >>>> >>>>> Am 14.11.2014 um 03:18 schrieb David Holmes >: >>>>> >>>>> Hi Patrick, >>>>> >>>>> On 14/11/2014 12:15 AM, Patrick Reinhart wrote: >>>>>> Hi Magnus, >>>>>> >>>>>> I actually merged down the freetype compilation from the source during the configuration cycle as it?s being done in JDK9 actually. This was not that straightforward but I could sort that out and had a successful compilation afterwards. >>>>>> >>>>>> Here is the link to the webrev: http://reinharts.dyndns.org/buildjdk8win/webrev/ > >>>>> >>>>> Please note that patches have to be submitted via OpenJDK infrastructure: cr.openjdk.java.net or email attachment to OpenJDK mailing list. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> [1] http://openjdk.java.net/legal/tou/ >>>>> >>>>> >>>>> >>>>> >>>>>> Cheers >>>>>> >>>>>> Patrick >>>>>> >>>>>> >>>>>>> Am 13.11.2014 um 14:50 schrieb Magnus Ihse Bursie >: >>>>>>> >>>>>>> On 2014-11-12 19:34, Patrick Reinhart wrote: >>>>>>>> Hi there, >>>>>>>> >>>>>>>> I?m updating the Adopt OpenJDK website with build instructions to build the OpenJDK on Windows 8.1. In order to lower the effort of building also the OpenJDK 8 on Windows, myself and some colleges have back ported the build scripts from OpenJDK 9. We also could provide a webrev containing all changes we made. >>>>>>>> >>>>>>>> Could someone sponsor this back port? >>>>>>> >>>>>>> Sure, I can sponsor that! >>>>>>> >>>>>>> Is the patch straightforward to apply on jdk9 from jdk8? >>>>>>> >>>>>>> /Magnus >>>>>> >>>> >> From erik.joelsson at oracle.com Fri Nov 14 09:26:08 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Nov 2014 10:26:08 +0100 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched In-Reply-To: <5C5934B6-741C-4EDF-A1AA-4B025F159F57@reini.net> References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> <5464B729.9090101@oracle.com> <331C0A42-4ECF-4FC0-8D3E-287BA7EDC50F@reini.net> <54656693.4090305@oracle.com> <6D4AD6B5-7267-4FD0-A258-A9AEA86B7954@reini.net> <5465B6F3.70907@oracle.com> <3DDA1BFA-F018-4767-809F-4C048B5BDA52@reini.net> <0D9ED57F-70A5-4B99-B873-C0D2AA4C2478@oracle.com> <5C5934B6-741C-4EDF-A1AA-4B025F159F57@reini.net> Message-ID: <5465CAB0.6090805@oracle.com> Hello Patrick, try reverting common/autoconf/generated-configure before generating the patch. That file does not need to be reviewed as it's just generated anyway. That should reduce the patch size. /Erik On 2014-11-14 09:54, Patrick Reinhart wrote: > Hi Magnus > > Unfortunately the patch itself is as big as 2 megabytes and will therefore get removed? Now I?m really stuck. > > Cheers Patrick > >> Am 14.11.2014 um 09:45 schrieb Magnus Ihse Bursie : >> >> Hi Patrick, >> >> I'm sorry for all the trouble you have encountered when trying to help improving OpenJDK. :( >> >> Try sending the patch only (not the webrev), as normal inlined text (not an attachment) in a mail to the list. I can create a webrev and put it on cr.openjdk.java.net for you. >> >> /Magnus >> >> 14 nov 2014 kl. 09:24 skrev Patrick Reinhart >: >> >>> Hi David, >>> >>> I?ve got a mail that the attachment was too big and was held by the moderator approval. I personally would love to put that on cr.openjdk.java.net but to put it there it seems that I fist has to be contributor and in order to be that I had be submit some patches first :-( >>> >>> It seems I?m stuck in a recursive loop somehow ;-) >>> >>> >>> Cheers Patrick >>> >>> PS: I did already contributed two fixes for the 2d printing part in the past. >>> >>> >>>> Am 14.11.2014 um 09:01 schrieb David Holmes >: >>>> >>>> On 14/11/2014 5:36 PM, Patrick Reinhart wrote: >>>>> An attachment in the email has been found to contain executable code and has been removed. >>>>> >>>>> File removed : webrev.zip, zip,html,js >>>> Unclear what removed the attachment. :( >>>> >>>> David >>>> >>>>> ---------------------------------------------------------------------- >>>>> Attached the webrev >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Am 14.11.2014 um 03:18 schrieb David Holmes >: >>>>>> >>>>>> Hi Patrick, >>>>>> >>>>>> On 14/11/2014 12:15 AM, Patrick Reinhart wrote: >>>>>>> Hi Magnus, >>>>>>> >>>>>>> I actually merged down the freetype compilation from the source during the configuration cycle as it?s being done in JDK9 actually. This was not that straightforward but I could sort that out and had a successful compilation afterwards. >>>>>>> >>>>>>> Here is the link to the webrev: http://reinharts.dyndns.org/buildjdk8win/webrev/ > >>>>>> Please note that patches have to be submitted via OpenJDK infrastructure: cr.openjdk.java.net or email attachment to OpenJDK mailing list. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> [1] http://openjdk.java.net/legal/tou/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> Patrick >>>>>>> >>>>>>> >>>>>>>> Am 13.11.2014 um 14:50 schrieb Magnus Ihse Bursie >: >>>>>>>> >>>>>>>> On 2014-11-12 19:34, Patrick Reinhart wrote: >>>>>>>>> Hi there, >>>>>>>>> >>>>>>>>> I?m updating the Adopt OpenJDK website with build instructions to build the OpenJDK on Windows 8.1. In order to lower the effort of building also the OpenJDK 8 on Windows, myself and some colleges have back ported the build scripts from OpenJDK 9. We also could provide a webrev containing all changes we made. >>>>>>>>> >>>>>>>>> Could someone sponsor this back port? >>>>>>>> Sure, I can sponsor that! >>>>>>>> >>>>>>>> Is the patch straightforward to apply on jdk9 from jdk8? >>>>>>>> >>>>>>>> /Magnus From patrick at reini.net Fri Nov 14 09:35:01 2014 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 14 Nov 2014 10:35:01 +0100 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched In-Reply-To: <5465CAB0.6090805@oracle.com> References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> <5464B729.9090101@oracle.com> <331C0A42-4ECF-4FC0-8D3E-287BA7EDC50F@reini.net> <54656693.4090305@oracle.com> <6D4AD6B5-7267-4FD0-A258-A9AEA86B7954@reini.net> <5465B6F3.70907@oracle.com> <3DDA1BFA-F018-4767-809F-4C048B5BDA52@reini.net> <0D9ED57F-70A5-4B99-B873-C0D2AA4C2478@oracle.com> <5C5934B6-741C-4EDF-A1AA-4B025F159F57@reini.net> <5465CAB0.6090805@oracle.com> Message-ID: <71A06C35-1AF2-474E-8643-437DAACB22B7@reini.net> Hi Erik / Magnus, See attachment? Patrick -------------- next part -------------- > Am 14.11.2014 um 10:26 schrieb Erik Joelsson : > > Hello Patrick, try reverting common/autoconf/generated-configure before generating the patch. That file does not need to be reviewed as it's just generated anyway. That should reduce the patch size. > > /Erik > > On 2014-11-1 From weijun.wang at oracle.com Fri Nov 14 09:56:12 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 14 Nov 2014 17:56:12 +0800 Subject: visual-studio-community? In-Reply-To: <5464B6BC.1020308@oracle.com> References: <6DD8D988-618C-48A4-8CC8-FA4F9F52B3F6@oracle.com> <5464B6BC.1020308@oracle.com> Message-ID: <934628E7-1689-4AD0-A5CD-F81B49E3500B@oracle.com> > On Nov 13, 2014, at 21:48, Magnus Ihse Bursie wrote: > > My guess is that the Visual Studio detection code in common/autoconf needs updating to locate the tools. Looks like vs2013 is not supported yet. If as Microsoft described the community version is full-featured it should be equivalent to vs2013. --Max From patrick at reini.net Fri Nov 14 10:21:40 2014 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 14 Nov 2014 11:21:40 +0100 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched In-Reply-To: <71A06C35-1AF2-474E-8643-437DAACB22B7@reini.net> References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> <5464B729.9090101@oracle.com> <331C0A42-4ECF-4FC0-8D3E-287BA7EDC50F@reini.net> <54656693.4090305@oracle.com> <6D4AD6B5-7267-4FD0-A258-A9AEA86B7954@reini.net> <5465B6F3.70907@oracle.com> <3DDA1BFA-F018-4767-809F-4C048B5BDA52@reini.net> <0D9ED57F-70A5-4B99-B873-C0D2AA4C2478@oracle.com> <5C5934B6-741C-4EDF-A1AA-4B025F159F57@reini.net> <5465CAB0.6090805@oracle.com> <71A06C35-1AF2-474E-8643-437DAACB22B7@reini.net> Message-ID: <01171662-3471-40AE-B574-A9FA4675E052@reini.net> Here is the patch also as inlined text: --- old/common/autoconf/help.m4 2014-11-14 10:32:44.000000000 +0100 +++ new/common/autoconf/help.m4 2014-11-14 10:32:44.000000000 +0100 @@ -75,20 +75,18 @@ HELP_MSG="You might be able to fix this by running '$PKGHANDLER_COMMAND'." ;; freetype) - if test "x$OPENJDK_TARGET_CPU_BITS" = x32; then - HELP_MSG="To install freetype, run: -wget \"http://gnuwin32.sourceforge.net/downlinks/freetype.php\" -O /tmp/freetype-setup.exe -chmod +x /tmp/freetype-setup.exe -/tmp/freetype-setup.exe -Follow GUI prompts, and install to default directory \"C:\Program Files (x86)\GnuWin32\". -After installation, locate lib/libfreetype.dll.a and make a copy with the name freetype.dll." - else - HELP_MSG="You need to build a 64-bit version of freetype. -This is not readily available. -You can find source code and build instructions on -http://www.freetype.org/ -If you put the resulting build in \"C:\Program Files\GnuWin32\", it will be found automatically." - fi + HELP_MSG=" +The freetype library can now be build during the configure process. +Download the freetype sources and unpack them into an arbitrary directory: + +wget http://download.savannah.gnu.org/releases/freetype/freetype-2.5.3.tar.gz +tar -xzf freetype-2.5.3.tar.gz + +Then run configure with '--with-freetype-src='. This will +automatically build the freetype library into '/lib64' for 64-bit +builds or into '/lib32' for 32-bit builds. +Afterwards you can always use '--with-freetype-include=/include' +and '--with-freetype-lib=/lib[32|64]' for other builds." ;; esac } --- old/common/autoconf/libraries.m4 2014-11-14 10:32:44.000000000 +0100 +++ new/common/autoconf/libraries.m4 2014-11-14 10:32:44.000000000 +0100 @@ -258,12 +258,95 @@ ]) +AC_DEFUN([LIB_BUILD_FREETYPE], +[ + FREETYPE_SRC_PATH="$1" + BUILD_FREETYPE=yes + + # Check if the freetype sources are acessible.. + if ! test -d $FREETYPE_SRC_PATH; then + AC_MSG_WARN([--with-freetype-src specified, but can't find path "$FREETYPE_SRC_PATH" - ignoring --with-freetype-src]) + BUILD_FREETYPE=no + fi + # ..and contain a vc2010 project file + vcxproj_path="$FREETYPE_SRC_PATH/builds/windows/vc2010/freetype.vcxproj" + if test "x$BUILD_FREETYPE" = xyes && ! test -s $vcxproj_path; then + AC_MSG_WARN([Can't find project file $vcxproj_path (you may try a newer freetype version) - ignoring --with-freetype-src]) + BUILD_FREETYPE=no + fi + # Now check if configure found a version of 'msbuild.exe' + if test "x$BUILD_FREETYPE" = xyes && test "x$MSBUILD" == x ; then + AC_MSG_WARN([Can't find an msbuild.exe executable (you may try to install .NET 4.0) - ignoring --with-freetype-src]) + BUILD_FREETYPE=no + fi + + # Ready to go.. + if test "x$BUILD_FREETYPE" = xyes; then + + # msbuild requires trailing slashes for output directories + freetype_lib_path="$FREETYPE_SRC_PATH/lib$OPENJDK_TARGET_CPU_BITS/" + freetype_lib_path_unix="$freetype_lib_path" + freetype_obj_path="$FREETYPE_SRC_PATH/obj$OPENJDK_TARGET_CPU_BITS/" + BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH(vcxproj_path) + BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH(freetype_lib_path) + BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH(freetype_obj_path) + if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then + freetype_platform=x64 + else + freetype_platform=win32 + fi + + # The original freetype project file is for VS 2010 (i.e. 'v100'), + # so we have to adapt the toolset if building with any other toolsed (i.e. SDK). + # Currently 'PLATFORM_TOOLSET' is set in 'TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT'/ + # 'TOOLCHAIN_CHECK_POSSIBLE_WIN_SDK_ROOT' in toolchain_windows.m4 + AC_MSG_NOTICE([Trying to compile freetype sources with PlatformToolset=$PLATFORM_TOOLSET to $freetype_lib_path_unix ...]) + + # First we try to build the freetype.dll + $ECHO -e "@echo off\n"\ + "$MSBUILD $vcxproj_path "\ + "/p:PlatformToolset=$PLATFORM_TOOLSET "\ + "/p:Configuration=\"Release Multithreaded\" "\ + "/p:Platform=$freetype_platform "\ + "/p:ConfigurationType=DynamicLibrary "\ + "/p:TargetName=freetype "\ + "/p:OutDir=\"$freetype_lib_path\" "\ + "/p:IntDir=\"$freetype_obj_path\" > freetype.log" > freetype.bat + cmd /c freetype.bat + + if test -s "$freetype_lib_path_unix/freetype.dll"; then + # If that succeeds we also build freetype.lib + $ECHO -e "@echo off\n"\ + "$MSBUILD $vcxproj_path "\ + "/p:PlatformToolset=$PLATFORM_TOOLSET "\ + "/p:Configuration=\"Release Multithreaded\" "\ + "/p:Platform=$freetype_platform "\ + "/p:ConfigurationType=StaticLibrary "\ + "/p:TargetName=freetype "\ + "/p:OutDir=\"$freetype_lib_path\" "\ + "/p:IntDir=\"$freetype_obj_path\" >> freetype.log" > freetype.bat + cmd /c freetype.bat + + if test -s "$freetype_lib_path_unix/freetype.lib"; then + # Once we build both, lib and dll, set freetype lib and include path appropriately + POTENTIAL_FREETYPE_INCLUDE_PATH="$FREETYPE_SRC_PATH/include" + POTENTIAL_FREETYPE_LIB_PATH="$freetype_lib_path_unix" + AC_MSG_NOTICE([Compiling freetype sources succeeded! (see freetype.log for build results)]) + else + BUILD_FREETYPE=no + fi + else + BUILD_FREETYPE=no + fi + fi +]) + AC_DEFUN([LIB_CHECK_POTENTIAL_FREETYPE], [ POTENTIAL_FREETYPE_INCLUDE_PATH="$1" POTENTIAL_FREETYPE_LIB_PATH="$2" METHOD="$3" - + # First check if the files exists. if test -s "$POTENTIAL_FREETYPE_INCLUDE_PATH/ft2build.h"; then # We found an arbitrary include file. That's a good sign. @@ -315,6 +398,8 @@ [specify directory for the freetype include files])]) AC_ARG_WITH(freetype-lib, [AS_HELP_STRING([--with-freetype-lib], [specify directory for the freetype library])]) + AC_ARG_WITH(freetype-src, [AS_HELP_STRING([--with-freetype-src], + [specify directory with freetype sources to automatically build the library (experimental, Windows-only)])]) AC_ARG_ENABLE(freetype-bundling, [AS_HELP_STRING([--disable-freetype-bundling], [disable bundling of the freetype library with the build result @<:@enabled on Windows or when using --with-freetype, disabled otherwise@:>@])]) @@ -323,7 +408,7 @@ FREETYPE_BUNDLE_LIB_PATH= if test "x$FREETYPE_NOT_NEEDED" = xyes; then - if test "x$with_freetype" != x || test "x$with_freetype_include" != x || test "x$with_freetype_lib" != x; then + if test "x$with_freetype" != x || test "x$with_freetype_include" != x || test "x$with_freetype_lib" != x || test "x$with_freetype_src" != x; then AC_MSG_WARN([freetype not used, so --with-freetype is ignored]) fi if test "x$enable_freetype_bundling" != x; then @@ -334,6 +419,25 @@ BUNDLE_FREETYPE="$enable_freetype_bundling" + if test "x$with_freetype_src" != x; then + if test "x$OPENJDK_TARGET_OS" = xwindows; then + # Try to build freetype if --with-freetype-src was given on Windows + LIB_BUILD_FREETYPE([$with_freetype_src]) + if test "x$BUILD_FREETYPE" = xyes; then + # Okay, we built it. Check that it works. + LIB_CHECK_POTENTIAL_FREETYPE($POTENTIAL_FREETYPE_INCLUDE_PATH, $POTENTIAL_FREETYPE_LIB_PATH, [--with-freetype-src]) + if test "x$FOUND_FREETYPE" != xyes; then + AC_MSG_ERROR([Can not use the built freetype at location given by --with-freetype-src]) + fi + else + AC_MSG_NOTICE([User specified --with-freetype-src but building freetype failed. (see freetype.log for build results)]) + AC_MSG_ERROR([Consider building freetype manually and using --with-freetype instead.]) + fi + else + AC_MSG_WARN([--with-freetype-src is currently only supported on Windows - ignoring]) + fi + fi + if test "x$with_freetype" != x || test "x$with_freetype_include" != x || test "x$with_freetype_lib" != x; then # User has specified settings @@ -341,12 +445,12 @@ # If not specified, default is to bundle freetype BUNDLE_FREETYPE=yes fi - + if test "x$with_freetype" != x; then POTENTIAL_FREETYPE_INCLUDE_PATH="$with_freetype/include" POTENTIAL_FREETYPE_LIB_PATH="$with_freetype/lib" fi - + # Allow --with-freetype-lib and --with-freetype-include to override if test "x$with_freetype_include" != x; then POTENTIAL_FREETYPE_INCLUDE_PATH="$with_freetype_include" @@ -475,7 +579,7 @@ FREETYPE_CFLAGS="-I$FREETYPE_INCLUDE_PATH" fi fi - + if test "x$FREETYPE_LIBS" = x; then BASIC_FIXUP_PATH(FREETYPE_LIB_PATH) if test "x$OPENJDK_TARGET_OS" = xwindows; then @@ -491,7 +595,7 @@ PREV_CXXCFLAGS="$CXXFLAGS" PREV_LIBS="$LIBS" PREV_CXX="$CXX" - CXXFLAGS="$CXXFLAGS $FREETYPE_CFLAGS" + CXXFLAGS="$CXXFLAGS $FREETYPE_CFLAGS" LIBS="$LIBS $FREETYPE_LIBS" CXX="$FIXPATH $CXX" AC_LINK_IFELSE([AC_LANG_SOURCE([[ @@ -509,9 +613,9 @@ AC_MSG_RESULT([no]) AC_MSG_NOTICE([Could not compile and link with freetype. This might be a 32/64-bit mismatch.]) AC_MSG_NOTICE([Using FREETYPE_CFLAGS=$FREETYPE_CFLAGS and FREETYPE_LIBS=$FREETYPE_LIBS]) - + HELP_MSG_MISSING_DEPENDENCY([freetype]) - + AC_MSG_ERROR([Can not continue without freetype. $HELP_MSG]) ] ) --- old/common/autoconf/toolchain.m4 2014-11-14 10:32:45.000000000 +0100 +++ new/common/autoconf/toolchain.m4 2014-11-14 10:32:45.000000000 +0100 @@ -385,6 +385,15 @@ AC_CHECK_PROG([RC], [rc], [rc],,, [/usr/bin/rc]) BASIC_FIXUP_EXECUTABLE(RC) + # We need to check for 'msbuild.exe' because at the place where we expect to + # find 'msbuild.exe' there's also a directory called 'msbuild' and configure + # won't find the 'msbuild.exe' executable in that case (and the + # 'ac_executable_extensions' is unusable due to performance reasons). + # Notice that we intentionally don't fix up the path to MSBUILD because we + # will call it in a DOS shell during freetype detection on Windows (see + # 'LIB_SETUP_FREETYPE' in "libraries.m4" + AC_CHECK_PROG([MSBUILD], [msbuild.exe], [msbuild.exe],,,) + # For hotspot, we need these in Windows mixed path, # so rewrite them all. Need added .exe suffix. HOTSPOT_CXX="$CXX.exe" --- old/common/autoconf/toolchain_windows.m4 2014-11-14 10:32:45.000000000 +0100 +++ new/common/autoconf/toolchain_windows.m4 2014-11-14 10:32:45.000000000 +0100 @@ -33,6 +33,10 @@ if test -f "$VS100BASE/$VCVARSFILE"; then AC_MSG_NOTICE([Found Visual Studio installation at $VS100BASE using $METHOD]) VS_ENV_CMD="$VS100BASE/$VCVARSFILE" + # PLATFORM_TOOLSET is used during the compilation of the freetype sources (see + # 'LIB_BUILD_FREETYPE' in libraries.m4) and must be one of 'v100', 'v110' or 'v120' for VS 2010, 2012 or VS2013 + # TODO: improve detection for other versions of VS + PLATFORM_TOOLSET="v100" else AC_MSG_NOTICE([Found Visual Studio installation at $VS100BASE using $METHOD]) AC_MSG_NOTICE([Warning: $VCVARSFILE is missing, this is probably Visual Studio Express. Ignoring]) @@ -61,6 +65,10 @@ else VS_ENV_ARGS="/x64" fi + # PLATFORM_TOOLSET is used during the compilation of the freetype sources (see + # 'LIB_BUILD_FREETYPE' in libraries.m4) and must be 'Windows7.1SDK' for Windows7.1SDK + # TODO: improve detection for other versions of SDK + PLATFORM_TOOLSET="Windows7.1SDK" else AC_MSG_NOTICE([Found Windows SDK installation at $WIN_SDK_BASE using $METHOD]) AC_MSG_NOTICE([Warning: Installation is broken, SetEnv.Cmd is missing. Ignoring]) From ivan at azulsystems.com Fri Nov 14 18:12:55 2014 From: ivan at azulsystems.com (Ivan Krylov) Date: Fri, 14 Nov 2014 10:12:55 -0800 Subject: visual-studio-community? In-Reply-To: <934628E7-1689-4AD0-A5CD-F81B49E3500B@oracle.com> References: <6DD8D988-618C-48A4-8CC8-FA4F9F52B3F6@oracle.com> <5464B6BC.1020308@oracle.com> <934628E7-1689-4AD0-A5CD-F81B49E3500B@oracle.com> Message-ID: <54664627.109@azulsystems.com> Are you looking at just the hotspot builds within VS or entire JDK? I am not sure that the VS makes a great java editor, so I've only looked at the hotspot part. Previously hotspot had a VS project generator and even though it would generate VS2010 projects - those would be fine within VS2010. Typically the only changes needed is the modification of compile/linker version in a sanity checker. Ivan On 14/11/2014 01:56, Wang Weijun wrote: >> On Nov 13, 2014, at 21:48, Magnus Ihse Bursie wrote: >> >> My guess is that the Visual Studio detection code in common/autoconf needs updating to locate the tools. > Looks like vs2013 is not supported yet. If as Microsoft described the community version is full-featured it should be equivalent to vs2013. > > --Max > > From dean.long at oracle.com Fri Nov 14 20:44:13 2014 From: dean.long at oracle.com (Dean Long) Date: Fri, 14 Nov 2014 12:44:13 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <62FBBB3A-B1CE-43D8-9D99-3087BDDBDC37@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <0B65D4AA-B876-4106-9CA0-2F2AF5F43F83@oracle.com> <62FBBB3A-B1CE-43D8-9D99-3087BDDBDC37@oracle.com> Message-ID: <5466699D.2050808@oracle.com> On 11/14/2014 12:39 AM, Magnus Ihse Bursie wrote: >> 13 nov 2014 kl. 19:33 skrev Christian Thalinger : >> >> >>> On Nov 13, 2014, at 6:09 AM, Magnus Ihse Bursie wrote: >>> >>>> On 2014-11-10 11:32, Volker Simonis wrote: >>>> On Mon, Nov 10, 2014 at 10:42 AM, Erik Joelsson >>>> wrote: >>>>> On 2014-11-10 10:27, Volker Simonis wrote: >>>>>> On Mon, Nov 10, 2014 at 9:08 AM, Erik Joelsson >>>>>> wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I would certainly like to have these files updated, but unfortunately the >>>>>>> license on these files changed from GPL2 to GPL3. This essentially means >>>>>>> that the switch is non trivial from a legal perspective and the >>>>>>> impression >>>>>>> I've received when I last inquired about updating these files was that >>>>>>> it's >>>>>>> unlikely to ever happen unless a very strong case can be presented for >>>>>>> why >>>>>>> it's needed. >>>>>>> >>>>>>> So the reason we have the over engineered solution for config.guess is >>>>>>> simply that it's much easier than getting legal approval for updating >>>>>>> these >>>>>>> files. >>>>>> OK, but in that case I don't see any reason for keeping this >>>>>> "over-engineered" solution at all. If there will not be any pulls from >>>>>> upstream anyway then there's no reason for keeping these file >>>>>> untouched. I'd propose then to just remove the wrappers and do all the >>>>>> chenges right in the corresponding files (of course that's not the >>>>>> topic of this change but should be done separately). >>>>> And again, the reason we didn't change the existing file but instead wrapped >>>>> it, was that we don't have explicit legal approval for doing derivative work >>>>> for these 3rd party files. Maybe it's ok, maybe it's not, I will not be the >>>>> person saying it is ok. >>>> OK, now I got it. I thought we just use the wrappers because we want >>>> to easily integrate the upstream versions. But instead it is only >>>> because we don't want to edit these files because of legal >>>> uncertainties. >>>> >>>> So in that case that means we're also not allowed to edit 'config.sub' >>>> and have to create a wrapper for it, right? >>> Yes, you are correct. We cannot modify these files. >>> >>> As far as I understand, the legal reason for including these files are the explicit exception: >>> >>> # As a special exception to the GNU General Public License, if you >>> # distribute this file as part of a program that contains a >>> # configuration script generated by Autoconf, you may include it under >>> # the same distribution terms that you use for the rest of that program. >>> >>> But this is just a distribution license, not a modification license. >>> >>> From my IANAL point of view, this exception should be enough to disregard if the file is also distributed under GPL2 or GPL3. Unfortunately, as Erik says, our lawyers are apprehensive of GLP3. So while we thought that we could be able to periodically sync these files with upstream (and remove our external "patches" after a while), we have not been able to do so. >> Why do we have these files in our repository in the first place? > Because they are needed by the configure script. They are a sort of runtime libraries for configure, but since they are written as shell scripts, the source code form and the executable form is the same. > > The distribution exception is there exactly since anyone should be able to distribute the files with their configure script. That does not mean that you are allowed to edit it, though. What if we require Autoconf to be installed on the host? Does that solve any problems? dl > /Magnus > >>> So, this fix will need to do the same dance with config.sub as for guess.guess. Unfortunately. :( >>> >>> /Magnus From daniel.daugherty at oracle.com Fri Nov 14 21:30:11 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 14 Nov 2014 14:30:11 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <5464F600.7040601@oracle.com> References: <546151A9.1080100@oracle.com> <5464C3E6.5000309@oracle.com> <5464F600.7040601@oracle.com> Message-ID: <54667463.7000405@oracle.com> > I presume I don't need to sent out another webrev... I have to change my mind on this because this fix needs to be backported to JDK8u-hs-dev. Here's the updated JDK9 webrev: http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/ And here's the JDK8u-hs-dev backport: http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/ Because of improvements to the JDK9 makefiles, a bunch of the anchor text has changed. The best way to sanity check the backport is to download the two patch files and look at them in your favorite diff tool: http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/hotspot.patch http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/8033602_for_jdk8u_hs_dev.patch I need just one sanity check on the backport... Thanks, in advance, for any comments, questions or suggestions. Dan On 11/13/14 11:18 AM, Daniel D. Daugherty wrote: > Magnus, > > Thanks for the review! > > Replies embedded below... > > On 11/13/14 7:44 AM, Magnus Ihse Bursie wrote: >> On 2014-11-11 01:00, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>> Yes, it is a small fix, but it is in Makefiles so feel free to >>> run screaming from the room... :-) On the plus side the fix does >>> delete two work around source files (Coleen would say that's a >>> Good Thing (TM)!) >> >> ... but you're only deleting the make files? > > Good catch! Looks like when I resurrected this fix from my JDK8 > queue I missed a couple of deletes. > > >> src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and >> src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c >> could be deleted as well, right? > > Yes, these should be deleted and I'll do that in this fix. > Since these are two deletes of files that can no longer be > built anyway, I presume I don't need to sent out another > webrev... > > >> >> Good idea for the fix, anyway. I opened >> https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a >> similar solution in configure. > > Sounds good to me. > > Dan > > >> >> /Magnus On 11/10/14 5:00 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a Solaris Full Debug Symbols (FDS) fix ready for review. > Yes, it is a small fix, but it is in Makefiles so feel free to > run screaming from the room... :-) On the plus side the fix does > delete two work around source files (Coleen would say that's a > Good Thing (TM)!) > > The fix is to detect the version of GNU objcopy that is being > used on the machine and only enable Full Debug Symbols when that > version is 2.21.1 or newer. If you don't have the right version, > then the build drops back to pre-FDS build configs with a message > like this: > > WARNING: /usr/sfw/bin/gobjcopy --version info: > WARNING: GNU objcopy 2.15 > WARNING: an objcopy version of 2.21.1 or newer is needed to create valid .debuginfo files. > WARNING: ignoring above objcopy command. > WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC version. > WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 version. > WARNING: Solaris 11 Update 1 contains the correct version. > INFO: no objcopy cmd found so cannot create .debuginfo files. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 > > This work is being tracked by the following bug IDs: > > JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC > https://bugs.openjdk.java.net/browse/JDK-8033602 > > JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on Solaris X86 > https://bugs.openjdk.java.net/browse/JDK-8034005 > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ > > Testing: > > - JPRT test jobs to verify that the current JPRT Solaris hosts > are happy > - local builds on my Solaris 10 X86 machine to verify that the > wrong version of GNU objcopy is caught > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From dmitry.samersoff at oracle.com Sat Nov 15 18:57:10 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 15 Nov 2014 21:57:10 +0300 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <54667463.7000405@oracle.com> References: <546151A9.1080100@oracle.com> <5464C3E6.5000309@oracle.com> <5464F600.7040601@oracle.com> <54667463.7000405@oracle.com> Message-ID: <5467A206.7020105@oracle.com> Dan, The fix looks good for me. -Dmitry On 2014-11-15 00:30, Daniel D. Daugherty wrote: >> I presume I don't need to sent out another webrev... > > I have to change my mind on this because this fix needs to be > backported to JDK8u-hs-dev. > > Here's the updated JDK9 webrev: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/ > > And here's the JDK8u-hs-dev backport: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/ > > Because of improvements to the JDK9 makefiles, a bunch of the > anchor text has changed. The best way to sanity check the backport > is to download the two patch files and look at them in your favorite > diff tool: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/hotspot.patch > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/8033602_for_jdk8u_hs_dev.patch > > > I need just one sanity check on the backport... > > Thanks, in advance, for any comments, questions or suggestions. > > Dan > > > On 11/13/14 11:18 AM, Daniel D. Daugherty wrote: >> Magnus, >> >> Thanks for the review! >> >> Replies embedded below... >> >> On 11/13/14 7:44 AM, Magnus Ihse Bursie wrote: >>> On 2014-11-11 01:00, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>>> Yes, it is a small fix, but it is in Makefiles so feel free to >>>> run screaming from the room... :-) On the plus side the fix does >>>> delete two work around source files (Coleen would say that's a >>>> Good Thing (TM)!) >>> >>> ... but you're only deleting the make files? >> >> Good catch! Looks like when I resurrected this fix from my JDK8 >> queue I missed a couple of deletes. >> >> >>> src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and >>> src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c >>> could be deleted as well, right? >> >> Yes, these should be deleted and I'll do that in this fix. >> Since these are two deletes of files that can no longer be >> built anyway, I presume I don't need to sent out another >> webrev... >> >> >>> >>> Good idea for the fix, anyway. I opened >>> https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a >>> similar solution in configure. >> >> Sounds good to me. >> >> Dan >> >> >>> >>> /Magnus > > > > On 11/10/14 5:00 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >> Yes, it is a small fix, but it is in Makefiles so feel free to >> run screaming from the room... :-) On the plus side the fix does >> delete two work around source files (Coleen would say that's a >> Good Thing (TM)!) >> >> The fix is to detect the version of GNU objcopy that is being >> used on the machine and only enable Full Debug Symbols when that >> version is 2.21.1 or newer. If you don't have the right version, >> then the build drops back to pre-FDS build configs with a message >> like this: >> >> WARNING: /usr/sfw/bin/gobjcopy --version info: >> WARNING: GNU objcopy 2.15 >> WARNING: an objcopy version of 2.21.1 or newer is needed to create > valid .debuginfo files. >> WARNING: ignoring above objcopy command. >> WARNING: patch 149063-01 or newer contains the correct Solaris 10 > SPARC version. >> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 > version. >> WARNING: Solaris 11 Update 1 contains the correct version. >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >> >> This work is being tracked by the following bug IDs: >> >> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >> https://bugs.openjdk.java.net/browse/JDK-8033602 >> >> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on > Solaris X86 >> https://bugs.openjdk.java.net/browse/JDK-8034005 >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >> >> Testing: >> >> - JPRT test jobs to verify that the current JPRT Solaris hosts >> are happy >> - local builds on my Solaris 10 X86 machine to verify that the >> wrong version of GNU objcopy is caught >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan -- 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 daniel.daugherty at oracle.com Sat Nov 15 19:06:59 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 15 Nov 2014 12:06:59 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <5467A206.7020105@oracle.com> References: <546151A9.1080100@oracle.com> <5464C3E6.5000309@oracle.com> <5464F600.7040601@oracle.com> <54667463.7000405@oracle.com> <5467A206.7020105@oracle.com> Message-ID: <5467A453.8020001@oracle.com> Thanks! Dan On 11/15/14 11:57 AM, Dmitry Samersoff wrote: > Dan, > > The fix looks good for me. > > -Dmitry > > > On 2014-11-15 00:30, Daniel D. Daugherty wrote: >>> I presume I don't need to sent out another webrev... >> I have to change my mind on this because this fix needs to be >> backported to JDK8u-hs-dev. >> >> Here's the updated JDK9 webrev: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/ >> >> And here's the JDK8u-hs-dev backport: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/ >> >> Because of improvements to the JDK9 makefiles, a bunch of the >> anchor text has changed. The best way to sanity check the backport >> is to download the two patch files and look at them in your favorite >> diff tool: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/hotspot.patch >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/8033602_for_jdk8u_hs_dev.patch >> >> >> I need just one sanity check on the backport... >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan >> >> >> On 11/13/14 11:18 AM, Daniel D. Daugherty wrote: >>> Magnus, >>> >>> Thanks for the review! >>> >>> Replies embedded below... >>> >>> On 11/13/14 7:44 AM, Magnus Ihse Bursie wrote: >>>> On 2014-11-11 01:00, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>>>> Yes, it is a small fix, but it is in Makefiles so feel free to >>>>> run screaming from the room... :-) On the plus side the fix does >>>>> delete two work around source files (Coleen would say that's a >>>>> Good Thing (TM)!) >>>> ... but you're only deleting the make files? >>> Good catch! Looks like when I resurrected this fix from my JDK8 >>> queue I missed a couple of deletes. >>> >>> >>>> src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and >>>> src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c >>>> could be deleted as well, right? >>> Yes, these should be deleted and I'll do that in this fix. >>> Since these are two deletes of files that can no longer be >>> built anyway, I presume I don't need to sent out another >>> webrev... >>> >>> >>>> Good idea for the fix, anyway. I opened >>>> https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a >>>> similar solution in configure. >>> Sounds good to me. >>> >>> Dan >>> >>> >>>> /Magnus >> >> >> On 11/10/14 5:00 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>> Yes, it is a small fix, but it is in Makefiles so feel free to >>> run screaming from the room... :-) On the plus side the fix does >>> delete two work around source files (Coleen would say that's a >>> Good Thing (TM)!) >>> >>> The fix is to detect the version of GNU objcopy that is being >>> used on the machine and only enable Full Debug Symbols when that >>> version is 2.21.1 or newer. If you don't have the right version, >>> then the build drops back to pre-FDS build configs with a message >>> like this: >>> >>> WARNING: /usr/sfw/bin/gobjcopy --version info: >>> WARNING: GNU objcopy 2.15 >>> WARNING: an objcopy version of 2.21.1 or newer is needed to create >> valid .debuginfo files. >>> WARNING: ignoring above objcopy command. >>> WARNING: patch 149063-01 or newer contains the correct Solaris 10 >> SPARC version. >>> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 >> version. >>> WARNING: Solaris 11 Update 1 contains the correct version. >>> INFO: no objcopy cmd found so cannot create .debuginfo files. >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >>> >>> This work is being tracked by the following bug IDs: >>> >>> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >>> https://bugs.openjdk.java.net/browse/JDK-8033602 >>> >>> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on >> Solaris X86 >>> https://bugs.openjdk.java.net/browse/JDK-8034005 >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >>> >>> Testing: >>> >>> - JPRT test jobs to verify that the current JPRT Solaris hosts >>> are happy >>> - local builds on my Solaris 10 X86 machine to verify that the >>> wrong version of GNU objcopy is caught >>> >>> Thanks, in advance, for any comments, questions or suggestions. >>> >>> Dan > From magnus.ihse.bursie at oracle.com Mon Nov 17 12:11:16 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 17 Nov 2014 13:11:16 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <5466699D.2050808@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <0B65D4AA-B876-4106-9CA0-2F2AF5F43F83@oracle.com> <62FBBB3A-B1CE-43D8-9D99-3087BDDBDC37@oracle.com> <5466699D.2050808@oracle.com> Message-ID: <5469E5E4.7040606@oracle.com> On 2014-11-14 21:44, Dean Long wrote: > >> >> The distribution exception is there exactly since anyone should be >> able to distribute the files with their configure script. That does >> not mean that you are allowed to edit it, though. > What if we require Autoconf to be installed on the host? Does that > solve any problems? No, unfortunately not. /Magnus From patrick at reini.net Mon Nov 17 12:16:55 2014 From: patrick at reini.net (Patrick Reinhart) Date: Mon, 17 Nov 2014 13:16:55 +0100 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched In-Reply-To: <01171662-3471-40AE-B574-A9FA4675E052@reini.net> References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> <5464B729.9090101@oracle.com> <331C0A42-4ECF-4FC0-8D3E-287BA7EDC50F@reini.net> <54656693.4090305@oracle.com> <6D4AD6B5-7267-4FD0-A258-A9AEA86B7954@reini.net> <5465B6F3.70907@oracle.com> <3DDA1BFA-F018-4767-809F-4C048B5BDA52@reini.net> <0D9ED57F-70A5-4B99-B873-C0D2AA4C2478@oracle.com> <5C5934B6-741C-4EDF-A1AA-4B025F159F57@reini.net> <5465CAB0.6090805@oracle.com> <71A06C35-1AF2-474E-8643-437DAACB22B7@reini.net> <01171662-3471-40AE-B574-A9FA4675E052@reini.net> Message-ID: <0E16D9F2-7B47-4594-AFD7-490426B0C4D5@reini.net> Hi Magnus, Did you get the time to look into the patch already? Is there something I can do? Cheers Patrick From christian.thalinger at oracle.com Tue Nov 18 00:59:05 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 17 Nov 2014 16:59:05 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <5469E5E4.7040606@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <0B65D4AA-B876-4106-9CA0-2F2AF5F43F83@oracle.com> <62FBBB3A-B1CE-43D8-9D99-3087BDDBDC37@oracle.com> <5466699D.2050808@oracle.com> <5469E5E4.7040606@oracle.com> Message-ID: > On Nov 17, 2014, at 4:11 AM, Magnus Ihse Bursie wrote: > > On 2014-11-14 21:44, Dean Long wrote: >> >>> >>> The distribution exception is there exactly since anyone should be able to distribute the files with their configure script. That does not mean that you are allowed to edit it, though. >> What if we require Autoconf to be installed on the host? Does that solve any problems? > No, unfortunately not. Why not? > > /Magnus From dean.long at oracle.com Tue Nov 18 03:20:16 2014 From: dean.long at oracle.com (Dean Long) Date: Mon, 17 Nov 2014 19:20:16 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <0B65D4AA-B876-4106-9CA0-2F2AF5F43F83@oracle.com> <62FBBB3A-B1CE-43D8-9D99-3087BDDBDC37@oracle.com> <5466699D.2050808@oracle.com> <5469E5E4.7040606@oracle.com> Message-ID: <546ABAF0.1030706@oracle.com> On 11/17/2014 4:59 PM, Christian Thalinger wrote: >> On Nov 17, 2014, at 4:11 AM, Magnus Ihse Bursie wrote: >> >> On 2014-11-14 21:44, Dean Long wrote: >>>> The distribution exception is there exactly since anyone should be able to distribute the files with their configure script. That does not mean that you are allowed to edit it, though. >>> What if we require Autoconf to be installed on the host? Does that solve any problems? >> No, unfortunately not. > Why not? Yes, not just any version of Autoconf, but a newer version with aarch64 support. Then we wouldn't have to edit the script, right? dl >> /Magnus From erik.joelsson at oracle.com Tue Nov 18 08:32:42 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 18 Nov 2014 09:32:42 +0100 Subject: RFR: JDK-8065183: Add --with-copyright-year option to configure Message-ID: <546B042A.6020000@oracle.com> Hello, Please review this small change, adding a configure option for changing the COPYRIGHT_YEAR value. Bug: https://bugs.openjdk.java.net/browse/JDK-8065183 Webrev: http://cr.openjdk.java.net/~erikj/8065183/webrev.root.01/ The same patch applies cleanly to jdk8u, except for generated-configure of course, and I would like to backport this to 8u. /Erik From erik.joelsson at oracle.com Tue Nov 18 12:41:35 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 18 Nov 2014 13:41:35 +0100 Subject: RFR: JDK-8058631 Rename posix to unix in build system to match file name changes In-Reply-To: <545A204A.4080301@oracle.com> References: <5422BB6E.1000500@oracle.com> <545A204A.4080301@oracle.com> Message-ID: <546B3E7F.7060704@oracle.com> This version looks good to me. /Erik On 2014-11-05 14:04, Magnus Ihse Bursie wrote: > On 2014-09-24 14:39, Magnus Ihse Bursie wrote: >> After Jigsaw M1, there is a new common "unix" directory structure. We >> have used "posix" in the build system for the same purpose, but this >> leads to unnecessary conversations. Instead, we should use "unix" all >> way through in the build system. >> >> Also, this means that OS_API is slightly misleading -- we're not >> actually checking for an API such as POSIX, but the general category >> of OSes. I'll rename the *_OS_API to *_OS_TYPE instead. The "winapi" >> OS_API was never used, and is removed -- we only need to check for >> "windows", there's no need to introduce an abstract "winapi" category. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8058631 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8058631-rename-posix-to-unix/webrev.01 > > This fix got stuck far down the priority list... > > It was pointed out to me that OS_API_SRC_DIRS should change name as > well, to match OS_TYPE. This updated webrev contain that fix. I have > also double-checked that no other name changes are needed to keep the > code consistent. > > Updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8058631-rename-posix-to-unix/webrev.02/ > > > /Magnus > From magnus.ihse.bursie at oracle.com Tue Nov 18 14:00:28 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Nov 2014 15:00:28 +0100 Subject: RFR: JDK-8065215 Print warning summary at end of configure Message-ID: <546B50FC.9090600@oracle.com> Warnings in configure tends to just fly by quickly and be buried in the verbose autoconf output. We could with a simple trick repeat all those warnings (if any) at the end of configure, where they will be more easily spotted. Bug: https://bugs.openjdk.java.net/browse/JDK-8065215 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8065215-print-warning-at-end-of-configure/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 18 14:01:46 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Nov 2014 15:01:46 +0100 Subject: RFR: JDK-8065183: Add --with-copyright-year option to configure In-Reply-To: <546B042A.6020000@oracle.com> References: <546B042A.6020000@oracle.com> Message-ID: <546B514A.8030308@oracle.com> On 2014-11-18 09:32, Erik Joelsson wrote: > Hello, > > Please review this small change, adding a configure option for > changing the COPYRIGHT_YEAR value. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065183 > Webrev: http://cr.openjdk.java.net/~erikj/8065183/webrev.root.01/ > > The same patch applies cleanly to jdk8u, except for > generated-configure of course, and I would like to backport this to 8u. Looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 18 14:14:42 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Nov 2014 15:14:42 +0100 Subject: RFR: JDK-8065215 Print warning summary at end of configure In-Reply-To: <546B50FC.9090600@oracle.com> References: <546B50FC.9090600@oracle.com> Message-ID: <546B5452.9010005@oracle.com> On 2014-11-18 15:00, Magnus Ihse Bursie wrote: > Warnings in configure tends to just fly by quickly and be buried in > the verbose autoconf output. > > We could with a simple trick repeat all those warnings (if any) at the > end of configure, where they will be more easily spotted. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065215 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8065215-print-warning-at-end-of-configure/webrev.01 As an example, the last part of the configure output might look like this: Tools summary: * Boot JDK: java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode) (at /localhome/java/jdk-8-fcs-bin-b132-linux-x64) * Toolchain: gcc (GNU Compiler Collection) * C Compiler: Version 4.8.2 (at /usr/bin/gcc) * C++ Compiler: Version 4.8.2 (at /usr/bin/g++) Build performance summary: * Cores to use: 14 * Memory limit: 28134 MB WARNING: The result of this configuration has overridden an older configuration. You *should* run 'make clean' to make sure you get a proper build. Failure to do so might result in strange build problems. The following warnings were produced. Repeated here for convenience: WARNING: Option --with-custom-make-dir is deprecated and will be ignored. /Magnus From tim.bell at oracle.com Tue Nov 18 15:02:37 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 18 Nov 2014 07:02:37 -0800 Subject: RFR: JDK-8065183: Add --with-copyright-year option to configure In-Reply-To: <546B042A.6020000@oracle.com> References: <546B042A.6020000@oracle.com> Message-ID: <546B5F8D.20409@oracle.com> Hi Erik: > Please review this small change, adding a configure option for > changing the COPYRIGHT_YEAR value. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065183 > Webrev: http://cr.openjdk.java.net/~erikj/8065183/webrev.root.01/ > > The same patch applies cleanly to jdk8u, except for > generated-configure of course, and I would like to backport this to 8u. Looks good to me. /Tim From magnus.ihse.bursie at oracle.com Tue Nov 18 15:36:25 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Nov 2014 16:36:25 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <0B65D4AA-B876-4106-9CA0-2F2AF5F43F83@oracle.com> <62FBBB3A-B1CE-43D8-9D99-3087BDDBDC37@oracle.com> <5466699D.2050808@oracle.com> <5469E5E4.7040606@oracle.com> Message-ID: <546B6779.9050608@oracle.com> On 2014-11-18 01:59, Christian Thalinger wrote: >> On Nov 17, 2014, at 4:11 AM, Magnus Ihse Bursie wrote: >> >> On 2014-11-14 21:44, Dean Long wrote: >>>> The distribution exception is there exactly since anyone should be able to distribute the files with their configure script. That does not mean that you are allowed to edit it, though. >>> What if we require Autoconf to be installed on the host? Does that solve any problems? >> No, unfortunately not. > Why not? Autoconf picks up these files automatically from the build-aux directory. That's also the reason we need to rename the original files and provide wrappers with the same name, since we can't even redirect that functionality to a file with another name. /Magnus From tim.bell at oracle.com Tue Nov 18 15:56:18 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 18 Nov 2014 07:56:18 -0800 Subject: RFR: JDK-8058631 Rename posix to unix in build system to match file name changes In-Reply-To: <546B3E7F.7060704@oracle.com> References: <5422BB6E.1000500@oracle.com> <545A204A.4080301@oracle.com> <546B3E7F.7060704@oracle.com> Message-ID: <546B6C22.6080501@oracle.com> Magnus: Looks good to me as well. Tim On 11/18/14 04:41, Erik Joelsson wrote: > This version looks good to me. > > /Erik > > On 2014-11-05 14:04, Magnus Ihse Bursie wrote: >> On 2014-09-24 14:39, Magnus Ihse Bursie wrote: >>> After Jigsaw M1, there is a new common "unix" directory structure. >>> We have used "posix" in the build system for the same purpose, but >>> this leads to unnecessary conversations. Instead, we should use >>> "unix" all way through in the build system. >>> >>> Also, this means that OS_API is slightly misleading -- we're not >>> actually checking for an API such as POSIX, but the general category >>> of OSes. I'll rename the *_OS_API to *_OS_TYPE instead. The "winapi" >>> OS_API was never used, and is removed -- we only need to check for >>> "windows", there's no need to introduce an abstract "winapi" category. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8058631 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8058631-rename-posix-to-unix/webrev.01 >> >> This fix got stuck far down the priority list... >> >> It was pointed out to me that OS_API_SRC_DIRS should change name as >> well, to match OS_TYPE. This updated webrev contain that fix. I have >> also double-checked that no other name changes are needed to keep the >> code consistent. >> >> Updated webrev: >> http://cr.openjdk.java.net/~ihse/JDK-8058631-rename-posix-to-unix/webrev.02/ >> >> >> /Magnus >> > From omajid at redhat.com Tue Nov 18 16:57:32 2014 From: omajid at redhat.com (Omair Majid) Date: Tue, 18 Nov 2014 11:57:32 -0500 Subject: Unused DEBUG_CLASSFILES variable in makefiles In-Reply-To: <543BBF40.5050100@oracle.com> References: <20141010165203.GE2698@redhat.com> <543B9414.1080108@oracle.com> <543BBF40.5050100@oracle.com> Message-ID: <20141118165732.GC4240@redhat.com> * Magnus Ihse Bursie [2014-10-13 07:49]: > On 2014-10-13 10:57, Erik Joelsson wrote: > >I think it's still used by the hotspot makefiles (sa-jdi.jar). Seems weird > >that we still set it in configure but then ignore the value in the jdk > >build. I would vote for resurrecting the option. > [...] > >I'm not sure if even more debug levels is the right way to go. It seems > >hard to name and that probably means it will be hard to understand. > >Perhaps completely separating native debug level and java debug level > >would make more sense? > > I'm not sure "resurrecting" (which actually means adding functionality which > has been gone for quite some time now) is good, since it adds to the > complexity. Well, we do need the debug information, but I am not at all tied to specific implementation. I would be happy to try and implement something that takes a different approach than resurrecting the feature. > However, there have been recurring requests of having more control of debug > vs release builds, and I think we need to address them in some way. Any suggestions for a suitable implementation? > As you > say, one dimension is asking wether java or native (or both) should be > compiled as debug. Another typical request is to separate hotspot debug > level from the rest of the JDK (this goes both ways). Also, debugging can > come in several "levels", depending on what tradeoff between > speed/similarity to release vs amount of debug support you need. >From the point of Linux distributions, we traditionally use the maximum debugging information that we can get with the minimal performance impact. In Fedora, we have used 'release' builds but with debugging enabled everywhere (hotspot, java files and other native code in the JDK). > Maybe it should be possible to set debugging level per module? IMO, that might be too fine-grained, but I don't really have any objections against it. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From aph at redhat.com Tue Nov 18 17:06:21 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 18 Nov 2014 17:06:21 +0000 Subject: RFR: AARCH64: 8064357: Top-level JDK changes In-Reply-To: <5464C85C.50908@redhat.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> <5464C85C.50908@redhat.com> Message-ID: <546B7C8D.7050409@redhat.com> On 11/13/2014 03:03 PM, Andrew Haley wrote: > On 11/13/2014 03:00 PM, Magnus Ihse Bursie wrote: >> >> hg mv config.sub autoconf-config.sub >> hg cp config.guess config.sub >> >> and then fix config.sub so that it runs autoconf-config.sub and modifies >> the output to what you expect it to be from config.sub when running on >> this particular platform. > > OK, I'll do that. Thanks! I've kicked around a few ideas, and I think this is right now. http://cr.openjdk.java.net/~aph/aarch64-8064357-3/ Thanks, Andrew. From eric.caspole at amd.com Tue Nov 18 17:22:30 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Tue, 18 Nov 2014 12:22:30 -0500 Subject: JDK-8028407 / gmake 4.0 Message-ID: <546B8056.4000004@amd.com> Hi build-dev, Is there any change this fix will make it into JDK 8 update repos? https://bugs.openjdk.java.net/browse/JDK-8028407 As far as I can tell it is only in JDK 9. Now Fedora 21 includes gmake 4.0. Thanks, Eric From christian.thalinger at oracle.com Tue Nov 18 18:09:07 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 18 Nov 2014 10:09:07 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <546B6779.9050608@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <0B65D4AA-B876-4106-9CA0-2F2AF5F43F83@oracle.com> <62FBBB3A-B1CE-43D8-9D99-3087BDDBDC37@oracle.com> <5466699D.2050808@oracle.com> <5469E5E4.7040606@oracle.com> <546B6779.9050608@oracle.com> Message-ID: <94199476-15AD-4226-8C18-2708F6F94DC3@oracle.com> > On Nov 18, 2014, at 7:36 AM, Magnus Ihse Bursie wrote: > > On 2014-11-18 01:59, Christian Thalinger wrote: >>> On Nov 17, 2014, at 4:11 AM, Magnus Ihse Bursie wrote: >>> >>> On 2014-11-14 21:44, Dean Long wrote: >>>>> The distribution exception is there exactly since anyone should be able to distribute the files with their configure script. That does not mean that you are allowed to edit it, though. >>>> What if we require Autoconf to be installed on the host? Does that solve any problems? >>> No, unfortunately not. >> Why not? > > Autoconf picks up these files automatically from the build-aux directory. That's also the reason we need to rename the original files and provide wrappers with the same name, since we can't even redirect that functionality to a file with another name. So do I understand you correctly that the files we need are automatically copied into the workspace but since we want to use our own, old versions we renamed them and use these instead? > > /Magnus From henry.jen at oracle.com Tue Nov 18 19:29:30 2014 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 18 Nov 2014 11:29:30 -0800 Subject: JDK-8028407 / gmake 4.0 In-Reply-To: <546B8056.4000004@amd.com> References: <546B8056.4000004@amd.com> Message-ID: <546B9E1A.6070306@oracle.com> I have seen quite a few reports on this issue, and I don't know any good reason not to. A backport request JDK-8065267 is created, I will send out a request to get proper approval. Cheers, Henry On 11/18/2014 09:22 AM, Eric Caspole wrote: > Hi build-dev, > Is there any change this fix will make it into JDK 8 update repos? > > https://bugs.openjdk.java.net/browse/JDK-8028407 > > As far as I can tell it is only in JDK 9. Now Fedora 21 includes gmake 4.0. > Thanks, > Eric From erik.joelsson at oracle.com Wed Nov 19 08:56:09 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Nov 2014 09:56:09 +0100 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <94199476-15AD-4226-8C18-2708F6F94DC3@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <0B65D4AA-B876-4106-9CA0-2F2AF5F43F83@oracle.com> <62FBBB3A-B1CE-43D8-9D99-3087BDDBDC37@oracle.com> <5466699D.2050808@oracle.com> <5469E5E4.7040606@oracle.com> <546B6779.9050608@oracle.com> <94199476-15AD-4226-8C18-2708F6F94DC3@oracle.com> Message-ID: <546C5B29.8050602@oracle.com> On 2014-11-18 19:09, Christian Thalinger wrote: >> On Nov 18, 2014, at 7:36 AM, Magnus Ihse Bursie wrote: >> >> On 2014-11-18 01:59, Christian Thalinger wrote: >>>> On Nov 17, 2014, at 4:11 AM, Magnus Ihse Bursie wrote: >>>> >>>> On 2014-11-14 21:44, Dean Long wrote: >>>>>> The distribution exception is there exactly since anyone should be able to distribute the files with their configure script. That does not mean that you are allowed to edit it, though. >>>>> What if we require Autoconf to be installed on the host? Does that solve any problems? >>>> No, unfortunately not. >>> Why not? >> Autoconf picks up these files automatically from the build-aux directory. That's also the reason we need to rename the original files and provide wrappers with the same name, since we can't even redirect that functionality to a file with another name. > So do I understand you correctly that the files we need are automatically copied into the workspace but since we want to use our own, old versions we renamed them and use these instead? No, I will try to clarify. Autoconf is a tool that takes one (or more) input files (written in m4 macro language) and generates a shell script, often named "configure". This shell script is what you would typically run to configure your project. Autoconf defines an API of m4 macros specifically for configure scripts which is basically what makes it useful. Most of these macros are expanded into the generated configure script. However, for reasons unknown to us, some of the more complex functionality has been split out into separate shell script "library" files. These library files, often referred to as "build-aux" are supposed to be distributed with the project source code, along with the generated configure script. We distribute them in common/autoconf/build-aux. These files can be found in the source distribution of autoconf or by downloading from the official scm repo for them. They are not part of the binary distribution of autoconf on my Ubuntu system at least. For this reason, it wouldn't help requiring autoconf to be installed as that wouldn't provide the files. For non GPL projects to be able to distribute the files in build-aux, they come with a special exception to GPL, which basically allows them to be freely distributed as long as they are part of a configure script. This exception does not seem to give any exception for deriving work from them. /Erik From tim.bell at oracle.com Wed Nov 19 17:03:48 2014 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 19 Nov 2014 09:03:48 -0800 Subject: RFR: JDK-8065215 Print warning summary at end of configure In-Reply-To: <546B5452.9010005@oracle.com> References: <546B50FC.9090600@oracle.com> <546B5452.9010005@oracle.com> Message-ID: <546CCD74.3090501@oracle.com> Magnus: >> Warnings in configure tends to just fly by quickly and be buried in >> the verbose autoconf output. >> >> We could with a simple trick repeat all those warnings (if any) at >> the end of configure, where they will be more easily spotted. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8065215 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8065215-print-warning-at-end-of-configure/webrev.01 > > As an example, the last part of the configure output might look like > this: > > Tools summary: > * Boot JDK: java version "1.8.0" Java(TM) SE Runtime Environment > (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, > mixed mode) (at /localhome/java/jdk-8-fcs-bin-b132-linux-x64) > * Toolchain: gcc (GNU Compiler Collection) > * C Compiler: Version 4.8.2 (at /usr/bin/gcc) > * C++ Compiler: Version 4.8.2 (at /usr/bin/g++) > > Build performance summary: > * Cores to use: 14 > * Memory limit: 28134 MB > > WARNING: The result of this configuration has overridden an older > configuration. You *should* run 'make clean' to make sure you get a > proper build. Failure to do so might result in strange build problems. > > The following warnings were produced. Repeated here for convenience: > WARNING: Option --with-custom-make-dir is deprecated and will be ignored. Looks good to me. /Tim From aph at redhat.com Wed Nov 19 17:49:40 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Nov 2014 17:49:40 +0000 Subject: RFR: AARCH64: 8064357: Top-level JDK changes In-Reply-To: <20141118180315.GB22927@redhat.com> References: <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> <5464C85C.50908@redhat.com> <546B7C8D.7050409@redhat.com> <20141118180315.GB22927@redhat.com> Message-ID: <546CD834.50004@redhat.com> I think this covers everything that reviewers have mentioned: http://cr.openjdk.java.net/~aph/aarch64-8064357-4/ Andrew. From patrick at reini.net Wed Nov 19 18:41:57 2014 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 19 Nov 2014 19:41:57 +0100 Subject: RFR(M): 8057538: Sponsor for back port of --with-freetype-src searched In-Reply-To: <0E16D9F2-7B47-4594-AFD7-490426B0C4D5@reini.net> References: <17F985A3-7B08-4A12-A43B-771751B924B1@reini.net> <6F72509E-72F6-43D6-B91C-A1CD02DF88CD@reini.net> <5464B729.9090101@oracle.com> <331C0A42-4ECF-4FC0-8D3E-287BA7EDC50F@reini.net> <54656693.4090305@oracle.com> <6D4AD6B5-7267-4FD0-A258-A9AEA86B7954@reini.net> <5465B6F3.70907@oracle.com> <3DDA1BFA-F018-4767-809F-4C048B5BDA52@reini.net> <0D9ED57F-70A5-4B99-B873-C0D2AA4C2478@oracle.com> <5C5934B6-741C-4EDF-A1AA-4B025F159F57@reini.net> <5465CAB0.6090805@oracle.com> <71A06C35-1AF2-474E-8643-437DAACB22B7@reini.net> <01171662-3471-40AE-B574-A9FA4675E052@reini.net> <0E16D9F2-7B47-4594-AFD7-490426B0C4D5@reini.net> Message-ID: Hi Magnus, Did you had the time to check my back port jet? Is there anything I can do to help? It would greatly improve the Adopt OpenJDK program to also having the JDK 8 built in the same ease as the JDK 9. Best regards Patrick > Am 17.11.2014 um 13:16 schrieb Patrick Reinhart : > > Hi Magnus, > > Did you get the time to look into the patch already? Is there something I can do? > > Cheers > > Patrick > From roger.riggs at oracle.com Wed Nov 19 20:47:35 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 19 Nov 2014 15:47:35 -0500 Subject: RFR 8u40: 8065397: Remove ExtendedPlatformComponent.java from EXFILES list Message-ID: <546D01E7.1020508@oracle.com> Please review a cleanup for the 8u40 build. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-build-8065353/ Thanks, Roger From mandy.chung at oracle.com Wed Nov 19 20:53:53 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Nov 2014 12:53:53 -0800 Subject: RFR 8u40: 8065397: Remove ExtendedPlatformComponent.java from EXFILES list In-Reply-To: <546D01E7.1020508@oracle.com> References: <546D01E7.1020508@oracle.com> Message-ID: <546D0361.5020703@oracle.com> On 11/19/2014 12:47 PM, roger riggs wrote: > Please review a cleanup for the 8u40 build. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-build-8065353/ Looks okay to me. Are you also asking for 8u40 putback approval as well? Or maybe you are thinking to send a separate 8u40 request? Mandy From roger.riggs at oracle.com Wed Nov 19 21:18:53 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 19 Nov 2014 16:18:53 -0500 Subject: [8u40] Request for approval for CR 8065397 - Remove ExtendedPlatformComponent.java from EXFILES list In-Reply-To: <546D0361.5020703@oracle.com> References: <546D01E7.1020508@oracle.com> <546D0361.5020703@oracle.com> Message-ID: <546D093D.3020806@oracle.com> With correct subject line, requesting approval for: >> Please review a cleanup for the 8u40 build. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-build-8065353/ > > Looks okay to me. > > Are you also asking for 8u40 putback approval as well? Or maybe you > are thinking to send a separate 8u40 request? > > Mandy > From christian.thalinger at oracle.com Thu Nov 20 00:28:57 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 19 Nov 2014 16:28:57 -0800 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <546C5B29.8050602@oracle.com> References: <545CFFA9.4070107@redhat.com> <545D0290.5080307@oracle.com> <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <0B65D4AA-B876-4106-9CA0-2F2AF5F43F83@oracle.com> <62FBBB3A-B1CE-43D8-9D99-3087BDDBDC37@oracle.com> <5466699D.2050808@oracle.com> <5469E5E4.7040606@oracle.com> <546B6779.9050608@oracle.com> <94199476-15AD-4226-8C18-2708F6F94DC3@oracle.com> <546C5B29.8050602@oracle.com> Message-ID: <1A79BF26-783C-4026-92B6-2150C3C49B4D@oracle.com> > On Nov 19, 2014, at 12:56 AM, Erik Joelsson wrote: > > > On 2014-11-18 19:09, Christian Thalinger wrote: >>> On Nov 18, 2014, at 7:36 AM, Magnus Ihse Bursie wrote: >>> >>> On 2014-11-18 01:59, Christian Thalinger wrote: >>>>> On Nov 17, 2014, at 4:11 AM, Magnus Ihse Bursie wrote: >>>>> >>>>> On 2014-11-14 21:44, Dean Long wrote: >>>>>>> The distribution exception is there exactly since anyone should be able to distribute the files with their configure script. That does not mean that you are allowed to edit it, though. >>>>>> What if we require Autoconf to be installed on the host? Does that solve any problems? >>>>> No, unfortunately not. >>>> Why not? >>> Autoconf picks up these files automatically from the build-aux directory. That's also the reason we need to rename the original files and provide wrappers with the same name, since we can't even redirect that functionality to a file with another name. >> So do I understand you correctly that the files we need are automatically copied into the workspace but since we want to use our own, old versions we renamed them and use these instead? > No, I will try to clarify. > > Autoconf is a tool that takes one (or more) input files (written in m4 macro language) and generates a shell script, often named "configure". This shell script is what you would typically run to configure your project. Autoconf defines an API of m4 macros specifically for configure scripts which is basically what makes it useful. Most of these macros are expanded into the generated configure script. > > However, for reasons unknown to us, some of the more complex functionality has been split out into separate shell script "library" files. These library files, often referred to as "build-aux" are supposed to be distributed with the project source code, along with the generated configure script. We distribute them in common/autoconf/build-aux. These files can be found in the source distribution of autoconf or by downloading from the official scm repo for them. They are not part of the binary distribution of autoconf on my Ubuntu system at least. Well, that?s because config.guess and config.sub are part of automake: http://git.savannah.gnu.org/gitweb/?p=automake.git;a=tree;f=lib;hb=HEAD and installed e.g. in this directory on Solaris: $ ls /usr/share/automake-1.10/ acinstall* ansi2knr.1 Automake/ config-ml.in config.sub* depcomp* INSTALL mdate-sh* mkinstalldirs* symlink-tree* ylwrap* am/ ansi2knr.c compile* config.guess* COPYING elisp-comp* install-sh* missing* py-compile* texinfo.tex $ automake --add-missing makes a copy of these files, if necessary: configure.ac:3: the top level configure.ac:3: installing `./config.sub' configure.ac:3: installing `./config.guess' $ ls -l config.* lrwxrwxrwx 1 cthaling staff 37 2014-11-19 16:26 config.guess -> /usr/share/automake-1.10/config.guess* lrwxrwxrwx 1 cthaling staff 35 2014-11-19 16:26 config.sub -> /usr/share/automake-1.10/config.sub* > For this reason, it wouldn't help requiring autoconf to be installed as that wouldn't provide the files. > > For non GPL projects to be able to distribute the files in build-aux, they come with a special exception to GPL, which basically allows them to be freely distributed as long as they are part of a configure script. This exception does not seem to give any exception for deriving work from them. > > /Erik From david.holmes at oracle.com Thu Nov 20 00:40:34 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Nov 2014 10:40:34 +1000 Subject: Unhelpful configure error on OSX for 8u Message-ID: <546D3882.7020106@oracle.com> configure:20727: The C compiler (located as /usr/bin/gcc) does not seem to be the required GCC compiler. configure:20729: The result from running with --version was: "Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1" configure:20731: error: GCC compiler is required. Try setting --with-tools-dir. --- Would be nice if it actually stated what the required gcc version is! I can't see anything in toolchain.m4 README-builds.html is not very helpful in getting an OSX system setup for builds, given the apparent need to downgrade the Xcode tools for 8u :( David From martinrb at google.com Thu Nov 20 01:18:38 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 19 Nov 2014 17:18:38 -0800 Subject: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' In-Reply-To: <546D3ECE.2040500@oracle.com> References: <546C7C2D.3060805@oracle.com> <546CDE30.6030907@oracle.com> <546CFF3C.2030904@oracle.com> <546D0285.3090504@oracle.com> <546D2C7C.5020103@oracle.com> <546D3126.5010301@oracle.com> <546D3ECE.2040500@oracle.com> Message-ID: [+ build-dev] I think I see the problem. By default, a Unix pipeline sadly fails only when the last command fails. In bash, you can change this to a more sensible default via set -o pipefail but that's not portable enough for openjdk. $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ | $(SED) -e '/^#/d' -e '/^$$$$/d' \ -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ -e 's/^[ ]*//;s/[ ]*$$$$//' \ -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ On Wed, Nov 19, 2014 at 5:07 PM, huizhe wang wrote: > > On 11/19/2014 4:09 PM, Mandy Chung wrote: >> >> >> On 11/19/2014 3:49 PM, Mandy Chung wrote: >>> >>> >>> On 11/19/2014 12:50 PM, Daniel Fuchs wrote: >>>> >>>> On 11/19/14 9:36 PM, Mandy Chung wrote: >>>>> >>>>> resources.jar will be gone when we move to the modular runtime image >>>>> (JEP 220 [1]). >>>>> JDK-8065138 and JDK-8065365 will become non-issue in JDK 9. >>>> >>>> Do you mean that the property files will no longer be stripped of their >>>> comments? >>> >>> >>> (sorry for my delay in reply as I was trying to get the number of the >>> resources in the modular image vs resources.jar but got distracted.) >>> >>> The current version copies all bytes when generating the modular image. >>> This is a good question whether we should strip off the comments when >>> writing to the modular runtime image. I think we should look at the >>> footprint and any performance saving and determine if we should do the same >>> in JDK 9. >>> >> >> I looked at the exploded image under BUILD_OUTPUTDIR/jdk/modules/java.xml >> and found that the comments of Encodings.properties are stripped. I was >> confused with the mention of resources.jar that I assume it was a step >> stripping the comments before writing to resources.jar. This is still >> an issue in jigsaw m2 I believe. >> >> Where does the build strip the comments? > > > A previous issue was that the build process strips off anything after '#' > when copying properties files. In JDK8: > jaxp/make/BuildJaxp.gmk: > $(JAXP_OUTPUTDIR)/classes/%.properties: $(JAXP_TOPDIR)/src/%.properties > $(MKDIR) -p $(@D) > $(RM) $@ $@.tmp > $(CAT) $< | LANG=C $(NAWK) '{ sub(/#.*$$/,"#"); print }' > $@.tmp > $(MV) $@.tmp $@ > > This was fixed in JDK 9. The per-repo process was removed. It looks like > the properties processing process is now consolidated into > make/common/JavaCompilation.gmk. So the issue Daniel found is new (in terms > of stripping). Search 'properties files' to see the macro. > > Joe > >> >> Mandy >> > From martinrb at google.com Thu Nov 20 01:20:45 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 19 Nov 2014 17:20:45 -0800 Subject: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' In-Reply-To: References: <546C7C2D.3060805@oracle.com> <546CDE30.6030907@oracle.com> <546CFF3C.2030904@oracle.com> <546D0285.3090504@oracle.com> <546D2C7C.5020103@oracle.com> <546D3126.5010301@oracle.com> <546D3ECE.2040500@oracle.com> Message-ID: Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it, but the $(SED)s need it too! On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz wrote: > [+ build-dev] > > I think I see the problem. By default, a Unix pipeline sadly fails > only when the last command fails. In bash, you can change this to a > more sensible default via > set -o pipefail > but that's not portable enough for openjdk. > > $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ > -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ > | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ > | $(SED) -e '/^#/d' -e '/^$$$$/d' \ > -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ > -e 's/^[ ]*//;s/[ ]*$$$$//' \ > -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ > > On Wed, Nov 19, 2014 at 5:07 PM, huizhe wang wrote: >> >> On 11/19/2014 4:09 PM, Mandy Chung wrote: >>> >>> >>> On 11/19/2014 3:49 PM, Mandy Chung wrote: >>>> >>>> >>>> On 11/19/2014 12:50 PM, Daniel Fuchs wrote: >>>>> >>>>> On 11/19/14 9:36 PM, Mandy Chung wrote: >>>>>> >>>>>> resources.jar will be gone when we move to the modular runtime image >>>>>> (JEP 220 [1]). >>>>>> JDK-8065138 and JDK-8065365 will become non-issue in JDK 9. >>>>> >>>>> Do you mean that the property files will no longer be stripped of their >>>>> comments? >>>> >>>> >>>> (sorry for my delay in reply as I was trying to get the number of the >>>> resources in the modular image vs resources.jar but got distracted.) >>>> >>>> The current version copies all bytes when generating the modular image. >>>> This is a good question whether we should strip off the comments when >>>> writing to the modular runtime image. I think we should look at the >>>> footprint and any performance saving and determine if we should do the same >>>> in JDK 9. >>>> >>> >>> I looked at the exploded image under BUILD_OUTPUTDIR/jdk/modules/java.xml >>> and found that the comments of Encodings.properties are stripped. I was >>> confused with the mention of resources.jar that I assume it was a step >>> stripping the comments before writing to resources.jar. This is still >>> an issue in jigsaw m2 I believe. >>> >>> Where does the build strip the comments? >> >> >> A previous issue was that the build process strips off anything after '#' >> when copying properties files. In JDK8: >> jaxp/make/BuildJaxp.gmk: >> $(JAXP_OUTPUTDIR)/classes/%.properties: $(JAXP_TOPDIR)/src/%.properties >> $(MKDIR) -p $(@D) >> $(RM) $@ $@.tmp >> $(CAT) $< | LANG=C $(NAWK) '{ sub(/#.*$$/,"#"); print }' > $@.tmp >> $(MV) $@.tmp $@ >> >> This was fixed in JDK 9. The per-repo process was removed. It looks like >> the properties processing process is now consolidated into >> make/common/JavaCompilation.gmk. So the issue Daniel found is new (in terms >> of stripping). Search 'properties files' to see the macro. >> >> Joe >> >>> >>> Mandy >>> >> From erik.joelsson at oracle.com Thu Nov 20 08:23:03 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 20 Nov 2014 09:23:03 +0100 Subject: RFR: JDK-8065215 Print warning summary at end of configure In-Reply-To: <546B5452.9010005@oracle.com> References: <546B50FC.9090600@oracle.com> <546B5452.9010005@oracle.com> Message-ID: <546DA4E7.5020303@oracle.com> Looks good to me. /Erik On 2014-11-18 15:14, Magnus Ihse Bursie wrote: > On 2014-11-18 15:00, Magnus Ihse Bursie wrote: >> Warnings in configure tends to just fly by quickly and be buried in >> the verbose autoconf output. >> >> We could with a simple trick repeat all those warnings (if any) at >> the end of configure, where they will be more easily spotted. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8065215 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8065215-print-warning-at-end-of-configure/webrev.01 > > As an example, the last part of the configure output might look like > this: > > Tools summary: > * Boot JDK: java version "1.8.0" Java(TM) SE Runtime Environment > (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, > mixed mode) (at /localhome/java/jdk-8-fcs-bin-b132-linux-x64) > * Toolchain: gcc (GNU Compiler Collection) > * C Compiler: Version 4.8.2 (at /usr/bin/gcc) > * C++ Compiler: Version 4.8.2 (at /usr/bin/g++) > > Build performance summary: > * Cores to use: 14 > * Memory limit: 28134 MB > > WARNING: The result of this configuration has overridden an older > configuration. You *should* run 'make clean' to make sure you get a > proper build. Failure to do so might result in strange build problems. > > The following warnings were produced. Repeated here for convenience: > WARNING: Option --with-custom-make-dir is deprecated and will be ignored. > > > /Magnus From erik.joelsson at oracle.com Thu Nov 20 09:26:19 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 20 Nov 2014 10:26:19 +0100 Subject: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' In-Reply-To: References: <546C7C2D.3060805@oracle.com> <546CDE30.6030907@oracle.com> <546CFF3C.2030904@oracle.com> <546D0285.3090504@oracle.com> <546D2C7C.5020103@oracle.com> <546D3126.5010301@oracle.com> <546D3ECE.2040500@oracle.com> Message-ID: <546DB3BB.7020901@oracle.com> Hello, On 2014-11-20 02:20, Martin Buchholz wrote: > Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it, but > the $(SED)s need it too! Yes, I think that's the correct fix in this case. > On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz wrote: >> [+ build-dev] >> >> I think I see the problem. By default, a Unix pipeline sadly fails >> only when the last command fails. In bash, you can change this to a >> more sensible default via >> set -o pipefail >> but that's not portable enough for openjdk. This is interesting and something I had missed. I will experiment with enabling pipefail if configure finds support for it. This will include setting the SHELL to bash. We really should fail instead of silently generating broken builds. Daniel, I can take over this bug if you want and work on a proper build fix. /Erik >> $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ >> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >> -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >> >> On Wed, Nov 19, 2014 at 5:07 PM, huizhe wang wrote: >>> On 11/19/2014 4:09 PM, Mandy Chung wrote: >>>> >>>> On 11/19/2014 3:49 PM, Mandy Chung wrote: >>>>> >>>>> On 11/19/2014 12:50 PM, Daniel Fuchs wrote: >>>>>> On 11/19/14 9:36 PM, Mandy Chung wrote: >>>>>>> resources.jar will be gone when we move to the modular runtime image >>>>>>> (JEP 220 [1]). >>>>>>> JDK-8065138 and JDK-8065365 will become non-issue in JDK 9. >>>>>> Do you mean that the property files will no longer be stripped of their >>>>>> comments? >>>>> >>>>> (sorry for my delay in reply as I was trying to get the number of the >>>>> resources in the modular image vs resources.jar but got distracted.) >>>>> >>>>> The current version copies all bytes when generating the modular image. >>>>> This is a good question whether we should strip off the comments when >>>>> writing to the modular runtime image. I think we should look at the >>>>> footprint and any performance saving and determine if we should do the same >>>>> in JDK 9. >>>>> >>>> I looked at the exploded image under BUILD_OUTPUTDIR/jdk/modules/java.xml >>>> and found that the comments of Encodings.properties are stripped. I was >>>> confused with the mention of resources.jar that I assume it was a step >>>> stripping the comments before writing to resources.jar. This is still >>>> an issue in jigsaw m2 I believe. >>>> >>>> Where does the build strip the comments? >>> >>> A previous issue was that the build process strips off anything after '#' >>> when copying properties files. In JDK8: >>> jaxp/make/BuildJaxp.gmk: >>> $(JAXP_OUTPUTDIR)/classes/%.properties: $(JAXP_TOPDIR)/src/%.properties >>> $(MKDIR) -p $(@D) >>> $(RM) $@ $@.tmp >>> $(CAT) $< | LANG=C $(NAWK) '{ sub(/#.*$$/,"#"); print }' > $@.tmp >>> $(MV) $@.tmp $@ >>> >>> This was fixed in JDK 9. The per-repo process was removed. It looks like >>> the properties processing process is now consolidated into >>> make/common/JavaCompilation.gmk. So the issue Daniel found is new (in terms >>> of stripping). Search 'properties files' to see the macro. >>> >>> Joe >>> >>>> Mandy >>>> From daniel.fuchs at oracle.com Thu Nov 20 09:34:36 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 20 Nov 2014 10:34:36 +0100 Subject: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' In-Reply-To: <546DB3BB.7020901@oracle.com> References: <546C7C2D.3060805@oracle.com> <546CDE30.6030907@oracle.com> <546CFF3C.2030904@oracle.com> <546D0285.3090504@oracle.com> <546D2C7C.5020103@oracle.com> <546D3126.5010301@oracle.com> <546D3ECE.2040500@oracle.com> <546DB3BB.7020901@oracle.com> Message-ID: <546DB5AC.60401@oracle.com> On 11/20/14 10:26 AM, Erik Joelsson wrote: > Hello, > > On 2014-11-20 02:20, Martin Buchholz wrote: >> Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it, but >> the $(SED)s need it too! > Yes, I think that's the correct fix in this case. >> On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz >> wrote: >>> [+ build-dev] >>> >>> I think I see the problem. By default, a Unix pipeline sadly fails >>> only when the last command fails. In bash, you can change this to a >>> more sensible default via >>> set -o pipefail >>> but that's not portable enough for openjdk. > This is interesting and something I had missed. I will experiment with > enabling pipefail if configure finds support for it. This will include > setting the SHELL to bash. We really should fail instead of silently > generating broken builds. > > Daniel, I can take over this bug if you want and work on a proper > build fix. Thanks Erik! You are welcome! So the whole issue seems to be that my default setting is LC_ALL=en_US.UTF-8 whereas sed requires LC_ALL=C to work properly on these property files... When the test first failed I tried to rerun the test with LC_ALL=C - with no success of course. But I never thought of rebuilding with LC_ALL=C :-( My apologies for the red herring :-( best regards -- daniel > > /Erik >>> $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e >>> 's/\([^\\]\)=/\1\\=/g' \ >>> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >>> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >>> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >>> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >>> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >>> -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >>> >>> On Wed, Nov 19, 2014 at 5:07 PM, huizhe wang >>> wrote: >>>> On 11/19/2014 4:09 PM, Mandy Chung wrote: >>>>> >>>>> On 11/19/2014 3:49 PM, Mandy Chung wrote: >>>>>> >>>>>> On 11/19/2014 12:50 PM, Daniel Fuchs wrote: >>>>>>> On 11/19/14 9:36 PM, Mandy Chung wrote: >>>>>>>> resources.jar will be gone when we move to the modular runtime >>>>>>>> image >>>>>>>> (JEP 220 [1]). >>>>>>>> JDK-8065138 and JDK-8065365 will become non-issue in JDK 9. >>>>>>> Do you mean that the property files will no longer be stripped >>>>>>> of their >>>>>>> comments? >>>>>> >>>>>> (sorry for my delay in reply as I was trying to get the number of >>>>>> the >>>>>> resources in the modular image vs resources.jar but got distracted.) >>>>>> >>>>>> The current version copies all bytes when generating the modular >>>>>> image. >>>>>> This is a good question whether we should strip off the comments >>>>>> when >>>>>> writing to the modular runtime image. I think we should look at >>>>>> the >>>>>> footprint and any performance saving and determine if we should >>>>>> do the same >>>>>> in JDK 9. >>>>>> >>>>> I looked at the exploded image under >>>>> BUILD_OUTPUTDIR/jdk/modules/java.xml >>>>> and found that the comments of Encodings.properties are stripped. >>>>> I was >>>>> confused with the mention of resources.jar that I assume it was a >>>>> step >>>>> stripping the comments before writing to resources.jar. This is still >>>>> an issue in jigsaw m2 I believe. >>>>> >>>>> Where does the build strip the comments? >>>> >>>> A previous issue was that the build process strips off anything >>>> after '#' >>>> when copying properties files. In JDK8: >>>> jaxp/make/BuildJaxp.gmk: >>>> $(JAXP_OUTPUTDIR)/classes/%.properties: >>>> $(JAXP_TOPDIR)/src/%.properties >>>> $(MKDIR) -p $(@D) >>>> $(RM) $@ $@.tmp >>>> $(CAT) $< | LANG=C $(NAWK) '{ sub(/#.*$$/,"#"); print }' > >>>> $@.tmp >>>> $(MV) $@.tmp $@ >>>> >>>> This was fixed in JDK 9. The per-repo process was removed. It >>>> looks like >>>> the properties processing process is now consolidated into >>>> make/common/JavaCompilation.gmk. So the issue Daniel found is new >>>> (in terms >>>> of stripping). Search 'properties files' to see the macro. >>>> >>>> Joe >>>> >>>>> Mandy >>>>> > From david.holmes at oracle.com Thu Nov 20 10:00:02 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Nov 2014 20:00:02 +1000 Subject: unlink problem on OSX with unzipped debuginfo Message-ID: <546DBBA2.9040201@oracle.com> Building 8u on OSX with --disable-zip-debug-info I see in the log: make[2]: unlink: /Users/jprtadm/davidh-test/build/b01/se-macosx-x86_64-ea/jdk/lib/libjsig.dylib.dSYM: Operation not permitted Can anyone shed any light on this? I'm not clear on what is being attempted nor the affects on the build. Thanks, David From erik.joelsson at oracle.com Thu Nov 20 10:21:45 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 20 Nov 2014 11:21:45 +0100 Subject: unlink problem on OSX with unzipped debuginfo In-Reply-To: <546DBBA2.9040201@oracle.com> References: <546DBBA2.9040201@oracle.com> Message-ID: <546DC0B9.502@oracle.com> I think it's Import.gmk that isn't working well with non zipped debug symbols on mac. The .dSYM file is actually a directory and the logic in Import.gmk probably hasn't been exercised with that much. /Erik On 2014-11-20 11:00, David Holmes wrote: > Building 8u on OSX with --disable-zip-debug-info I see in the log: > > make[2]: unlink: > /Users/jprtadm/davidh-test/build/b01/se-macosx-x86_64-ea/jdk/lib/libjsig.dylib.dSYM: > Operation not permitted > > Can anyone shed any light on this? I'm not clear on what is being > attempted nor the affects on the build. > > Thanks, > David From erik.joelsson at oracle.com Thu Nov 20 11:19:03 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 20 Nov 2014 12:19:03 +0100 Subject: RFR: JDK-8065412: generated source to compile .properties file incorreectly includes the module name in the package name Message-ID: <546DCE27.2040905@oracle.com> Hello, Please review this small fix, correcting the source generation from properties when the properties files are in platform specific source directories. The bug was introduced by me in JDK-8055191. Bug: https://bugs.openjdk.java.net/browse/JDK-8065412 Patch inline: diff --git a/make/gensrc/GensrcProperties.gmk b/make/gensrc/GensrcProperties.gmk --- a/make/gensrc/GensrcProperties.gmk +++ b/make/gensrc/GensrcProperties.gmk @@ -58,13 +58,15 @@ $1_CLASS := $3 # Convert .../src//share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties - # to .../langtools/gensrc//com/sun/tools/javac/resources/javac_zh_CN.java + # to .../support/gensrc//com/sun/tools/javac/resources/javac_zh_CN.java # Strip away prefix and suffix, leaving for example only: # "/share/classes/com/sun/tools/javac/resources/javac_zh_CN" $1_JAVAS := $$(patsubst $(JDK_TOPDIR)/src/%, \ $(JDK_OUTPUTDIR)/gensrc/%, \ $$(patsubst %.properties, %.java, \ - $$(subst /share/classes,, $$($1_SRCS)))) + $$(subst /$(OPENJDK_TARGET_OS)/classes,, \ + $$(subst /$(OPENJDK_TARGET_OS_API_DIR)/classes,, \ + $$(subst /share/classes,, $$($1_SRCS)))))) # Generate the package dirs for the to be generated java files. Sort to remove # duplicates. Note to Magnus. If this makes it in before your variable renaming, this adds another place to rename. /Erik From erik.joelsson at oracle.com Thu Nov 20 13:36:48 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 20 Nov 2014 14:36:48 +0100 Subject: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' In-Reply-To: <546DB5AC.60401@oracle.com> References: <546C7C2D.3060805@oracle.com> <546CDE30.6030907@oracle.com> <546CFF3C.2030904@oracle.com> <546D0285.3090504@oracle.com> <546D2C7C.5020103@oracle.com> <546D3126.5010301@oracle.com> <546D3ECE.2040500@oracle.com> <546DB3BB.7020901@oracle.com> <546DB5AC.60401@oracle.com> Message-ID: <546DEE70.6020306@oracle.com> Here is my proposal for fixing the particular issue of generating the correct properties files. I'm simply adding LC_ALL=C to the whole command line instead of just the sort at the end. It seems to require using "export" to get picked up. Bug: https://bugs.openjdk.java.net/browse/JDK-8065138 Patch: diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk --- a/make/common/JavaCompilation.gmk +++ b/make/common/JavaCompilation.gmk @@ -400,13 +400,15 @@ # Now we can setup the depency that will trigger the copying. $$($1_BIN)$$($2_TARGET) : $2 $(MKDIR) -p $$(@D) - $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ + export LC_ALL=C ; $(CAT) $$< \ + | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ | $(SED) -e '/^#/d' -e '/^$$$$/d' \ -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ -e 's/^[ ]*//;s/[ ]*$$$$//' \ - -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ + -e 's/\\=/=/' \ + | $(SORT) > $$@ $(CHMOD) -f ug+w $$@ # And do not forget this target I filed a separate issue [1] for investigating the use of pipefail. /Erik [1] https://bugs.openjdk.java.net/browse/JDK-8065576 On 2014-11-20 10:34, Daniel Fuchs wrote: > On 11/20/14 10:26 AM, Erik Joelsson wrote: >> Hello, >> >> On 2014-11-20 02:20, Martin Buchholz wrote: >>> Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it, but >>> the $(SED)s need it too! >> Yes, I think that's the correct fix in this case. >>> On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz >>> wrote: >>>> [+ build-dev] >>>> >>>> I think I see the problem. By default, a Unix pipeline sadly fails >>>> only when the last command fails. In bash, you can change this to a >>>> more sensible default via >>>> set -o pipefail >>>> but that's not portable enough for openjdk. >> This is interesting and something I had missed. I will experiment >> with enabling pipefail if configure finds support for it. This will >> include setting the SHELL to bash. We really should fail instead of >> silently generating broken builds. >> >> Daniel, I can take over this bug if you want and work on a proper >> build fix. > > Thanks Erik! You are welcome! > So the whole issue seems to be that my default setting is > LC_ALL=en_US.UTF-8 > whereas sed requires LC_ALL=C to work properly on these property files... > > When the test first failed I tried to rerun the test with LC_ALL=C - > with no success > of course. But I never thought of rebuilding with LC_ALL=C :-( > > My apologies for the red herring :-( > > best regards > > -- daniel > >> >> /Erik >>>> $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e >>>> 's/\([^\\]\)=/\1\\=/g' \ >>>> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >>>> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >>>> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >>>> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >>>> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >>>> -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >>>> >>>> On Wed, Nov 19, 2014 at 5:07 PM, huizhe wang >>>> wrote: >>>>> On 11/19/2014 4:09 PM, Mandy Chung wrote: >>>>>> >>>>>> On 11/19/2014 3:49 PM, Mandy Chung wrote: >>>>>>> >>>>>>> On 11/19/2014 12:50 PM, Daniel Fuchs wrote: >>>>>>>> On 11/19/14 9:36 PM, Mandy Chung wrote: >>>>>>>>> resources.jar will be gone when we move to the modular runtime >>>>>>>>> image >>>>>>>>> (JEP 220 [1]). >>>>>>>>> JDK-8065138 and JDK-8065365 will become non-issue in JDK 9. >>>>>>>> Do you mean that the property files will no longer be stripped >>>>>>>> of their >>>>>>>> comments? >>>>>>> >>>>>>> (sorry for my delay in reply as I was trying to get the number >>>>>>> of the >>>>>>> resources in the modular image vs resources.jar but got >>>>>>> distracted.) >>>>>>> >>>>>>> The current version copies all bytes when generating the modular >>>>>>> image. >>>>>>> This is a good question whether we should strip off the comments >>>>>>> when >>>>>>> writing to the modular runtime image. I think we should look >>>>>>> at the >>>>>>> footprint and any performance saving and determine if we should >>>>>>> do the same >>>>>>> in JDK 9. >>>>>>> >>>>>> I looked at the exploded image under >>>>>> BUILD_OUTPUTDIR/jdk/modules/java.xml >>>>>> and found that the comments of Encodings.properties are stripped. >>>>>> I was >>>>>> confused with the mention of resources.jar that I assume it was a >>>>>> step >>>>>> stripping the comments before writing to resources.jar. This is >>>>>> still >>>>>> an issue in jigsaw m2 I believe. >>>>>> >>>>>> Where does the build strip the comments? >>>>> >>>>> A previous issue was that the build process strips off anything >>>>> after '#' >>>>> when copying properties files. In JDK8: >>>>> jaxp/make/BuildJaxp.gmk: >>>>> $(JAXP_OUTPUTDIR)/classes/%.properties: >>>>> $(JAXP_TOPDIR)/src/%.properties >>>>> $(MKDIR) -p $(@D) >>>>> $(RM) $@ $@.tmp >>>>> $(CAT) $< | LANG=C $(NAWK) '{ sub(/#.*$$/,"#"); print }' >>>>> > $@.tmp >>>>> $(MV) $@.tmp $@ >>>>> >>>>> This was fixed in JDK 9. The per-repo process was removed. It >>>>> looks like >>>>> the properties processing process is now consolidated into >>>>> make/common/JavaCompilation.gmk. So the issue Daniel found is new >>>>> (in terms >>>>> of stripping). Search 'properties files' to see the macro. >>>>> >>>>> Joe >>>>> >>>>>> Mandy >>>>>> >> > From tim.bell at oracle.com Thu Nov 20 14:57:33 2014 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 20 Nov 2014 06:57:33 -0800 Subject: RFR: JDK-8065412: generated source to compile .properties file incorreectly includes the module name in the package name In-Reply-To: <546DCE27.2040905@oracle.com> References: <546DCE27.2040905@oracle.com> Message-ID: <546E015D.1060105@oracle.com> Erik: > Please review this small fix, correcting the source generation from > properties when the properties files are in platform specific source > directories. The bug was introduced by me in JDK-8055191. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065412 > Patch inline: > > diff --git a/make/gensrc/GensrcProperties.gmk > b/make/gensrc/GensrcProperties.gmk > --- a/make/gensrc/GensrcProperties.gmk > +++ b/make/gensrc/GensrcProperties.gmk > @@ -58,13 +58,15 @@ > $1_CLASS := $3 > > # Convert > .../src//share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties > - # to > .../langtools/gensrc//com/sun/tools/javac/resources/javac_zh_CN.java > + # to > .../support/gensrc//com/sun/tools/javac/resources/javac_zh_CN.java > # Strip away prefix and suffix, leaving for example only: > # "/share/classes/com/sun/tools/javac/resources/javac_zh_CN" > $1_JAVAS := $$(patsubst $(JDK_TOPDIR)/src/%, \ > $(JDK_OUTPUTDIR)/gensrc/%, \ > $$(patsubst %.properties, %.java, \ > - $$(subst /share/classes,, $$($1_SRCS)))) > + $$(subst /$(OPENJDK_TARGET_OS)/classes,, \ > + $$(subst /$(OPENJDK_TARGET_OS_API_DIR)/classes,, \ > + $$(subst /share/classes,, $$($1_SRCS)))))) > > # Generate the package dirs for the to be generated java files. > Sort to remove > # duplicates. > > > Note to Magnus. If this makes it in before your variable renaming, > this adds another place to rename. Looks good to me. /Tim From daniel.fuchs at oracle.com Thu Nov 20 17:25:03 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 20 Nov 2014 18:25:03 +0100 Subject: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' In-Reply-To: <546DEE70.6020306@oracle.com> References: <546C7C2D.3060805@oracle.com> <546CDE30.6030907@oracle.com> <546CFF3C.2030904@oracle.com> <546D0285.3090504@oracle.com> <546D2C7C.5020103@oracle.com> <546D3126.5010301@oracle.com> <546D3ECE.2040500@oracle.com> <546DB3BB.7020901@oracle.com> <546DB5AC.60401@oracle.com> <546DEE70.6020306@oracle.com> Message-ID: <546E23EF.4000506@oracle.com> On 20/11/14 14:36, Erik Joelsson wrote: > Here is my proposal for fixing the particular issue of generating the > correct properties files. I'm simply adding LC_ALL=C to the whole > command line instead of just the sort at the end. It seems to require > using "export" to get picked up. Hi Erik, Looks good to me. I have applied your patch (manually, because the copy/paste seems to have eaten the tab characters away, which caused patch to reject the diff) - and I confirm that the issue has disappeared. Thanks for solving this! Do you think it would be worth to commit this test modification later on, in a followup Bug/RFE? http://cr.openjdk.java.net/~dfuchs/webrev_8065138/webrev.00/jdk/test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java.frames.html If so I will take care of it. best regards, -- daniel > Bug: https://bugs.openjdk.java.net/browse/JDK-8065138 > Patch: > diff --git a/make/common/JavaCompilation.gmk > b/make/common/JavaCompilation.gmk > --- a/make/common/JavaCompilation.gmk > +++ b/make/common/JavaCompilation.gmk > @@ -400,13 +400,15 @@ > # Now we can setup the depency that will trigger the copying. > $$($1_BIN)$$($2_TARGET) : $2 > $(MKDIR) -p $$(@D) > - $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e > 's/\([^\\]\)=/\1\\=/g' \ > + export LC_ALL=C ; $(CAT) $$< \ > + | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ > -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ > | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ > | $(SED) -e '/^#/d' -e '/^$$$$/d' \ > -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ > -e 's/^[ ]*//;s/[ ]*$$$$//' \ > - -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ > + -e 's/\\=/=/' \ > + | $(SORT) > $$@ > $(CHMOD) -f ug+w $$@ > > # And do not forget this target > > > I filed a separate issue [1] for investigating the use of pipefail. > > /Erik > > [1] https://bugs.openjdk.java.net/browse/JDK-8065576 > > On 2014-11-20 10:34, Daniel Fuchs wrote: >> On 11/20/14 10:26 AM, Erik Joelsson wrote: >>> Hello, >>> >>> On 2014-11-20 02:20, Martin Buchholz wrote: >>>> Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it, but >>>> the $(SED)s need it too! >>> Yes, I think that's the correct fix in this case. >>>> On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz >>>> wrote: >>>>> [+ build-dev] >>>>> >>>>> I think I see the problem. By default, a Unix pipeline sadly fails >>>>> only when the last command fails. In bash, you can change this to a >>>>> more sensible default via >>>>> set -o pipefail >>>>> but that's not portable enough for openjdk. >>> This is interesting and something I had missed. I will experiment >>> with enabling pipefail if configure finds support for it. This will >>> include setting the SHELL to bash. We really should fail instead of >>> silently generating broken builds. >>> >>> Daniel, I can take over this bug if you want and work on a proper >>> build fix. >> >> Thanks Erik! You are welcome! >> So the whole issue seems to be that my default setting is >> LC_ALL=en_US.UTF-8 >> whereas sed requires LC_ALL=C to work properly on these property files... >> >> When the test first failed I tried to rerun the test with LC_ALL=C - >> with no success >> of course. But I never thought of rebuilding with LC_ALL=C :-( >> >> My apologies for the red herring :-( >> >> best regards >> >> -- daniel >> >>> >>> /Erik >>>>> $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e >>>>> 's/\([^\\]\)=/\1\\=/g' \ >>>>> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >>>>> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >>>>> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >>>>> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >>>>> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >>>>> -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >>>>> >>>>> On Wed, Nov 19, 2014 at 5:07 PM, huizhe wang >>>>> wrote: >>>>>> On 11/19/2014 4:09 PM, Mandy Chung wrote: >>>>>>> >>>>>>> On 11/19/2014 3:49 PM, Mandy Chung wrote: >>>>>>>> >>>>>>>> On 11/19/2014 12:50 PM, Daniel Fuchs wrote: >>>>>>>>> On 11/19/14 9:36 PM, Mandy Chung wrote: >>>>>>>>>> resources.jar will be gone when we move to the modular runtime >>>>>>>>>> image >>>>>>>>>> (JEP 220 [1]). >>>>>>>>>> JDK-8065138 and JDK-8065365 will become non-issue in JDK 9. >>>>>>>>> Do you mean that the property files will no longer be stripped >>>>>>>>> of their >>>>>>>>> comments? >>>>>>>> >>>>>>>> (sorry for my delay in reply as I was trying to get the number >>>>>>>> of the >>>>>>>> resources in the modular image vs resources.jar but got >>>>>>>> distracted.) >>>>>>>> >>>>>>>> The current version copies all bytes when generating the modular >>>>>>>> image. >>>>>>>> This is a good question whether we should strip off the comments >>>>>>>> when >>>>>>>> writing to the modular runtime image. I think we should look >>>>>>>> at the >>>>>>>> footprint and any performance saving and determine if we should >>>>>>>> do the same >>>>>>>> in JDK 9. >>>>>>>> >>>>>>> I looked at the exploded image under >>>>>>> BUILD_OUTPUTDIR/jdk/modules/java.xml >>>>>>> and found that the comments of Encodings.properties are stripped. >>>>>>> I was >>>>>>> confused with the mention of resources.jar that I assume it was a >>>>>>> step >>>>>>> stripping the comments before writing to resources.jar. This is >>>>>>> still >>>>>>> an issue in jigsaw m2 I believe. >>>>>>> >>>>>>> Where does the build strip the comments? >>>>>> >>>>>> A previous issue was that the build process strips off anything >>>>>> after '#' >>>>>> when copying properties files. In JDK8: >>>>>> jaxp/make/BuildJaxp.gmk: >>>>>> $(JAXP_OUTPUTDIR)/classes/%.properties: >>>>>> $(JAXP_TOPDIR)/src/%.properties >>>>>> $(MKDIR) -p $(@D) >>>>>> $(RM) $@ $@.tmp >>>>>> $(CAT) $< | LANG=C $(NAWK) '{ sub(/#.*$$/,"#"); print }' >>>>>> > $@.tmp >>>>>> $(MV) $@.tmp $@ >>>>>> >>>>>> This was fixed in JDK 9. The per-repo process was removed. It >>>>>> looks like >>>>>> the properties processing process is now consolidated into >>>>>> make/common/JavaCompilation.gmk. So the issue Daniel found is new >>>>>> (in terms >>>>>> of stripping). Search 'properties files' to see the macro. >>>>>> >>>>>> Joe >>>>>> >>>>>>> Mandy >>>>>>> >>> >> > From mandy.chung at oracle.com Thu Nov 20 17:56:13 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Nov 2014 09:56:13 -0800 Subject: RFR: JDK-8065412: generated source to compile .properties file incorreectly includes the module name in the package name In-Reply-To: <546DCE27.2040905@oracle.com> References: <546DCE27.2040905@oracle.com> Message-ID: <546E2B3D.9080605@oracle.com> On 11/20/14 3:19 AM, Erik Joelsson wrote: > Hello, > > Please review this small fix, correcting the source generation from > properties when the properties files are in platform specific source > directories. The bug was introduced by me in JDK-8055191. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065412 > Patch inline: > > diff --git a/make/gensrc/GensrcProperties.gmk > b/make/gensrc/GensrcProperties.gmk > --- a/make/gensrc/GensrcProperties.gmk > +++ b/make/gensrc/GensrcProperties.gmk > @@ -58,13 +58,15 @@ > $1_CLASS := $3 > > # Convert > .../src//share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties > - # to > .../langtools/gensrc//com/sun/tools/javac/resources/javac_zh_CN.java > + # to > .../support/gensrc//com/sun/tools/javac/resources/javac_zh_CN.java > # Strip away prefix and suffix, leaving for example only: > # "/share/classes/com/sun/tools/javac/resources/javac_zh_CN" > $1_JAVAS := $$(patsubst $(JDK_TOPDIR)/src/%, \ > $(JDK_OUTPUTDIR)/gensrc/%, \ > $$(patsubst %.properties, %.java, \ > - $$(subst /share/classes,, $$($1_SRCS)))) > + $$(subst /$(OPENJDK_TARGET_OS)/classes,, \ > + $$(subst /$(OPENJDK_TARGET_OS_API_DIR)/classes,, \ > + $$(subst /share/classes,, $$($1_SRCS)))))) > > # Generate the package dirs for the to be generated java files. > Sort to remove > # duplicates. Looks good to me. Phil - FYI. JDK-8055191 was integrated in b36. This bug impacts windows and macosx sun/awt resource bundles. Perhaps catching this regression requires manual testing and not yet verified on those two platforms? It may be good to include some basic sanity regression test for loading sun.awt resource bundles. Mandy From huizhe.wang at oracle.com Thu Nov 20 17:57:36 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 20 Nov 2014 09:57:36 -0800 Subject: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' In-Reply-To: <546E23EF.4000506@oracle.com> References: <546C7C2D.3060805@oracle.com> <546CDE30.6030907@oracle.com> <546CFF3C.2030904@oracle.com> <546D0285.3090504@oracle.com> <546D2C7C.5020103@oracle.com> <546D3126.5010301@oracle.com> <546D3ECE.2040500@oracle.com> <546DB3BB.7020901@oracle.com> <546DB5AC.60401@oracle.com> <546DEE70.6020306@oracle.com> <546E23EF.4000506@oracle.com> Message-ID: <546E2B90.2050503@oracle.com> Awesome! Glad to see the fix in the build process. It's a relief to know we don't have to worry about individual properties files. Daniel, your test looks good to me. That's how jaxp loads Encodings.properties. Thanks, Joe On 11/20/2014 9:25 AM, Daniel Fuchs wrote: > On 20/11/14 14:36, Erik Joelsson wrote: >> Here is my proposal for fixing the particular issue of generating the >> correct properties files. I'm simply adding LC_ALL=C to the whole >> command line instead of just the sort at the end. It seems to require >> using "export" to get picked up. > > Hi Erik, > > Looks good to me. > > I have applied your patch (manually, because the copy/paste > seems to have eaten the tab characters away, which caused patch to > reject the diff) - and I confirm that the issue has disappeared. > > Thanks for solving this! > > Do you think it would be worth to commit this test modification > later on, in a followup Bug/RFE? > > http://cr.openjdk.java.net/~dfuchs/webrev_8065138/webrev.00/jdk/test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java.frames.html > > > If so I will take care of it. > > best regards, > > -- daniel > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8065138 >> Patch: >> diff --git a/make/common/JavaCompilation.gmk >> b/make/common/JavaCompilation.gmk >> --- a/make/common/JavaCompilation.gmk >> +++ b/make/common/JavaCompilation.gmk >> @@ -400,13 +400,15 @@ >> # Now we can setup the depency that will trigger the copying. >> $$($1_BIN)$$($2_TARGET) : $2 >> $(MKDIR) -p $$(@D) >> - $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e >> 's/\([^\\]\)=/\1\\=/g' \ >> + export LC_ALL=C ; $(CAT) $$< \ >> + | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ >> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >> - -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >> + -e 's/\\=/=/' \ >> + | $(SORT) > $$@ >> $(CHMOD) -f ug+w $$@ >> >> # And do not forget this target >> >> >> I filed a separate issue [1] for investigating the use of pipefail. >> >> /Erik >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8065576 >> >> On 2014-11-20 10:34, Daniel Fuchs wrote: >>> On 11/20/14 10:26 AM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> On 2014-11-20 02:20, Martin Buchholz wrote: >>>>> Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it, >>>>> but >>>>> the $(SED)s need it too! >>>> Yes, I think that's the correct fix in this case. >>>>> On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz >>>>> wrote: >>>>>> [+ build-dev] >>>>>> >>>>>> I think I see the problem. By default, a Unix pipeline sadly fails >>>>>> only when the last command fails. In bash, you can change this to a >>>>>> more sensible default via >>>>>> set -o pipefail >>>>>> but that's not portable enough for openjdk. >>>> This is interesting and something I had missed. I will experiment >>>> with enabling pipefail if configure finds support for it. This will >>>> include setting the SHELL to bash. We really should fail instead of >>>> silently generating broken builds. >>>> >>>> Daniel, I can take over this bug if you want and work on a proper >>>> build fix. >>> >>> Thanks Erik! You are welcome! >>> So the whole issue seems to be that my default setting is >>> LC_ALL=en_US.UTF-8 >>> whereas sed requires LC_ALL=C to work properly on these property >>> files... >>> >>> When the test first failed I tried to rerun the test with LC_ALL=C - >>> with no success >>> of course. But I never thought of rebuilding with LC_ALL=C :-( >>> >>> My apologies for the red herring :-( >>> >>> best regards >>> >>> -- daniel >>> >>>> >>>> /Erik >>>>>> $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e >>>>>> 's/\([^\\]\)=/\1\\=/g' \ >>>>>> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >>>>>> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >>>>>> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >>>>>> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >>>>>> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >>>>>> -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >>>>>> >>>>>> On Wed, Nov 19, 2014 at 5:07 PM, huizhe wang >>>>>> wrote: >>>>>>> On 11/19/2014 4:09 PM, Mandy Chung wrote: >>>>>>>> >>>>>>>> On 11/19/2014 3:49 PM, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> On 11/19/2014 12:50 PM, Daniel Fuchs wrote: >>>>>>>>>> On 11/19/14 9:36 PM, Mandy Chung wrote: >>>>>>>>>>> resources.jar will be gone when we move to the modular runtime >>>>>>>>>>> image >>>>>>>>>>> (JEP 220 [1]). >>>>>>>>>>> JDK-8065138 and JDK-8065365 will become non-issue in JDK 9. >>>>>>>>>> Do you mean that the property files will no longer be stripped >>>>>>>>>> of their >>>>>>>>>> comments? >>>>>>>>> >>>>>>>>> (sorry for my delay in reply as I was trying to get the number >>>>>>>>> of the >>>>>>>>> resources in the modular image vs resources.jar but got >>>>>>>>> distracted.) >>>>>>>>> >>>>>>>>> The current version copies all bytes when generating the modular >>>>>>>>> image. >>>>>>>>> This is a good question whether we should strip off the comments >>>>>>>>> when >>>>>>>>> writing to the modular runtime image. I think we should look >>>>>>>>> at the >>>>>>>>> footprint and any performance saving and determine if we should >>>>>>>>> do the same >>>>>>>>> in JDK 9. >>>>>>>>> >>>>>>>> I looked at the exploded image under >>>>>>>> BUILD_OUTPUTDIR/jdk/modules/java.xml >>>>>>>> and found that the comments of Encodings.properties are stripped. >>>>>>>> I was >>>>>>>> confused with the mention of resources.jar that I assume it was a >>>>>>>> step >>>>>>>> stripping the comments before writing to resources.jar. This is >>>>>>>> still >>>>>>>> an issue in jigsaw m2 I believe. >>>>>>>> >>>>>>>> Where does the build strip the comments? >>>>>>> >>>>>>> A previous issue was that the build process strips off anything >>>>>>> after '#' >>>>>>> when copying properties files. In JDK8: >>>>>>> jaxp/make/BuildJaxp.gmk: >>>>>>> $(JAXP_OUTPUTDIR)/classes/%.properties: >>>>>>> $(JAXP_TOPDIR)/src/%.properties >>>>>>> $(MKDIR) -p $(@D) >>>>>>> $(RM) $@ $@.tmp >>>>>>> $(CAT) $< | LANG=C $(NAWK) '{ sub(/#.*$$/,"#"); print }' >>>>>>> > $@.tmp >>>>>>> $(MV) $@.tmp $@ >>>>>>> >>>>>>> This was fixed in JDK 9. The per-repo process was removed. It >>>>>>> looks like >>>>>>> the properties processing process is now consolidated into >>>>>>> make/common/JavaCompilation.gmk. So the issue Daniel found is new >>>>>>> (in terms >>>>>>> of stripping). Search 'properties files' to see the macro. >>>>>>> >>>>>>> Joe >>>>>>> >>>>>>>> Mandy >>>>>>>> >>>> >>> >> > From chris.hegarty at oracle.com Thu Nov 20 21:41:38 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 20 Nov 2014 21:41:38 +0000 Subject: RFR [JEP 220] Modular Run-Time Images References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: > From: Chris Hegarty > Subject: RFR [JEP 220] Modular Run-Time Images > Date: 20 November 2014 21:39:14 GMT > To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons , Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie , Mandy Chung , Mark Reinhold , Paul Sandoz , "A. Sundararajan" > > This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. > > There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the 'To' section of this mail, and they will help address any comments arising from this review request. > > The new run-time image structure is defined in JEP 220 [1], and can be seen as a result of building the staging forest [2], or in the early access builds [3]. > > Webrevs: > http://cr.openjdk.java.net/~chegar/8061971/00/ > > Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev. > > -Chris. > > [1] http://openjdk.java.net/jeps/220 > [2] http://hg.openjdk.java.net/jigsaw/m2/ > [3] http://openjdk.java.net/projects/jigsaw/ea From david.lloyd at redhat.com Fri Nov 7 18:53:58 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 07 Nov 2014 12:53:58 -0600 Subject: RFR: AARCH64: Top-level JDK changes In-Reply-To: <545D0D33.70400@redhat.com> References: <545CFFA9.4070107@redhat.com> <6313454D-6690-4119-B55C-DBB356E4B3AC@oracle.com> <545D078E.2090509@redhat.com> <545D0D33.70400@redhat.com> Message-ID: <545D1546.9050902@redhat.com> On 11/07/2014 12:19 PM, Andrew Haley wrote: > On 11/07/2014 06:10 PM, Christian Thalinger wrote: >> >>> On Nov 7, 2014, at 9:55 AM, Andrew Haley wrote: >>> >>> On 11/07/2014 05:42 PM, Christian Thalinger wrote: >>>> >>>>> On Nov 7, 2014, at 9:21 AM, Andrew Haley wrote: >>>>> >>>>> The first patch: top-level build machinery changes. >>>>> >>>>> http://cr.openjdk.java.net/~aph/8064357-rev-1/ >>>> >>>> common/autoconf/flags.m4 >>>> >>>> + aarch64) >>>> + ZERO_ARCHFLAG="" >>>> + ;; >>>> >>>> Why is this required on aarch64 but not all the other architectures? >>> >>> I think it's because GCC rejects "-m64?. >> >> That?s interesting. I thought -m is some kind of common >> flag that works on all architectures. > > No, all the "-m" stuff is target-dependent. > >> Can someone verify this? > > mustang-01:~ $ gcc -m64 hello.c > gcc: error: unrecognized command line option '-m64' > mustang-01:~ $ gcc --version > gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Also the man page lists -m64 under only specific targets. -- - DML From mandy.chung at oracle.com Thu Nov 20 22:07:08 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Nov 2014 14:07:08 -0800 Subject: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' In-Reply-To: <546E23EF.4000506@oracle.com> References: <546C7C2D.3060805@oracle.com> <546CDE30.6030907@oracle.com> <546CFF3C.2030904@oracle.com> <546D0285.3090504@oracle.com> <546D2C7C.5020103@oracle.com> <546D3126.5010301@oracle.com> <546D3ECE.2040500@oracle.com> <546DB3BB.7020901@oracle.com> <546DB5AC.60401@oracle.com> <546DEE70.6020306@oracle.com> <546E23EF.4000506@oracle.com> Message-ID: <546E660C.1060909@oracle.com> Daniel, Your test change looks fine and good to push this change that should catch if similar regression occurs in the future. I was tempted to suggest to have a dedicated test for the build-time modification to the properties file. Maybe a low priority RFE. Mandy On 11/20/14 9:25 AM, Daniel Fuchs wrote: > On 20/11/14 14:36, Erik Joelsson wrote: >> Here is my proposal for fixing the particular issue of generating the >> correct properties files. I'm simply adding LC_ALL=C to the whole >> command line instead of just the sort at the end. It seems to require >> using "export" to get picked up. > > Hi Erik, > > Looks good to me. > > I have applied your patch (manually, because the copy/paste > seems to have eaten the tab characters away, which caused patch to > reject the diff) - and I confirm that the issue has disappeared. > > Thanks for solving this! > > Do you think it would be worth to commit this test modification > later on, in a followup Bug/RFE? > > http://cr.openjdk.java.net/~dfuchs/webrev_8065138/webrev.00/jdk/test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java.frames.html > > > If so I will take care of it. > > best regards, > > -- daniel > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8065138 >> Patch: >> diff --git a/make/common/JavaCompilation.gmk >> b/make/common/JavaCompilation.gmk >> --- a/make/common/JavaCompilation.gmk >> +++ b/make/common/JavaCompilation.gmk >> @@ -400,13 +400,15 @@ >> # Now we can setup the depency that will trigger the copying. >> $$($1_BIN)$$($2_TARGET) : $2 >> $(MKDIR) -p $$(@D) >> - $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e >> 's/\([^\\]\)=/\1\\=/g' \ >> + export LC_ALL=C ; $(CAT) $$< \ >> + | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ >> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >> - -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >> + -e 's/\\=/=/' \ >> + | $(SORT) > $$@ >> $(CHMOD) -f ug+w $$@ >> >> # And do not forget this target >> >> >> I filed a separate issue [1] for investigating the use of pipefail. >> >> /Erik >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8065576 >> >> On 2014-11-20 10:34, Daniel Fuchs wrote: >>> On 11/20/14 10:26 AM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> On 2014-11-20 02:20, Martin Buchholz wrote: >>>>> Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it, >>>>> but >>>>> the $(SED)s need it too! >>>> Yes, I think that's the correct fix in this case. >>>>> On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz >>>>> wrote: >>>>>> [+ build-dev] >>>>>> >>>>>> I think I see the problem. By default, a Unix pipeline sadly fails >>>>>> only when the last command fails. In bash, you can change this to a >>>>>> more sensible default via >>>>>> set -o pipefail >>>>>> but that's not portable enough for openjdk. >>>> This is interesting and something I had missed. I will experiment >>>> with enabling pipefail if configure finds support for it. This will >>>> include setting the SHELL to bash. We really should fail instead of >>>> silently generating broken builds. >>>> >>>> Daniel, I can take over this bug if you want and work on a proper >>>> build fix. >>> >>> Thanks Erik! You are welcome! >>> So the whole issue seems to be that my default setting is >>> LC_ALL=en_US.UTF-8 >>> whereas sed requires LC_ALL=C to work properly on these property >>> files... >>> >>> When the test first failed I tried to rerun the test with LC_ALL=C - >>> with no success >>> of course. But I never thought of rebuilding with LC_ALL=C :-( >>> >>> My apologies for the red herring :-( >>> >>> best regards >>> >>> -- daniel >>> >>>> >>>> /Erik >>>>>> $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e >>>>>> 's/\([^\\]\)=/\1\\=/g' \ >>>>>> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >>>>>> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >>>>>> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >>>>>> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >>>>>> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >>>>>> -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >>>>>> >>>>>> On Wed, Nov 19, 2014 at 5:07 PM, huizhe wang >>>>>> wrote: >>>>>>> On 11/19/2014 4:09 PM, Mandy Chung wrote: >>>>>>>> >>>>>>>> On 11/19/2014 3:49 PM, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> On 11/19/2014 12:50 PM, Daniel Fuchs wrote: >>>>>>>>>> On 11/19/14 9:36 PM, Mandy Chung wrote: >>>>>>>>>>> resources.jar will be gone when we move to the modular runtime >>>>>>>>>>> image >>>>>>>>>>> (JEP 220 [1]). >>>>>>>>>>> JDK-8065138 and JDK-8065365 will become non-issue in JDK 9. >>>>>>>>>> Do you mean that the property files will no longer be stripped >>>>>>>>>> of their >>>>>>>>>> comments? >>>>>>>>> >>>>>>>>> (sorry for my delay in reply as I was trying to get the number >>>>>>>>> of the >>>>>>>>> resources in the modular image vs resources.jar but got >>>>>>>>> distracted.) >>>>>>>>> >>>>>>>>> The current version copies all bytes when generating the modular >>>>>>>>> image. >>>>>>>>> This is a good question whether we should strip off the comments >>>>>>>>> when >>>>>>>>> writing to the modular runtime image. I think we should look >>>>>>>>> at the >>>>>>>>> footprint and any performance saving and determine if we should >>>>>>>>> do the same >>>>>>>>> in JDK 9. >>>>>>>>> >>>>>>>> I looked at the exploded image under >>>>>>>> BUILD_OUTPUTDIR/jdk/modules/java.xml >>>>>>>> and found that the comments of Encodings.properties are stripped. >>>>>>>> I was >>>>>>>> confused with the mention of resources.jar that I assume it was a >>>>>>>> step >>>>>>>> stripping the comments before writing to resources.jar. This is >>>>>>>> still >>>>>>>> an issue in jigsaw m2 I believe. >>>>>>>> >>>>>>>> Where does the build strip the comments? >>>>>>> >>>>>>> A previous issue was that the build process strips off anything >>>>>>> after '#' >>>>>>> when copying properties files. In JDK8: >>>>>>> jaxp/make/BuildJaxp.gmk: >>>>>>> $(JAXP_OUTPUTDIR)/classes/%.properties: >>>>>>> $(JAXP_TOPDIR)/src/%.properties >>>>>>> $(MKDIR) -p $(@D) >>>>>>> $(RM) $@ $@.tmp >>>>>>> $(CAT) $< | LANG=C $(NAWK) '{ sub(/#.*$$/,"#"); print }' >>>>>>> > $@.tmp >>>>>>> $(MV) $@.tmp $@ >>>>>>> >>>>>>> This was fixed in JDK 9. The per-repo process was removed. It >>>>>>> looks like >>>>>>> the properties processing process is now consolidated into >>>>>>> make/common/JavaCompilation.gmk. So the issue Daniel found is new >>>>>>> (in terms >>>>>>> of stripping). Search 'properties files' to see the macro. >>>>>>> >>>>>>> Joe >>>>>>> >>>>>>>> Mandy >>>>>>>> >>>> >>> >> > From sean.coffey at oracle.com Fri Nov 21 13:58:35 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Fri, 21 Nov 2014 13:58:35 +0000 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: <546F450B.6090204@oracle.com> Chris, just a passing comment from me. I've been looking at the extension directory changes. Looks like some code, locale resource files, man pages and help menus still need updating to remove the ext dir references. Is that tracked already ? The rmic, javadoc and javac tools still have the concept of an extension directory. e.g. http://hg.openjdk.java.net/jigsaw/m2/jdk/file/tip/src/jdk.rmic/share/classes/sun/rmi/rmic/newrmic/Main.java#l305 http://hg.openjdk.java.net/jigsaw/m2/langtools/file/tip/src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ToolOption.java#l70 http://hg.openjdk.java.net/jigsaw/m2/langtools/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java#l187 http://hg.openjdk.java.net/jigsaw/m2/jdk/file/tip/src/linux/doc/man/ja/javac.1 Hope that's expected. regards, Sean. On 20/11/14 21:41, Chris Hegarty wrote: >> From: Chris Hegarty >> Subject: RFR [JEP 220] Modular Run-Time Images >> Date: 20 November 2014 21:39:14 GMT >> To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons , Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie , Mandy Chung , Mark Reinhold , Paul Sandoz , "A. Sundararajan" >> >> This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. >> >> There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the 'To' section of this mail, and they will help address any comments arising from this review request. >> >> The new run-time image structure is defined in JEP 220 [1], and can be seen as a result of building the staging forest [2], or in the early access builds [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8061971/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev. >> >> -Chris. >> >> [1] http://openjdk.java.net/jeps/220 >> [2] http://hg.openjdk.java.net/jigsaw/m2/ >> [3] http://openjdk.java.net/projects/jigsaw/ea From Alan.Bateman at oracle.com Fri Nov 21 14:19:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Nov 2014 14:19:40 +0000 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: <546F450B.6090204@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <546F450B.6090204@oracle.com> Message-ID: <546F49FC.3090005@oracle.com> On 21/11/2014 13:58, Se?n Coffey wrote: > Chris, > > just a passing comment from me. I've been looking at the extension > directory changes. Looks like some code, locale resource files, man > pages and help menus still need updating to remove the ext dir > references. Is that tracked already ? > > The rmic, javadoc and javac tools still have the concept of an > extension directory. Yes, there is a bit of clean-up required, particularly docs/man pages, and there is an issue tracking that. For javac then we have JDK-8062015 to track looking at -endorseddirs as the changes mean it's only applicable when compiling to an target <= 8. Jon can confirm but I think that will be sorted out later. -Alan. From daniel.fuchs at oracle.com Fri Nov 21 14:33:05 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 21 Nov 2014 15:33:05 +0100 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: <546F4D21.8070106@oracle.com> Hi Chris, I had a look at the changes in java.logging and java.management modules (+ corresponding tests) and they look reasonable to me. I also had a cursory look at the jdeps changes. It's difficult for me to review that without importing the changes and playing with the tool as this is a part I'm less familiar with - but I didn't see anything that would be obviously wrong. I skipped most of the rest (especially the build changes ;-)). best regards, -- daniel On 20/11/14 22:41, Chris Hegarty wrote: > >> From: Chris Hegarty >> Subject: RFR [JEP 220] Modular Run-Time Images >> Date: 20 November 2014 21:39:14 GMT >> To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons , Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie , Mandy Chung , Mark Reinhold , Paul Sandoz , "A. Sundararajan" >> >> This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. >> >> There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the 'To' section of this mail, and they will help address any comments arising from this review request. >> >> The new run-time image structure is defined in JEP 220 [1], and can be seen as a result of building the staging forest [2], or in the early access builds [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8061971/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev. >> >> -Chris. >> >> [1] http://openjdk.java.net/jeps/220 >> [2] http://hg.openjdk.java.net/jigsaw/m2/ >> [3] http://openjdk.java.net/projects/jigsaw/ea > From erik.helin at oracle.com Fri Nov 21 14:57:52 2014 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 21 Nov 2014 15:57:52 +0100 Subject: RFR: 8065648: Remove the flag -fsanitize=undefined for GCC 4.9 and later Message-ID: <20141121145752.GA9983@ehelin-desktop> Hi all, this patch removes the usage of the flag -fsanitize=undefined introduced in GCC 4.9. The reason for not using this flag is that the implementation in GCC still seem to have some bugs [0] (which I have encountered). The flag is currently only enabled for slowdebug builds. My suggestion is that we remove the flag for now, since the only supported GCC version is 4.8.2 [1]. Then we can revisit this decisision when we upgrade the supported compiler to GCC 4.9.x, since hopefully the bugs in GCC have been fixed by then. What do you think? Webrev: http://cr.openjdk.java.net/~ehelin/8065648/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8065648 Testing: - Verified that generated-configure.sh no longer tries to enable the flag. Thanks, Erik [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1166173 [1]: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001489.html From erik.helin at oracle.com Fri Nov 21 15:30:12 2014 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 21 Nov 2014 16:30:12 +0100 Subject: RFR: 8065656: Use DWARF debug symbols for Solaris Message-ID: <20141121153011.GA12067@ehelin-desktop> Hi all, this patch changes the debug symbols format on Solaris from STABS [0] to DWARF [1] for libjvm.so. Since the supported compiler on Solaris has been updated to Oracle Solaris Studio 12.3 [2], the STABS debug format is now deprecated in the supported compiler [3]: -xdebugformat=stabs generates debugging information using the stabs standard format. The stabs format is no longer supported. Furthermore, in Oracle Solaris Studio 12.4, the release notes says [4]: The ?xdebugformat=stabs for all compilers might be removed in a future release. The only debugger format option will be ?xdebugformat=dwarf, which is currently the default. So, it seems to be a good time to change the debug format to DWARF when compiling with Oracle Solaris Studio. I also changed the debug format for GCC on Solaris to be DWARF, since the STABS support in GCC is in maintenance mode [5]. More reasons for using DWARF instead of STABS are: - Better support by Oracle Studio Performance Analyzer (the performance team have requested that we use DWARF v2 or later instead of STABS). - DWARF provides a better debugging experience for C++ compared to STABS. The one drawback of using DWARF compared to STABS is that the size of the debuginfo increases. For a SPARC fastdebug build the size of libjvm.debuginfo built with STABS is 782 MB and with DWARF 1002 MB. To summarize, we need to change from STABS to DWARF because STABS is deprecated in 12.3 (even "more" deprecated 12.4 given the wording in the release notes). I would suggest to change sooner rather than later, given that the change to DWARF also brings Oracle Studio Performance Analyzer support as well as a better C++ debugging experience in dbx. Webrev: http://cr.openjdk.java.net/~ehelin/8065656/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8065656 Testing: - Compiled with Oracle Solaris Studio 12.3 on both Solaris 11.1 on SPARC and Solaris 11.1 on x86-64 using JPRT. - Verified that DWARF v2 symbols are produced with objdump. Thanks, Erik [0]: http://www.sourceware.org/gdb/onlinedocs/stabs.html [1]: http://www.dwarfstd.org/ [2]: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001489.html [3]: https://docs.oracle.com/cd/E24457_01/html/E22003/cplusplus.1.html [4]: https://docs.oracle.com/cd/E37069_01/html/E37070/gnxfn.html [5]: https://sourceware.org/ml/binutils/2013-01/msg00028.html From magnus.ihse.bursie at oracle.com Fri Nov 21 15:46:38 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 21 Nov 2014 16:46:38 +0100 Subject: RFR: AARCH64: 8064357: Top-level JDK changes In-Reply-To: <546CD834.50004@redhat.com> References: <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> <5464C85C.50908@redhat.com> <546B7C8D.7050409@redhat.com> <20141118180315.GB22927@redhat.com> <546CD834.50004@redhat.com> Message-ID: <546F5E5E.3030309@oracle.com> On 2014-11-19 18:49, Andrew Haley wrote: > I think this covers everything that reviewers have mentioned: > > http://cr.openjdk.java.net/~aph/aarch64-8064357-4/ > > Andrew. > Almost there! :-) 1) Comment in config.sub identifies it as config.guess. 2) As as understand it, your first attempt is to just dispatch through to autoconf-config.sub if there is no aarch64 arguments. Good! However, the code could be made clearer: The dot is small and some comment clarifying that we will exit after this line might be helpful to the reader. Also, you're using a $sub_args which is not defined. This will not break, but it makes the reader confused. (I suspect copy/paste glitch.) 3) The webrev indicates that the original config.sub was renamed to config.sub.orig, instead of autoconf-config.sub. But since that is how it is called in the new config.sub wrapper, the patch is unlikely to work. When you test this, make sure you have no lingering files in your workspace that can mess up the results. (e.g. no "?" files in hg status). /Magnus From aph at redhat.com Fri Nov 21 16:01:50 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Nov 2014 16:01:50 +0000 Subject: RFR: AARCH64: 8064357: Top-level JDK changes In-Reply-To: <546F5E5E.3030309@oracle.com> References: <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> <5464C85C.50908@redhat.com> <546B7C8D.7050409@redhat.com> <20141118180315.GB22927@redhat.com> <546CD834.50004@redhat.com> <546F5E5E.3030309@oracle.com> Message-ID: <546F61EE.7050609@redhat.com> On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote: > > Almost there! :-) > > 1) Comment in config.sub identifies it as config.guess. > > 2) As as understand it, your first attempt is to just dispatch through > to autoconf-config.sub if there is no aarch64 arguments. Good! However, > the code could be made clearer: The dot is small and some comment > clarifying that we will exit after this line might be helpful to the > reader. I could just add exit $? after the call to autoconf-config.sub. That way it does not matter whether autoconf-config.sub exits or not, and the reader can tell that we don't go any further. > Also, you're using a $sub_args which is not defined. This will > not break, but it makes the reader confused. (I suspect copy/paste glitch.) Oh, bah. Right you are. > 3) The webrev indicates that the original config.sub was renamed to > config.sub.orig, instead of autoconf-config.sub. How strange. I'll fix that. > But since that is how > it is called in the new config.sub wrapper, the patch is unlikely to > work. When you test this, make sure you have no lingering files in your > workspace that can mess up the results. (e.g. no "?" files in hg status). OK. Andrew. From daniel.daugherty at oracle.com Fri Nov 21 16:14:06 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 21 Nov 2014 09:14:06 -0700 Subject: RFR: 8065656: Use DWARF debug symbols for Solaris In-Reply-To: <20141121153011.GA12067@ehelin-desktop> References: <20141121153011.GA12067@ehelin-desktop> Message-ID: <546F64CE.8090100@oracle.com> > http://cr.openjdk.java.net/~ehelin/8065656/webrev.00/ make/solaris/makefiles/gcc.make No comments. make/solaris/makefiles/sparcWorks.make No comments. Thumbs up! Dan On 11/21/14 8:30 AM, Erik Helin wrote: > Hi all, > > this patch changes the debug symbols format on Solaris from STABS > [0] to DWARF [1] for libjvm.so. Since the supported compiler on Solaris > has been updated to Oracle Solaris Studio 12.3 [2], the STABS debug format > is now deprecated in the supported compiler [3]: > > -xdebugformat=stabs generates debugging information > using the stabs standard format. The stabs format is no > longer supported. > > Furthermore, in Oracle Solaris Studio 12.4, the release notes says [4]: > > The ?xdebugformat=stabs for all compilers might be removed in a future > release. The only debugger format option will be ?xdebugformat=dwarf, > which is currently the default. > > So, it seems to be a good time to change the debug format to DWARF when > compiling with Oracle Solaris Studio. I also changed the debug format for > GCC on Solaris to be DWARF, since the STABS support in GCC is in > maintenance mode [5]. > > More reasons for using DWARF instead of STABS are: > - Better support by Oracle Studio Performance Analyzer (the performance > team have requested that we use DWARF v2 or later instead of STABS). > - DWARF provides a better debugging experience for C++ compared to STABS. > > The one drawback of using DWARF compared to STABS is that the size of the > debuginfo increases. For a SPARC fastdebug build the size of > libjvm.debuginfo built with STABS is 782 MB and with DWARF 1002 MB. > > To summarize, we need to change from STABS to DWARF because STABS is > deprecated in 12.3 (even "more" deprecated 12.4 given the wording in the > release notes). I would suggest to change sooner rather than later, given > that the change to DWARF also brings Oracle Studio Performance Analyzer > support as well as a better C++ debugging experience in dbx. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8065656/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8065656 > > Testing: > - Compiled with Oracle Solaris Studio 12.3 on both Solaris 11.1 on SPARC > and Solaris 11.1 on x86-64 using JPRT. > - Verified that DWARF v2 symbols are produced with objdump. > > Thanks, > Erik > > [0]: http://www.sourceware.org/gdb/onlinedocs/stabs.html > [1]: http://www.dwarfstd.org/ > [2]: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001489.html > [3]: https://docs.oracle.com/cd/E24457_01/html/E22003/cplusplus.1.html > [4]: https://docs.oracle.com/cd/E37069_01/html/E37070/gnxfn.html > [5]: https://sourceware.org/ml/binutils/2013-01/msg00028.html From charlie.hunt at oracle.com Fri Nov 21 16:30:18 2014 From: charlie.hunt at oracle.com (charlie hunt) Date: Fri, 21 Nov 2014 10:30:18 -0600 Subject: RFR: 8065656: Use DWARF debug symbols for Solaris In-Reply-To: <20141121153011.GA12067@ehelin-desktop> References: <20141121153011.GA12067@ehelin-desktop> Message-ID: <5C3C7BAF-ACF0-421F-A20B-F75022AF84D0@oracle.com> Looks good, though I am not an official (R)eviewer. Charlie > On Nov 21, 2014, at 9:30 AM, Erik Helin wrote: > > Hi all, > > this patch changes the debug symbols format on Solaris from STABS > [0] to DWARF [1] for libjvm.so. Since the supported compiler on Solaris > has been updated to Oracle Solaris Studio 12.3 [2], the STABS debug format > is now deprecated in the supported compiler [3]: > > -xdebugformat=stabs generates debugging information > using the stabs standard format. The stabs format is no > longer supported. > > Furthermore, in Oracle Solaris Studio 12.4, the release notes says [4]: > > The ?xdebugformat=stabs for all compilers might be removed in a future > release. The only debugger format option will be ?xdebugformat=dwarf, > which is currently the default. > > So, it seems to be a good time to change the debug format to DWARF when > compiling with Oracle Solaris Studio. I also changed the debug format for > GCC on Solaris to be DWARF, since the STABS support in GCC is in > maintenance mode [5]. > > More reasons for using DWARF instead of STABS are: > - Better support by Oracle Studio Performance Analyzer (the performance > team have requested that we use DWARF v2 or later instead of STABS). > - DWARF provides a better debugging experience for C++ compared to STABS. > > The one drawback of using DWARF compared to STABS is that the size of the > debuginfo increases. For a SPARC fastdebug build the size of > libjvm.debuginfo built with STABS is 782 MB and with DWARF 1002 MB. > > To summarize, we need to change from STABS to DWARF because STABS is > deprecated in 12.3 (even "more" deprecated 12.4 given the wording in the > release notes). I would suggest to change sooner rather than later, given > that the change to DWARF also brings Oracle Studio Performance Analyzer > support as well as a better C++ debugging experience in dbx. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8065656/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8065656 > > Testing: > - Compiled with Oracle Solaris Studio 12.3 on both Solaris 11.1 on SPARC > and Solaris 11.1 on x86-64 using JPRT. > - Verified that DWARF v2 symbols are produced with objdump. > > Thanks, > Erik > > [0]: http://www.sourceware.org/gdb/onlinedocs/stabs.html > [1]: http://www.dwarfstd.org/ > [2]: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001489.html > [3]: https://docs.oracle.com/cd/E24457_01/html/E22003/cplusplus.1.html > [4]: https://docs.oracle.com/cd/E37069_01/html/E37070/gnxfn.html > [5]: https://sourceware.org/ml/binutils/2013-01/msg00028.html From sean.mullan at oracle.com Fri Nov 21 16:51:03 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 21 Nov 2014 11:51:03 -0500 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: <546F6D77.1050006@oracle.com> The JDK security related changes look fine to me. The test/java/net/URLPermission/policy.* files only have copyright changes for some reason. --Sean On 11/20/2014 04:41 PM, Chris Hegarty wrote: > >> From: Chris Hegarty >> Subject: RFR [JEP 220] Modular Run-Time Images >> Date: 20 November 2014 21:39:14 GMT >> To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons , Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie , Mandy Chung , Mark Reinhold , Paul Sandoz , "A. Sundararajan" >> >> This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. >> >> There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the 'To' section of this mail, and they will help address any comments arising from this review request. >> >> The new run-time image structure is defined in JEP 220 [1], and can be seen as a result of building the staging forest [2], or in the early access builds [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8061971/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev. >> >> -Chris. >> >> [1] http://openjdk.java.net/jeps/220 >> [2] http://hg.openjdk.java.net/jigsaw/m2/ >> [3] http://openjdk.java.net/projects/jigsaw/ea > From aph at redhat.com Fri Nov 21 17:02:09 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Nov 2014 17:02:09 +0000 Subject: RFR: AARCH64: 8064357: Top-level JDK changes In-Reply-To: <546F5E5E.3030309@oracle.com> References: <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> <5464C85C.50908@redhat.com> <546B7C8D.7050409@redhat.com> <20141118180315.GB22927@redhat.com> <546CD834.50004@redhat.com> <546F5E5E.3030309@oracle.com> Message-ID: <546F7011.50600@redhat.com> On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote: > > 1) Comment in config.sub identifies it as config.guess. > > 2) As as understand it, your first attempt is to just dispatch through > to autoconf-config.sub if there is no aarch64 arguments. Good! However, > the code could be made clearer: The dot is small and some comment > clarifying that we will exit after this line might be helpful to the > reader. Also, you're using a $sub_args which is not defined. This will > not break, but it makes the reader confused. (I suspect copy/paste glitch.) > > 3) The webrev indicates that the original config.sub was renamed to > config.sub.orig, instead of autoconf-config.sub. But since that is how > it is called in the new config.sub wrapper, the patch is unlikely to > work. When you test this, make sure you have no lingering files in your > workspace that can mess up the results. (e.g. no "?" files in hg status). http://cr.openjdk.java.net/~aph/aarch64-8064357-5/ Thanks, Andrew. From chris.hegarty at oracle.com Fri Nov 21 17:08:15 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 21 Nov 2014 17:08:15 +0000 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: <546F6D77.1050006@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <546F6D77.1050006@oracle.com> Message-ID: On 21 Nov 2014, at 16:51, Sean Mullan wrote: > The JDK security related changes look fine to me. The test/java/net/URLPermission/policy.* files only have copyright changes for some reason. Thanks for reviewing the security related changes Sean. The jdk/test/java/net/URLPermission/policy.* files were changed in jigsaw/m2, at one point. Subsequent changes sync?ed from the JDK 9 mainline rendered these changes redundant, but the copyright, year range, change remained. The changes in these files are unnecessary and I have reversed them in jigsaw/m2 [1] Thanks, -Chris. [1] http://hg.openjdk.java.net/jigsaw/m2/jdk/rev/3032b0232660 > --Sean > > > On 11/20/2014 04:41 PM, Chris Hegarty wrote: >> >>> From: Chris Hegarty >>> Subject: RFR [JEP 220] Modular Run-Time Images >>> Date: 20 November 2014 21:39:14 GMT >>> To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons , Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie , Mandy Chung , Mark Reinhold , Paul Sandoz , "A. Sundararajan" >>> >>> This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. >>> >>> There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the 'To' section of this mail, and they will help address any comments arising from this review request. >>> >>> The new run-time image structure is defined in JEP 220 [1], and can be seen as a result of building the staging forest [2], or in the early access builds [3]. >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~chegar/8061971/00/ >>> >>> Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev. >>> >>> -Chris. >>> >>> [1] http://openjdk.java.net/jeps/220 >>> [2] http://hg.openjdk.java.net/jigsaw/m2/ >>> [3] http://openjdk.java.net/projects/jigsaw/ea >> From magnus.ihse.bursie at oracle.com Fri Nov 21 18:03:58 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 21 Nov 2014 19:03:58 +0100 Subject: RFR: AARCH64: 8064357: Top-level JDK changes In-Reply-To: <546F7011.50600@redhat.com> References: <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> <5464C85C.50908@redhat.com> <546B7C8D.7050409@redhat.com> <20141118180315.GB22927@redhat.com> <546CD834.50004@redhat.com> <546F5E5E.3030309@oracle.com> <546F7011.50600@redhat.com> Message-ID: <546F7E8E.2090405@oracle.com> On 2014-11-21 18:02, Andrew Haley wrote: > On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote: >> 1) Comment in config.sub identifies it as config.guess. >> >> 2) As as understand it, your first attempt is to just dispatch through >> to autoconf-config.sub if there is no aarch64 arguments. Good! However, >> the code could be made clearer: The dot is small and some comment >> clarifying that we will exit after this line might be helpful to the >> reader. Also, you're using a $sub_args which is not defined. This will >> not break, but it makes the reader confused. (I suspect copy/paste glitch.) >> >> 3) The webrev indicates that the original config.sub was renamed to >> config.sub.orig, instead of autoconf-config.sub. But since that is how >> it is called in the new config.sub wrapper, the patch is unlikely to >> work. When you test this, make sure you have no lingering files in your >> workspace that can mess up the results. (e.g. no "?" files in hg status). > http://cr.openjdk.java.net/~aph/aarch64-8064357-5/ Looks good to me. Thanks for working through all these iterations! /Magnus From vladimir.kozlov at oracle.com Fri Nov 21 18:09:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Nov 2014 10:09:35 -0800 Subject: RFR: AARCH64: 8064357: Top-level JDK changes In-Reply-To: <546F7E8E.2090405@oracle.com> References: <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> <5464C85C.50908@redhat.com> <546B7C8D.7050409@redhat.com> <20141118180315.GB22927@redhat.com> <546CD834.50004@redhat.com> <546F5E5E.3030309@oracle.com> <546F7011.50600@redhat.com> <546F7E8E.2090405@oracle.com> Message-ID: <546F7FDF.7050302@oracle.com> Thank you, Magnus I will push this into aarch64 staging repo after testing in JPRT. Vladimir On 11/21/14 10:03 AM, Magnus Ihse Bursie wrote: > > On 2014-11-21 18:02, Andrew Haley wrote: >> On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote: >>> 1) Comment in config.sub identifies it as config.guess. >>> >>> 2) As as understand it, your first attempt is to just dispatch through >>> to autoconf-config.sub if there is no aarch64 arguments. Good! However, >>> the code could be made clearer: The dot is small and some comment >>> clarifying that we will exit after this line might be helpful to the >>> reader. Also, you're using a $sub_args which is not defined. This will >>> not break, but it makes the reader confused. (I suspect copy/paste >>> glitch.) >>> >>> 3) The webrev indicates that the original config.sub was renamed to >>> config.sub.orig, instead of autoconf-config.sub. But since that is how >>> it is called in the new config.sub wrapper, the patch is unlikely to >>> work. When you test this, make sure you have no lingering files in your >>> workspace that can mess up the results. (e.g. no "?" files in hg >>> status). >> http://cr.openjdk.java.net/~aph/aarch64-8064357-5/ > > Looks good to me. > > Thanks for working through all these iterations! > > /Magnus From magnus.ihse.bursie at oracle.com Fri Nov 21 18:22:24 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 21 Nov 2014 19:22:24 +0100 Subject: Official and community supported build platforms for JDK 8 and 9 Message-ID: <546F82E0.9070909@oracle.com> A recurring theme in the build-dev list is confusion on which platforms it is possible to build OpenJDK. Unfortunately, information about this has not been easy to gather. It has also not been clear what kind of build issues the Build Team will respond to and with what kind of urgency. To help address this, I've created a publicly available wiki page: https://wiki.openjdk.java.net/display/Build/Supported+build+platforms Support for building on different platforms come in two varieties: official support and community support. Oracle defines a number of official build platforms, with carefully specified versions of operating systems, compilers and other build tools. If you report a failure to build on any of these platforms, the report will be processed with high priority from the build team in Oracle. Under normal circumstances, a build on any of these platforms will always succeed. In addition to the official build platforms, OpenJDK can normally be built on many more platforms. For these platforms, there is no guarantee that the build will succeed. The Oracle build team can help to solve some problems encountered, but only on a best-effort basis. In addition to the Oracle build team, the OpenJDK community at large is welcome to help with making OpenJDK compile on these platforms. The official and community supported build platforms are listed on the wiki page. Note that build support is different for different versions of the JDK. We welcome updates from the community to the list of community supported platforms. If you have succeeded (or not!) in building OpenJDK on a platform that is substantially different from the ones already listed, please document your experience in the list. The list of community supported platforms on the wiki is currently much shorter than the number of platforms I expect OpenJDK to build on. Once again, please help us by filling in the wiki! /Magnus From dean.long at oracle.com Fri Nov 21 19:31:08 2014 From: dean.long at oracle.com (Dean Long) Date: Fri, 21 Nov 2014 11:31:08 -0800 Subject: RFR: AARCH64: 8064357: Top-level JDK changes In-Reply-To: <546F7E8E.2090405@oracle.com> References: <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> <5464C85C.50908@redhat.com> <546B7C8D.7050409@redhat.com> <20141118180315.GB22927@redhat.com> <546CD834.50004@redhat.com> <546F5E5E.3030309@oracle.com> <546F7011.50600@redhat.com> <546F7E8E.2090405@oracle.com> Message-ID: <546F92FC.4080700@oracle.com> One minor comment: do we want to preserve the history in the new config.sub, or check it in as a new file? dl On 11/21/2014 10:03 AM, Magnus Ihse Bursie wrote: > > On 2014-11-21 18:02, Andrew Haley wrote: >> On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote: >>> 1) Comment in config.sub identifies it as config.guess. >>> >>> 2) As as understand it, your first attempt is to just dispatch through >>> to autoconf-config.sub if there is no aarch64 arguments. Good! However, >>> the code could be made clearer: The dot is small and some comment >>> clarifying that we will exit after this line might be helpful to the >>> reader. Also, you're using a $sub_args which is not defined. This will >>> not break, but it makes the reader confused. (I suspect copy/paste >>> glitch.) >>> >>> 3) The webrev indicates that the original config.sub was renamed to >>> config.sub.orig, instead of autoconf-config.sub. But since that is how >>> it is called in the new config.sub wrapper, the patch is unlikely to >>> work. When you test this, make sure you have no lingering files in your >>> workspace that can mess up the results. (e.g. no "?" files in hg >>> status). >> http://cr.openjdk.java.net/~aph/aarch64-8064357-5/ > > Looks good to me. > > Thanks for working through all these iterations! > > /Magnus From huizhe.wang at oracle.com Fri Nov 21 19:55:10 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 21 Nov 2014 11:55:10 -0800 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: <546F989E.6060101@oracle.com> Hi Chris, The jaxp changes look good as well. Only a couple of debug info in javax/xml/datatype/FactoryFinder.java and javax/xml/parsers/FactoryFinder.java may be fixed. They were wrong originally. You've fixed it in other FactoryFinders. "found in $java.home/jaxp.properties, "found in $java.home/conf/jaxp.properties, Thanks, Joe On 11/20/2014 1:41 PM, Chris Hegarty wrote: >> From: Chris Hegarty >> Subject: RFR [JEP 220] Modular Run-Time Images >> Date: 20 November 2014 21:39:14 GMT >> To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons , Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie , Mandy Chung , Mark Reinhold , Paul Sandoz , "A. Sundararajan" >> >> This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. >> >> There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the 'To' section of this mail, and they will help address any comments arising from this review request. >> >> The new run-time image structure is defined in JEP 220 [1], and can be seen as a result of building the staging forest [2], or in the early access builds [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8061971/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev. >> >> -Chris. >> >> [1] http://openjdk.java.net/jeps/220 >> [2] http://hg.openjdk.java.net/jigsaw/m2/ >> [3] http://openjdk.java.net/projects/jigsaw/ea From vladimir.kozlov at oracle.com Fri Nov 21 20:03:48 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Nov 2014 12:03:48 -0800 Subject: RFR: AARCH64: 8064357: Top-level JDK changes In-Reply-To: <546F92FC.4080700@oracle.com> References: <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> <5464C85C.50908@redhat.com> <546B7C8D.7050409@redhat.com> <20141118180315.GB22927@redhat.com> <546CD834.50004@redhat.com> <546F5E5E.3030309@oracle.com> <546F7011.50600@redhat.com> <546F7E8E.2090405@oracle.com> <546F92FC.4080700@oracle.com> Message-ID: <546F9AA4.3090206@oracle.com> The history is preserved since patch is applied above config.sub. I did 'hg copy config.sub autoconf-config.sub' and then applied the patch. And there are only 2 changesets in config.sub: changeset: 574:b66c81dfa291 user: ohair date: Mon Jan 14 16:38:25 2013 -0800 summary: 8005284: build-infra: nonstandard copyright headers under common/autoconf/build-aux changeset: 423:e1830598f0b7 parent: 417:42f275168fa5 user: ohair date: Tue Apr 10 08:18:28 2012 -0700 summary: 7074397: Build infrastructure changes (makefile re-write) Thanks, Vladimir On 11/21/14 11:31 AM, Dean Long wrote: > One minor comment: do we want to preserve the history in the new > config.sub, > or check it in as a new file? > > dl > > On 11/21/2014 10:03 AM, Magnus Ihse Bursie wrote: >> >> On 2014-11-21 18:02, Andrew Haley wrote: >>> On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote: >>>> 1) Comment in config.sub identifies it as config.guess. >>>> >>>> 2) As as understand it, your first attempt is to just dispatch through >>>> to autoconf-config.sub if there is no aarch64 arguments. Good! However, >>>> the code could be made clearer: The dot is small and some comment >>>> clarifying that we will exit after this line might be helpful to the >>>> reader. Also, you're using a $sub_args which is not defined. This will >>>> not break, but it makes the reader confused. (I suspect copy/paste >>>> glitch.) >>>> >>>> 3) The webrev indicates that the original config.sub was renamed to >>>> config.sub.orig, instead of autoconf-config.sub. But since that is how >>>> it is called in the new config.sub wrapper, the patch is unlikely to >>>> work. When you test this, make sure you have no lingering files in your >>>> workspace that can mess up the results. (e.g. no "?" files in hg >>>> status). >>> http://cr.openjdk.java.net/~aph/aarch64-8064357-5/ >> >> Looks good to me. >> >> Thanks for working through all these iterations! >> >> /Magnus > From dean.long at oracle.com Fri Nov 21 20:28:32 2014 From: dean.long at oracle.com (Dean Long) Date: Fri, 21 Nov 2014 12:28:32 -0800 Subject: RFR: AARCH64: 8064357: Top-level JDK changes In-Reply-To: <546F9AA4.3090206@oracle.com> References: <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> <5464C85C.50908@redhat.com> <546B7C8D.7050409@redhat.com> <20141118180315.GB22927@redhat.com> <546CD834.50004@redhat.com> <546F5E5E.3030309@oracle.com> <546F7011.50600@redhat.com> <546F7E8E.2090405@oracle.com> <546F92FC.4080700@oracle.com> <546F9AA4.3090206@oracle.com> Message-ID: <546FA070.2060801@oracle.com> I was thinking 'hg mv config.sub autoconf-config.sub' and then 'hg add config.sub' so it doesn't look like we are modifying the upstream version of config.sub, but maybe it's not a big deal? dl On 11/21/2014 12:03 PM, Vladimir Kozlov wrote: > The history is preserved since patch is applied above config.sub. > I did 'hg copy config.sub autoconf-config.sub' and then applied the > patch. > > And there are only 2 changesets in config.sub: > > changeset: 574:b66c81dfa291 > user: ohair > date: Mon Jan 14 16:38:25 2013 -0800 > summary: 8005284: build-infra: nonstandard copyright headers under > common/autoconf/build-aux > > changeset: 423:e1830598f0b7 > parent: 417:42f275168fa5 > user: ohair > date: Tue Apr 10 08:18:28 2012 -0700 > summary: 7074397: Build infrastructure changes (makefile re-write) > > Thanks, > Vladimir > > > On 11/21/14 11:31 AM, Dean Long wrote: >> One minor comment: do we want to preserve the history in the new >> config.sub, >> or check it in as a new file? >> >> dl >> >> On 11/21/2014 10:03 AM, Magnus Ihse Bursie wrote: >>> >>> On 2014-11-21 18:02, Andrew Haley wrote: >>>> On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote: >>>>> 1) Comment in config.sub identifies it as config.guess. >>>>> >>>>> 2) As as understand it, your first attempt is to just dispatch >>>>> through >>>>> to autoconf-config.sub if there is no aarch64 arguments. Good! >>>>> However, >>>>> the code could be made clearer: The dot is small and some comment >>>>> clarifying that we will exit after this line might be helpful to the >>>>> reader. Also, you're using a $sub_args which is not defined. This >>>>> will >>>>> not break, but it makes the reader confused. (I suspect copy/paste >>>>> glitch.) >>>>> >>>>> 3) The webrev indicates that the original config.sub was renamed to >>>>> config.sub.orig, instead of autoconf-config.sub. But since that is >>>>> how >>>>> it is called in the new config.sub wrapper, the patch is unlikely to >>>>> work. When you test this, make sure you have no lingering files in >>>>> your >>>>> workspace that can mess up the results. (e.g. no "?" files in hg >>>>> status). >>>> http://cr.openjdk.java.net/~aph/aarch64-8064357-5/ >>> >>> Looks good to me. >>> >>> Thanks for working through all these iterations! >>> >>> /Magnus >> From patrick at reini.net Fri Nov 21 20:46:55 2014 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 21 Nov 2014 21:46:55 +0100 Subject: Official and community supported build platforms for JDK 8 and 9 In-Reply-To: <546F82E0.9070909@oracle.com> References: <546F82E0.9070909@oracle.com> Message-ID: <80D05DC7-C7F3-4169-A49C-92DE0ED4668E@reini.net> Hi Magnus, > A recurring theme in the build-dev list is confusion on which platforms it is possible to build OpenJDK. Unfortunately, information about this has not been easy to gather. It has also not been clear what kind of build issues the Build Team will respond to and with what kind of urgency. > > To help address this, I?ve created a publicly available wiki page: https://wiki.openjdk.java.net/display/Build/Supported+build+platforms Nice work, that belongs on my shortcut list from now on. > Support for building on different platforms come in two varieties: official support and community support. > > Oracle defines a number of official build platforms, with carefully specified versions of operating systems, compilers and other build tools. If you report a failure to build on any of these platforms, the report will be processed with high priority from the build team in Oracle. Under normal circumstances, a build on any of these platforms will always succeed. > > In addition to the official build platforms, OpenJDK can normally be built on many more platforms. For these platforms, there is no guarantee that the build will succeed. The Oracle build team can help to solve some problems encountered, but only on a best-effort basis. In addition to the Oracle build team, the OpenJDK community at large is welcome to help with making OpenJDK compile on these platforms. > > The official and community supported build platforms are listed on the wiki page. Note that build support is different for different versions of the JDK. We welcome updates from the community to the list of community supported platforms. If you have succeeded (or not!) in building OpenJDK on a platform that is substantially different from the ones already listed, please document your experience in the list. I?m able to fluently build JDK 8u and JDK 9 on Fedora 21 x64 > The list of community supported platforms on the wiki is currently much shorter than the number of platforms I expect OpenJDK to build on. Once again, please help us by filling in the wiki! > > /Magnus I would like to help improve also documentations for the community? Patrick From omajid at redhat.com Fri Nov 21 20:55:16 2014 From: omajid at redhat.com (Omair Majid) Date: Fri, 21 Nov 2014 15:55:16 -0500 Subject: Official and community supported build platforms for JDK 8 and 9 In-Reply-To: <546F82E0.9070909@oracle.com> References: <546F82E0.9070909@oracle.com> Message-ID: <20141121205516.GA7046@redhat.com> Hi, Thanks for creating this! * Magnus Ihse Bursie [2014-11-21 13:22]: > To help address this, I've created a publicly available wiki page: > https://wiki.openjdk.java.net/display/Build/Supported+build+platforms Can you clarify what "Works correctly" means? Does it mean just building or does it include building and running? For example, OpenJDK 8 probably fails to build (or at least it used to fail to build) on most Linux distributions that were using Make 4.0. A patch was needed to fix that, but when that was fixed, OpenJDK 8 would build and run just fine. In cases like this, is it better to say "works correctly" and/or "builds with workarounds" or something else entirely? How about adding a column named "last checked" or "last updated" to make it obvious when building on that platform was last checked? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From aph at redhat.com Fri Nov 21 20:58:28 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Nov 2014 20:58:28 +0000 Subject: RFR: AARCH64: 8064357: Top-level JDK changes In-Reply-To: <546F7E8E.2090405@oracle.com> References: <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> <5464C85C.50908@redhat.com> <546B7C8D.7050409@redhat.com> <20141118180315.GB22927@redhat.com> <546CD834.50004@redhat.com> <546F5E5E.3030309@oracle.com> <546F7011.50600@redhat.com> <546F7E8E.2090405@oracle.com> Message-ID: <546FA774.7040401@redhat.com> On 11/21/2014 06:03 PM, Magnus Ihse Bursie wrote: > Thanks for working through all these iterations! Oh, the thanks should be the other way around. I really want this to be right. Andrew. From magnus.ihse.bursie at oracle.com Fri Nov 21 21:07:33 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 21 Nov 2014 22:07:33 +0100 Subject: RFR: JDK-8065412: generated source to compile .properties file incorreectly includes the module name in the package name In-Reply-To: <546DCE27.2040905@oracle.com> References: <546DCE27.2040905@oracle.com> Message-ID: <546FA995.7060704@oracle.com> On 2014-11-20 12:19, Erik Joelsson wrote: > Hello, > > Please review this small fix, correcting the source generation from > properties when the properties files are in platform specific source > directories. The bug was introduced by me in JDK-8055191. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065412 > Patch inline: > > diff --git a/make/gensrc/GensrcProperties.gmk > b/make/gensrc/GensrcProperties.gmk > --- a/make/gensrc/GensrcProperties.gmk > +++ b/make/gensrc/GensrcProperties.gmk > @@ -58,13 +58,15 @@ > $1_CLASS := $3 > > # Convert > .../src//share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties > - # to > .../langtools/gensrc//com/sun/tools/javac/resources/javac_zh_CN.java > + # to > .../support/gensrc//com/sun/tools/javac/resources/javac_zh_CN.java > # Strip away prefix and suffix, leaving for example only: > # "/share/classes/com/sun/tools/javac/resources/javac_zh_CN" > $1_JAVAS := $$(patsubst $(JDK_TOPDIR)/src/%, \ > $(JDK_OUTPUTDIR)/gensrc/%, \ > $$(patsubst %.properties, %.java, \ > - $$(subst /share/classes,, $$($1_SRCS)))) > + $$(subst /$(OPENJDK_TARGET_OS)/classes,, \ > + $$(subst /$(OPENJDK_TARGET_OS_API_DIR)/classes,, \ > + $$(subst /share/classes,, $$($1_SRCS)))))) > > # Generate the package dirs for the to be generated java files. > Sort to remove > # duplicates. > > > Note to Magnus. If this makes it in before your variable renaming, > this adds another place to rename. Looks good to me. But the variable renaming just went in, so you need to update your patch. /Magnus From martinrb at google.com Fri Nov 21 21:40:07 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 21 Nov 2014 13:40:07 -0800 Subject: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' In-Reply-To: <546E660C.1060909@oracle.com> References: <546C7C2D.3060805@oracle.com> <546CDE30.6030907@oracle.com> <546CFF3C.2030904@oracle.com> <546D0285.3090504@oracle.com> <546D2C7C.5020103@oracle.com> <546D3126.5010301@oracle.com> <546D3ECE.2040500@oracle.com> <546DB3BB.7020901@oracle.com> <546DB5AC.60401@oracle.com> <546DEE70.6020306@oracle.com> <546E23EF.4000506@oracle.com> <546E660C.1060909@oracle.com> Message-ID: A high-level followup ... Running most text-based OS tools, including sed and sort, is risky because the user's encoding may be different from the encoding of source files in the JDK (of course, this is particularly problematic with properties files, which must be ISO-8859-1). These tools will probably work better when run with LC_ALL=C. We should consider changing the definition of SED and SORT to something like $(ENV) LC_ALL=C sed As for set -o pipefail, it is sad that every single pipeline in the makefiles is vulnerable to failure to detect broken builds. The workaround in http://stackoverflow.com/questions/23079651/equivalent-of-pipefail-in-gnu-make is unaesthetic. It's enough to make you rewrite all your build tools in java! On Thu, Nov 20, 2014 at 2:07 PM, Mandy Chung wrote: > Daniel, > > Your test change looks fine and good to push this change that should catch > if similar regression occurs in the future. I was tempted to suggest to > have a dedicated test for the build-time modification to the properties > file. Maybe a low priority RFE. > > Mandy > > > On 11/20/14 9:25 AM, Daniel Fuchs wrote: >> >> On 20/11/14 14:36, Erik Joelsson wrote: >>> >>> Here is my proposal for fixing the particular issue of generating the >>> correct properties files. I'm simply adding LC_ALL=C to the whole >>> command line instead of just the sort at the end. It seems to require >>> using "export" to get picked up. >> >> >> Hi Erik, >> >> Looks good to me. >> >> I have applied your patch (manually, because the copy/paste >> seems to have eaten the tab characters away, which caused patch to >> reject the diff) - and I confirm that the issue has disappeared. >> >> Thanks for solving this! >> >> Do you think it would be worth to commit this test modification >> later on, in a followup Bug/RFE? >> >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8065138/webrev.00/jdk/test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java.frames.html >> >> If so I will take care of it. >> >> best regards, >> >> -- daniel >> >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8065138 >>> Patch: >>> diff --git a/make/common/JavaCompilation.gmk >>> b/make/common/JavaCompilation.gmk >>> --- a/make/common/JavaCompilation.gmk >>> +++ b/make/common/JavaCompilation.gmk >>> @@ -400,13 +400,15 @@ >>> # Now we can setup the depency that will trigger the copying. >>> $$($1_BIN)$$($2_TARGET) : $2 >>> $(MKDIR) -p $$(@D) >>> - $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e >>> 's/\([^\\]\)=/\1\\=/g' \ >>> + export LC_ALL=C ; $(CAT) $$< \ >>> + | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ >>> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >>> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >>> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >>> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >>> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >>> - -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >>> + -e 's/\\=/=/' \ >>> + | $(SORT) > $$@ >>> $(CHMOD) -f ug+w $$@ >>> >>> # And do not forget this target >>> >>> >>> I filed a separate issue [1] for investigating the use of pipefail. >>> >>> /Erik >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8065576 >>> >>> On 2014-11-20 10:34, Daniel Fuchs wrote: >>>> >>>> On 11/20/14 10:26 AM, Erik Joelsson wrote: >>>>> >>>>> Hello, >>>>> >>>>> On 2014-11-20 02:20, Martin Buchholz wrote: >>>>>> >>>>>> Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it, but >>>>>> the $(SED)s need it too! >>>>> >>>>> Yes, I think that's the correct fix in this case. >>>>>> >>>>>> On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz >>>>>> wrote: >>>>>>> >>>>>>> [+ build-dev] >>>>>>> >>>>>>> I think I see the problem. By default, a Unix pipeline sadly fails >>>>>>> only when the last command fails. In bash, you can change this to a >>>>>>> more sensible default via >>>>>>> set -o pipefail >>>>>>> but that's not portable enough for openjdk. >>>>> >>>>> This is interesting and something I had missed. I will experiment >>>>> with enabling pipefail if configure finds support for it. This will >>>>> include setting the SHELL to bash. We really should fail instead of >>>>> silently generating broken builds. >>>>> >>>>> Daniel, I can take over this bug if you want and work on a proper >>>>> build fix. >>>> >>>> >>>> Thanks Erik! You are welcome! >>>> So the whole issue seems to be that my default setting is >>>> LC_ALL=en_US.UTF-8 >>>> whereas sed requires LC_ALL=C to work properly on these property >>>> files... >>>> >>>> When the test first failed I tried to rerun the test with LC_ALL=C - >>>> with no success >>>> of course. But I never thought of rebuilding with LC_ALL=C :-( >>>> >>>> My apologies for the red herring :-( >>>> >>>> best regards >>>> >>>> -- daniel >>>> >>>>> >>>>> /Erik >>>>>>> >>>>>>> $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e >>>>>>> 's/\([^\\]\)=/\1\\=/g' \ >>>>>>> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >>>>>>> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >>>>>>> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >>>>>>> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >>>>>>> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >>>>>>> -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >>>>>>> >>>>>>> On Wed, Nov 19, 2014 at 5:07 PM, huizhe wang >>>>>>> wrote: >>>>>>>> >>>>>>>> On 11/19/2014 4:09 PM, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/19/2014 3:49 PM, Mandy Chung wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/19/2014 12:50 PM, Daniel Fuchs wrote: >>>>>>>>>>> >>>>>>>>>>> On 11/19/14 9:36 PM, Mandy Chung wrote: >>>>>>>>>>>> >>>>>>>>>>>> resources.jar will be gone when we move to the modular runtime >>>>>>>>>>>> image >>>>>>>>>>>> (JEP 220 [1]). >>>>>>>>>>>> JDK-8065138 and JDK-8065365 will become non-issue in JDK 9. >>>>>>>>>>> >>>>>>>>>>> Do you mean that the property files will no longer be stripped >>>>>>>>>>> of their >>>>>>>>>>> comments? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (sorry for my delay in reply as I was trying to get the number >>>>>>>>>> of the >>>>>>>>>> resources in the modular image vs resources.jar but got >>>>>>>>>> distracted.) >>>>>>>>>> >>>>>>>>>> The current version copies all bytes when generating the modular >>>>>>>>>> image. >>>>>>>>>> This is a good question whether we should strip off the comments >>>>>>>>>> when >>>>>>>>>> writing to the modular runtime image. I think we should look >>>>>>>>>> at the >>>>>>>>>> footprint and any performance saving and determine if we should >>>>>>>>>> do the same >>>>>>>>>> in JDK 9. >>>>>>>>>> >>>>>>>>> I looked at the exploded image under >>>>>>>>> BUILD_OUTPUTDIR/jdk/modules/java.xml >>>>>>>>> and found that the comments of Encodings.properties are stripped. >>>>>>>>> I was >>>>>>>>> confused with the mention of resources.jar that I assume it was a >>>>>>>>> step >>>>>>>>> stripping the comments before writing to resources.jar. This is >>>>>>>>> still >>>>>>>>> an issue in jigsaw m2 I believe. >>>>>>>>> >>>>>>>>> Where does the build strip the comments? >>>>>>>> >>>>>>>> >>>>>>>> A previous issue was that the build process strips off anything >>>>>>>> after '#' >>>>>>>> when copying properties files. In JDK8: >>>>>>>> jaxp/make/BuildJaxp.gmk: >>>>>>>> $(JAXP_OUTPUTDIR)/classes/%.properties: >>>>>>>> $(JAXP_TOPDIR)/src/%.properties >>>>>>>> $(MKDIR) -p $(@D) >>>>>>>> $(RM) $@ $@.tmp >>>>>>>> $(CAT) $< | LANG=C $(NAWK) '{ sub(/#.*$$/,"#"); print }' >>>>>>>> > $@.tmp >>>>>>>> $(MV) $@.tmp $@ >>>>>>>> >>>>>>>> This was fixed in JDK 9. The per-repo process was removed. It >>>>>>>> looks like >>>>>>>> the properties processing process is now consolidated into >>>>>>>> make/common/JavaCompilation.gmk. So the issue Daniel found is new >>>>>>>> (in terms >>>>>>>> of stripping). Search 'properties files' to see the macro. >>>>>>>> >>>>>>>> Joe >>>>>>>> >>>>>>>>> Mandy >>>>>>>>> >>>>> >>>> >>> >> > From ysr1729 at gmail.com Fri Nov 21 21:42:23 2014 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 21 Nov 2014 13:42:23 -0800 Subject: RFR: 8065656: Use DWARF debug symbols for Solaris In-Reply-To: <5C3C7BAF-ACF0-421F-A20B-F75022AF84D0@oracle.com> References: <20141121153011.GA12067@ehelin-desktop> <5C3C7BAF-ACF0-421F-A20B-F75022AF84D0@oracle.com> Message-ID: What does Peter think? For those too young to remember, Peter invented stabs way back when he was a young grad student at Berkeley :-) It has given admirable service, like so much else he has touched! -- Ramki ysr1729 > On Nov 21, 2014, at 08:30, charlie hunt wrote: > > Looks good, though I am not an official (R)eviewer. > > Charlie > >> On Nov 21, 2014, at 9:30 AM, Erik Helin wrote: >> >> Hi all, >> >> this patch changes the debug symbols format on Solaris from STABS >> [0] to DWARF [1] for libjvm.so. Since the supported compiler on Solaris >> has been updated to Oracle Solaris Studio 12.3 [2], the STABS debug format >> is now deprecated in the supported compiler [3]: >> >> -xdebugformat=stabs generates debugging information >> using the stabs standard format. The stabs format is no >> longer supported. >> >> Furthermore, in Oracle Solaris Studio 12.4, the release notes says [4]: >> >> The ?xdebugformat=stabs for all compilers might be removed in a future >> release. The only debugger format option will be ?xdebugformat=dwarf, >> which is currently the default. >> >> So, it seems to be a good time to change the debug format to DWARF when >> compiling with Oracle Solaris Studio. I also changed the debug format for >> GCC on Solaris to be DWARF, since the STABS support in GCC is in >> maintenance mode [5]. >> >> More reasons for using DWARF instead of STABS are: >> - Better support by Oracle Studio Performance Analyzer (the performance >> team have requested that we use DWARF v2 or later instead of STABS). >> - DWARF provides a better debugging experience for C++ compared to STABS. >> >> The one drawback of using DWARF compared to STABS is that the size of the >> debuginfo increases. For a SPARC fastdebug build the size of >> libjvm.debuginfo built with STABS is 782 MB and with DWARF 1002 MB. >> >> To summarize, we need to change from STABS to DWARF because STABS is >> deprecated in 12.3 (even "more" deprecated 12.4 given the wording in the >> release notes). I would suggest to change sooner rather than later, given >> that the change to DWARF also brings Oracle Studio Performance Analyzer >> support as well as a better C++ debugging experience in dbx. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8065656/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8065656 >> >> Testing: >> - Compiled with Oracle Solaris Studio 12.3 on both Solaris 11.1 on SPARC >> and Solaris 11.1 on x86-64 using JPRT. >> - Verified that DWARF v2 symbols are produced with objdump. >> >> Thanks, >> Erik >> >> [0]: http://www.sourceware.org/gdb/onlinedocs/stabs.html >> [1]: http://www.dwarfstd.org/ >> [2]: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001489.html >> [3]: https://docs.oracle.com/cd/E24457_01/html/E22003/cplusplus.1.html >> [4]: https://docs.oracle.com/cd/E37069_01/html/E37070/gnxfn.html >> [5]: https://sourceware.org/ml/binutils/2013-01/msg00028.html From ysr1729 at gmail.com Fri Nov 21 21:47:13 2014 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 21 Nov 2014 13:47:13 -0800 Subject: RFR: 8065656: Use DWARF debug symbols for Solaris In-Reply-To: References: <20141121153011.GA12067@ehelin-desktop> <5C3C7BAF-ACF0-421F-A20B-F75022AF84D0@oracle.com> Message-ID: Peter's email id corrected, this time... ysr1729 > On Nov 21, 2014, at 13:42, Srinivas Ramakrishna wrote: > > > What does Peter think? For those too young to remember, Peter invented stabs way back when he was a young grad student at Berkeley :-) > It has given admirable service, like so much else he has touched! > > -- Ramki > > ysr1729 > >> On Nov 21, 2014, at 08:30, charlie hunt wrote: >> >> Looks good, though I am not an official (R)eviewer. >> >> Charlie >> >>> On Nov 21, 2014, at 9:30 AM, Erik Helin wrote: >>> >>> Hi all, >>> >>> this patch changes the debug symbols format on Solaris from STABS >>> [0] to DWARF [1] for libjvm.so. Since the supported compiler on Solaris >>> has been updated to Oracle Solaris Studio 12.3 [2], the STABS debug format >>> is now deprecated in the supported compiler [3]: >>> >>> -xdebugformat=stabs generates debugging information >>> using the stabs standard format. The stabs format is no >>> longer supported. >>> >>> Furthermore, in Oracle Solaris Studio 12.4, the release notes says [4]: >>> >>> The ?xdebugformat=stabs for all compilers might be removed in a future >>> release. The only debugger format option will be ?xdebugformat=dwarf, >>> which is currently the default. >>> >>> So, it seems to be a good time to change the debug format to DWARF when >>> compiling with Oracle Solaris Studio. I also changed the debug format for >>> GCC on Solaris to be DWARF, since the STABS support in GCC is in >>> maintenance mode [5]. >>> >>> More reasons for using DWARF instead of STABS are: >>> - Better support by Oracle Studio Performance Analyzer (the performance >>> team have requested that we use DWARF v2 or later instead of STABS). >>> - DWARF provides a better debugging experience for C++ compared to STABS. >>> >>> The one drawback of using DWARF compared to STABS is that the size of the >>> debuginfo increases. For a SPARC fastdebug build the size of >>> libjvm.debuginfo built with STABS is 782 MB and with DWARF 1002 MB. >>> >>> To summarize, we need to change from STABS to DWARF because STABS is >>> deprecated in 12.3 (even "more" deprecated 12.4 given the wording in the >>> release notes). I would suggest to change sooner rather than later, given >>> that the change to DWARF also brings Oracle Studio Performance Analyzer >>> support as well as a better C++ debugging experience in dbx. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8065656/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8065656 >>> >>> Testing: >>> - Compiled with Oracle Solaris Studio 12.3 on both Solaris 11.1 on SPARC >>> and Solaris 11.1 on x86-64 using JPRT. >>> - Verified that DWARF v2 symbols are produced with objdump. >>> >>> Thanks, >>> Erik >>> >>> [0]: http://www.sourceware.org/gdb/onlinedocs/stabs.html >>> [1]: http://www.dwarfstd.org/ >>> [2]: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001489.html >>> [3]: https://docs.oracle.com/cd/E24457_01/html/E22003/cplusplus.1.html >>> [4]: https://docs.oracle.com/cd/E37069_01/html/E37070/gnxfn.html >>> [5]: https://sourceware.org/ml/binutils/2013-01/msg00028.html From vladimir.kozlov at oracle.com Fri Nov 21 22:37:10 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Nov 2014 14:37:10 -0800 Subject: RFR: AARCH64: 8064357: Top-level JDK changes In-Reply-To: <546FA070.2060801@oracle.com> References: <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> <5464C85C.50908@redhat.com> <546B7C8D.7050409@redhat.com> <20141118180315.GB22927@redhat.com> <546CD834.50004@redhat.com> <546F5E5E.3030309@oracle.com> <546F7011.50600@redhat.com> <546F7E8E.2090405@oracle.com> <546F92FC.4080700@oracle.com> <546F9AA4.3090206@oracle.com> <546FA070.2060801@oracle.com> Message-ID: <546FBE96.20303@oracle.com> I did as you said: hg mv common/autoconf/build-aux/config.sub common/autoconf/build-aux/autoconf-config.sub $ hg st M common/autoconf/generated-configure.sh M common/autoconf/jdk-options.m4 M common/autoconf/platform.m4 A common/autoconf/build-aux/autoconf-config.sub R common/autoconf/build-aux/config.sub $ cp new_config.sub common/autoconf/build-aux/config.sub $ hg add common/autoconf/build-aux/config.sub $ hg st M common/autoconf/generated-configure.sh M common/autoconf/jdk-options.m4 M common/autoconf/platform.m4 A common/autoconf/build-aux/autoconf-config.sub R common/autoconf/build-aux/config.sub And webrev shows config.sub diffs vs original one and not as new file. Vladimir On 11/21/14 12:28 PM, Dean Long wrote: > I was thinking 'hg mv config.sub autoconf-config.sub' and then > 'hg add config.sub' so it doesn't look like we are modifying the > upstream version > of config.sub, but maybe it's not a big deal? > > dl > > On 11/21/2014 12:03 PM, Vladimir Kozlov wrote: >> The history is preserved since patch is applied above config.sub. >> I did 'hg copy config.sub autoconf-config.sub' and then applied the >> patch. >> >> And there are only 2 changesets in config.sub: >> >> changeset: 574:b66c81dfa291 >> user: ohair >> date: Mon Jan 14 16:38:25 2013 -0800 >> summary: 8005284: build-infra: nonstandard copyright headers under >> common/autoconf/build-aux >> >> changeset: 423:e1830598f0b7 >> parent: 417:42f275168fa5 >> user: ohair >> date: Tue Apr 10 08:18:28 2012 -0700 >> summary: 7074397: Build infrastructure changes (makefile re-write) >> >> Thanks, >> Vladimir >> >> >> On 11/21/14 11:31 AM, Dean Long wrote: >>> One minor comment: do we want to preserve the history in the new >>> config.sub, >>> or check it in as a new file? >>> >>> dl >>> >>> On 11/21/2014 10:03 AM, Magnus Ihse Bursie wrote: >>>> >>>> On 2014-11-21 18:02, Andrew Haley wrote: >>>>> On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote: >>>>>> 1) Comment in config.sub identifies it as config.guess. >>>>>> >>>>>> 2) As as understand it, your first attempt is to just dispatch >>>>>> through >>>>>> to autoconf-config.sub if there is no aarch64 arguments. Good! >>>>>> However, >>>>>> the code could be made clearer: The dot is small and some comment >>>>>> clarifying that we will exit after this line might be helpful to the >>>>>> reader. Also, you're using a $sub_args which is not defined. This >>>>>> will >>>>>> not break, but it makes the reader confused. (I suspect copy/paste >>>>>> glitch.) >>>>>> >>>>>> 3) The webrev indicates that the original config.sub was renamed to >>>>>> config.sub.orig, instead of autoconf-config.sub. But since that is >>>>>> how >>>>>> it is called in the new config.sub wrapper, the patch is unlikely to >>>>>> work. When you test this, make sure you have no lingering files in >>>>>> your >>>>>> workspace that can mess up the results. (e.g. no "?" files in hg >>>>>> status). >>>>> http://cr.openjdk.java.net/~aph/aarch64-8064357-5/ >>>> >>>> Looks good to me. >>>> >>>> Thanks for working through all these iterations! >>>> >>>> /Magnus >>> > From Peter.B.Kessler at Oracle.COM Fri Nov 21 23:03:25 2014 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Fri, 21 Nov 2014 15:03:25 -0800 Subject: RFR: 8065656: Use DWARF debug symbols for Solaris In-Reply-To: References: <20141121153011.GA12067@ehelin-desktop> <5C3C7BAF-ACF0-421F-A20B-F75022AF84D0@oracle.com> Message-ID: <546FC4BD.2050209@Oracle.COM> I don't think I invented the stab format. I think stab.h came with adb and sdb, but might predate even those. Stab.h covers the basics of global symbols, procedures, source files, line numbers, etc. (The earliest copy I can find is http://svnweb.freebsd.org/csrg/include/stab.h?revision=12194&view=markup) I probably did invent the N_PC (0x30) stab variant for the Berkeley Pascal compiler. The trick there was that, rather than having to negotiate for some modest number of the limited (< 2 bytes) available space for stab entries, to claim only one entry for all the Pascal symbolic information and put all the information I needed into the string part of the "symbol". That left lots of room for other languages, and separated the Pascal compiler (and all the other languages) from having to edit stab.h as we figured out what we wanted in the way of debugging information. Maybe that is the origin of the "symbol table in the string" (stabs) idea. That said, I'm happy to see stabs replaced by something better. I'm also not an upper-case R reviewer. ... peter On 11/21/14 01:42 PM, Srinivas Ramakrishna wrote: > > What does Peter think? For those too young to remember, Peter invented stabs way back when he was a young grad student at Berkeley :-) > It has given admirable service, like so much else he has touched! > > -- Ramki > > ysr1729 > >> On Nov 21, 2014, at 08:30, charlie hunt wrote: >> >> Looks good, though I am not an official (R)eviewer. >> >> Charlie >> >>> On Nov 21, 2014, at 9:30 AM, Erik Helin wrote: >>> >>> Hi all, >>> >>> this patch changes the debug symbols format on Solaris from STABS >>> [0] to DWARF [1] for libjvm.so. Since the supported compiler on Solaris >>> has been updated to Oracle Solaris Studio 12.3 [2], the STABS debug format >>> is now deprecated in the supported compiler [3]: >>> >>> -xdebugformat=stabs generates debugging information >>> using the stabs standard format. The stabs format is no >>> longer supported. >>> >>> Furthermore, in Oracle Solaris Studio 12.4, the release notes says [4]: >>> >>> The ?xdebugformat=stabs for all compilers might be removed in a future >>> release. The only debugger format option will be ?xdebugformat=dwarf, >>> which is currently the default. >>> >>> So, it seems to be a good time to change the debug format to DWARF when >>> compiling with Oracle Solaris Studio. I also changed the debug format for >>> GCC on Solaris to be DWARF, since the STABS support in GCC is in >>> maintenance mode [5]. >>> >>> More reasons for using DWARF instead of STABS are: >>> - Better support by Oracle Studio Performance Analyzer (the performance >>> team have requested that we use DWARF v2 or later instead of STABS). >>> - DWARF provides a better debugging experience for C++ compared to STABS. >>> >>> The one drawback of using DWARF compared to STABS is that the size of the >>> debuginfo increases. For a SPARC fastdebug build the size of >>> libjvm.debuginfo built with STABS is 782 MB and with DWARF 1002 MB. >>> >>> To summarize, we need to change from STABS to DWARF because STABS is >>> deprecated in 12.3 (even "more" deprecated 12.4 given the wording in the >>> release notes). I would suggest to change sooner rather than later, given >>> that the change to DWARF also brings Oracle Studio Performance Analyzer >>> support as well as a better C++ debugging experience in dbx. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8065656/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8065656 >>> >>> Testing: >>> - Compiled with Oracle Solaris Studio 12.3 on both Solaris 11.1 on SPARC >>> and Solaris 11.1 on x86-64 using JPRT. >>> - Verified that DWARF v2 symbols are produced with objdump. >>> >>> Thanks, >>> Erik >>> >>> [0]: http://www.sourceware.org/gdb/onlinedocs/stabs.html >>> [1]: http://www.dwarfstd.org/ >>> [2]: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001489.html >>> [3]: https://docs.oracle.com/cd/E24457_01/html/E22003/cplusplus.1.html >>> [4]: https://docs.oracle.com/cd/E37069_01/html/E37070/gnxfn.html >>> [5]: https://sourceware.org/ml/binutils/2013-01/msg00028.html From magnus.ihse.bursie at oracle.com Fri Nov 21 23:16:02 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 22 Nov 2014 00:16:02 +0100 Subject: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' In-Reply-To: References: <546C7C2D.3060805@oracle.com> <546CDE30.6030907@oracle.com> <546CFF3C.2030904@oracle.com> <546D0285.3090504@oracle.com> <546D2C7C.5020103@oracle.com> <546D3126.5010301@oracle.com> <546D3ECE.2040500@oracle.com> <546DB3BB.7020901@oracle.com> <546DB5AC.60401@oracle.com> <546DEE70.6020306@oracle.com> <546E23EF.4000506@oracle.com> <546E660C.1060909@oracle.com> Message-ID: <546FC7B2.6060707@oracle.com> On 2014-11-21 22:40, Martin Buchholz wrote: > A high-level followup ... > > Running most text-based OS tools, including sed and sort, is risky > because the user's encoding may be different from the encoding of > source files in the JDK (of course, this is particularly problematic > with properties files, which must be ISO-8859-1). These tools will > probably work better when run with LC_ALL=C. We should consider > changing the definition of SED and SORT to something like > $(ENV) LC_ALL=C sed I agree. We should use LC_ALL=C on a more generic level, preferrably by prefixing all, or a selected set of tools with that. I opened https://bugs.openjdk.java.net/browse/JDK-8065704 to track that. > > As for set -o pipefail, it is sad that every single pipeline in the > makefiles is vulnerable to failure to detect broken builds. Fortunately, we already require bash for building, so given that -o pipefail it is not a too new invention in bash, we can enable it quite easily. Erik has already opened a bug for that, https://bugs.openjdk.java.net/browse/JDK-8065576. /Magnus From martinrb at google.com Fri Nov 21 23:39:43 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 21 Nov 2014 15:39:43 -0800 Subject: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' In-Reply-To: <546FC7B2.6060707@oracle.com> References: <546C7C2D.3060805@oracle.com> <546CDE30.6030907@oracle.com> <546CFF3C.2030904@oracle.com> <546D0285.3090504@oracle.com> <546D2C7C.5020103@oracle.com> <546D3126.5010301@oracle.com> <546D3ECE.2040500@oracle.com> <546DB3BB.7020901@oracle.com> <546DB5AC.60401@oracle.com> <546DEE70.6020306@oracle.com> <546E23EF.4000506@oracle.com> <546E660C.1060909@oracle.com> <546FC7B2.6060707@oracle.com> Message-ID: Great! On Fri, Nov 21, 2014 at 3:16 PM, Magnus Ihse Bursie wrote: > > On 2014-11-21 22:40, Martin Buchholz wrote: >> >> A high-level followup ... >> >> Running most text-based OS tools, including sed and sort, is risky >> because the user's encoding may be different from the encoding of >> source files in the JDK (of course, this is particularly problematic >> with properties files, which must be ISO-8859-1). These tools will >> probably work better when run with LC_ALL=C. We should consider >> changing the definition of SED and SORT to something like >> $(ENV) LC_ALL=C sed > > I agree. We should use LC_ALL=C on a more generic level, preferrably by > prefixing all, or a selected set of tools with that. I opened > https://bugs.openjdk.java.net/browse/JDK-8065704 to track that. > >> >> As for set -o pipefail, it is sad that every single pipeline in the >> makefiles is vulnerable to failure to detect broken builds. > > Fortunately, we already require bash for building, so given that -o pipefail > it is not a too new invention in bash, we can enable it quite easily. Erik > has already opened a bug for that, > https://bugs.openjdk.java.net/browse/JDK-8065576. > > /Magnus From dean.long at oracle.com Sat Nov 22 00:29:20 2014 From: dean.long at oracle.com (Dean Long) Date: Fri, 21 Nov 2014 16:29:20 -0800 Subject: RFR: AARCH64: 8064357: Top-level JDK changes In-Reply-To: <546FBE96.20303@oracle.com> References: <545D150F.0@redhat.com> <54607289.9090002@oracle.com> <54608868.3010108@oracle.com> <5464BBA9.1000809@oracle.com> <5464BFFA.7050205@redhat.com> <5464C7A0.4080304@oracle.com> <5464C85C.50908@redhat.com> <546B7C8D.7050409@redhat.com> <20141118180315.GB22927@redhat.com> <546CD834.50004@redhat.com> <546F5E5E.3030309@oracle.com> <546F7011.50600@redhat.com> <546F7E8E.2090405@oracle.com> <546F92FC.4080700@oracle.com> <546F9AA4.3090206@oracle.com> <546FA070.2060801@oracle.com> <546FBE96.20303@oracle.com> Message-ID: <546FD8E0.5050000@oracle.com> This may be a bug in webrev. If 'hg log -f' shows it as a new file, that should be enough. dl On 11/21/2014 2:37 PM, Vladimir Kozlov wrote: > I did as you said: > > hg mv common/autoconf/build-aux/config.sub > common/autoconf/build-aux/autoconf-config.sub > > $ hg st > M common/autoconf/generated-configure.sh > M common/autoconf/jdk-options.m4 > M common/autoconf/platform.m4 > A common/autoconf/build-aux/autoconf-config.sub > R common/autoconf/build-aux/config.sub > > $ cp new_config.sub common/autoconf/build-aux/config.sub > $ hg add common/autoconf/build-aux/config.sub > $ hg st > M common/autoconf/generated-configure.sh > M common/autoconf/jdk-options.m4 > M common/autoconf/platform.m4 > A common/autoconf/build-aux/autoconf-config.sub > R common/autoconf/build-aux/config.sub > > And webrev shows config.sub diffs vs original one and not as new file. > > Vladimir > > On 11/21/14 12:28 PM, Dean Long wrote: >> I was thinking 'hg mv config.sub autoconf-config.sub' and then >> 'hg add config.sub' so it doesn't look like we are modifying the >> upstream version >> of config.sub, but maybe it's not a big deal? >> >> dl >> >> On 11/21/2014 12:03 PM, Vladimir Kozlov wrote: >>> The history is preserved since patch is applied above config.sub. >>> I did 'hg copy config.sub autoconf-config.sub' and then applied the >>> patch. >>> >>> And there are only 2 changesets in config.sub: >>> >>> changeset: 574:b66c81dfa291 >>> user: ohair >>> date: Mon Jan 14 16:38:25 2013 -0800 >>> summary: 8005284: build-infra: nonstandard copyright headers under >>> common/autoconf/build-aux >>> >>> changeset: 423:e1830598f0b7 >>> parent: 417:42f275168fa5 >>> user: ohair >>> date: Tue Apr 10 08:18:28 2012 -0700 >>> summary: 7074397: Build infrastructure changes (makefile re-write) >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 11/21/14 11:31 AM, Dean Long wrote: >>>> One minor comment: do we want to preserve the history in the new >>>> config.sub, >>>> or check it in as a new file? >>>> >>>> dl >>>> >>>> On 11/21/2014 10:03 AM, Magnus Ihse Bursie wrote: >>>>> >>>>> On 2014-11-21 18:02, Andrew Haley wrote: >>>>>> On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote: >>>>>>> 1) Comment in config.sub identifies it as config.guess. >>>>>>> >>>>>>> 2) As as understand it, your first attempt is to just dispatch >>>>>>> through >>>>>>> to autoconf-config.sub if there is no aarch64 arguments. Good! >>>>>>> However, >>>>>>> the code could be made clearer: The dot is small and some comment >>>>>>> clarifying that we will exit after this line might be helpful to >>>>>>> the >>>>>>> reader. Also, you're using a $sub_args which is not defined. This >>>>>>> will >>>>>>> not break, but it makes the reader confused. (I suspect copy/paste >>>>>>> glitch.) >>>>>>> >>>>>>> 3) The webrev indicates that the original config.sub was renamed to >>>>>>> config.sub.orig, instead of autoconf-config.sub. But since that is >>>>>>> how >>>>>>> it is called in the new config.sub wrapper, the patch is >>>>>>> unlikely to >>>>>>> work. When you test this, make sure you have no lingering files in >>>>>>> your >>>>>>> workspace that can mess up the results. (e.g. no "?" files in hg >>>>>>> status). >>>>>> http://cr.openjdk.java.net/~aph/aarch64-8064357-5/ >>>>> >>>>> Looks good to me. >>>>> >>>>> Thanks for working through all these iterations! >>>>> >>>>> /Magnus >>>> >> From erik.joelsson at oracle.com Mon Nov 24 09:47:42 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 24 Nov 2014 10:47:42 +0100 Subject: RFR: 8065648: Remove the flag -fsanitize=undefined for GCC 4.9 and later In-Reply-To: <20141121145752.GA9983@ehelin-desktop> References: <20141121145752.GA9983@ehelin-desktop> Message-ID: <5472FEBE.7030103@oracle.com> I think it's a reasonable change to remove the flag as it has most likely not seen much use (if any) yet. I'm not sure what it does, but I assume it's something to improve exploit protection the source code. But if it doesn't work, we can't use it. We could also consider disabling the flag for the specific file where we have the problem, if we think it's useful to keep the flag. /Erik On 2014-11-21 15:57, Erik Helin wrote: > Hi all, > > this patch removes the usage of the flag -fsanitize=undefined introduced > in GCC 4.9. The reason for not using this flag is that the implementation > in GCC still seem to have some bugs [0] (which I have encountered). The > flag is currently only enabled for slowdebug builds. > > My suggestion is that we remove the flag for now, since the only supported > GCC version is 4.8.2 [1]. Then we can revisit this decisision when we upgrade > the supported compiler to GCC 4.9.x, since hopefully the bugs in GCC have > been fixed by then. > > What do you think? > > Webrev: > http://cr.openjdk.java.net/~ehelin/8065648/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8065648 > > Testing: > - Verified that generated-configure.sh no longer tries to enable the flag. > > Thanks, > Erik > > [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1166173 > [1]: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001489.html From erik.joelsson at oracle.com Mon Nov 24 10:44:47 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 24 Nov 2014 11:44:47 +0100 Subject: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' In-Reply-To: <546E23EF.4000506@oracle.com> References: <546C7C2D.3060805@oracle.com> <546CDE30.6030907@oracle.com> <546CFF3C.2030904@oracle.com> <546D0285.3090504@oracle.com> <546D2C7C.5020103@oracle.com> <546D3126.5010301@oracle.com> <546D3ECE.2040500@oracle.com> <546DB3BB.7020901@oracle.com> <546DB5AC.60401@oracle.com> <546DEE70.6020306@oracle.com> <546E23EF.4000506@oracle.com> Message-ID: <54730C1F.10101@oracle.com> Hello Daniel, Test seems like a great idea. Thanks! /Erik On 2014-11-20 18:25, Daniel Fuchs wrote: > On 20/11/14 14:36, Erik Joelsson wrote: >> Here is my proposal for fixing the particular issue of generating the >> correct properties files. I'm simply adding LC_ALL=C to the whole >> command line instead of just the sort at the end. It seems to require >> using "export" to get picked up. > > Hi Erik, > > Looks good to me. > > I have applied your patch (manually, because the copy/paste > seems to have eaten the tab characters away, which caused patch to > reject the diff) - and I confirm that the issue has disappeared. > > Thanks for solving this! > > Do you think it would be worth to commit this test modification > later on, in a followup Bug/RFE? > > http://cr.openjdk.java.net/~dfuchs/webrev_8065138/webrev.00/jdk/test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java.frames.html > > > If so I will take care of it. > > best regards, > > -- daniel > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8065138 >> Patch: >> diff --git a/make/common/JavaCompilation.gmk >> b/make/common/JavaCompilation.gmk >> --- a/make/common/JavaCompilation.gmk >> +++ b/make/common/JavaCompilation.gmk >> @@ -400,13 +400,15 @@ >> # Now we can setup the depency that will trigger the copying. >> $$($1_BIN)$$($2_TARGET) : $2 >> $(MKDIR) -p $$(@D) >> - $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e >> 's/\([^\\]\)=/\1\\=/g' \ >> + export LC_ALL=C ; $(CAT) $$< \ >> + | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ >> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >> - -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >> + -e 's/\\=/=/' \ >> + | $(SORT) > $$@ >> $(CHMOD) -f ug+w $$@ >> >> # And do not forget this target >> >> >> I filed a separate issue [1] for investigating the use of pipefail. >> >> /Erik >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8065576 >> >> On 2014-11-20 10:34, Daniel Fuchs wrote: >>> On 11/20/14 10:26 AM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> On 2014-11-20 02:20, Martin Buchholz wrote: >>>>> Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it, >>>>> but >>>>> the $(SED)s need it too! >>>> Yes, I think that's the correct fix in this case. >>>>> On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz >>>>> wrote: >>>>>> [+ build-dev] >>>>>> >>>>>> I think I see the problem. By default, a Unix pipeline sadly fails >>>>>> only when the last command fails. In bash, you can change this to a >>>>>> more sensible default via >>>>>> set -o pipefail >>>>>> but that's not portable enough for openjdk. >>>> This is interesting and something I had missed. I will experiment >>>> with enabling pipefail if configure finds support for it. This will >>>> include setting the SHELL to bash. We really should fail instead of >>>> silently generating broken builds. >>>> >>>> Daniel, I can take over this bug if you want and work on a proper >>>> build fix. >>> >>> Thanks Erik! You are welcome! >>> So the whole issue seems to be that my default setting is >>> LC_ALL=en_US.UTF-8 >>> whereas sed requires LC_ALL=C to work properly on these property >>> files... >>> >>> When the test first failed I tried to rerun the test with LC_ALL=C - >>> with no success >>> of course. But I never thought of rebuilding with LC_ALL=C :-( >>> >>> My apologies for the red herring :-( >>> >>> best regards >>> >>> -- daniel >>> >>>> >>>> /Erik >>>>>> $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e >>>>>> 's/\([^\\]\)=/\1\\=/g' \ >>>>>> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >>>>>> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >>>>>> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >>>>>> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >>>>>> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >>>>>> -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >>>>>> >>>>>> On Wed, Nov 19, 2014 at 5:07 PM, huizhe wang >>>>>> wrote: >>>>>>> On 11/19/2014 4:09 PM, Mandy Chung wrote: >>>>>>>> >>>>>>>> On 11/19/2014 3:49 PM, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> On 11/19/2014 12:50 PM, Daniel Fuchs wrote: >>>>>>>>>> On 11/19/14 9:36 PM, Mandy Chung wrote: >>>>>>>>>>> resources.jar will be gone when we move to the modular runtime >>>>>>>>>>> image >>>>>>>>>>> (JEP 220 [1]). >>>>>>>>>>> JDK-8065138 and JDK-8065365 will become non-issue in JDK 9. >>>>>>>>>> Do you mean that the property files will no longer be stripped >>>>>>>>>> of their >>>>>>>>>> comments? >>>>>>>>> >>>>>>>>> (sorry for my delay in reply as I was trying to get the number >>>>>>>>> of the >>>>>>>>> resources in the modular image vs resources.jar but got >>>>>>>>> distracted.) >>>>>>>>> >>>>>>>>> The current version copies all bytes when generating the modular >>>>>>>>> image. >>>>>>>>> This is a good question whether we should strip off the comments >>>>>>>>> when >>>>>>>>> writing to the modular runtime image. I think we should look >>>>>>>>> at the >>>>>>>>> footprint and any performance saving and determine if we should >>>>>>>>> do the same >>>>>>>>> in JDK 9. >>>>>>>>> >>>>>>>> I looked at the exploded image under >>>>>>>> BUILD_OUTPUTDIR/jdk/modules/java.xml >>>>>>>> and found that the comments of Encodings.properties are stripped. >>>>>>>> I was >>>>>>>> confused with the mention of resources.jar that I assume it was a >>>>>>>> step >>>>>>>> stripping the comments before writing to resources.jar. This is >>>>>>>> still >>>>>>>> an issue in jigsaw m2 I believe. >>>>>>>> >>>>>>>> Where does the build strip the comments? >>>>>>> >>>>>>> A previous issue was that the build process strips off anything >>>>>>> after '#' >>>>>>> when copying properties files. In JDK8: >>>>>>> jaxp/make/BuildJaxp.gmk: >>>>>>> $(JAXP_OUTPUTDIR)/classes/%.properties: >>>>>>> $(JAXP_TOPDIR)/src/%.properties >>>>>>> $(MKDIR) -p $(@D) >>>>>>> $(RM) $@ $@.tmp >>>>>>> $(CAT) $< | LANG=C $(NAWK) '{ sub(/#.*$$/,"#"); print }' >>>>>>> > $@.tmp >>>>>>> $(MV) $@.tmp $@ >>>>>>> >>>>>>> This was fixed in JDK 9. The per-repo process was removed. It >>>>>>> looks like >>>>>>> the properties processing process is now consolidated into >>>>>>> make/common/JavaCompilation.gmk. So the issue Daniel found is new >>>>>>> (in terms >>>>>>> of stripping). Search 'properties files' to see the macro. >>>>>>> >>>>>>> Joe >>>>>>> >>>>>>>> Mandy >>>>>>>> >>>> >>> >> > From chris.hegarty at oracle.com Mon Nov 24 10:55:11 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 24 Nov 2014 10:55:11 +0000 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: <54726AA3.3050708@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <54726AA3.3050708@oracle.com> Message-ID: <54730E8F.2040002@oracle.com> On 23/11/14 23:15, Magnus Ihse Bursie wrote: > > On 2014-11-20 22:39, Chris Hegarty wrote: >> This is a review request for the changes for JEP 220: Modular Run-Time >> Images [1]. >> >> There are a number of individuals responsible for these changes. Some, >> possibly not all, are explicitly listed in the 'To' section of this >> mail, and they will help address any comments arising from this review >> request. >> >> The new run-time image structure is defined in JEP 220 [1], and can be >> seen as a result of building the staging forest [2], or in the early >> access builds [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8061971/00/ > > I have thoroughly reviewed all the build changes, and they look good to > me, with the following remarks. Thanks for taking the time to review the build changes Magnus. > It would have been nice to use the new "wrapper" based approach for all > module-phase specific details -- this is done now for all phases except > gensrc and rmic. But this is not necessary for the patch to work, and > can be addressed later on. > > We also need to update configure to accept a module-based JDK as a boot > JDK. In the patch, this is done sort-of -- we can run a bootcycle build > with the new module-based JDK, but we will not accept it as an initial > boot JDK. But this too can be fixed later on. > > And of course there is always some syntax issues. :-) In > langtools/make/gensrc/Gensrc-jdk.*.gmk, there are several calls of the > pattern: > $(eval $(call SetupVersionProperties,JAVAP_VERSION, ...)) > $(eval $(call SetupCompileProperties,COMPILE_PROPERTIES, ...)) > These should have a space following the comma to adhere to the > recommended style. But once again, I'm okay with fixing this in a follow > up. It is up to you. If some of these changes are benign, then maybe you could work with Erik to get them into jigsaw/m2, otherwise we can fix them in jdk9/dev. Thanks again, -Chris. From daniel.fuchs at oracle.com Mon Nov 24 11:00:59 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 24 Nov 2014 12:00:59 +0100 Subject: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' In-Reply-To: <54730C1F.10101@oracle.com> References: <546C7C2D.3060805@oracle.com> <546CDE30.6030907@oracle.com> <546CFF3C.2030904@oracle.com> <546D0285.3090504@oracle.com> <546D2C7C.5020103@oracle.com> <546D3126.5010301@oracle.com> <546D3ECE.2040500@oracle.com> <546DB3BB.7020901@oracle.com> <546DB5AC.60401@oracle.com> <546DEE70.6020306@oracle.com> <546E23EF.4000506@oracle.com> <54730C1F.10101@oracle.com> Message-ID: <54730FEB.9020909@oracle.com> On 24/11/14 11:44, Erik Joelsson wrote: > Hello Daniel, > > Test seems like a great idea. Thanks! OK - I have logged JDK-8065748 https://bugs.openjdk.java.net/browse/JDK-8065748 I'll send a patch for review when your fix is in :-) Thanks! -- daniel > > /Erik > > On 2014-11-20 18:25, Daniel Fuchs wrote: >> On 20/11/14 14:36, Erik Joelsson wrote: >>> Here is my proposal for fixing the particular issue of generating the >>> correct properties files. I'm simply adding LC_ALL=C to the whole >>> command line instead of just the sort at the end. It seems to require >>> using "export" to get picked up. >> >> Hi Erik, >> >> Looks good to me. >> >> I have applied your patch (manually, because the copy/paste >> seems to have eaten the tab characters away, which caused patch to >> reject the diff) - and I confirm that the issue has disappeared. >> >> Thanks for solving this! >> >> Do you think it would be worth to commit this test modification >> later on, in a followup Bug/RFE? >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8065138/webrev.00/jdk/test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java.frames.html >> >> >> If so I will take care of it. >> >> best regards, >> >> -- daniel >> >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8065138 >>> Patch: >>> diff --git a/make/common/JavaCompilation.gmk >>> b/make/common/JavaCompilation.gmk >>> --- a/make/common/JavaCompilation.gmk >>> +++ b/make/common/JavaCompilation.gmk >>> @@ -400,13 +400,15 @@ >>> # Now we can setup the depency that will trigger the copying. >>> $$($1_BIN)$$($2_TARGET) : $2 >>> $(MKDIR) -p $$(@D) >>> - $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e >>> 's/\([^\\]\)=/\1\\=/g' \ >>> + export LC_ALL=C ; $(CAT) $$< \ >>> + | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ >>> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >>> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >>> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >>> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >>> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >>> - -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >>> + -e 's/\\=/=/' \ >>> + | $(SORT) > $$@ >>> $(CHMOD) -f ug+w $$@ >>> >>> # And do not forget this target >>> >>> >>> I filed a separate issue [1] for investigating the use of pipefail. >>> >>> /Erik >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8065576 >>> >>> On 2014-11-20 10:34, Daniel Fuchs wrote: >>>> On 11/20/14 10:26 AM, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> On 2014-11-20 02:20, Martin Buchholz wrote: >>>>>> Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it, >>>>>> but >>>>>> the $(SED)s need it too! >>>>> Yes, I think that's the correct fix in this case. >>>>>> On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz >>>>>> wrote: >>>>>>> [+ build-dev] >>>>>>> >>>>>>> I think I see the problem. By default, a Unix pipeline sadly fails >>>>>>> only when the last command fails. In bash, you can change this to a >>>>>>> more sensible default via >>>>>>> set -o pipefail >>>>>>> but that's not portable enough for openjdk. >>>>> This is interesting and something I had missed. I will experiment >>>>> with enabling pipefail if configure finds support for it. This will >>>>> include setting the SHELL to bash. We really should fail instead of >>>>> silently generating broken builds. >>>>> >>>>> Daniel, I can take over this bug if you want and work on a proper >>>>> build fix. >>>> >>>> Thanks Erik! You are welcome! >>>> So the whole issue seems to be that my default setting is >>>> LC_ALL=en_US.UTF-8 >>>> whereas sed requires LC_ALL=C to work properly on these property >>>> files... >>>> >>>> When the test first failed I tried to rerun the test with LC_ALL=C - >>>> with no success >>>> of course. But I never thought of rebuilding with LC_ALL=C :-( >>>> >>>> My apologies for the red herring :-( >>>> >>>> best regards >>>> >>>> -- daniel >>>> >>>>> >>>>> /Erik >>>>>>> $(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e >>>>>>> 's/\([^\\]\)=/\1\\=/g' \ >>>>>>> -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >>>>>>> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >>>>>>> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >>>>>>> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >>>>>>> -e 's/^[ ]*//;s/[ ]*$$$$//' \ >>>>>>> -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >>>>>>> >>>>>>> On Wed, Nov 19, 2014 at 5:07 PM, huizhe wang >>>>>>> wrote: >>>>>>>> On 11/19/2014 4:09 PM, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> On 11/19/2014 3:49 PM, Mandy Chung wrote: >>>>>>>>>> >>>>>>>>>> On 11/19/2014 12:50 PM, Daniel Fuchs wrote: >>>>>>>>>>> On 11/19/14 9:36 PM, Mandy Chung wrote: >>>>>>>>>>>> resources.jar will be gone when we move to the modular runtime >>>>>>>>>>>> image >>>>>>>>>>>> (JEP 220 [1]). >>>>>>>>>>>> JDK-8065138 and JDK-8065365 will become non-issue in JDK 9. >>>>>>>>>>> Do you mean that the property files will no longer be stripped >>>>>>>>>>> of their >>>>>>>>>>> comments? >>>>>>>>>> >>>>>>>>>> (sorry for my delay in reply as I was trying to get the number >>>>>>>>>> of the >>>>>>>>>> resources in the modular image vs resources.jar but got >>>>>>>>>> distracted.) >>>>>>>>>> >>>>>>>>>> The current version copies all bytes when generating the modular >>>>>>>>>> image. >>>>>>>>>> This is a good question whether we should strip off the comments >>>>>>>>>> when >>>>>>>>>> writing to the modular runtime image. I think we should look >>>>>>>>>> at the >>>>>>>>>> footprint and any performance saving and determine if we should >>>>>>>>>> do the same >>>>>>>>>> in JDK 9. >>>>>>>>>> >>>>>>>>> I looked at the exploded image under >>>>>>>>> BUILD_OUTPUTDIR/jdk/modules/java.xml >>>>>>>>> and found that the comments of Encodings.properties are stripped. >>>>>>>>> I was >>>>>>>>> confused with the mention of resources.jar that I assume it was a >>>>>>>>> step >>>>>>>>> stripping the comments before writing to resources.jar. This is >>>>>>>>> still >>>>>>>>> an issue in jigsaw m2 I believe. >>>>>>>>> >>>>>>>>> Where does the build strip the comments? >>>>>>>> >>>>>>>> A previous issue was that the build process strips off anything >>>>>>>> after '#' >>>>>>>> when copying properties files. In JDK8: >>>>>>>> jaxp/make/BuildJaxp.gmk: >>>>>>>> $(JAXP_OUTPUTDIR)/classes/%.properties: >>>>>>>> $(JAXP_TOPDIR)/src/%.properties >>>>>>>> $(MKDIR) -p $(@D) >>>>>>>> $(RM) $@ $@.tmp >>>>>>>> $(CAT) $< | LANG=C $(NAWK) '{ sub(/#.*$$/,"#"); print }' >>>>>>>> > $@.tmp >>>>>>>> $(MV) $@.tmp $@ >>>>>>>> >>>>>>>> This was fixed in JDK 9. The per-repo process was removed. It >>>>>>>> looks like >>>>>>>> the properties processing process is now consolidated into >>>>>>>> make/common/JavaCompilation.gmk. So the issue Daniel found is new >>>>>>>> (in terms >>>>>>>> of stripping). Search 'properties files' to see the macro. >>>>>>>> >>>>>>>> Joe >>>>>>>> >>>>>>>>> Mandy >>>>>>>>> >>>>> >>>> >>> >> > From chris.hegarty at oracle.com Mon Nov 24 13:56:13 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 24 Nov 2014 13:56:13 +0000 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: <546F989E.6060101@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <546F989E.6060101@oracle.com> Message-ID: <547338FD.5040005@oracle.com> Thanks for reviewing these changes Joe. On 21/11/14 19:55, huizhe wang wrote: > Hi Chris, > > The jaxp changes look good as well. Only a couple of debug info in > javax/xml/datatype/FactoryFinder.java and > javax/xml/parsers/FactoryFinder.java may be fixed. They were wrong > originally. You've fixed it in other FactoryFinders. > "found in $java.home/jaxp.properties, > "found in $java.home/conf/jaxp.properties, This has been fixed in jigsaw/m2. -Chris > > Thanks, > Joe > > On 11/20/2014 1:41 PM, Chris Hegarty wrote: >>> From: Chris Hegarty >>> Subject: RFR [JEP 220] Modular Run-Time Images >>> Date: 20 November 2014 21:39:14 GMT >>> To: jigsaw-dev , jdk9-dev >>> , build-dev , >>> Alan Bateman , Alex Buckley >>> , Chris Hegarty , >>> Erik Joelsson , Jonathan Gibbons >>> , Karen Kinnear >>> , "Jim Laskey (Oracle)" >>> , Magnus Ihse Bursie >>> , Mandy Chung >>> , Mark Reinhold , >>> Paul Sandoz , "A. Sundararajan" >>> >>> >>> This is a review request for the changes for JEP 220: Modular >>> Run-Time Images [1]. >>> >>> There are a number of individuals responsible for these changes. >>> Some, possibly not all, are explicitly listed in the 'To' section of >>> this mail, and they will help address any comments arising from this >>> review request. >>> >>> The new run-time image structure is defined in JEP 220 [1], and can >>> be seen as a result of building the staging forest [2], or in the >>> early access builds [3]. >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~chegar/8061971/00/ >>> >>> Due to the significant impact of these changes, a JDK 9 promotion has >>> been tentatively reserved for their integration. All comments are >>> welcome, although given the nature of the changes then we might have >>> to create separate issues in JIRA to address some of them later in >>> jdk9/dev. >>> >>> -Chris. >>> >>> [1] http://openjdk.java.net/jeps/220 >>> [2] http://hg.openjdk.java.net/jigsaw/m2/ >>> [3] http://openjdk.java.net/projects/jigsaw/ea > From erik.helin at oracle.com Mon Nov 24 14:07:34 2014 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 24 Nov 2014 15:07:34 +0100 Subject: RFR: 8065648: Remove the flag -fsanitize=undefined for GCC 4.9 and later In-Reply-To: <5472FEBE.7030103@oracle.com> References: <20141121145752.GA9983@ehelin-desktop> <5472FEBE.7030103@oracle.com> Message-ID: <20141124140734.GA23108@ehelin-desktop> Hi Erik, thanks for having a look! I realized that I had forgot to remove one usage of $HAS_CFLAG_DETECT_UNDEFINED_BEHAVIOR, please see new webrev at: http://cr.openjdk.java.net/~ehelin/8065648/webrev.01/ On 2014-11-24, Erik Joelsson wrote: > I think it's a reasonable change to remove the flag as it has most > likely not seen much use (if any) yet. I'm not sure what it does, > but I assume it's something to improve exploit protection the source > code. But if it doesn't work, we can't use it. I should have mentioned what the flag does. From the official documentation [2]: Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector. Various computations will be instrumented to detect undefined behavior at runtime. GCC will instrument (add) code to detect if we are using any undefined behavior at runtime, for example if the code divides an integer by zero. The flag was only enabled for slowdebug builds due to the overhead of this instrumentation. On 2014-11-24, Erik Joelsson wrote: > We could also consider disabling the flag for the specific file > where we have the problem, if we think it's useful to keep the flag. Given that the internal compiler error in GCC happens for such a small program as void fun() { double f = 0.0; (int)(1.0 < f ? 1.0 : 0.0); } I think it is better to not enable the flag for now and then re-enable it when the implementation in GCC is more stable (hopefully in some future GCC 4.9.x release). Thanks, Erik [2]: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Debugging-Options.html#Debugging-Options > /Erik > > On 2014-11-21 15:57, Erik Helin wrote: > >Hi all, > > > >this patch removes the usage of the flag -fsanitize=undefined introduced > >in GCC 4.9. The reason for not using this flag is that the implementation > >in GCC still seem to have some bugs [0] (which I have encountered). The > >flag is currently only enabled for slowdebug builds. > > > >My suggestion is that we remove the flag for now, since the only supported > >GCC version is 4.8.2 [1]. Then we can revisit this decisision when we upgrade > >the supported compiler to GCC 4.9.x, since hopefully the bugs in GCC have > >been fixed by then. > > > >What do you think? > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8065648/webrev.00/ > > > >Bug: > >https://bugs.openjdk.java.net/browse/JDK-8065648 > > > >Testing: > >- Verified that generated-configure.sh no longer tries to enable the flag. > > > >Thanks, > >Erik > > > >[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1166173 > >[1]: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001489.html > From erik.joelsson at oracle.com Mon Nov 24 14:19:13 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 24 Nov 2014 15:19:13 +0100 Subject: RFR: 8065648: Remove the flag -fsanitize=undefined for GCC 4.9 and later In-Reply-To: <20141124140734.GA23108@ehelin-desktop> References: <20141121145752.GA9983@ehelin-desktop> <5472FEBE.7030103@oracle.com> <20141124140734.GA23108@ehelin-desktop> Message-ID: <54733E61.4050803@oracle.com> Right, it's not a question of our code hitting the check, it's the compiler crashing on us. We can't have errors in the compiler we use. Looks good to me. Don't forget to regenerate configure and also push the closed version. /Erik On 2014-11-24 15:07, Erik Helin wrote: > Hi Erik, > > thanks for having a look! I realized that I had forgot to remove one usage > of $HAS_CFLAG_DETECT_UNDEFINED_BEHAVIOR, please see new webrev at: > > http://cr.openjdk.java.net/~ehelin/8065648/webrev.01/ > > On 2014-11-24, Erik Joelsson wrote: >> I think it's a reasonable change to remove the flag as it has most >> likely not seen much use (if any) yet. I'm not sure what it does, >> but I assume it's something to improve exploit protection the source >> code. But if it doesn't work, we can't use it. > I should have mentioned what the flag does. From the official > documentation [2]: > > Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector. > Various computations will be instrumented to detect undefined behavior > at runtime. > > GCC will instrument (add) code to detect if we are using any undefined > behavior at runtime, for example if the code divides an integer by zero. > The flag was only enabled for slowdebug builds due to the overhead of this > instrumentation. > > On 2014-11-24, Erik Joelsson wrote: >> We could also consider disabling the flag for the specific file >> where we have the problem, if we think it's useful to keep the flag. > Given that the internal compiler error in GCC happens for such a small > program as > > void fun() { > double f = 0.0; > (int)(1.0 < f ? 1.0 : 0.0); > } > > I think it is better to not enable the flag for now and then re-enable it > when the implementation in GCC is more stable (hopefully in some future > GCC 4.9.x release). > > Thanks, > Erik > > [2]: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Debugging-Options.html#Debugging-Options > >> /Erik >> >> On 2014-11-21 15:57, Erik Helin wrote: >>> Hi all, >>> >>> this patch removes the usage of the flag -fsanitize=undefined introduced >>> in GCC 4.9. The reason for not using this flag is that the implementation >>> in GCC still seem to have some bugs [0] (which I have encountered). The >>> flag is currently only enabled for slowdebug builds. >>> >>> My suggestion is that we remove the flag for now, since the only supported >>> GCC version is 4.8.2 [1]. Then we can revisit this decisision when we upgrade >>> the supported compiler to GCC 4.9.x, since hopefully the bugs in GCC have >>> been fixed by then. >>> >>> What do you think? >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8065648/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8065648 >>> >>> Testing: >>> - Verified that generated-configure.sh no longer tries to enable the flag. >>> >>> Thanks, >>> Erik >>> >>> [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1166173 >>> [1]: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001489.html From steven.loomis at oracle.com Mon Nov 24 17:52:41 2014 From: steven.loomis at oracle.com (Steven R. Loomis) Date: Mon, 24 Nov 2014 09:52:41 -0800 Subject: RFR: JDK-8027584 disable ccache by default In-Reply-To: <5465A84D.5090707@oracle.com> References: <52E83DCC.9040809@oracle.com> <5465A84D.5090707@oracle.com> Message-ID: <54737069.3050906@oracle.com> Filed: https://bugs.openjdk.java.net/browse/JDK-8065791 On 11/13/2014 10:59 PM, Steven R. Loomis wrote: > Late to the party, but please note that the README-builds.html *still* > says that ccache is great and you should install it. Doesn't mention > *anything* about ccache being off by default or `--enable-ccache` being > needed. In fact, configure actively disables ccache if you use a > symlink to ccache for gcc. > > I'll file a ticket if need be to fix the docs. Bit by this change- > ccache does much, much more good than harm for people who are making > small changes to big projects. Not going to argue the default, but > please keep the capability around if possible. > > -s (doing an overnight build to prime the ccache pump) > > On 1/28/2014 3:31 PM, Magnus Ihse Bursie wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8027584 >> >> While ccache can be used to speed up recompilations, there are also >> several issues with ccache. Old versions does not work correctly for >> the jdk (we try to detect that). It does not work well on other >> platforms than Linux; on Windows it does not work at all. Nevertheless >> is ccache enabled on Windows if it is installed, which it apparently >> tends to be with Cygwin nowadays, requiring the use of >> --disable-ccache to avoid compilation failure. >> >> In many circumstances ccache also does not provide any performance >> benefit. For instance, new compilations gets a performance hit. Only >> recompilations benefits. >> >> It is better to turn this upside down. This patch makes ccache >> disabled by default, on all platforms. If you want ccache and are sure >> you are in a situation that benefits from it, then you can enable it. >> It also removes the output in configure hinting that ccache should be >> used. >> >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8027584-disable-ccache-by-default/webrev.01 >> >> /Magnus From david.holmes at oracle.com Tue Nov 25 07:20:33 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Nov 2014 17:20:33 +1000 Subject: unlink problem on OSX with unzipped debuginfo In-Reply-To: <546DC0B9.502@oracle.com> References: <546DBBA2.9040201@oracle.com> <546DC0B9.502@oracle.com> Message-ID: <54742DC1.8020009@oracle.com> On 20/11/2014 8:21 PM, Erik Joelsson wrote: > I think it's Import.gmk that isn't working well with non zipped debug > symbols on mac. The .dSYM file is actually a directory and the logic in > Import.gmk probably hasn't been exercised with that much. Certainly some issues with Import.gmk eg it doesn't account for the Info.plist files. I'll fix that as part of what I am working on in 8u. But not sure if that relates to the unlink issue. Thanks, David > /Erik > > On 2014-11-20 11:00, David Holmes wrote: >> Building 8u on OSX with --disable-zip-debug-info I see in the log: >> >> make[2]: unlink: >> /Users/jprtadm/davidh-test/build/b01/se-macosx-x86_64-ea/jdk/lib/libjsig.dylib.dSYM: >> Operation not permitted >> >> Can anyone shed any light on this? I'm not clear on what is being >> attempted nor the affects on the build. >> >> Thanks, >> David > From magnus.ihse.bursie at oracle.com Tue Nov 25 15:13:23 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 25 Nov 2014 16:13:23 +0100 Subject: RFR: JDK-8065911 Introduce EvalDebugWrapper for all Setup* macros Message-ID: <54749C93.2040005@oracle.com> We should generalize the use of EvalDebugWrapper to all our SetupFoo functions. This will allow better debug possibilities of the build system. It will also, as a side effect, allow us to use proper whitespace around the parameters when calling this function. I also broke out the SetupZipArchive into a separate file. It is still included by SetupJavaCompilation, since it is required when doing a source zip, so no other changes are needed. Future cleanup will allow us to include ZipArchive only instead of JavaCompilation if we just want to create a zip file. Bug: https://bugs.openjdk.java.net/browse/JDK-8065911 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8065911-evalwrapper/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 25 15:56:33 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 25 Nov 2014 16:56:33 +0100 Subject: RFR: JDK-8065913 Various improvements in SetupNativeCompilation Message-ID: <5474A6B1.2040702@oracle.com> This is a bag of fixes that has been developed in the build-infra forest as part of preparatory work for converting the hotspot repo and closed Oracle repos to the new build-infra structure. The fix includes: * Setup proper dependencies for Windows RC files (.res) * Make it easier to support new types of native files and new extensions * Improved support for Objective-C * Additional arguments for customization * Improved logging Bug: https://bugs.openjdk.java.net/browse/JDK-8065913 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8065913-native-compilation-improvements/webrev.01 /Magnus From erik.joelsson at oracle.com Tue Nov 25 17:57:30 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 25 Nov 2014 18:57:30 +0100 Subject: RFR: JDK-8065911 Introduce EvalDebugWrapper for all Setup* macros In-Reply-To: <54749C93.2040005@oracle.com> References: <54749C93.2040005@oracle.com> Message-ID: <5474C30A.7000703@oracle.com> In ZipArchive.gmk, the file starts with comments referring to sjavac that look like they were copied from JavaCompilation.gmk. Otherwise looks good. I still haven't tried EvalDebugWrapper but it looks really neat. /Erik On 2014-11-25 16:13, Magnus Ihse Bursie wrote: > We should generalize the use of EvalDebugWrapper to all our SetupFoo > functions. This will allow better debug possibilities of the build > system. It will also, as a side effect, allow us to use proper > whitespace around the parameters when calling this function. > > I also broke out the SetupZipArchive into a separate file. It is still > included by SetupJavaCompilation, since it is required when doing a > source zip, so no other changes are needed. Future cleanup will allow > us to include ZipArchive only instead of JavaCompilation if we just > want to create a zip file. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065911 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8065911-evalwrapper/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 25 19:19:51 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 25 Nov 2014 20:19:51 +0100 Subject: RFR: JDK-8065911 Introduce EvalDebugWrapper for all Setup* macros In-Reply-To: <5474C30A.7000703@oracle.com> References: <54749C93.2040005@oracle.com> <5474C30A.7000703@oracle.com> Message-ID: <5474D657.7050407@oracle.com> On 2014-11-25 18:57, Erik Joelsson wrote: > In ZipArchive.gmk, the file starts with comments referring to sjavac > that look like they were copied from JavaCompilation.gmk. Which is exactly what is was. :-) > > Otherwise looks good. I still haven't tried EvalDebugWrapper but it > looks really neat. Thanks. Updated webrev with fixes for ZipArchive: http://cr.openjdk.java.net/~ihse/JDK-8065911-evalwrapper/webrev.02 /Magnus > > /Erik > > On 2014-11-25 16:13, Magnus Ihse Bursie wrote: >> We should generalize the use of EvalDebugWrapper to all our SetupFoo >> functions. This will allow better debug possibilities of the build >> system. It will also, as a side effect, allow us to use proper >> whitespace around the parameters when calling this function. >> >> I also broke out the SetupZipArchive into a separate file. It is >> still included by SetupJavaCompilation, since it is required when >> doing a source zip, so no other changes are needed. Future cleanup >> will allow us to include ZipArchive only instead of JavaCompilation >> if we just want to create a zip file. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8065911 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8065911-evalwrapper/webrev.01 >> >> /Magnus > From erik.joelsson at oracle.com Wed Nov 26 10:24:14 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 26 Nov 2014 11:24:14 +0100 Subject: RFR: JDK-8065911 Introduce EvalDebugWrapper for all Setup* macros In-Reply-To: <5474D657.7050407@oracle.com> References: <54749C93.2040005@oracle.com> <5474C30A.7000703@oracle.com> <5474D657.7050407@oracle.com> Message-ID: <5475AA4E.4060400@oracle.com> Looks good. /Erik On 2014-11-25 20:19, Magnus Ihse Bursie wrote: > > On 2014-11-25 18:57, Erik Joelsson wrote: >> In ZipArchive.gmk, the file starts with comments referring to sjavac >> that look like they were copied from JavaCompilation.gmk. > Which is exactly what is was. :-) >> >> Otherwise looks good. I still haven't tried EvalDebugWrapper but it >> looks really neat. > > Thanks. > > Updated webrev with fixes for ZipArchive: > http://cr.openjdk.java.net/~ihse/JDK-8065911-evalwrapper/webrev.02 > > /Magnus > >> >> /Erik >> >> On 2014-11-25 16:13, Magnus Ihse Bursie wrote: >>> We should generalize the use of EvalDebugWrapper to all our SetupFoo >>> functions. This will allow better debug possibilities of the build >>> system. It will also, as a side effect, allow us to use proper >>> whitespace around the parameters when calling this function. >>> >>> I also broke out the SetupZipArchive into a separate file. It is >>> still included by SetupJavaCompilation, since it is required when >>> doing a source zip, so no other changes are needed. Future cleanup >>> will allow us to include ZipArchive only instead of JavaCompilation >>> if we just want to create a zip file. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8065911 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8065911-evalwrapper/webrev.01 >>> >>> /Magnus >> > From erik.joelsson at oracle.com Wed Nov 26 12:00:36 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 26 Nov 2014 13:00:36 +0100 Subject: RFR: JDK-8065913 Various improvements in SetupNativeCompilation In-Reply-To: <5474A6B1.2040702@oracle.com> References: <5474A6B1.2040702@oracle.com> Message-ID: <5475C0E4.8030608@oracle.com> NativeCompilation.gmk looks like there is a \ missing at line 3 of replace_with_obj_extensions. Otherwise looks good. /Erik On 2014-11-25 16:56, Magnus Ihse Bursie wrote: > This is a bag of fixes that has been developed in the build-infra > forest as part of preparatory work for converting the hotspot repo and > closed Oracle repos to the new build-infra structure. > > The fix includes: > * Setup proper dependencies for Windows RC files (.res) > * Make it easier to support new types of native files and new > extensions > * Improved support for Objective-C > * Additional arguments for customization > * Improved logging > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065913 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8065913-native-compilation-improvements/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Wed Nov 26 13:22:50 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 26 Nov 2014 14:22:50 +0100 Subject: RFR: JDK-8065914 Various improvements and cleanup of build system Message-ID: <5475D42A.60305@oracle.com> This is another bunch of improvements from the preparatory work in the build-infra forest. This fix includes: * Compare script improvements * Improvements of TextFileProcessing and RmiCompilation * Make install-file more robust * Better handling of top-level make on error and integration with external tools like bash completion. * Remove trailing whitespace * Various minor fixes Bug: https://bugs.openjdk.java.net/browse/JDK-8065914 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8065914-build-improvements/webrev.01 /Magnus From denis.fokin at gmail.com Wed Nov 26 13:30:40 2014 From: denis.fokin at gmail.com (Denis Fokin) Date: Wed, 26 Nov 2014 16:30:40 +0300 Subject: Building openjdk 8 on Mac OS X In-Reply-To: <5F78A0ED-DCE6-410D-9471-0732784DCD56@oracle.com> References: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> <545B318F.3090805@oracle.com> <5F78A0ED-DCE6-410D-9471-0732784DCD56@oracle.com> Message-ID: Hi guys, good news. I am able to build open jdk8 on Yosemite (thanks to Anton Tarasov for his script to build on 10.9) Steps: 1. Download and save in some secure place Xcode4.6 2. Make a link form Xcode.4 lipo to /usr/bin/lipo 3. Set MACOSX_DEPLOYMENT_TARGET enviroment variable to 10.8 4. Execute configure like this sh configure --with-freetype=/Volumes/HD-PATU3/tools/freetype-2.4.0/ --with-extra-cflags="-isysroot /Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks" --with-extra-cxxflags="-isysroot /Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks" --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/ Thank you, Denis. > On 12 Nov 2014, at 20:29, David DeHaven wrote: > > > Not 8, 9... > > -DrD- > >> Hi Wang >> >> You were able to compile openjdk8 on Yosemite!! Can you please look into the error faced by me (first post in the thread; posted below as well) and figure out the problem(s)? >> >> Regards, >> Manas >> >> >> >>> Yes, I can compile the whole mess on Yosemite/Xcode 6.1. There was an issue with FreeType when building OpenJDK, but it looks like that's been resolved now. >>> >>> -DrD- >>> >> >> Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp >> Making signal interposition lib... >> couldn't understand kern.osversion `14.0.0' >> warning: (x86_64) /var/folders/16/5m_yzyd961b3l31crzg2hsl40000gp/T//ccEmbC6U.o unable to open object file >> warning: no debug symbols in executable (-arch x86_64) >> Making SA debugger back-end... >> couldn't understand kern.osversion `14.0.0' >> In file included from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:55, >> from /System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12, >> from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:80, >> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >> /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:262: error: expected ?,? or ?}? before ?__attribute__? >> /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:414: error: expected ?,? or ?}? before ?__attribute__? >> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:119, >> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >> /System/Library/Frameworks/Foundation.framework/Headers/NSUserActivity.h:55: error: expected a property attribute before ?weak? >> Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/runtime/vm_version.cpp >> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:171, >> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >> /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error: expected ?,? or ?}? before ?__attribute__? >> make[8]: *** [libsaproc.dylib] Error 1 >> make[8]: *** Waiting for unfinished jobs.... >> make[7]: *** [the_vm] Error 2 >> make[6]: *** [product] Error 2 >> make[5]: *** [generic_build2] Error 2 >> make[4]: *** [product] Error 2 >> make[3]: *** [all_product_universal] Error 2 >> make[2]: *** [universal_product] Error 2 >> make[1]: *** [/Users/manas/Desktop/Software/openjdk/sources/openjdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 >> make: *** [hotspot-only] Error 2 >> > From magnus.ihse.bursie at oracle.com Wed Nov 26 14:05:02 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 26 Nov 2014 15:05:02 +0100 Subject: RFR: JDK-8065913 Various improvements in SetupNativeCompilation In-Reply-To: <5475C0E4.8030608@oracle.com> References: <5474A6B1.2040702@oracle.com> <5475C0E4.8030608@oracle.com> Message-ID: <5475DE0E.9070308@oracle.com> On 2014-11-26 13:00, Erik Joelsson wrote: > NativeCompilation.gmk > looks like there is a \ missing at line 3 of replace_with_obj_extensions. Fixed. http://cr.openjdk.java.net/~ihse/JDK-8065913-native-compilation-improvements/webrev.02 > > Otherwise looks good. Thanks! /Magnus From erik.joelsson at oracle.com Wed Nov 26 14:05:28 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 26 Nov 2014 15:05:28 +0100 Subject: RFR: JDK-8065913 Various improvements in SetupNativeCompilation In-Reply-To: <5475DE0E.9070308@oracle.com> References: <5474A6B1.2040702@oracle.com> <5475C0E4.8030608@oracle.com> <5475DE0E.9070308@oracle.com> Message-ID: <5475DE28.2070403@oracle.com> Looks good. /Erik On 2014-11-26 15:05, Magnus Ihse Bursie wrote: > On 2014-11-26 13:00, Erik Joelsson wrote: >> NativeCompilation.gmk >> looks like there is a \ missing at line 3 of >> replace_with_obj_extensions. > Fixed. > > http://cr.openjdk.java.net/~ihse/JDK-8065913-native-compilation-improvements/webrev.02 > > >> >> Otherwise looks good. > Thanks! > > /Magnus > From erik.joelsson at oracle.com Wed Nov 26 14:14:55 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 26 Nov 2014 15:14:55 +0100 Subject: RFR: JDK-8065914 Various improvements and cleanup of build system In-Reply-To: <5475D42A.60305@oracle.com> References: <5475D42A.60305@oracle.com> Message-ID: <5475E05F.3080401@oracle.com> Looks good. /Erik On 2014-11-26 14:22, Magnus Ihse Bursie wrote: > This is another bunch of improvements from the preparatory work in the > build-infra forest. > > This fix includes: > * Compare script improvements > * Improvements of TextFileProcessing and RmiCompilation > * Make install-file more robust > * Better handling of top-level make on error and integration with > external tools like bash completion. > * Remove trailing whitespace > * Various minor fixes > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065914 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8065914-build-improvements/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Wed Nov 26 14:56:14 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 26 Nov 2014 15:56:14 +0100 Subject: RFR: JDK-8065576: Enable pipefail in the shell used by make to better detect build errors Message-ID: <5475EA0E.6040405@oracle.com> Hello, Please review this build reliability fix. In JDK-8065138, we would have caught the error much faster if the build had failed instead of silently generating bad output. To avoid this in the future, this patch activates pipefail and errexit in the shell, when available. This means that long command lines, consisting of multiple commands, chained together either by pipes or ';', will fail the build regardless of which of the sub commands that failed. Currently, all but the last command would be ignored. Since these features my not always be available in all versions of bash, I added a check to configure for each of them and only enable them if they are available. I also had to fix some instances where we have 'grep' and 'find' returning non zero without it being an error. Thanks to Martin who suggested this in the first place. Bug: https://bugs.openjdk.java.net/browse/JDK-8065576 Webrev: http://cr.openjdk.java.net/~erikj/8065576/webrev.root.01/ /Erik From tim.bell at oracle.com Wed Nov 26 16:01:20 2014 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 26 Nov 2014 08:01:20 -0800 Subject: RFR: JDK-8065576: Enable pipefail in the shell used by make to better detect build errors In-Reply-To: <5475EA0E.6040405@oracle.com> References: <5475EA0E.6040405@oracle.com> Message-ID: <5475F950.6030900@oracle.com> Erik: > Please review this build reliability fix. In JDK-8065138, we would > have caught the error much faster if the build had failed instead of > silently generating bad output. To avoid this in the future, this > patch activates pipefail and errexit in the shell, when available. > This means that long command lines, consisting of multiple commands, > chained together either by pipes or ';', will fail the build > regardless of which of the sub commands that failed. Currently, all > but the last command would be ignored. > > Since these features my not always be available in all versions of > bash, I added a check to configure for each of them and only enable > them if they are available. I also had to fix some instances where we > have 'grep' and 'find' returning non zero without it being an error. > > Thanks to Martin who suggested this in the first place. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065576 > Webrev: http://cr.openjdk.java.net/~erikj/8065576/webrev.root.01 Looks good to me. Tim From martinrb at google.com Wed Nov 26 16:42:51 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 26 Nov 2014 08:42:51 -0800 Subject: RFR: JDK-8065576: Enable pipefail in the shell used by make to better detect build errors In-Reply-To: <5475EA0E.6040405@oracle.com> References: <5475EA0E.6040405@oracle.com> Message-ID: Looks good to me too. I appreciate the high bar for build correctness. I would test with both make 3.81 and 4.x On Wed, Nov 26, 2014 at 6:56 AM, Erik Joelsson wrote: > Hello, > > Please review this build reliability fix. In JDK-8065138, we would have > caught the error much faster if the build had failed instead of silently > generating bad output. To avoid this in the future, this patch activates > pipefail and errexit in the shell, when available. This means that long > command lines, consisting of multiple commands, chained together either by > pipes or ';', will fail the build regardless of which of the sub commands > that failed. Currently, all but the last command would be ignored. > > Since these features my not always be available in all versions of bash, I > added a check to configure for each of them and only enable them if they are > available. I also had to fix some instances where we have 'grep' and 'find' > returning non zero without it being an error. > > Thanks to Martin who suggested this in the first place. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065576 > Webrev: http://cr.openjdk.java.net/~erikj/8065576/webrev.root.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Wed Nov 26 23:21:10 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 27 Nov 2014 00:21:10 +0100 Subject: RFR: JDK-8065576: Enable pipefail in the shell used by make to better detect build errors In-Reply-To: <5475EA0E.6040405@oracle.com> References: <5475EA0E.6040405@oracle.com> Message-ID: <54766066.9060206@oracle.com> On 2014-11-26 15:56, Erik Joelsson wrote: > Hello, > > Please review this build reliability fix. In JDK-8065138, we would > have caught the error much faster if the build had failed instead of > silently generating bad output. To avoid this in the future, this > patch activates pipefail and errexit in the shell, when available. > This means that long command lines, consisting of multiple commands, > chained together either by pipes or ';', will fail the build > regardless of which of the sub commands that failed. Currently, all > but the last command would be ignored. > > Since these features my not always be available in all versions of > bash, I added a check to configure for each of them and only enable > them if they are available. I also had to fix some instances where we > have 'grep' and 'find' returning non zero without it being an error. > > Thanks to Martin who suggested this in the first place. Thank you for fixing this so quickly! The webrev looks good as such, but I think you have missed how this interact with common/bin/shell-tracer.sh. Which, unfortunately, is non-trivial. :-( First of all, I realize that the existing line in MakeBase: WRAPPER_SHELL:=$$(BASH) $$(SRC_ROOT)/common/bin/shell-tracer.sh $$(if $$(findstring yes,$$(IS_GNU_TIME)),$$(TIME),-) $$(OUTPUT_ROOT)/build-trace-time.log $$(BASH) is incorrect. (It's my bad...) The last $$(BASH) is supposed to be the old value of $(SHELL), according to shell-tracer.sh. So, even before your fix, it should have been $$(SHELL), not $$(BASH). However, even if you fix that, I'm not sure how this will work with a $(SHELL) that has spaces in it. I think you can get it working it by sending "$$(SHELL)" as last argument in WRAPPER_SHELL, and updating shell-tracer.sh, so that the assignment to OLD_SHELL keeps the "" around $3, but the calls to "$OLD_SHELL" (note, two places) removes the "". But you'll have to verify that. /Magnus From jvanek at redhat.com Thu Nov 27 13:03:11 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 27 Nov 2014 14:03:11 +0100 Subject: Official and community supported build platforms for JDK 8 and 9 In-Reply-To: <20141121205516.GA7046@redhat.com> References: <546F82E0.9070909@oracle.com> <20141121205516.GA7046@redhat.com> Message-ID: <5477210F.7010107@redhat.com> On 11/21/2014 09:55 PM, Omair Majid wrote: > Hi, > > Thanks for creating this! > > * Magnus Ihse Bursie [2014-11-21 13:22]: >> To help address this, I've created a publicly available wiki page: >> https://wiki.openjdk.java.net/display/Build/Supported+build+platforms > > Can you clarify what "Works correctly" means? Does it mean just building > or does it include building and running? For example, OpenJDK 8 probably > fails to build (or at least it used to fail to build) on most Linux > distributions that were using Make 4.0. A patch was needed to fix that, > but when that was fixed, OpenJDK 8 would build and run just fine. In > cases like this, is it better to say "works correctly" and/or "builds > with workarounds" or something else entirely? > > How about adding a column named "last checked" or "last updated" to make > it obvious when building on that platform was last checked? > > Thanks, > Omair > Hi! At first, really thank you for this page, Looking at it today, I need to update, that there is nothing like Fedora 9 alive. I'm maintaining Openjdk for Fedora and Rhel so there is updated list - probably for "community builds": jdk8: Fedora 19, 20,21, - works flawlessly - we have u25here notes: have patches to build on non intel arches, have patches to use system libjpg, libpng and lcms. (generally all selected intree libraries, the workarounds are only customizations) Fedora rawhide (future 22) - the same as above, except we have u40 here, and libjpeg-turbo-1.4-compat.patch to build with newest libjpg. (so here not flawlessly, but " Works partially or workaround(s) needed" RHEL: Openjdk8 is now available only in 6.6: again, works flawlessly notes: have patches to use system libjpg, libpng and lcms (generally all selected intree libraries) If I may speak my opinion, then it is worthy to add to this page also Openjdk7 and 6 (even when it have different maintainer then Oracle. People are keeping asking about those builds). I will keep you informed when something from above changes, or some other jdk is supported on fedora/rhel. Also if you decide to include jdk6/7 I will send you detailed information. Thank you! J. From sundararajan.athijegannathan at oracle.com Fri Nov 28 10:41:36 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 28 Nov 2014 16:11:36 +0530 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs Message-ID: <54785160.3070501@oracle.com> Hi, Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8066146 Thanks, -Sundar From erik.joelsson at oracle.com Fri Nov 28 10:58:04 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 28 Nov 2014 11:58:04 +0100 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <54785160.3070501@oracle.com> References: <54785160.3070501@oracle.com> Message-ID: <5478553C.8040408@oracle.com> Hello, Should: 1140 NASHORNAPI2COREAPI := ../../$(JDKJRE2COREAPI) be? 1140 NASHORNAPI2COREAPI := ../$(JDKJRE2COREAPI) I assume it's relative to DOCDIR defined on the line above. /Erik On 2014-11-28 11:41, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8066146 > > Thanks, > -Sundar From andreas.lundblad at oracle.com Fri Nov 28 11:06:34 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Fri, 28 Nov 2014 12:06:34 +0100 Subject: RFR: 8066138: Trailing whitespace in title of javadoc Message-ID: <20141128110633.GA9294@e6430> Hi build-dev, Would appreciate a review of this small patch that addresses JDK-8066138. The patch removes trailing whitespace in javadoc titles such as "Overview (Java Platform SE 7 )" Link to webrev: http://cr.openjdk.java.net/~alundblad/8066138/ Link to bug report: https://bugs.openjdk.java.net/browse/JDK-8066138 thanks in advance, Andreas Lundblad From sundararajan.athijegannathan at oracle.com Fri Nov 28 11:50:24 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 28 Nov 2014 17:20:24 +0530 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <5478553C.8040408@oracle.com> References: <54785160.3070501@oracle.com> <5478553C.8040408@oracle.com> Message-ID: <54786180.60503@oracle.com> Hi, Thanks for catching that! Please review updated http://cr.openjdk.java.net/~sundar/8066146/webrev.01/ Thanks, -Sundar Erik Joelsson wrote: > Hello, > > Should: > > 1140 NASHORNAPI2COREAPI := ../../$(JDKJRE2COREAPI) > > be? > > 1140 NASHORNAPI2COREAPI := ../$(JDKJRE2COREAPI) > > I assume it's relative to DOCDIR defined on the line above. > > /Erik > > On 2014-11-28 11:41, A. Sundararajan wrote: >> Hi, >> >> Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8066146 >> >> Thanks, >> -Sundar > From erik.joelsson at oracle.com Fri Nov 28 11:54:24 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 28 Nov 2014 12:54:24 +0100 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <54786180.60503@oracle.com> References: <54785160.3070501@oracle.com> <5478553C.8040408@oracle.com> <54786180.60503@oracle.com> Message-ID: <54786270.5060309@oracle.com> Looks good to me. /Erik On 2014-11-28 12:50, A. Sundararajan wrote: > Hi, > > Thanks for catching that! > > Please review updated > http://cr.openjdk.java.net/~sundar/8066146/webrev.01/ > > Thanks, > -Sundar > > Erik Joelsson wrote: >> Hello, >> >> Should: >> >> 1140 NASHORNAPI2COREAPI := ../../$(JDKJRE2COREAPI) >> >> be? >> >> 1140 NASHORNAPI2COREAPI := ../$(JDKJRE2COREAPI) >> >> I assume it's relative to DOCDIR defined on the line above. >> >> /Erik >> >> On 2014-11-28 11:41, A. Sundararajan wrote: >>> Hi, >>> >>> Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ >>> for https://bugs.openjdk.java.net/browse/JDK-8066146 >>> >>> Thanks, >>> -Sundar >> > From james.laskey at oracle.com Fri Nov 28 12:06:03 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 28 Nov 2014 08:06:03 -0400 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <54785160.3070501@oracle.com> References: <54785160.3070501@oracle.com> Message-ID: <6E7A15A8-A01E-459B-B510-C1C485C50D9E@oracle.com> +1 On Nov 28, 2014, at 6:41 AM, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8066146 > > Thanks, > -Sundar From marcus.lagergren at oracle.com Fri Nov 28 12:50:25 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 28 Nov 2014 13:50:25 +0100 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <54786180.60503@oracle.com> References: <54785160.3070501@oracle.com> <5478553C.8040408@oracle.com> <54786180.60503@oracle.com> Message-ID: +1 > On 28 Nov 2014, at 12:50, A. Sundararajan wrote: > > Hi, > > Thanks for catching that! > > Please review updated http://cr.openjdk.java.net/~sundar/8066146/webrev.01/ > > Thanks, > -Sundar > > Erik Joelsson wrote: >> Hello, >> >> Should: >> >> 1140 NASHORNAPI2COREAPI := ../../$(JDKJRE2COREAPI) >> >> be? >> >> 1140 NASHORNAPI2COREAPI := ../$(JDKJRE2COREAPI) >> >> I assume it's relative to DOCDIR defined on the line above. >> >> /Erik >> >> On 2014-11-28 11:41, A. Sundararajan wrote: >>> Hi, >>> >>> Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8066146 >>> >>> Thanks, >>> -Sundar >> > From magnus.ihse.bursie at oracle.com Fri Nov 28 23:33:48 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 29 Nov 2014 00:33:48 +0100 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <54785160.3070501@oracle.com> References: <54785160.3070501@oracle.com> Message-ID: <5479065C.2090302@oracle.com> On 2014-11-28 11:41, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8066146 > > Thanks, > -Sundar Is it by intention that you do not add $(NASHORNAPI_PKGS) to NON_CORE_PKGS? /Magnus From mandy.chung at oracle.com Sat Nov 29 01:32:00 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 28 Nov 2014 17:32:00 -0800 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <54785160.3070501@oracle.com> References: <54785160.3070501@oracle.com> Message-ID: <54792210.70704@oracle.com> Hi Sundar, On 11/28/2014 2:41 AM, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8066146 Is jdk.nashorn.api.scripting a supported API? It looks like some classes are defined for JEP 202 [1] and is the entire package new in 8u40 and 9? @since is missing in the javadoc and I can't tell for sure. If supported, this should be declared in /modules.xml: jdk.scripting.nashorn java.base java.logging java.scripting jdk.nashorn.api.scripting JDK-8066146 is a build change. Probably best to file a new bug to follow up missing @since and modules.xml change? thanks Mandy [1] http://openjdk.java.net/jeps/202 From chris.hegarty at oracle.com Sun Nov 30 21:21:01 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 30 Nov 2014 21:21:01 +0000 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: <8E7293BD-C262-4F46-A10E-669DEEF6E246@oracle.com> I?ve taken a pass over the non-build changes and don?t see anything of concern. I put them though our internal build and test system, and the results look positive. -Chris. On 20 Nov 2014, at 21:39, Chris Hegarty wrote: > This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. > > There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the 'To' section of this mail, and they will help address any comments arising from this review request. > > The new run-time image structure is defined in JEP 220 [1], and can be seen as a result of building the staging forest [2], or in the early access builds [3]. > > Webrevs: > http://cr.openjdk.java.net/~chegar/8061971/00/ > > Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev. > > -Chris. > > [1] http://openjdk.java.net/jeps/220 > [2] http://hg.openjdk.java.net/jigsaw/m2/ > [3] http://openjdk.java.net/projects/jigsaw/ea From magnus.ihse.bursie at oracle.com Sun Nov 23 23:15:47 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 24 Nov 2014 00:15:47 +0100 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: <54726AA3.3050708@oracle.com> On 2014-11-20 22:39, Chris Hegarty wrote: > This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. > > There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the 'To' section of this mail, and they will help address any comments arising from this review request. > > The new run-time image structure is defined in JEP 220 [1], and can be seen as a result of building the staging forest [2], or in the early access builds [3]. > > Webrevs: > http://cr.openjdk.java.net/~chegar/8061971/00/ I have thoroughly reviewed all the build changes, and they look good to me, with the following remarks. It would have been nice to use the new "wrapper" based approach for all module-phase specific details -- this is done now for all phases except gensrc and rmic. But this is not necessary for the patch to work, and can be addressed later on. We also need to update configure to accept a module-based JDK as a boot JDK. In the patch, this is done sort-of -- we can run a bootcycle build with the new module-based JDK, but we will not accept it as an initial boot JDK. But this too can be fixed later on. And of course there is always some syntax issues. :-) In langtools/make/gensrc/Gensrc-jdk.*.gmk, there are several calls of the pattern: $(eval $(call SetupVersionProperties,JAVAP_VERSION, ...)) $(eval $(call SetupCompileProperties,COMPILE_PROPERTIES, ...)) These should have a space following the comma to adhere to the recommended style. But once again, I'm okay with fixing this in a follow up. /Magnus