New bug in build process

Ted Neward ted at tedneward.com
Tue Jul 31 04:42:29 UTC 2007


> Is this t2k.lib file the one you created from t2k.dll?
> 
Yes.

> I've never seen these errors before, but it looks like it's in the
> fastdebug build, which would mean you got past the product build,
> which is significant.
> 
Unfortunately, no, that's not the case--I was doing a fastdebug build
explicitly (make fastdebug_build DEV=1).

> Keep in mind that although we regularly build the fastdebug bits (-g -O),
> and
> some developers build the debug bits (-g), neither are tested very
> extensively.
> With the exception of the Hotspot VM, which gets tested fairly well with
> VM type tests.
> It's the product built bits that get most of the formal JDK testing done
> to them.
> 
I'm primarily interested in the debug builds because then I have symbols and
can do a lot better exploratory spelunking in tools like debuggers. Besides,
as I spelunk, I'll want to make some source changes (just to play around or
display information), and a lot more info is present in debug builds than
product builds. Frankly, just getting a fastdebug build to go from start to
finish would probably be sufficient.

Actually, just having fastdebug Hotspot is really sufficient for what I want
to play around with, but I figure while I'm here I'll try to help debug the
Windows build process if I can. :-)

> Product .obj/.o files should end up in a obj directory (under
> build/*/tmp),
> fastdebug ones in obj_gO, and debug ones in obj_g. I'm curious why you are
> seeing
> some obj_gO references and some obj_g references. Maybe there is another
> bug in
> the BinaryPlugs.gmk file... :^(
>
Let me start over and do a fresh build, capture the results (is there a good
way to capture the complete build output?), and send them to you. What
"make" command should I use? "make all DEV=1"? Something else?

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
 

> -----Original Message-----
> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM]
> Sent: Monday, July 30, 2007 7:02 AM
> To: Ted Neward
> Cc: build-dev at openjdk.java.net
> Subject: Re: New bug in build process
> 
> Is this t2k.lib file the one you created from t2k.dll?
> 
> I've never seen these errors before, but it looks like it's in the
> fastdebug build, which would mean you got past the product build,
> which is significant.
> 
> This is just a wild guess, but I wonder if the debug t2k.dll file has more
> external symbols than the product one? I'm not that familiar with
> the external list for this library.
> 
> ---
> 
> Keep in mind that although we regularly build the fastdebug bits (-g -O),
> and
> some developers build the debug bits (-g), neither are tested very
> extensively.
> With the exception of the Hotspot VM, which gets tested fairly well with
> VM type tests.
> It's the product built bits that get most of the formal JDK testing done
> to them.
> 
> Product .obj/.o files should end up in a obj directory (under
> build/*/tmp),
> fastdebug ones in obj_gO, and debug ones in obj_g. I'm curious why you are
> seeing
> some obj_gO references and some obj_g references. Maybe there is another
> bug in
> the BinaryPlugs.gmk file... :^(
> 
> -kto
> 
> Ted Neward wrote:
> > After doing a “nuke” of the build dir, and doing a fresh “make
> > debug_build DEV=1” (again, on Windows), I get this:
> >
> >
> >
> >    Creating library
> > c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.fo
> >
> > nt/fontmanager/obj_gO/fontmanager.lib and object
> > c:/Prg/OpenJDK/openjdk/control/
> >
> > build/WINDOW~2/tmp/sun/sun.font/fontmanager/obj_gO/fontmanager.exp
> >
> > sunFont.obj : error LNK2019: unresolved external symbol _setSunFontIDs
> > reference
> >
> > d in function _Java_sun_font_FontManager_initIDs at 8
> >
> > sunFont.obj : error LNK2019: unresolved external symbol
> > _isNullScalerContext ref
> >
> > erenced in function _Java_sun_font_StrikeCache_freeIntMemory at 20
> >
> > SunLayoutEngine.obj : error LNK2019: unresolved external symbol
> > _getUnitsPerEmFo
> >
> > rLayout referenced in function "public: virtual long __thiscall
> > FontInstanceAdap
> >
> > ter::getUnitsPerEM(void)const "
> (?getUnitsPerEM at FontInstanceAdapter@@UBEJXZ)
> >
> > FontInstanceAdapter.obj : error LNK2001: unresolved external symbol
> > _getUnitsPer
> >
> > EmForLayout
> >
> > FontInstanceAdapter.obj : error LNK2019: unresolved external symbol
> > _getLayoutTa
> >
> > bles referenced in function "public: __thiscall
> > FontInstanceAdapter::FontInstanc
> >
> > eAdapter(struct JNIEnv_ *,class _jobject *,class _jobject *,float
> > *,long,long)"
> >
> > (??0FontInstanceAdapter@@QAE at PAUJNIEnv_@@PAV_jobject@@1PAMJJ at Z)
> >
> >
> c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.font/fontmanager
> /obj_g
> >
> > O/fontmanager.dll : fatal error LNK1120: 4 unresolved externals
> >
> > make[5]: ***
> > [c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/bin/fontmanager.dll]
> >
> >  Error 96
> >
> > make[5]: Leaving directory
> > `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font'
> >
> > make[4]: *** [all] Error 1
> >
> > make[4]: Leaving directory
> `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun'
> >
> > make[3]: *** [all] Error 1
> >
> > make[3]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make'
> >
> > make[2]: *** [j2se-build] Error 2
> >
> > make[2]: Leaving directory
> `/cygdrive/c/Prg/OpenJDK/openjdk/control/make'
> >
> > make[1]: *** [generic_debug_build] Error 2
> >
> > make[1]: Leaving directory
> `/cygdrive/c/Prg/OpenJDK/openjdk/control/make'
> >
> > make: *** [fastdebug_build] Error 2
> >
> > CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/control/make
> >
> > $
> >
> >
> >
> > Apparently there’s some missing object files in the link step of
> > fontmanager.lib; any ideas? Intuition tells me this is t2k.lib-related
> > again, since we’re back in the silly font directory again, and yes, I
> > know, t2k is going away soon, but I’d like to see if it can be worked
> > around in the meantime. Legal issues have this annoying tendency to take
> > MUCH longer than engineers think they should… :-)
> >
> >
> >
> > The build output prior to this link line is pretty verbose, but I can
> > send it if it’ll help debug the problem….
> >
> >
> >
> > Ted Neward
> >
> > Java, .NET, XML Services
> >
> > Consulting, Teaching, Speaking, Writing
> >
> > http://www.tedneward.com
> >
> >
> >
> >
> >
> >
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date:
> > 7/28/2007 3:50 PM
> >
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007
> 3:50 PM
> 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007
3:50 PM
 




More information about the build-dev mailing list