Re: Review for 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable
On 2012-02-09 03:51, David Holmes wrote: make/defs.make: + ifneq (,$(SPEC)) + include $(SPEC) + endif Having the blank first looks odd. I assume you aren't using -inlcude because you want to see errors if SPEC is set but not found. I guess it's an unconscious habit from java where you rather do .equals(something) to avoid NPE. I will switch it around. And the assumption is correct. We used -include at first, but I figured that we wanted to know if the include failed at least on the root level Makefile. make/windows/makefiles/compile.make: The definitions of MT=mt.exe in each block for the different VS versions seems redundant. If we factor this out is there any reason not to group: CXX=cl.exe MT=mt.exe RC=rc.exe LD=link.exe together and use the same if (,$(SPEC)) approach? Grouping them together would certainly look nicer, but MT isn't set for every possible compiler version. Not sure if that matters since we don't support older versions anyway, right? As for testing for SPEC, this is nmake and the SPEC file is only gnumake compatible. CXX, MT, RC and LD are sent in to nmake on the command line from gnumake. They are then generated into local.make which is in turn included by sub invocations of nmake. Sending in SPEC as well seemed redundant to me, but we could send it in as a flag signaling that configure should be in control. Wouldn't look obviously better to me though. I'm open for suggestions. /Erik
Re: Review for 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable
New webrev: http://cr.openjdk.java.net/~erikj/7141244/webrev.02/ http://cr.openjdk.java.net/%7Eerikj/7141244/webrev.02/ 177 lines changed: 89 ins; 29 del; 59 mod; 3970 unchg Changes since last time: * Moved the , to after $(SPEC) * Changed comment in gcc/sparcWorks.make according to suggestion from Fredrik. Haven't changed anything regarding the nmake files. /Erik On 2012-02-09 10:09, Erik Joelsson wrote: On 2012-02-09 03:51, David Holmes wrote: make/defs.make: + ifneq (,$(SPEC)) + include $(SPEC) + endif Having the blank first looks odd. I assume you aren't using -inlcude because you want to see errors if SPEC is set but not found. I guess it's an unconscious habit from java where you rather do .equals(something) to avoid NPE. I will switch it around. And the assumption is correct. We used -include at first, but I figured that we wanted to know if the include failed at least on the root level Makefile. make/windows/makefiles/compile.make: The definitions of MT=mt.exe in each block for the different VS versions seems redundant. If we factor this out is there any reason not to group: CXX=cl.exe MT=mt.exe RC=rc.exe LD=link.exe together and use the same if (,$(SPEC)) approach? Grouping them together would certainly look nicer, but MT isn't set for every possible compiler version. Not sure if that matters since we don't support older versions anyway, right? As for testing for SPEC, this is nmake and the SPEC file is only gnumake compatible. CXX, MT, RC and LD are sent in to nmake on the command line from gnumake. They are then generated into local.make which is in turn included by sub invocations of nmake. Sending in SPEC as well seemed redundant to me, but we could send it in as a flag signaling that configure should be in control. Wouldn't look obviously better to me though. I'm open for suggestions. /Erik
Re: Review for 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable
Looks good! //Fredrik - erik.joels...@oracle.com skrev: New webrev: http://cr.openjdk.java.net/~erikj/7141244/webrev.02/ http://cr.openjdk.java.net/%7Eerikj/7141244/webrev.02/ 177 lines changed: 89 ins; 29 del; 59 mod; 3970 unchg Changes since last time: * Moved the , to after $(SPEC) * Changed comment in gcc/sparcWorks.make according to suggestion from Fredrik. Haven't changed anything regarding the nmake files. /Erik On 2012-02-09 10:09, Erik Joelsson wrote: On 2012-02-09 03:51, David Holmes wrote: make/defs.make: + ifneq (,$(SPEC)) + include $(SPEC) + endif Having the blank first looks odd. I assume you aren't using -inlcude because you want to see errors if SPEC is set but not found. I guess it's an unconscious habit from java where you rather do .equals(something) to avoid NPE. I will switch it around. And the assumption is correct. We used -include at first, but I figured that we wanted to know if the include failed at least on the root level Makefile. make/windows/makefiles/compile.make: The definitions of MT=mt.exe in each block for the different VS versions seems redundant. If we factor this out is there any reason not to group: CXX=cl.exe MT=mt.exe RC=rc.exe LD=link.exe together and use the same if (,$(SPEC)) approach? Grouping them together would certainly look nicer, but MT isn't set for every possible compiler version. Not sure if that matters since we don't support older versions anyway, right? As for testing for SPEC, this is nmake and the SPEC file is only gnumake compatible. CXX, MT, RC and LD are sent in to nmake on the command line from gnumake. They are then generated into local.make which is in turn included by sub invocations of nmake. Sending in SPEC as well seemed redundant to me, but we could send it in as a flag signaling that configure should be in control. Wouldn't look obviously better to me though. I'm open for suggestions. /Erik
Re: Review for 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable
Added back runtime to the cc list On 9/02/2012 7:33 PM, Erik Joelsson wrote: New webrev: http://cr.openjdk.java.net/~erikj/7141244/webrev.02/ http://cr.openjdk.java.net/%7Eerikj/7141244/webrev.02/ 177 lines changed: 89 ins; 29 del; 59 mod; 3970 unchg Changes since last time: * Moved the , to after $(SPEC) * Changed comment in gcc/sparcWorks.make according to suggestion from Fredrik. Haven't changed anything regarding the nmake files. That's okay - it was just an observation. Seems okay to me. Let's see if we can get Kelly or someone else from HS to comment. David - /Erik On 2012-02-09 10:09, Erik Joelsson wrote: On 2012-02-09 03:51, David Holmes wrote: make/defs.make: + ifneq (,$(SPEC)) + include $(SPEC) + endif Having the blank first looks odd. I assume you aren't using -inlcude because you want to see errors if SPEC is set but not found. I guess it's an unconscious habit from java where you rather do .equals(something) to avoid NPE. I will switch it around. And the assumption is correct. We used -include at first, but I figured that we wanted to know if the include failed at least on the root level Makefile. make/windows/makefiles/compile.make: The definitions of MT=mt.exe in each block for the different VS versions seems redundant. If we factor this out is there any reason not to group: CXX=cl.exe MT=mt.exe RC=rc.exe LD=link.exe together and use the same if (,$(SPEC)) approach? Grouping them together would certainly look nicer, but MT isn't set for every possible compiler version. Not sure if that matters since we don't support older versions anyway, right? As for testing for SPEC, this is nmake and the SPEC file is only gnumake compatible. CXX, MT, RC and LD are sent in to nmake on the command line from gnumake. They are then generated into local.make which is in turn included by sub invocations of nmake. Sending in SPEC as well seemed redundant to me, but we could send it in as a flag signaling that configure should be in control. Wouldn't look obviously better to me though. I'm open for suggestions. /Erik
Re: Review for 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable
The only issue I see is that it's using cygpath -m -a and not cygpath -s -m -a which I think means that the path could have spaces in it. Otherwise, looks fine. -kto On Feb 9, 2012, at 1:33 AM, Erik Joelsson wrote: New webrev: http://cr.openjdk.java.net/~erikj/7141244/webrev.02/ http://cr.openjdk.java.net/%7Eerikj/7141244/webrev.02/ 177 lines changed: 89 ins; 29 del; 59 mod; 3970 unchg Changes since last time: * Moved the , to after $(SPEC) * Changed comment in gcc/sparcWorks.make according to suggestion from Fredrik. Haven't changed anything regarding the nmake files. /Erik On 2012-02-09 10:09, Erik Joelsson wrote: On 2012-02-09 03:51, David Holmes wrote: make/defs.make: + ifneq (,$(SPEC)) + include $(SPEC) + endif Having the blank first looks odd. I assume you aren't using -inlcude because you want to see errors if SPEC is set but not found. I guess it's an unconscious habit from java where you rather do .equals(something) to avoid NPE. I will switch it around. And the assumption is correct. We used -include at first, but I figured that we wanted to know if the include failed at least on the root level Makefile. make/windows/makefiles/compile.make: The definitions of MT=mt.exe in each block for the different VS versions seems redundant. If we factor this out is there any reason not to group: CXX=cl.exe MT=mt.exe RC=rc.exe LD=link.exe together and use the same if (,$(SPEC)) approach? Grouping them together would certainly look nicer, but MT isn't set for every possible compiler version. Not sure if that matters since we don't support older versions anyway, right? As for testing for SPEC, this is nmake and the SPEC file is only gnumake compatible. CXX, MT, RC and LD are sent in to nmake on the command line from gnumake. They are then generated into local.make which is in turn included by sub invocations of nmake. Sending in SPEC as well seemed redundant to me, but we could send it in as a flag signaling that configure should be in control. Wouldn't look obviously better to me though. I'm open for suggestions. /Erik
Re: Is anyone able to build on Win 7
Does this article provide any help:
https://kc.mcafee.com/corporate/index?page=contentid=KB55075actp=searchviewlocale=en_USsearchid=1328818133782
It suggests that rebase'ing the CYGWIN DLL's will help. Seems a bit strange to
me, just passing it on.
-kto
On Jan 25, 2012, at 5:10 PM, Pete Brunet 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 problem of Cygwin running on 64-bit Windows 7
I'll try to further narrow down the problem, but of course any hints
are highly welcome (unfortunately I can't easily get rid of the McAffe
stuff without losing my job, so please don't advise this:)
Regards,
Volker
PS: below you can find the exact versions of the software/hardware I'm
using:
64-bit Windows 7, SP 1
Dual Core Intel i7, 8GB RAM
Cygwin (output of uname -a):
CYGWIN_NT-6.1-WOW64 WDFN00299915A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686
Cygwin
bash 4.1.10(4) // installed by Cygwin setup.exe
make 3.82 // compiled by myself
In the Virtual box VM I have the following system:
64-bit Windows XP Professional Version 2003 SP 2
Cygwin (output of uname -a):
CYGWIN_NT-5.2-WOW64 WDFV00248216A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686
Cygwin
bash 4.1.10(4) // installed by Cygwin setup.exe
make 3.82 // compiled by myself
On Tue, Jan 24, 2012 at 5:52 PM, Pete Brunet peter.bru...@oracle.com
wrote:
Is anyone able to build on
Re: RFR 7142950: jdk7u cannot bootstrap Mac OS build [macosx]
Hi, http://cr.openjdk.java.net/~michaelm/7142950/jdk/webrev.2/ This is an updated webrev based on the contribution/suggestion from Scott Kovatch. It changes the build image directories on Mac, to have the same format/directory structure as the other platforms (ie. it removes the Contents/Home stuff). That directory structure required by Mac bundles is now generated in specific bundle directories and these are used by the install. A consequence of this change is that anyone who has adjusted scripts that used the built j2sdk-image, or j2re-image to know about the mac specific paths will have to change that back again. This version of the change is almost agnostic on the os.arch setting. The only dependency is on 'src/macosx/bin/amd64/jvm.cfg'. That will have to be renamed to x86_64/jvm.cfg when 'os.arch' is changed. No other change is required. With this change, jdk only, and incremental builds should work again. If you are using the previous output from a control build as bootstrap or import jdk for a subsequent jdk only build, then it is possible you could run into the build problem described in 6967648. The workaround is to rename the top-level build directory to some other name before doing the jdk build. Thanks, Michael On 06/02/12 23:21, Scott Kovatch wrote: On Feb 6, 2012, at 2:31 PM, Michael McMahon wrote: There are a few problems with the Mac build at the moment. 1. If SKIP_BOOT_CYCLE=false then the build fails, due to two problems:- 1) top level Makefile doesn't know about Mac OS image directory structure 2) it also fails due to problem 2. below 2. General bootstrapping problem. The build currently cannot use itself as the bootstrap JDK due to an assumption in the framework classes that os.arch is x86_64, whereas we currently set it to amd64. The change is to fix that code to expect amd64. There is a related question then about what the correct value for os.arch should be. I'd like to raise this in a separate discussion and hopefully fix these build problems independently of that. I was going to propose that we fix the image directory issues by building into the image directories the same way on all platforms and have the mac build copy the image directories into j2sdk-bundle. (7133768) I'm pretty sure that even with this change you can't build rt.jar because the jar tool gets moved out from underneath the running build when the bundle is constructed. I don't think your changes would interfere with my proposed fix for 7133768, though. And, the other changes for generating the folder name dynamically are very much welcome. -- Scott K. Scott Kovatch scott.kova...@oracle.com Santa Clara/Pleasanton, CA
Re: Review for 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable
Erik Joelsson (erik.joels...@oracle.com) wrote: New webrev: http://cr.openjdk.java.net/~erikj/7141244/webrev.02/ http://cr.openjdk.java.net/%7Eerikj/7141244/webrev.02/ 177 lines changed: 89 ins; 29 del; 59 mod; 3970 unchg Changes since last time: * Moved the , to after $(SPEC) * Changed comment in gcc/sparcWorks.make according to suggestion from Fredrik. Looks good. One minor request: in linux/makefiles/gcc.make, you moved the setting of STRIP under the SPEC conditional. Might as well fold it into the CROSS_COMPILE_ARCH conditional that's already there. -John On 2012-02-09 10:09, Erik Joelsson wrote: On 2012-02-09 03:51, David Holmes wrote: make/defs.make: + ifneq (,$(SPEC)) + include $(SPEC) + endif Having the blank first looks odd. I assume you aren't using -inlcude because you want to see errors if SPEC is set but not found. I guess it's an unconscious habit from java where you rather do .equals(something) to avoid NPE. I will switch it around. And the assumption is correct. We used -include at first, but I figured that we wanted to know if the include failed at least on the root level Makefile. make/windows/makefiles/compile.make: The definitions of MT=mt.exe in each block for the different VS versions seems redundant. If we factor this out is there any reason not to group: CXX=cl.exe MT=mt.exe RC=rc.exe LD=link.exe together and use the same if (,$(SPEC)) approach? Grouping them together would certainly look nicer, but MT isn't set for every possible compiler version. Not sure if that matters since we don't support older versions anyway, right? As for testing for SPEC, this is nmake and the SPEC file is only gnumake compatible. CXX, MT, RC and LD are sent in to nmake on the command line from gnumake. They are then generated into local.make which is in turn included by sub invocations of nmake. Sending in SPEC as well seemed redundant to me, but we could send it in as a flag signaling that configure should be in control. Wouldn't look obviously better to me though. I'm open for suggestions. /Erik
