Review for 7141242: build-infra merge: Rename CPP-CXX and LINK-LD
http://cr.openjdk.java.net/~erikj/7141242/webrev.00/ 240 lines changed: 0 ins; 19 del; 221 mod; 6363 unchg 7141242: build-infra merge: Rename CPP-CXX and LINK-LD The build-infra project is starting to move into jdk8. For the hotspot build to stay compatible with the changes, the naming of standard make variables, like CC and LD need to be standardized across the build. Currently hotspot names the C++ compiler CPP, which is traditionally the name of the preprocessor. The windows nmake files name the linker LINK. We would like to rename the C++ compiler to CXX and have the linker named LD everywhere. Patch is tested with hsx/hotspot-rt. Testing with jdk7u is in progress. /Erik
Re: Patch to fix build breakage with GCC 4.7
linux-sparc used to build and run fine (I did the port way back when), so it should be relatively easy to resurrect. The original port was on a T1. Paul On 1/31/12 10:23 AM, Deepak Bhole wrote: * David Holmesdavid.hol...@oracle.com [2012-01-30 21:50]: On 31/01/2012 12:36 PM, Deepak Bhole wrote: * David Holmesdavid.hol...@oracle.com [2012-01-30 19:57]: While gcc compilation on sparc is rare I'm not sure that simply deleting the sparc-only option unconditionally is the right thing to do. I thought about that too. But I was unable to find info on OpenJDK + SPARC + Linux. Is that combination even supported? The README doesn't list it: http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE Linux-sparc is not one of Oracle's supported OpenJDK platforms. However AFAIK there are people in the community building OpenJDK on Linux-sparc using the Zero interpreter. I don't know if this would affect them but it still seems to me that we should be careful not to break other people's builds. Ah fair enough. If it is supported, the patch definitely needs to be fixed. I will re-post. Thanks for taking a look! Deepak David - The option seemed more like a relic from Solaris + SPARC config rather than a requirement for Linux + SPARC. Cheers, Deepak David On 31/01/2012 1:20 AM, Deepak Bhole wrote: Hi, JDK builds currently fail with GCC 4.7 due to its stricter option checking. GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain files in JDK supply the -mimpure-text option to GCC. This option is only valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build on Linux (I suppose . This patch removes the option: http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html 2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html If OK for push, please feel free to do so (I don't have commit access). Cheers, Deepak
Re: Patch for: 7132779: build-infra merge: Enable ccache to work for most developer builds.
2012-01-31 22:38, David Holmes skrev: I don't understand the comment on the new method though. Since jre_release_version() has a similar use case as vm_release(), ie it is called from crash handlers and error reporting handlers, I copied the comment for vm_release() to jre_release_version(). But perhaps it is a bit too much information since it is not that likely that the code will be refactored to have stringStreams instead of char *. I'm assuming that the actual problem is the ccache compares the defines used for a compilation and so if the version string contains a timestamp and gets updated on each (incremental?) build then ccache thinks it has to recompile. Yes, that is correct. As can be seen in most build server logs, the ccache is rarely used. It is only used when a build number is explicitly set, since the build number prevents a date and time to be inserted in the JRE_RELEASE_VERSION. //Fredrik
Re: 7140918: Remove dependency on apt and com.sun.mirror API
On 01/02/2012 15:13, Miroslav Kos wrote: Hi Alan, do you have any update about approving the changeset? The jaxws bundle is already in place, so there should be nothing blocking us from the final step(?) I plan to push it later this week once I've verified the the downloads and done a few test builds with and without ALLOW_DOWNLOADS. -Alan.
fastdebug
What is the difference between using a target of fastdebug_build and no target but using the variable FASTDEBUG=true?
Re: Is anyone able to build on Win 7
I went the other way round by trying the newest Cygwin snapshots
(2012-01-23 and 2012-02-01) but unfortunately with absolutely no
success!
Quite contrary to Cygwin 1.7.9, the build reproducibly freezes after
finishing jdk/make/java/jvm when entering jdk/make/java/redist and I
hove no idea why. So the bad news is that the build problems on
Windows7 will eventually get even worse with the next version of
Cygwin.
I've also tried with a Cygwin 1.7.9 and a slightly differently
configured version of Gnumake 3.82 (I've set HAVE_CYGWIN_SHELL in
config.h which was not the default). This looked promising in the
beginning and I did several successful builds, however today the build
crashed again with the well known fork: Resource temporarily
unavailable error. So that was apparently not the solution.
I really think we need support from a Cygwin/Gnumake expert here but
I'm not sure how many people really qualify for this job:)
By the way Peter, where did you get the old Cygwin version from? I
couldn't find old versions on cygwin.com.
And Peter, what kind of make are you using? Is it a Cygwin make (which
version, compiled by you or original one from the distro) or is it a
native Gnumake compiled with MinGW or even with VisualStudio?
Thank you and best regards,
Volker
On Thu, Jan 26, 2012 at 2:10 AM, Pete Brunet peter.bru...@oracle.com wrote:
I just had success with the following changes:
- downgraded from cygwin 1.7.9 (with bash 4.1.10) to 1.7.0 (with bash
3.2.49)
- changed ...\jdk\make\docs\Makefile line 74
ifeq ($(ARCH_DATA_MODEL),64)
MAX_VM_MEMORY = 1024
else
MAX_VM_MEMORY = 1024 --- This was 512
endif
I've only done one build and in prior builds had other issues besides
the memory problem, i.e. fork and error 126, but there's always hope.
If others could report their W7 configurations and whether or not there
were problems, that would be helpful.
Pete
On 1/25/12 6:17 PM, Kelly O'Hair wrote:
Sorry guys, I don't have the time or priority to track this down.
Official builds are still happening on Windows XP and Windows 2003 X64 and
these
problems are not being seen on those systems yet...
although we recently have been visited by the McAfee plague so maybe it's
just a matter of time. ;^(
Someone with some strong Windows experience needs to run this to ground.
We do need this to work, eventually.
-kto
On Jan 25, 2012, at 9:09 AM, Pete Brunet wrote:
I started W7 in safe mode and the build failed with a fork failure. I
think that eliminates things in the BLODA list. If anyone out there is
building OK on W7 please send your configuration, e.g. as shown below.
Maybe that will suggest a different version of cygwin or bash. -Pete
On 1/25/12 9:55 AM, Pete Brunet wrote:
Thanks Volker, I was thinking I'm going to have to try using XP in a
VM. My W7 config is very close to yours (make 3.81 instead of 3.82).
W7 Pro, 64 bit, SP1
Intel Core 2 Duo, P8700, 2.53 GHz, 8 GB RAM
CYGWIN_NT-6.1-WOW64 Bevo 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)
GNU Make 3.81
Pete
On 1/25/12 9:06 AM, Volker Simonis wrote:
Hi Peter,
glad to see that other have the same problems:)
But seriously, on Windows 7 I'm currently experiencing the same
massive build problems and I'm not sure what the root cause of these
problems is.
I found the following bug which exactly describes the problems I'm facing:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6903517
Among others, these are:
- rm: cannot remove directory `META-INF': Directory not empty
- error: cannot create example2.html: Permission denied
- [javac]
C:\Software\OpenJDK\jdk8\langtools\src\share\classes\com\sun\tools\javac\util\SharedNameTable.java:40:
error: error while writing SharedNameTable:
c:\Software\OpenJDK\output_amd64\langtools\build\bootstrap\classes\com\sun\tools\javac\util\SharedNameTable.class
(Access is denied)
but I also saw the 'out of memory' and 'for' problems mentioned by you.
The description of bug 6903517 references the Big List of Dodgy Apps
(http://cygwin.com/faq/faq.using.html#faq.using.bloda). This is a list
in the Cygwin FAQ which lists applications like Virus Scanners which
can interfere with Cygwin in an unpredictable way. An indeed the
Windows 7 box on which I observe the problems has some of them
installed (e.g. McAffe {Agent, GTI Proxy Agent, Intrusion Prevention,
VirusScan Enterprise, AntySpywaare Enterprise} to name just a few).
On the other hand, on the same Windows 7 box I have a virtual machine
running inside VirtualBox with WindowsXP which has the same McAffe
software installed and it is running without any problems. The OpenJDK
build always succeeds in the virtual machine!
So I'm not quite sure of this is:
- a problem of some additional software which is running on my Windows
7 box and interferes with Cygwin
- a general Windows7 problem
- a problem of the specific Cygwin version I'm using
- a
Re: Is anyone able to build on Win 7
Volker, Will you be able to debug this ? FWIW my cygwin is 1.7.8 and I use win7 x64, for JDK builds and have done so for about as long as its been available, and probably the main issue I've had is accidentally using the wrong version of gnu make, and I don't know offhand any more if the cygwin make is OK to use. At some point it was not. Kelly ? If there *is* a problem new with the latest cygwins it would be nice to track that down as we'd need to decide if we need to a) go back and fix all the 7 updates and the rest to work with the newer cygwins b) tell every one to archive last known good cygwin - I don't think we'd be able to host/redistribute it here. c) ask cygwin to correct the problem. That's all still speculative of course. -phil. On 2/1/2012 9:43 AM, Volker Simonis wrote: I went the other way round by trying the newest Cygwin snapshots (2012-01-23 and 2012-02-01) but unfortunately with absolutely no success! Quite contrary to Cygwin 1.7.9, the build reproducibly freezes after finishing jdk/make/java/jvm when entering jdk/make/java/redist and I hove no idea why. So the bad news is that the build problems on Windows7 will eventually get even worse with the next version of Cygwin. I've also tried with a Cygwin 1.7.9 and a slightly differently configured version of Gnumake 3.82 (I've set HAVE_CYGWIN_SHELL in config.h which was not the default). This looked promising in the beginning and I did several successful builds, however today the build crashed again with the well known fork: Resource temporarily unavailable error. So that was apparently not the solution. I really think we need support from a Cygwin/Gnumake expert here but I'm not sure how many people really qualify for this job:) By the way Peter, where did you get the old Cygwin version from? I couldn't find old versions on cygwin.com. And Peter, what kind of make are you using? Is it a Cygwin make (which version, compiled by you or original one from the distro) or is it a native Gnumake compiled with MinGW or even with VisualStudio? Thank you and best regards, Volker On Thu, Jan 26, 2012 at 2:10 AM, Pete Brunetpeter.bru...@oracle.com wrote: I just had success with the following changes: - downgraded from cygwin 1.7.9 (with bash 4.1.10) to 1.7.0 (with bash 3.2.49) - changed ...\jdk\make\docs\Makefile line 74 ifeq ($(ARCH_DATA_MODEL),64) MAX_VM_MEMORY = 1024 else MAX_VM_MEMORY = 1024--- This was 512 endif I've only done one build and in prior builds had other issues besides the memory problem, i.e. fork and error 126, but there's always hope. If others could report their W7 configurations and whether or not there were problems, that would be helpful. Pete On 1/25/12 6:17 PM, Kelly O'Hair wrote: Sorry guys, I don't have the time or priority to track this down. Official builds are still happening on Windows XP and Windows 2003 X64 and these problems are not being seen on those systems yet... although we recently have been visited by the McAfee plague so maybe it's just a matter of time. ;^( Someone with some strong Windows experience needs to run this to ground. We do need this to work, eventually. -kto On Jan 25, 2012, at 9:09 AM, Pete Brunet wrote: I started W7 in safe mode and the build failed with a fork failure. I think that eliminates things in the BLODA list. If anyone out there is building OK on W7 please send your configuration, e.g. as shown below. Maybe that will suggest a different version of cygwin or bash. -Pete On 1/25/12 9:55 AM, Pete Brunet wrote: Thanks Volker, I was thinking I'm going to have to try using XP in a VM. My W7 config is very close to yours (make 3.81 instead of 3.82). W7 Pro, 64 bit, SP1 Intel Core 2 Duo, P8700, 2.53 GHz, 8 GB RAM CYGWIN_NT-6.1-WOW64 Bevo 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin GNU bash, version 4.1.10(4)-release (i686-pc-cygwin) GNU Make 3.81 Pete On 1/25/12 9:06 AM, Volker Simonis wrote: Hi Peter, glad to see that other have the same problems:) But seriously, on Windows 7 I'm currently experiencing the same massive build problems and I'm not sure what the root cause of these problems is. I found the following bug which exactly describes the problems I'm facing: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6903517 Among others, these are: - rm: cannot remove directory `META-INF': Directory not empty - error: cannot create example2.html: Permission denied - [javac] C:\Software\OpenJDK\jdk8\langtools\src\share\classes\com\sun\tools\javac\util\SharedNameTable.java:40: error: error while writing SharedNameTable: c:\Software\OpenJDK\output_amd64\langtools\build\bootstrap\classes\com\sun\tools\javac\util\SharedNameTable.class (Access is denied) but I also saw the 'out of memory' and 'for' problems mentioned by you. The description of bug 6903517 references the Big List of Dodgy Apps (http://cygwin.com/faq/faq.using.html#faq.using.bloda). This is a list in the Cygwin FAQ which lists applications like Virus Scanners which
Re: Is anyone able to build on Win 7
On 2/1/12 11:43 AM, Volker Simonis wrote:
I went the other way round by trying the newest Cygwin snapshots
(2012-01-23 and 2012-02-01) but unfortunately with absolutely no
success!
Quite contrary to Cygwin 1.7.9, the build reproducibly freezes after
finishing jdk/make/java/jvm when entering jdk/make/java/redist and I
hove no idea why. So the bad news is that the build problems on
Windows7 will eventually get even worse with the next version of
Cygwin.
I've also tried with a Cygwin 1.7.9 and a slightly differently
configured version of Gnumake 3.82 (I've set HAVE_CYGWIN_SHELL in
config.h which was not the default). This looked promising in the
beginning and I did several successful builds, however today the build
crashed again with the well known fork: Resource temporarily
unavailable error. So that was apparently not the solution.
I really think we need support from a Cygwin/Gnumake expert here but
I'm not sure how many people really qualify for this job:)
By the way Peter, where did you get the old Cygwin version from? I
couldn't find old versions on cygwin.com.
I had it on another drive that I was using when I was running XP. This
might help:
http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine
or if that doesn't work out I could zip up 1.7.0 and put it on an ftp
site for you.
And Peter, what kind of make are you using? Is it a Cygwin make (which
version, compiled by you or original one from the distro) or is it a
native Gnumake compiled with MinGW or even with VisualStudio?
I am using the make 3.8.1 from:
http://www.cmake.org/files/cygwin/make.exe
I notice that there is also:
http://www.cmake.org/files/cygwin/make.exe-cygwin1.7
but I have not tried it. I just downloaded it and it's also version
3.8.1. It might be worth a try.
Thank you and best regards,
Volker
On Thu, Jan 26, 2012 at 2:10 AM, Pete Brunet peter.bru...@oracle.com wrote:
I just had success with the following changes:
- downgraded from cygwin 1.7.9 (with bash 4.1.10) to 1.7.0 (with bash
3.2.49)
- changed ...\jdk\make\docs\Makefile line 74
ifeq ($(ARCH_DATA_MODEL),64)
MAX_VM_MEMORY = 1024
else
MAX_VM_MEMORY = 1024 --- This was 512
endif
I've only done one build and in prior builds had other issues besides
the memory problem, i.e. fork and error 126, but there's always hope.
If others could report their W7 configurations and whether or not there
were problems, that would be helpful.
Pete
On 1/25/12 6:17 PM, Kelly O'Hair wrote:
Sorry guys, I don't have the time or priority to track this down.
Official builds are still happening on Windows XP and Windows 2003 X64 and
these
problems are not being seen on those systems yet...
although we recently have been visited by the McAfee plague so maybe it's
just a matter of time. ;^(
Someone with some strong Windows experience needs to run this to ground.
We do need this to work, eventually.
-kto
On Jan 25, 2012, at 9:09 AM, Pete Brunet wrote:
I started W7 in safe mode and the build failed with a fork failure. I
think that eliminates things in the BLODA list. If anyone out there is
building OK on W7 please send your configuration, e.g. as shown below.
Maybe that will suggest a different version of cygwin or bash. -Pete
On 1/25/12 9:55 AM, Pete Brunet wrote:
Thanks Volker, I was thinking I'm going to have to try using XP in a
VM. My W7 config is very close to yours (make 3.81 instead of 3.82).
W7 Pro, 64 bit, SP1
Intel Core 2 Duo, P8700, 2.53 GHz, 8 GB RAM
CYGWIN_NT-6.1-WOW64 Bevo 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)
GNU Make 3.81
Pete
On 1/25/12 9:06 AM, Volker Simonis wrote:
Hi Peter,
glad to see that other have the same problems:)
But seriously, on Windows 7 I'm currently experiencing the same
massive build problems and I'm not sure what the root cause of these
problems is.
I found the following bug which exactly describes the problems I'm
facing:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6903517
Among others, these are:
- rm: cannot remove directory `META-INF': Directory not empty
- error: cannot create example2.html: Permission denied
- [javac]
C:\Software\OpenJDK\jdk8\langtools\src\share\classes\com\sun\tools\javac\util\SharedNameTable.java:40:
error: error while writing SharedNameTable:
c:\Software\OpenJDK\output_amd64\langtools\build\bootstrap\classes\com\sun\tools\javac\util\SharedNameTable.class
(Access is denied)
but I also saw the 'out of memory' and 'for' problems mentioned by you.
The description of bug 6903517 references the Big List of Dodgy Apps
(http://cygwin.com/faq/faq.using.html#faq.using.bloda). This is a list
in the Cygwin FAQ which lists applications like Virus Scanners which
can interfere with Cygwin in an unpredictable way. An indeed the
Windows 7 box on which I observe the problems has some of them
installed (e.g. McAffe {Agent, GTI Proxy Agent, Intrusion Prevention,
How to build openjdk under mac osx
Hi, I am trying to following the steps here to build openjdk 7 on Mac OS 10.6.8. https://wikis.oracle.com/display/OpenJDK/Darwin10Build But I am getting this error: rm -f bsd_x86_32.o /usr/bin/gcc -c -x assembler-with-cpp -m32 -march=i586 -mstackrealign -MMD -MP -MF ../generated/dependencies/bsd_x86_32.o.d -o bsd_x86_32.o /Users/michael/Src/openjdk/bsd-port/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_32.s /Users/michael/Src/openjdk/bsd-port/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_32.s:27:Unknown pseudo-op: .type /Users/michael/Src/openjdk/bsd-port/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_32.s:27:Rest of line ignored. 1st junk character valued 95 (_). make[6]: *** [bsd_x86_32.o] Error 1 make[5]: *** [the_vm] Error 2 make[4]: *** [product] Error 2 make[3]: *** [generic_build2] Error 2 make[2]: *** [product] Error 2 make[1]: *** [hotspot-build] Error 2 make: *** [build_product_image] Error 2 Does anyone know how to fix it? Thank you.
Re: ...\jdk\make\docs\Makefile needs a fix
Probably should be 1024 now for everybody, but as I recall, that could create problems for some windows machines that might not have that big a hole available in the virtual memory. export NO_DOCS=true should skip most javadoc runs. Not sure many developers really need to constantly run javadoc, not the speediest animal on the planet. :^( -kto On Jan 31, 2012, at 9:08 PM, Pete Brunet wrote: Back in November there was a change to ...\jdk\make\docs\Makefile to fix an out of memory problem by raising the memory size for a 32 bit build (line 74) from 512 to 612. That didn't work on my machine: 64 bit Windows 7 with 8 mb. I raised it up to 1024 to bypass the problem. I don't know if that's too much but it worked. Pete
Re: Is anyone able to build on Win 7
On Feb 1, 2012, at 10:07 AM, Phil Race wrote: Volker, Will you be able to debug this ? FWIW my cygwin is 1.7.8 and I use win7 x64, for JDK builds and have done so for about as long as its been available, and probably the main issue I've had is accidentally using the wrong version of gnu make, and I don't know offhand any more if the cygwin make is OK to use. If it is the wrong make.exe (the one that does not support C:/ style pathnames) then you will find out very quickly, it just does not get very far. It thinks the : character is a target:dependencies separator. At some point it was not. Kelly ? I don't know what the current state is. The CYGWIN community seemed pretty adamant that they wanted to stamp out all drive letter pathnames. As I understood it, it's not so much the version of make.exe, but how the make.exe was built. Some kind of 'allow drive letter paths' option needs to be turned on when building. I've been trapped in a hidey-hole for some time now managing physical and virtual machines that seem to dance around me like pink elephants from the Dumbo movie. :^( So I'm a bit disconnected right now. I have automated the copy of an make.exe that works onto the build machines, so I use the same exact make.exe on all Windows systems and all CYGWIN versions. Hasn't been an issue. I know that make 3.82 had some kind of problem, not sure it was windows related though. If there *is* a problem new with the latest cygwins it would be nice to track that down as we'd need to decide if we need to a) go back and fix all the 7 updates and the rest to work with the newer cygwins b) tell every one to archive last known good cygwin - I don't think we'd be able to host/redistribute it here. c) ask cygwin to correct the problem. Agreed. That's all still speculative of course. With Windows it's always speculative. -kto -phil. On 2/1/2012 9:43 AM, Volker Simonis wrote: I went the other way round by trying the newest Cygwin snapshots (2012-01-23 and 2012-02-01) but unfortunately with absolutely no success! Quite contrary to Cygwin 1.7.9, the build reproducibly freezes after finishing jdk/make/java/jvm when entering jdk/make/java/redist and I hove no idea why. So the bad news is that the build problems on Windows7 will eventually get even worse with the next version of Cygwin. I've also tried with a Cygwin 1.7.9 and a slightly differently configured version of Gnumake 3.82 (I've set HAVE_CYGWIN_SHELL in config.h which was not the default). This looked promising in the beginning and I did several successful builds, however today the build crashed again with the well known fork: Resource temporarily unavailable error. So that was apparently not the solution. I really think we need support from a Cygwin/Gnumake expert here but I'm not sure how many people really qualify for this job:) By the way Peter, where did you get the old Cygwin version from? I couldn't find old versions on cygwin.com. And Peter, what kind of make are you using? Is it a Cygwin make (which version, compiled by you or original one from the distro) or is it a native Gnumake compiled with MinGW or even with VisualStudio? Thank you and best regards, Volker On Thu, Jan 26, 2012 at 2:10 AM, Pete Brunetpeter.bru...@oracle.com wrote: I just had success with the following changes: - downgraded from cygwin 1.7.9 (with bash 4.1.10) to 1.7.0 (with bash 3.2.49) - changed ...\jdk\make\docs\Makefile line 74 ifeq ($(ARCH_DATA_MODEL),64) MAX_VM_MEMORY = 1024 else MAX_VM_MEMORY = 1024--- This was 512 endif I've only done one build and in prior builds had other issues besides the memory problem, i.e. fork and error 126, but there's always hope. If others could report their W7 configurations and whether or not there were problems, that would be helpful. Pete On 1/25/12 6:17 PM, Kelly O'Hair wrote: Sorry guys, I don't have the time or priority to track this down. Official builds are still happening on Windows XP and Windows 2003 X64 and these problems are not being seen on those systems yet... although we recently have been visited by the McAfee plague so maybe it's just a matter of time. ;^( Someone with some strong Windows experience needs to run this to ground. We do need this to work, eventually. -kto On Jan 25, 2012, at 9:09 AM, Pete Brunet wrote: I started W7 in safe mode and the build failed with a fork failure. I think that eliminates things in the BLODA list. If anyone out there is building OK on W7 please send your configuration, e.g. as shown below. Maybe that will suggest a different version of cygwin or bash. -Pete On 1/25/12 9:55 AM, Pete Brunet wrote: Thanks Volker, I was thinking I'm going to have to try using XP in a VM. My W7 config is very close to yours (make 3.81 instead of 3.82). W7 Pro, 64 bit, SP1 Intel Core 2 Duo, P8700, 2.53 GHz, 8 GB RAM CYGWIN_NT-6.1-WOW64 Bevo
Re: Is anyone able to build on Win 7
On Feb 1, 2012, at 9:43 AM, Volker Simonis wrote: Quite contrary to Cygwin 1.7.9, the build reproducibly freezes after finishing jdk/make/java/jvm when entering jdk/make/java/redist and I hove no idea why. So the bad news is that the build problems on Windows7 will eventually get even worse with the next version of Cygwin. for the most part jdk/make/java/redist is copying files. That smells like an anti-virus on-access scanning issue. You might try turning off AV on-access scanning temporarily and see if that changes things. Or add your source tree and build result area to the AV directory exclude list temporarily. Of course, changing AV settings is a dangerous notice I said 'temporarily'. Ultimate AV solution is Linux or Solaris of course. ;^) Has anyone invented a Windows application build system that runs on Linux? ;^) -kto
hg: jdk8/build/corba: Added tag jdk8-b23 for changeset 5218eb256658
Changeset: b98f0e6dddf9 Author:katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/b98f0e6dddf9 Added tag jdk8-b23 for changeset 5218eb256658 ! .hgtags
hg: jdk8/build: Added tag jdk8-b23 for changeset 60d6f64a86b1
Changeset: 1a5f1d6b98d6 Author:katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/1a5f1d6b98d6 Added tag jdk8-b23 for changeset 60d6f64a86b1 ! .hgtags
hg: jdk8/build/hotspot: 45 new changesets
Changeset: 6edfe6e42a68 Author:katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6edfe6e42a68 Added tag jdk8-b23 for changeset e850d8e7ea54 ! .hgtags Changeset: 5f3fcd591768 Author:amurillo Date: 2012-01-20 17:07 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5f3fcd591768 7131979: new hotspot build - hs23-b12 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 53a127075045 Author:kvn Date: 2012-01-20 09:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/53a127075045 7131302: connode.cpp:205 Error: ShouldNotReachHere() Summary: Add Value() methods to short and byte Load nodes to truncate constants which does not fit. Reviewed-by: jrose ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: 9164b8236699 Author:iveresov Date: 2012-01-20 15:02 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9164b8236699 7131028: Switch statement takes wrong path Summary: Pass correct type to branch in LIRGenerator::do_SwitchRanges() Reviewed-by: kvn, never ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: a81f60ddab06 Author:never Date: 2012-01-22 14:03 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a81f60ddab06 7130676: Tiered: assert(bci == 0 || 0= bci bcicode_size()) during stack trace construction Reviewed-by: kvn, iveresov ! src/share/vm/classfile/javaClasses.cpp Changeset: 82e5a84b7436 Author:bdelsart Date: 2012-01-24 15:41 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/82e5a84b7436 7120450: complete information dumped by frame_describe Summary: improvements of frame_describe Reviewed-by: never, twisti ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/runtime/frame.cpp Changeset: dddf0be88eb1 Author:iveresov Date: 2012-01-24 17:00 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/dddf0be88eb1 7132945: Tiered: adjust OSR threshold of level 3 Summary: Change the value of Tier3BackEdgeThreshold from 7000 to 6 Reviewed-by: kvn, never ! src/share/vm/runtime/globals.hpp Changeset: cf407b7d3d78 Author:roland Date: 2012-01-25 09:31 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cf407b7d3d78 7116050: C2/ARM: memory stomping error with DivideMcTests Summary: Block::schedule_local() may write beyond end of ready_cnt array Reviewed-by: never, kvn ! src/share/vm/opto/block.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp Changeset: 52474ec73861 Author:kvn Date: 2012-01-24 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/52474ec73861 7132936: guarantee(t != NULL) failed: must be con Summary: Use !higher_equal() check to skip top and values which fit. Reviewed-by: never ! src/share/vm/opto/memnode.cpp Changeset: 94f0ce74d48e Author:kvn Date: 2012-01-25 08:10 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/94f0ce74d48e Merge Changeset: 9a28ddfc1f4a Author:roland Date: 2012-01-26 09:38 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9a28ddfc1f4a 7123910: Some CTW tests crash VM: is_loaded() that-is_loaded() Summary: handle not loaded array klass in Parse::do_checkcast(). Reviewed-by: kvn, never ! src/share/vm/opto/parseHelper.cpp Changeset: 5dbed2f542ff Author:bdelsart Date: 2012-01-26 16:49 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5dbed2f542ff 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle Summary: improvements of TraceMethodHandles for JSR292 Reviewed-by: never, twisti ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp Changeset: 20334ed5ed3c Author:iveresov Date: 2012-01-26 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/20334ed5ed3c 7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS Summary: Make sure that CompilationPolicy::event() doesn't throw exceptions Reviewed-by: kvn, never ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp !
hg: jdk8/build/jaxp: Added tag jdk8-b23 for changeset 95102fd33418
Changeset: 7836655e2495 Author:katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/7836655e2495 Added tag jdk8-b23 for changeset 95102fd33418 ! .hgtags
hg: jdk8/build/jaxws: Added tag jdk8-b23 for changeset 25ce7a000487
Changeset: e0d90803439b Author:katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/e0d90803439b Added tag jdk8-b23 for changeset 25ce7a000487 ! .hgtags
hg: jdk8/build/jdk: Added tag jdk8-b23 for changeset 54202e0148ec
Changeset: 34029a0c69bb Author:katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/34029a0c69bb Added tag jdk8-b23 for changeset 54202e0148ec ! .hgtags
hg: jdk8/build/langtools: Added tag jdk8-b23 for changeset 601ffcc6551d
Changeset: 6c9d21ca92c4 Author:katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/6c9d21ca92c4 Added tag jdk8-b23 for changeset 601ffcc6551d ! .hgtags
Re: Review for 7141242: build-infra merge: Rename CPP-CXX and LINK-LD
Hi Erik, On 1/02/2012 7:13 PM, Erik Joelsson wrote: http://cr.openjdk.java.net/~erikj/7141242/webrev.00/ 240 lines changed: 0 ins; 19 del; 221 mod; 6363 unchg 7141242: build-infra merge: Rename CPP-CXX and LINK-LD Lots of CCC to CXX too :) One compatibility concern: anyone currently setting CPP_FLAGS or LINK_FLAGS etc, externally, will need to change to the new names. Probably worth sending a wider email (jdk8-dev?) when this gets pushed. --- make/bsd/makefiles/gcc.make - CPP = $(CXX) + CXX = $(CXX) infinite recursion or a tautology? :) --- make/*/makefiles/launcher.make Not your doing but this has highlighted some strange rules eg: + $(QUIETLY) $(CC) -g -o $@ -c $ -MMD $(LAUNCHERFLAGS) $(CXXFLAGS) C++ flags passed to C compiler? --- make/*/makefiles/rules.make -# $(CC) is the c compiler (cc/gcc), $(CCC) is the c++ compiler (CC/g++). -C_COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) -CC_COMPILE = $(CCC) $(CPPFLAGS) $(CFLAGS) +# $(CC) is the c compiler (cc/gcc), $(CXX) is the c++ compiler (CC/g++). +C_COMPILE = $(CC) $(CXXFLAGS) $(CFLAGS) +CC_COMPILE = $(CXX) $(CXXFLAGS) $(CFLAGS) The original code is confusing, given that CC is the C compiler it makes no sense that a C++ compile be called CC_COMPILE. Is it worth changing these to CC_COMPILE and CXX_COMPILE? Maybe a secondary cleanup? And again C++ flags passed to C compiler :( --- You missed a couple of scripts on Windows that use LINK_VER: windows/get_msc_ver.sh windows/build_vm_def.sh Cheers, David - The build-infra project is starting to move into jdk8. For the hotspot build to stay compatible with the changes, the naming of standard make variables, like CC and LD need to be standardized across the build. Currently hotspot names the C++ compiler CPP, which is traditionally the name of the preprocessor. The windows nmake files name the linker LINK. We would like to rename the C++ compiler to CXX and have the linker named LD everywhere. Patch is tested with hsx/hotspot-rt. Testing with jdk7u is in progress. /Erik
