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
