hg: jdk8/build/jdk: 7150392: Linux build breaks with GCC 4.7 due to unrecognized option
Changeset: fb3a2cafc230 Author:andrew Date: 2012-03-08 14:04 + URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fb3a2cafc230 7150392: Linux build breaks with GCC 4.7 due to unrecognized option Summary: Remove -mimpure-text option. Reviewed-by: ohair, dholmes, phh, andrew Contributed-by: Deepak Bhole dbh...@redhat.com ! make/common/shared/Compiler-gcc.gmk ! src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt ! src/share/demo/jvmti/gctest/sample.makefile.txt ! src/share/demo/jvmti/heapTracker/sample.makefile.txt ! src/share/demo/jvmti/heapViewer/sample.makefile.txt ! src/share/demo/jvmti/hprof/sample.makefile.txt ! src/share/demo/jvmti/index.html ! src/share/demo/jvmti/java_crw_demo/sample.makefile.txt ! src/share/demo/jvmti/minst/sample.makefile.txt ! src/share/demo/jvmti/mtrace/sample.makefile.txt ! src/share/demo/jvmti/versionCheck/sample.makefile.txt ! src/share/demo/jvmti/waiters/sample.makefile.txt
Re: Patch to fix build breakage with GCC 4.7
- Original Message - * Andrew Hughes ahug...@redhat.com [2012-03-02 10:09]: - Original Message - * Andrew Hughes ahug...@redhat.com [2012-03-01 15:40]: - Original Message - * Kelly O'Hair kelly.oh...@oracle.com [2012-02-29 20:39]: The sample.makefile.txt files may not even be used during the build, I'm not sure. They may have only been supplied as documentation on how to build the native code. Deleting the -mimpure-text is probably right all around. Okay, so then looks like the first iteration should be OK for that: http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00/ If so, please go ahead and commit on my behalf as I can't. Why can't you? This is a jdk change. Only HotSpot changes have to go through JPRT. I don't have commit access to jdk: http://openjdk.java.net/census#dbhole Oh as 'author' you mean? I have to admit I'm still confused by these new bylaws and rules. Presumably I can push it on your behalf as jdk8 reviewer. Sure, that'd be great. Thanks! Done: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fb3a2cafc230 Deepak -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
RFR (M): Enable OpenJDK builds on Windows with MinGW/MSYS
Hi, please review the following changes which make it possible to use MinGW/MSYS as underlying build environment for Windows. Because the changes touch several repositories I prepared three webrevs, all relative to http://hg.openjdk.java.net/jdk8/build For the main repository: http://cr.openjdk.java.net/~simonis/MinGW_MSYS.v1/ For the HotSpot repository: http://cr.openjdk.java.net/~simonis/MinGW_MSYS_hotspot.v1/ For the JDK repository http://cr.openjdk.java.net/~simonis/MinGW_MSYS_jdk.v1/ Please be so kind and also create three bug ids for the corresponding changes. The changes are minimal in the sense that I did just enough changes to be able to build on Windows with either one of the three Unix emulation environments (MKS, Cygwin, MinGW/MSYS). The main benefits of the new MinGW/MSYS based Windows build are: - no problems with make - one can simply use the make tool which comes with MinGW/MSYS - with the current MinGW/MSYS version the build is known to succeed, while the newest Cygwin 1.7.10 version is known to break the OpenJDK build (see: http://old.nabble.com/Is-anyone-able-to-build-on-Win-7-td33196055.html) - speed - the MinGW/MSYS build times are comparable to the MKS build times and is at least 50% faster than the Cygwin build times (see numbers below) The changes are intentionally against the old, traditional build system to fix the mentioned Cygwin problems and simplify the Windows build just now. I don't expect any problems in adapting the new build infrastructure to MinGW/MSYS as well in a follow-up step. More information on each change can be found in the corresponding webrevs. Timing results for the different build environments (MKS ver. 9.4, Cygwin ver. 1.7.9, MinGW/MSYS 1.0.17) for a full JDK 8 product build on a freshly booted, dual core i7 notebook with 8GB RAM, HDD and 64-bit Windows 7: /p MKS -- Build times -- Target all_product_build Start 2012-02-29 19:19:26 End 2012-02-29 20:07:44 00:03:10 corba 00:03:44 hotspot 00:00:30 jaxp 00:00:37 jaxws 00:39:39 jdk 00:00:36 langtools 00:48:18 TOTAL - MinGW/MSYS -- Build times -- Target all_product_build Start 2012-02-29 18:16:31 End 2012-02-29 19:10:59 00:02:57 corba 00:03:04 hotspot 00:00:32 jaxp 00:00:40 jaxws 00:46:36 jdk 00:00:36 langtools 00:54:28 TOTAL - Cygwin -- Build times -- Target all_product_build Start 2012-02-29 14:36:50 End 2012-02-29 16:05:50 00:05:47 corba 00:03:24 hotspot 00:00:33 jaxp 00:00:43 jaxws 01:17:45 jdk 00:00:39 langtools 01:29:00 TOTAL - Regards, Volker
Re: Is anyone able to build on Win 7
An interesting tidbit... I was talking to the JavaFX RE team which does builds on Windows XP and Windows 2003 X64. They have always used CYGWIN for builds, but there isn't many Makefiles used on Windows, it's mostly Ant scripts. So CYGWIN is used but probably not a major player. No MKS was ever used. Both windows builds had been the long pole, maybe 2 hours each, and past experiments showed that using physical hardware rather than VMware virtual machines could reduce the builds to about 1hour. So we knew that VMs would cost us, but assumed that as we got faster hosts this would improve. After McAfee was installed, the Windows XP builds went down the toilet, but the Windows X64 builds were not impacted as much. Apparently the policies in place for Windows XP (considered a desktop environment) are considerably different from that of Windows 2003 (considered a server environment). Another... I now have 3 Windows 7 X64 systems I can now use to test jdk8 builds. I built the entire openjdk8 (hotspot included, product only) in slightly under an hour, just the Windows 64bit product. This is a VMware VM on a fully loaded X4170M2 system hosting just 6 VMs, each VM has 4 vCPUs with lots of RAM. This was using MKS 9.0p4 I can use it to do some additional experiments on Volker's changes, but it will take me a little time. -kto On Feb 15, 2012, at 4:10 AM, Fredrik Öhrström wrote: - kelly.oh...@oracle.com skrev: So I'm with you on the stat() theory, makes a great deal of sense. The stat theory is very interesting, but it is unclear to me if it explains all of the problem. I setup a quadruple boot x86_64 machine with 4GB of ram and 4 cores: Winxp 32bit Win7 64bit Solaris 64bit Ubuntu 64bit And tested the build times on the different OS:es. Ubuntu Fastest by far. Solaris, slower, but this is only because of bad CC performance. Winxp, even slower but still ok. Win7, ridiculously slow. The configure script prints one line per second! Clearly, just running a bash script in cygwin/win7/64bit is problematic. If we get 10% speedup from dash, then that is not going to help because the slowdown is a factor 10. Could someone try out the difference between a 32bit win7 clean install and a 64 bit win7 clean install when running the latest cygwin and just the build-infra/jdk8/common/autoconf/configure script? (My patience for installing many OSes into the same box, just ran out. And virtualization testing can give a hint, but cannot be entirely trusted.) //Fredrik
Re: RFR (M): Enable OpenJDK builds on Windows with MinGW/MSYS
On Mar 8, 2012, at 9:39 AM, Volker Simonis wrote: Hi, please review the following changes which make it possible to use MinGW/MSYS as underlying build environment for Windows. Because the changes touch several repositories I prepared three webrevs, all relative to http://hg.openjdk.java.net/jdk8/build For the main repository: http://cr.openjdk.java.net/~simonis/MinGW_MSYS.v1/ I had originally purged all mention of MKS from this README because we wanted to stop using it in favor of CYGWIN, and only maintain one way to build on Windows. That never happened internally, many kept using MKS because it was so much faster. So as much as I hate seeing the MKS instructions being added, I understand why you felt compelled to add them, and see no obvious inaccuracies We didn't have any plans to continue to support MKS with the new build infrastructure work. It creates a complication that we wanted to avoid, but at the same time we are running into the CYGWIN is too slow, especially on 64bit Windows problem. So we will need to discuss this on the build-infra-dev alias. Since this change is just README, and I see nothing wrong with regards to your changes, it seems ok, with the caveat that if we end up really abandoning MKS, we may need to purge the MKS references. I just don't know what will happen here right now. For the HotSpot repository: http://cr.openjdk.java.net/~simonis/MinGW_MSYS_hotspot.v1/ Seems fine. This change could probably proceed regardless of the others I think. But someone from the hotspot team may need to help here or maybe I could do it... Was the /option to -option a style issue, or was it required somehow? Just curious, I have no objection to making it consistent. Also, the quotes on the paths.. any particular reason why? For the JDK repository http://cr.openjdk.java.net/~simonis/MinGW_MSYS_jdk.v1/ Seems fine but unfortunately, we have other closed repos that might be impacted here. The cpio change concerns me, not that I'm in love with cpio, I tried to get rid of it a long time ago, but it was so much faster than tar for some reason. So I'll need to make sure the entire Oracle JDK build process is ok with these changes before this could go in. Right now I'm not so concerned about using MinGW/MSYS as making sure the existing builds are not broken. But I am looking forward to using MinGW/MSYS soon. I may need to enlist someone to do some image comparisons and double check that the end result has not changed too. Please be so kind and also create three bug ids for the corresponding changes. Created: 7152336: Enable builds on Windows with MinGW/MSYS I think we can use the same CR for all repos. Unless you really want 3 CRs. The changes are minimal in the sense that I did just enough changes to be able to build on Windows with either one of the three Unix emulation environments (MKS, Cygwin, MinGW/MSYS). The main benefits of the new MinGW/MSYS based Windows build are: - no problems with make - one can simply use the make tool which comes with MinGW/MSYS - with the current MinGW/MSYS version the build is known to succeed, while the newest Cygwin 1.7.10 version is known to break the OpenJDK build (see: http://old.nabble.com/Is-anyone-able-to-build-on-Win-7-td33196055.html) - speed - the MinGW/MSYS build times are comparable to the MKS build times and is at least 50% faster than the Cygwin build times (see numbers below) That 50% faster is great news. The changes are intentionally against the old, traditional build system to fix the mentioned Cygwin problems and simplify the Windows build just now. I don't expect any problems in adapting the new build infrastructure to MinGW/MSYS as well in a follow-up step. More information on each change can be found in the corresponding webrevs. Timing results for the different build environments (MKS ver. 9.4, Cygwin ver. 1.7.9, MinGW/MSYS 1.0.17) for a full JDK 8 product build on a freshly booted, dual core i7 notebook with 8GB RAM, HDD and 64-bit Windows 7: /p MKS -- Build times -- Target all_product_build Start 2012-02-29 19:19:26 End 2012-02-29 20:07:44 00:03:10 corba 00:03:44 hotspot 00:00:30 jaxp 00:00:37 jaxws 00:39:39 jdk 00:00:36 langtools 00:48:18 TOTAL - MinGW/MSYS -- Build times -- Target all_product_build Start 2012-02-29 18:16:31 End 2012-02-29 19:10:59 00:02:57 corba 00:03:04 hotspot 00:00:32 jaxp 00:00:40 jaxws 00:46:36 jdk 00:00:36 langtools 00:54:28 TOTAL - Cygwin -- Build times -- Target all_product_build Start 2012-02-29 14:36:50 End 2012-02-29 16:05:50 00:05:47 corba 00:03:24 hotspot 00:00:33 jaxp 00:00:43 jaxws 01:17:45 jdk 00:00:39 langtools 01:29:00 TOTAL - Excellent details. Thanks. I'll definitely work with you to get these changes integrated. -kto Regards, Volker
Re: RFR (M): Enable OpenJDK builds on Windows with MinGW/MSYS
On 9/03/2012 5:58 AM, Kelly O'Hair wrote: On Mar 8, 2012, at 9:39 AM, Volker Simonis wrote: Please be so kind and also create three bug ids for the corresponding changes. Created: 7152336: Enable builds on Windows with MinGW/MSYS I think we can use the same CR for all repos. Unless you really want 3 CRs. You need at least two CRs as hotspot's must be separate: different product, release target, build numbers etc. David The changes are minimal in the sense that I did just enough changes to be able to build on Windows with either one of the three Unix emulation environments (MKS, Cygwin, MinGW/MSYS). The main benefits of the new MinGW/MSYS based Windows build are: - no problems with make - one can simply use the make tool which comes with MinGW/MSYS - with the current MinGW/MSYS version the build is known to succeed, while the newest Cygwin 1.7.10 version is known to break the OpenJDK build (see: http://old.nabble.com/Is-anyone-able-to-build-on-Win-7-td33196055.html) - speed - the MinGW/MSYS build times are comparable to the MKS build times and is at least 50% faster than the Cygwin build times (see numbers below) That 50% faster is great news. The changes are intentionally against the old, traditional build system to fix the mentioned Cygwin problems and simplify the Windows build just now. I don't expect any problems in adapting the new build infrastructure to MinGW/MSYS as well in a follow-up step. More information on each change can be found in the corresponding webrevs. Timing results for the different build environments (MKS ver. 9.4, Cygwin ver. 1.7.9, MinGW/MSYS 1.0.17) for a full JDK 8 product build on a freshly booted, dual core i7 notebook with 8GB RAM, HDD and 64-bit Windows 7:/p MKS -- Build times -- Target all_product_build Start 2012-02-29 19:19:26 End 2012-02-29 20:07:44 00:03:10 corba 00:03:44 hotspot 00:00:30 jaxp 00:00:37 jaxws 00:39:39 jdk 00:00:36 langtools 00:48:18 TOTAL - MinGW/MSYS -- Build times -- Target all_product_build Start 2012-02-29 18:16:31 End 2012-02-29 19:10:59 00:02:57 corba 00:03:04 hotspot 00:00:32 jaxp 00:00:40 jaxws 00:46:36 jdk 00:00:36 langtools 00:54:28 TOTAL - Cygwin -- Build times -- Target all_product_build Start 2012-02-29 14:36:50 End 2012-02-29 16:05:50 00:05:47 corba 00:03:24 hotspot 00:00:33 jaxp 00:00:43 jaxws 01:17:45 jdk 00:00:39 langtools 01:29:00 TOTAL - Excellent details. Thanks. I'll definitely work with you to get these changes integrated. -kto Regards, Volker
Re: RFR (M): Enable OpenJDK builds on Windows with MinGW/MSYS
Hi Volker, On 9/03/2012 3:39 AM, Volker Simonis wrote: please review the following changes which make it possible to use MinGW/MSYS as underlying build environment for Windows. Because the changes touch several repositories I prepared three webrevs, all relative to http://hg.openjdk.java.net/jdk8/build For the main repository: http://cr.openjdk.java.net/~simonis/MinGW_MSYS.v1/ Saw one typo: fastes For the HotSpot repository: http://cr.openjdk.java.net/~simonis/MinGW_MSYS_hotspot.v1/ I'm mainly looking at this from the does it break anything perspective, but note that in make/windows/makefiles/defs.make SYSTEM_UNAME is only set when doing a full build (JDK/control). If you just try to build hotspot this will not be set, so I expect you will want to change this. I was also wondering about the / to - changes but see in the README-builds.html changes that MSYS might otherwise misinterpret them. make/windows/makefiles/rules.make As Kelly said: why the quotes? Does MinGW not handle spaces in paths the way Cygwin does? make/windows/makefiles/sa.make So changes from \ to / . Not sure about this. Seems odd that we had a mix of \ and / to start with so I can't help but wonder if there was some Cygwin issue that this was addressing. I guess as long as it works then it is okay in that sense. Cheers, David --- For the JDK repository http://cr.openjdk.java.net/~simonis/MinGW_MSYS_jdk.v1/ Please be so kind and also create three bug ids for the corresponding changes. The changes are minimal in the sense that I did just enough changes to be able to build on Windows with either one of the three Unix emulation environments (MKS, Cygwin, MinGW/MSYS). The main benefits of the new MinGW/MSYS based Windows build are: - no problems with make - one can simply use the make tool which comes with MinGW/MSYS - with the current MinGW/MSYS version the build is known to succeed, while the newest Cygwin 1.7.10 version is known to break the OpenJDK build (see: http://old.nabble.com/Is-anyone-able-to-build-on-Win-7-td33196055.html) - speed - the MinGW/MSYS build times are comparable to the MKS build times and is at least 50% faster than the Cygwin build times (see numbers below) The changes are intentionally against the old, traditional build system to fix the mentioned Cygwin problems and simplify the Windows build just now. I don't expect any problems in adapting the new build infrastructure to MinGW/MSYS as well in a follow-up step. More information on each change can be found in the corresponding webrevs. Timing results for the different build environments (MKS ver. 9.4, Cygwin ver. 1.7.9, MinGW/MSYS 1.0.17) for a full JDK 8 product build on a freshly booted, dual core i7 notebook with 8GB RAM, HDD and 64-bit Windows 7:/p MKS -- Build times -- Target all_product_build Start 2012-02-29 19:19:26 End 2012-02-29 20:07:44 00:03:10 corba 00:03:44 hotspot 00:00:30 jaxp 00:00:37 jaxws 00:39:39 jdk 00:00:36 langtools 00:48:18 TOTAL - MinGW/MSYS -- Build times -- Target all_product_build Start 2012-02-29 18:16:31 End 2012-02-29 19:10:59 00:02:57 corba 00:03:04 hotspot 00:00:32 jaxp 00:00:40 jaxws 00:46:36 jdk 00:00:36 langtools 00:54:28 TOTAL - Cygwin -- Build times -- Target all_product_build Start 2012-02-29 14:36:50 End 2012-02-29 16:05:50 00:05:47 corba 00:03:24 hotspot 00:00:33 jaxp 00:00:43 jaxws 01:17:45 jdk 00:00:39 langtools 01:29:00 TOTAL - Regards, Volker
Re: Cross Compiling
Martin, On 9/03/2012 3:40 AM, martin burtscher wrote: Hello, can anybody confirm, that cross compiling is working with make flags: CROSS_COMPILE_ARCH ALT_COMPILER_PATH? With confirm i mean tested and not just read in readme, because theres also a BUILD_HEADLESS_ONLY in the readme which doesn't work. Cross-compilation works for our internal builds - but they only change processor architecture and not the OS (they are all Linux). I don't know whether anyone outside Oracle is using this means of cross-compiling as they also need the actual target platform sources, and those tend to come from other projects (IcedTea, Zero, Shark) with their own build mechanisms. David Thanks. Martin
Re: Cross Compiling
On 9/03/2012 9:20 AM, David Holmes wrote: On 9/03/2012 3:40 AM, martin burtscher wrote: can anybody confirm, that cross compiling is working with make flags: CROSS_COMPILE_ARCH ALT_COMPILER_PATH? With confirm i mean tested and not just read in readme, because theres also a BUILD_HEADLESS_ONLY in the readme which doesn't work. Cross-compilation works for our internal builds - but they only change processor architecture and not the OS (they are all Linux). Actually there is a piece missing in the README. You may also have to set the ARCH make variable for the desired architecture. However if you are 'cross compiling for x86 that would be a problem because the JDK side of the build and the Hotspot side of the build use different ARCH values for 32-bit x86 (i586 and i686 respectively). I'm not sure if setting CROSS_COMPILE_ARCH=i586 by itself will work. I'm trying it out now. David - I don't know whether anyone outside Oracle is using this means of cross-compiling as they also need the actual target platform sources, and those tend to come from other projects (IcedTea, Zero, Shark) with their own build mechanisms. David Thanks. Martin
hg: jdk8/build/jaxws: 7152425: Fix copyright notices on 12 files in jaxws
Changeset: c46e0b6e3f98 Author:ohair Date: 2012-03-08 18:20 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/c46e0b6e3f98 7152425: Fix copyright notices on 12 files in jaxws Reviewed-by: mbykov ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/EnvelopeStyle.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/EnvelopeStyleFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/Databinding.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingMode.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingModeFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/JavaCallInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/ContentType.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/DistributedPropertySet.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/MessageContext.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/MessageContextFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/PropertySet.java
