building part of jdk 8 (original) (raw)

Pete Brunet peter.brunet at oracle.com
Wed Feb 15 17:01:52 UTC 2012

Thanks Kelly, That's interesting. That might provide a hint regarding a problem I am working on. When I do a full fastdebug_build build with my patch applied I get a hang when exiting the app, but when I do a subsequent partial build (with the side effect of using obj instead of obj_gO) there is no problem.

What do I have to change in the following partial build invocation to compile with fastdebug (and use the fastdebug obj_gO directory) or to compile with debug (and use the debug obj_g directory)?

eval bin/vsvars.sh -v10 -32 cd /cygdrive/c/OpenJDK/jdk8/jdk/make/sun/awt/ make ARCH_DATA_MODEL=32 2>&1 | tee build.log

As a reminder, this is what I do before invoking cywin:

set ALT_OUTPUTDIR=c:/OpenJDK/jdk8/build/windows-i586-fastdebug set ALT_JDK_IMPORT_PATH=c:/OpenJDK/jdk8/build/j2sdk-image set ALT_BOOTDIR=C:/Progra1/Java/jdk1.7.0_02 set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010 set ANT_HOME=C:/Progra2/apache-ant-1.7.1 set CLASSPATH= set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; set CYGWIN=nodosfilewarning

And if anyone has an idea why using obj_gO results in a hang on exit but using obj doesn't that would be helpful. Maybe when building just awt there is a mismatch between the awt obj files and the rest of the obj files that make up awt.dll.

Or maybe my full build needs to be a product build rather than a fastdebug_build build (to ensure a match between my full and partial builds). Is that done by removing fastdebug_build when running make at the top level?

Pete

On 2/15/12 10:37 AM, Kelly O'Hair wrote:

The debug (objg/), fastdebug (objgO/), and product (obj/) directories keep the different .o or .obj files separate, since there is no guarantee that these can be mixed together and work. All compilations for a library need to be the same kind of compilation.

-kto On Feb 14, 2012, at 7:35 PM, Pete Brunet wrote:

I don't know if this is a problem but it's something I noticed. When I do the full fastdebugbuild build there are two directories under C:\OpenJDK\jdk8\build\windows-i586-fastdebug\tmp\sun\sun.awt\awt, i.e. CClassHeaders and ObjgO. When I then do the partial build of awt (described in the history below) a new directory, obj, is added and populated.

On 2/13/12 3:13 PM, Kelly O'Hair wrote: 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:/Progra2/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:/Progra2/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 eval bin/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

More information about the build-dev mailing list