LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (ATL.CRegObject)(0x020002ac)

LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (ATL.CRegObject)(0x020002ac)

• Gary Wang

  You shouldn't need to change the size. BTW: I'm not sure 40 bytes are accurate, I only calculated that myself looking at the source code.

  Anyway CRegObject is a polymorphic type (introduces a hidden virtual table table pointer = 4 bytes) has an CExpansionVector member (12 bytes) and a CComObjectThreadModel::AutoDeleteCriticalSection.

  The latter is a typedef for CComFakeCriticalSection or CComAutoDeleteCriticalSection depending on the global threading model, which is selected by the defines.

  CComFakeCriticalSection has no members and is therefore of size 1. Hence, CRegObject would have 4+12+1=17 bytes aligned to dword boundary = 20 bytes.

  CComAutoDeleteCriticalSection has a bool plus 6 dwords from RTL_CRITICAL_SECTION (total 25 bytes aligned to 4 bytes = 28), so that the total size is 4+12+28 = 44. (I missed the DebugInfo in my first calculation).

  Note the C++ standard does not require this layout for non-PODs. Bottom line, use the same class definition, i.e. make sure ATL global threading model is identical for all contributing translation units.

  -hg

  
  

• Insider

  Hi, you were right, when I repleaced the define _ATL_FREE_THREADED with the define ATL_APARTMENT_THREADED
  it worked.

  unfortunatelly if I'll need to change it back to _ATL_FREE_THREADED in the future , I still don't get how do I change CRegObject so it would be 40 bytes.

  thanks, Uri

  
  

• Jamie Carper

  I'll elaborate more so it would be more clear:

  vtsxml.lib is comprised of 2 obj files: vtsxml.obj and and enum.obj, the problematic type is defined in those files as follows: vtsxmlobj.il: TypeDef #683 (020002ac) // ------------------------------------------------------- // TypDefName: ATL.CRegObject (020002AC) // Flags : [NotPublic] [SequentialLayout] [Class] [Sealed] [AnsiClass] [BeforeFieldInit] (00100108) // Extends : 0100000B [TypeRef] System.ValueType // Layout : Packing:0, Size:20 // CustomAttribute #1 (0c000b2f) // ------------------------------------------------------- // CustomAttribute Type: 0a000001 // CustomAttributeName: Microsoft.VisualC.DebugInfoInPDBAttribute :: instance void .ctor() // Length: 4 // Value : 01 00 00 00 > < // ctor args: () // // CustomAttribute #2 (0c000b30) // ------------------------------------------------------- // CustomAttribute Type: 0a000004 // CustomAttributeName: System.Runtime.CompilerServices.NativeCppClassAttribute :: instance void .ctor() // Length: 4 // Value : 01 00 00 00 > < // ctor args: () // // CustomAttribute #3 (0c000b31) // ------------------------------------------------------- // CustomAttribute Type: 0a000003 // CustomAttributeName: Microsoft.VisualC.MiscellaneousBitsAttribute :: instance void .ctor(int32) // Length: 8 // Value : 01 00 40 00 00 00 00 00 > @ < // ctor args: (64) // enum.il: TypeDef #683 (020002ac) // ------------------------------------------------------- // TypDefName: ATL.CRegObject (020002AC) // Flags : [NotPublic] [SequentialLayout] [Class] [Sealed] [AnsiClass] [BeforeFieldInit] (00100108) // Extends : 0100000B [TypeRef] System.ValueType // Layout : Packing:0, Size:20 // CustomAttribute #1 (0c000b2f) // ------------------------------------------------------- // CustomAttribute Type: 0a000001 // CustomAttributeName: Microsoft.VisualC.DebugInfoInPDBAttribute :: instance void .ctor() // Length: 4 // Value : 01 00 00 00 > < // ctor args: () // // CustomAttribute #2 (0c000b30) // ------------------------------------------------------- // CustomAttribute Type: 0a000003 // CustomAttributeName: Microsoft.VisualC.MiscellaneousBitsAttribute :: instance void .ctor(int32) // Length: 8 // Value : 01 00 40 00 00 00 00 00 > @ < // ctor args: (64) // // CustomAttribute #3 (0c000b31) // ------------------------------------------------------- // CustomAttribute Type: 0a000004 // CustomAttributeName: System.Runtime.CompilerServices.NativeCppClassAttribute :: instance void .ctor() // Length: 4 // Value : 01 00 00 00 > < // ctor args: () configxml.lib is comprised of 3 obj files, the third one(stdafx.obj) can't be interpreted by the ildasm tool, I don't know why, the other 2 -their il's are defined as follows: tablexml.il: TypeDef #683 (020002ac) // ------------------------------------------------------- // TypDefName: ATL.CRegObject (020002AC) // Flags : [NotPublic] [SequentialLayout] [Class] [Sealed] [AnsiClass] [BeforeFieldInit] (00100108) // Extends : 0100000B [TypeRef] System.ValueType // Layout : Packing:0, Size:20 // CustomAttribute #1 (0c000b30) // ------------------------------------------------------- // CustomAttribute Type: 0a000001 // CustomAttributeName: Microsoft.VisualC.DebugInfoInPDBAttribute :: instance void .ctor() // Length: 4 // Value : 01 00 00 00 > < // ctor args: () // // CustomAttribute #2 (0c000b31) // ------------------------------------------------------- // CustomAttribute Type: 0a000003 // CustomAttributeName: Microsoft.VisualC.MiscellaneousBitsAttribute :: instance void .ctor(int32) // Length: 8 // Value : 01 00 40 00 00 00 00 00 > @ < // ctor args: (64) // // CustomAttribute #3 (0c000b32) // ------------------------------------------------------- // CustomAttribute Type: 0a000004 // CustomAttributeName: System.Runtime.CompilerServices.NativeCppClassAttribute :: instance void .ctor() // Length: 4 // Value : 01 00 00 00 > < // ctor args: () // strparse.il: TypeDef #683 (020002ac) // ------------------------------------------------------- // TypDefName: ATL.CRegObject (020002AC) // Flags : [NotPublic] [SequentialLayout] [Class] [Sealed] [AnsiClass] [BeforeFieldInit] (00100108) // Extends : 0100000B [TypeRef] System.ValueType // Layout : Packing:0, Size:20 // CustomAttribute #1 (0c000b2f) // ------------------------------------------------------- // CustomAttribute Type: 0a000003 // CustomAttributeName: Microsoft.VisualC.MiscellaneousBitsAttribute :: instance void .ctor(int32) // Length: 8 // Value : 01 00 40 00 00 00 00 00 > @ < // ctor args: (64) // // CustomAttribute #2 (0c000b30) // ------------------------------------------------------- // CustomAttribute Type: 0a000001 // CustomAttributeName: Microsoft.VisualC.DebugInfoInPDBAttribute :: instance void .ctor() // Length: 4 // Value : 01 00 00 00 > < // ctor args: () // // CustomAttribute #3 (0c000b31) // ------------------------------------------------------- // CustomAttribute Type: 0a000004 // CustomAttributeName: System.Runtime.CompilerServices.NativeCppClassAttribute :: instance void .ctor() // Length: 4 // Value : 01 00 00 00 > < // ctor args: () can somebody see why the compiler see differnces in this type(020002ac) , what obj files of those above the compiler fails to merge thanks ,

  
  

• Brian5003

  Re the object files, the diagnostic only list one file, right It tells you there's a conflict between the CLR TypeDef in that object file and one in another object file. It does not tell you however, which one is the other object file.

  When you link the final image (.DLL or .EXE but not .OBJ or .LIB) the linker merges the metadata definitions. Since the metadata you showed for the the libs look okay to me, I figured the offending object file comes from your main project (the one that creates the DLL). You should run ildasm on these (look in the intermediate directory of your project).

  For some additional background: the compiler creates managed code for your standard C++ source code, if possible. Managed code functions need signatures described by metadata. The compiler therefore creates value types for your native classes. Contrary to ordinary managed types, the C++ compiler lays out the members and bases in these. This information is not encoded (some things are not naturally representable in the CLR type system). However, size and alignment are, because this information is required so that the execution engine can provide the storage for local variables. You can see the alignment and size in the TypeDef metadata.

  If the linker complains about a mismatch, your original code probably had bugs already. /clr compilation just reveals these at build time. You shouldn't have incompatible definitions of the same class in your project. The easiest way to do this: make sure your build options are the same for all compilands contributing to the final image (this includes compilands in your libraries!).

  So in your project make sure the global ATL threading model is the same for your main project and the library projects.

  -hg

  
  

• stefandemetz

  I don't see any difference here. The tokens should be fixed up during linking. I guess, you're looking at the wrong file. There's probably another object file with another definition (maybe in your main project's .obj files)

  I suspect you build one of these with a multithreaded model.

  Do you define any of _ATL_SINGLE_THREADED, _ATL_APARTMENT_THREADED
  _ATL_FREE_THREADED If the latter, the size of ATL::CRegObject should 40 bytes.

  -hg
  

  
  

• DIII

   I guess, you're looking at the wrong file

  that's the file the compiler has indicated of.

   

  Do you define any of _ATL_SINGLE_THREADED, _ATL_APARTMENT_THREADED
  _ATL_FREE_THREADED

  the _ATL_FREE_THREADED is defined in my program.How do I check that it's size is 40 bytes

  
  
• LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (ATL.CRegObject)(0x020002ac)