 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / November 2005VS7.1 to VS 8 : MSVCMRTD.lib(mstartup.obj) : LNK2022 : tagTEXTMETR
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, 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: [quoted text clipped - 4 lines] > (8013118D) : Inconsistent layout information in duplicated types > (tagTEXTMETRICA): (0x02000039). Are you sure that you have compiled with the same settings for CLR? (/clr:oldsyntax) ?  SignatureGreetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/ Yes. I replaced the /clr option in our common makefile with the new /clr:oldSyntax option. > Hi consultutah! > > I am trying to upgrade from VS7.1 to VS8, but whenever I link any of our MC++ [quoted text clipped - 8 lines] > Are you sure that you have compiled with the same settings for CLR? > (/clr:oldsyntax) ? "consultutah@nospam.nospam" >I am trying to upgrade from VS7.1 to VS8, but whenever I link any of our >MC++ [quoted text clipped - 4 lines] > 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 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@nospam.nospam" <consultutahnospamnospam@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 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.NativeCppClassAttribute :: 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.NativeCppClassAttribute :: 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, "consultutah@nospam.nospam" <consultutahnospamnospam@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 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, Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.