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:/Progra~1/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:/Progra~2/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 (obj_g/), fastdebug (obj_gO/), 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 fastdebug_build build there are two directories under >> C:\OpenJDK\jdk8\build\windows-i586-fastdebug\tmp\sun\sun.awt\awt, i.e. >> CClassHeaders and Obj_gO. 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 ALT_OUTPUTDIR=c:/OpenJDK/jdk8/build/windows-i586-fastdebug >>>>>> set >>>>>> ALT_JDK_IMPORT_PATH=c:/OpenJDK/jdk8/build/windows-i586-fastdebug/j2sdk-image >>>>> The above two settings make no sense to me. >>>>> >>>>> ALT_OUTPUTDIR 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 fastdebug_build full build. >>> Understood. That's a perfectly valid reason. >>> >>>>> ALT_JDK_IMPORT_PATH 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 ALT_JDK_IMPORT_PATH 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 ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02 >>>>> 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 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:/Progra~2/apache-ant-1.7.1 >>>>>> set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin >>>>> Not sure why ALT_MSDEVTOOLS_PATH 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 ARCH_DATA_MODEL=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 awt_Component.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 ALT_BOOTDIR=C:/Progra~1/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:/Progra~2/apache-ant-1.7.1 >>>>>>>>> set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/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 ARCH_DATA_MODEL=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 >>>>>>>>> `compile_all_props'. 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 >>>>>>> `compile_all_props'. 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
