building part of jdk 8 (original) (raw)
Kelly O'Hair kelly.ohair at oracle.com
Mon Feb 13 21:13:46 UTC 2012
- Previous message (by thread): building part of jdk 8
- Next message (by thread): building part of jdk 8
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Feb 13, 2012, at 12:12 PM, Pete Brunet wrote:
On 2/13/12 1:35 PM, Kelly O'Hair wrote:
Just a few comments below...
On Feb 13, 2012, at 9:08 AM, Pete Brunet wrote:
This worked for me today for building just awt:
This is in my bat file. The first two sets are what resolved my issue. set ALTOUTPUTDIR=c:/OpenJDK/jdk8/build/windows-i586-fastdebug set ALTJDKIMPORTPATH=c:/OpenJDK/jdk8/build/windows-i586-fastdebug/j2sdk-image The above two settings make no sense to me. ALTOUTPUTDIR is supposed to point at the directory where you want the build results to go. One of the directories created is the j2sdk-image. This is a huge disk write area. I think I needed this to make my partial build use the same directory as my fastdebugbuild full build.
Understood. That's a perfectly valid reason.
ALTJDKIMPORTPATH is something you set when you are doing partial builds, e.g. not building hotspot. It needs to point at some place that is pretty golden and steady, for a place to get parts of the jdk image that you are not building. You have it set to the same place you are building. :^( That seems fishy to me. I would have done a full build, moved or copied j2sdk-image to some place safe, and had ALTJDKIMPORTPATH refer to that copy, where it would be safe from destruction during the build. I only build parts of awt and swing so maybe I've been lucky. In any event I made that change.
set ALTBOOTDIR=C:/Progra~1/Java/jdk1.7.002 The official boot jdk for jdk8 is actually the first shipping jdk7, although 7u2 should work, our release engineering and automated build systems use jdk7 fcs. set ALTFREETYPEHEADERSPATH=C:/Users/Pete/freetype-2.4.8/include set ALTFREETYPELIBPATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010 set ANTHOME=C:/Progra~2/apache-ant-1.7.1 set ALTMSDEVTOOLSPATH=C:/Progra
2/MICROS1/Windows/v7.0A/bin Not sure why ALTMSDEVTOOLSPATH is needed. Did you find this necessary for some reason? set CLASSPATH= set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; set CYGWIN=nodosfilewarning cd c:\Users\Pete\cygwin\bin bash --login -i This bash command will add /usr/bin to the PATH, and convert PATH to the CYGWIN world. Do I need to change something?
No you are perfectly fine. I was just commenting that the PATH setting has changed. I always keep track of when PATH changes.
Then at the cygwin command line: eval
bin/vsvars.sh -v10 -32
Perfect. That adjusts PATH, LIB, INCLUDE, etc, all for the Visual Studio compiler. cd /cygdrive/c/OpenJDK/jdk8/jdk/make/sun/awt/ make ARCHDATAMODEL=32 2>&1 | tee build.log Yup. Note: I suspect I don't need wbem in my path; I'll remove it the next time I do a build. I've never been sure about Wbem needing to be in the system path. Let me know what you find out. Rebuilding after tweaking awtComponent.cpp worked fine without this. I'll report back at some other time after doing a full rebuild.
http://www.pcreview.co.uk/forums/do-need-wbem-path-statement-t2330116.html
My tendency is to leave Wbem in PATH. Not sure we need it, but why vary the standard Windows PATH and ask for trouble? ;^)
-kto
---- So this is Windows 7 right? Is it Windows 7 X64 or X86? (32 or 64 bit OS) 64 bit Windows 7 Do you have any anti-virus software installed, and any special settings? I have Norton 360 and for a full build I disable auto-protect. I don't bother disabling that for a partial build. Is this the latest CYGWIN? (what does uname -a say?) 1.7.0 (I dropped back from using 1.7.9 and so far this has been working, but I haven't done enough full builds yet to be sure.) Pete There have been reports of problems with Windows 7 building, possibly involving CYGWIN and McAfee colliding somehow. Just curious. -kto
Pete
On 2/2/12 2:19 PM, Pete Brunet wrote: On 2/1/12 10:54 PM, Pete Brunet wrote: On 1/23/12 9:39 AM, Pete Brunet wrote: In the past I was able to build part of jdk 8 but that is not currently working although I am able to do a full 32 bit build. I've recently moved from XP to W7 so my environment might not be set up quite right yet. Here's what I do...
// These are done in a bat file before I do any makes set ALTBOOTDIR=C:/Progra~1/Java/jdk1.7.002 set ALTFREETYPEHEADERSPATH=C:/Users/Pete/freetype-2.4.8/include set ALTFREETYPELIBPATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010 set ANTHOME=C:/Progra~2/apache-ant-1.7.1 set ALTMSDEVTOOLSPATH=C:/Progra
2/MICROS1/Windows/v7.0A/bin set CLASSPATH= set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; set CYGWIN=nodosfilewarning cd c:\Users\Pete\cygwin\bin bash --login -i // These are done at the command line evalbin/vsvars.sh -v10 -32
cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/ make ARCHDATAMODEL=32 FASTDEBUG=true 2>&1 | tee build.log The error I am getting is make: *** No rule to make target../../../build/windows-i586/btjars/compileproperties.jar', needed by_ _
compileallprops'. Stop. When building below the top level, for some reason a partial build directory is being created in jdk8/jdk. When doing a full build from the top level the only build directory I see is the one in jdk8. It appears that ../../../build/... is using the build under jdk rather than the build under the top level. Tonight I saw a similar failure when trying to rebuild JLabel.java from jdk: make[2]: Entering directory/cygdrive/c/OpenJDK/jdk8/jdk/make/javax/swing'_ _make[2]: *** No rule to make target
javax/swing/JLabel', needed by../../../build/windows-i586/tmp/com/javax.swing/.classes.list'. Stop._ _and when trying to build directly at .../jdk/make/javax/swing, i.e._ _make: *** No rule to make target
javax/swing/JLabel', needed by../../../build/windows-i586/tmp/com/javax.swing/.classes.list'. Stop._ _The JLabel issue was caused by the existence of_ _...\jdk\src\share\classes\javax\swing\JLabel - Copy.java. (This is_ _Windows' scheme for copies.). However, that wouldn't explain the use of_ _a build directory under jdk (instead of under the top level), i.e. my_ _original problem might have been caused by using the wrong build dir:_ _make: *** No rule to make target_ _
../../../build/windows-i586/btjars/compileproperties.jar', needed by `compileallprops'. Stop. In case it's helpful jdk/build contains these directories: bin btbins btclasses btjars classes gensrc include lib Since the above has windows-i586 instead of windows-i586-debug it looks like I need to add another variable when invoking make. Pete
- Previous message (by thread): building part of jdk 8
- Next message (by thread): building part of jdk 8
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]