VS7.1 to VS 8 : MSVCMRTD.lib(mstartup.obj) : LNK2022 : tagTEXTMETR

[consultutah]

I am trying to upgrade from VS7.1 to VS8, but whenever I link any of our MC++
DLL's, I get the following errors:

Creating library \sda\Main\bin\debug\XWRAP70.lib and object
\sda\Main\bin\debug\XWRAP70.exp
MSVCMRTD.lib(mstartup.obj) : error LNK2022: metadata operation failed
(8013118D) : Inconsistent layout information in duplicated types
(tagTEXTMETRICA): (0x02000039).
MSVCMRTD.lib(mehvecdtr.obj) : error LNK2022: metadata operation failed
(8013118D) : Inconsistent layout information in duplicated types
(tagTEXTMETRICA): (0x0200002a).
MSVCMRTD.lib(managdeh.obj) : error LNK2022: metadata operation failed
(8013118D) : Inconsistent layout information in duplicated types
(tagTEXTMETRICA): (0x02000029).
MSVCMRTD.lib(msilexit.obj) : error LNK2022: metadata operation failed
(8013118D) : Inconsistent layout information in duplicated types
(tagTEXTMETRICA): (0x0200002f).
MSVCMRTD.lib(puremsilcode.obj) : error LNK2022: metadata operation failed
(8013118D) : Inconsistent layout information in duplicated types
(tagTEXTMETRICA): (0x02000029).
LINK : fatal error LNK1255: link failed because of metadata errors

Any ideas on what I need to change to eliminate these?

Thanks,

[Jochen Kalmbach [MVP]]

Hi consultutah!

I am trying to upgrade from VS7.1 to VS8, but whenever I link any of our MC++
DLL's, I get the following errors:

Creating library \sda\Main\bin\debug\XWRAP70.lib and object
\sda\Main\bin\debug\XWRAP70.exp
MSVCMRTD.lib(mstartup.obj) : error LNK2022: metadata operation failed
(8013118D) : Inconsistent layout information in duplicated types
(tagTEXTMETRICA): (0x02000039).

Are you sure that you have compiled with the same settings for CLR?
(/clr:oldsyntax) ?

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Holger Grund]

"co*********@nospam.nospam"
<co*********@[e-mail].c om> wrote

I am trying to upgrade from VS7.1 to VS8, but whenever I link any of our
MC++
DLL's, I get the following errors:

Creating library \sda\Main\bin\debug\XWRAP70.lib and object
\sda\Main\bin\debug\XWRAP70.exp
MSVCMRTD.lib(mstartup.obj) : error LNK2022: metadata operation failed
(8013118D) : Inconsistent layout information in duplicated types [..] LINK : fatal error LNK1255: link failed because of metadata errors

Any ideas on what I need to change to eliminate these?

Use the same settings and defines as were used to compile the
other files (the information is embedded in the object files).
This one actually looks like a VC bug.

BTW: You can always use ildasm /OUT on the object files
(you might need another switch for numerical token values
(/TOKENS ?) ). Lib can extract objects from archives.

-hg

[consultutah]

I'm sorry, I don't understand.

I am using the same cl and link options for every file. We have one common
makefile.mif that gets included by all other makefiles. That way, there is
only one place to change the options.

Here is the command line for cl.exe (though I'm pretty sure that the real
problem is the linker):

cl -c -Fddebug\ -Fodebug\ -WX -Gd -Zp1 -nologo -vmg -Gs -D_WIN95 -DWIN32
-DWINVER=0x0400 -W3 -MDd /clr:oldSyntax -wd 4562 -wd 4835 -wd 4996 -wd 4793
-DVS2005 -DFORWARD_DECLARE_FIX -DNO_PL -DNO_ITEM_HIER -DINCLUDE_XPERTS
-DIN_XACTWRAP_DLL -DDEBUG -Od -Zi xwmain.cpp > xwmain.drr

Here is the command line for link.exe:
link -debug -OPT:NOWIN98 /CLRIMAGETYPE:IJW /CLRTHREADATTRIBUTE:MTA -nologo
/DLL
-subsystem:windows,4.0 -OUT:\sda\Main\bin\debug\XWRAP70.DLL /MACHINE:IX86
/BASE:
0x44000000 /INCREMENTAL:NO ..\xacttool\debug\xttoolbr.obj
...\xactcore\debug\clis
tptr.obj ..\xactcore\debug\compitem.obj ..\xactcore\debug\complist.obj
...\xactco
re\debug\debug.obj ..\xactcore\debug\pcharutl.obj ..\xactcore\debug\r64.obj
...\x
actcore\debug\strcvt.obj ..\xactcore\debug\strgbl.obj
...\xactcore\debug\strings.
obj ..\xactcore\debug\time.obj ..\xactcore\debug\timegbl.obj
...\xactcore\debug\t
ree.obj ..\xactcore\debug\vector.obj ..\xactcore\debug\xbase.obj
...\xactcore\deb
ug\xcblob.obj ..\xactcore\debug\xcerror.obj ..\xactcore\debug\xcfile.obj
...\xact
core\debug\xcfilesy.obj ..\xactcore\debug\xcfdelim.obj
...\xactcore\debug\xclk.ob
j ..\xactcore\debug\xcmark.obj ..\xactcore\debug\xcmemo.obj
...\xactcore\debug\xc
mutex.obj ..\xactcore\debug\xcompres.obj ..\xactcore\debug\xcstorage.obj
...\xact
core\debug\xcstream.obj ..\xactcore\debug\xctextvld.obj
...\xactcore\debug\xcvari
an.obj ..\xactcore\debug\xcvartyp.obj ..\xactcore\debug\xczip.obj
...\xactcore\de
bug\xczipstg.obj ..\xactcore\debug\xczipstg_xc.obj
...\xactcore\debug\xczipstg_zp
..obj ..\xactcore\debug\xstack.obj debug\imgapi.obj debug\wevent.obj
debug\xwanim
at.obj debug\xwcompedit.obj debug\xwimglst.obj debug\xwlistvw.obj
debug\xwlvitem
..obj debug\xwmhook.obj debug\xwmsghk.obj debug\xwprogbr.obj
debug\xwspiner.obj d
ebug\xwstatus.obj debug\xwtooltp.obj debug\xwtreevw.obj debug\xwtritem.obj
debug
\xwudctrl.obj debug\xwwait.obj debug\xwwtdisp.obj debug\xwrap_mn.obj
debug\xdlli
nit.obj debug\xwrap_cm.obj debug\datacach.obj debug\xwbitdat.obj
debug\xwbrush.o
bj debug\xwbutton.obj debug\xwclipbd.obj debug\xwcontrl.obj
debug\xwcstruc.obj d
ebug\xwdialog.obj debug\xwdispla.obj debug\xwedit.obj debug\xwenhdsp.obj
debug\x
wevent.obj debug\xwfont.obj debug\xwfontme.obj debug\xwgraphi.obj
debug\xwimage.
obj debug\xwimgwin.obj debug\xwkhook.obj debug\xwlists.obj
debug\xwmemdis.obj de
bug\xwmenu.obj debug\xwmetdsp.obj debug\xwmodule.obj debug\xwnetwrk.obj
debug\xw
ole.obj debug\xwole1.obj debug\xwoleclp.obj debug\xwoledat.obj
debug\xwpalett.ob
j debug\xwpoint.obj debug\xwprint.obj debug\xwprtdis.obj debug\xwprtdlg.obj
debu
g\xwrect.obj debug\xwregion.obj debug\xwregist.obj debug\xwscroll.obj
debug\xwst
atic.obj debug\xwsystem.obj debug\xwtable.obj debug\xwwin.obj
debug\xwwininf.obj
debug\xwwinobj.obj debug\xwmenubar.obj debug\xwmsgflthk.obj debug\xwapp.obj
deb
ug\xwdockfr.obj debug\xwgbox.obj debug\xwimagewrit.obj
...\themewrap\debug\xpthem
e.obj ..\config\debug\CONFIG.OBJ ..\config\debug\CONFIGC.OBJ kernel32.lib
advapi
32.lib user32.lib gdi32.lib comdlg32.lib winspool.lib comctl32.lib ole32.lib
uui
d.lib vfw32.lib oledlg.lib winmm.lib oleaut32.lib mpr.lib version.lib
\sda\Main\
bin\debug\x_dll32.lib \sda\Main\bin\debug\implodei.lib debug\xactwrap.res
/NOENT
RY

[consultutah]

Yes. I replaced the /clr option in our common makefile with the new
/clr:oldSyntax option.
"Jochen Kalmbach [MVP]" wrote:

Hi consultutah!

I am trying to upgrade from VS7.1 to VS8, but whenever I link any of our MC++
DLL's, I get the following errors:

Creating library \sda\Main\bin\debug\XWRAP70.lib and object
\sda\Main\bin\debug\XWRAP70.exp
MSVCMRTD.lib(mstartup.obj) : error LNK2022: metadata operation failed
(8013118D) : Inconsistent layout information in duplicated types
(tagTEXTMETRICA): (0x02000039).

Are you sure that you have compiled with the same settings for CLR?
(/clr:oldsyntax) ?

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Holger Grund]

"co*********@nospam.nospam"
<co*********************@discussions.microsoft.com > wrote

I'm sorry, I don't understand.

It's just a poor diagnostic (It doesn't tell you where the other definition
is).

I think what happens is that you use tagTEXTMETRICA in your
code with a different definition than was used to build the CRT libs.

The compiler translates every native type into a CLR value type.
The linker does a merge of the assembly fragments. In your
case there are duplicate CLR TypeDefs which are not identical.

I'm not sure, however, as to why the CRT modules have a
definition for tagTEXTMETRICA at all. I fail to see a reason
why the CRT would use it. I also don't see why it should be
different in different object files (AFAICT it doesn't depend
on WINVER or things like that).

I don't see anything wrong in the command lines.

I'd suggest you run ildasm /OUT on the object files
contributing to the final image.
E.g.
FOR %f IN (*.obj) DO ildasm /OUT=%f.il %f
and extract one of the object files from msvcrtmd.lib
(you can use LIB /EXTRACT to do so)

Find the definition for tagTEXTMETRICA in
your object files and compare it to the one from
the CRT.

BTW: Which version are you using? It looks odd that
the CRT has these definitions.

-hg

[consultutah]

I'm using version 8 (.NET 2.0).

You were right, this does show the difference:

From MSVCMRTD.lib:
// TypDefName: tagTEXTMETRICA (02000028)
// Flags : [NotPublic] [SequentialLayout] [Class] [Sealed] [AnsiClass]
[BeforeFieldInit] (00100108)
// Extends : 0100000E [TypeRef] System.ValueType
// Layout : Packing:0, Size:56
// CustomAttribute #1 (0c000096)
// -------------------------------------------------------
// CustomAttribute Type: 0a000001
// CustomAttributeName: Microsoft.VisualC.DebugInfoInPDBAttribute ::
instance void .ctor()
// Length: 4
// Value : 01 00 00 00 >
<
// ctor args: ()
//
// CustomAttribute #2 (0c000097)
// -------------------------------------------------------
// CustomAttribute Type: 0a000002
// CustomAttributeName: Microsoft.VisualC.MiscellaneousBitsAttribute ::
instance void .ctor(int32)
// Length: 8
// Value : 01 00 41 00 00 00 00 00 > A
<
// ctor args: (65)
//
// CustomAttribute #3 (0c000098)
// -------------------------------------------------------
// CustomAttribute Type: 0a000003
// CustomAttributeName:
System.Runtime.CompilerServices.NativeCppClassAttr ibute :: instance void
..ctor()
// Length: 4
// Value : 01 00 00 00 >
<
// ctor args: ()

From my obj - (I've limited it down to 1):
// TypDefName: tagTEXTMETRICA (02000030)
// Flags : [NotPublic] [SequentialLayout] [Class] [Sealed] [AnsiClass]
[BeforeFieldInit] (00100108)
// Extends : 0100000B [TypeRef] System.ValueType
// Layout : Packing:0, Size:53
// CustomAttribute #1 (0c0000cf)
// -------------------------------------------------------
// CustomAttribute Type: 0a000001
// CustomAttributeName: Microsoft.VisualC.DebugInfoInPDBAttribute ::
instance void .ctor()
// Length: 4
// Value : 01 00 00 00 >
<
// ctor args: ()
//
// CustomAttribute #2 (0c0000d0)
// -------------------------------------------------------
// CustomAttribute Type: 0a000003
// CustomAttributeName: Microsoft.VisualC.MiscellaneousBitsAttribute ::
instance void .ctor(int32)
// Length: 8
// Value : 01 00 41 00 00 00 00 00 > A
<
// ctor args: (65)
//
// CustomAttribute #3 (0c0000d1)
// -------------------------------------------------------
// CustomAttribute Type: 0a000004
// CustomAttributeName:
System.Runtime.CompilerServices.NativeCppClassAttr ibute :: instance void
..ctor()
// Length: 4
// Value : 01 00 00 00 >
<
// ctor args: ()

Notice that the difference is the size! The library version is 56 bytes,
whereas the version that is in my dlls is 53 bytes! So, does that mean I
might be including the declaration of tagMETRICA from the VS7.1 headers
instead of the VS8 headers?

Thanks,

[Holger Grund]

"co*********@nospam.nospam"
<co*********************@discussions.microsoft.com > wrote

I'm using version 8 (.NET 2.0).
Is that the RTM version? Or Beta 2?

[..] Notice that the difference is the size! The library version is 56 bytes,
whereas the version that is in my dlls is 53 bytes! So, does that mean I
might be including the declaration of tagMETRICA from the VS7.1 headers
instead of the VS8 headers?

Unlikely. The size should always be the same (after all both VS 7.1
and VS 8 generated executables should run on Windows ;-) )

It looks like you have a bad alignment for the Windows headers.
I'm not sure whether the Windows headers are supposed to be
resilient to bad alignment settings.

Looking at your compiler settings there is -Zp1 which is likely
the culprit. I suggest you remove the switch, and add a
#pragma pack _after_ including the windows headers.

Ideally you should stick to standard alignment in the long term
and use #pragma pack or __declspec(align) only where needed.

-hg

[consultutah]

That was it. I will have to see why the packing was set at 1.... It does
seem odd.

But at very least you got me past that one!

Thanks,