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 [EMAIL PROTECTED]
sunFont.obj : error LNK2019: unresolved external symbol
_isNullScalerContext ref
erenced in function [EMAIL PROTECTED]
SunLayoutEngine.obj : error LNK2019: unresolved external symbol
_getUnitsPerEmFo
rLayout referenced in function "public: virtual long __thiscall
FontInstanceAdap
ter::getUnitsPerEM(void)const " ([EMAIL PROTECTED]@@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@@[EMAIL PROTECTED]@@PAV_jobject@@[EMAIL PROTECTED])
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:[EMAIL PROTECTED]:/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
