LNK 2022: Inconsistent layout information, after migrating to VS2010

Question

I have a VS2010 solution that contains (among others), the following projects:

Native.DLL (native C++ project that statically links to a third party lib, ITK, which includes STL)

Pseudo-code (very simplified):

using namespace std;

bool Native::CalcSomething(double* result, string& errorMsg);

Wrapper.DLL (C++/CLI project that dynamically links to Native.DLL and uses std:string in a call to the Native.DLL)

Pseudo-code (very simplified)

bool Wrapper::WrappedCalcSomething([System::Runtime::InteropServices::OutAttribute] double[] result,[System::Runtime::InteropServices::OutAttribute] System::String^ errorMsg)
{
   Native* ntv = new Native();

   std:string error;
   pin_ptr<double> resultPtr = &result[0];

   bool success = ntv->CalcSomething(resultPtr, error);

   errorMsg = gcnew System::String(error.c_str());

   return success;
}

This compiled and linked perfectly in VS2008 (x64), but after migrating to VS2010 (for various reasons), the linker gives the following errors:

2>  Generating Code...
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std.logic_error): (0x02000049).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std.domain_error): (0x0200004a).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std.invalid_argument): (0x0200004b).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std.length_error): (0x0200004c).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std.out_of_range): (0x0200004d).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std.runtime_error): (0x0200004e).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std.overflow_error): (0x02000050).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std.underflow_error): (0x02000051).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std.range_error): (0x02000052).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std._Locinfo): (0x02000054).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (_Locimp): (0x02000059).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (failure): (0x02000068).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std._String_val<char,std::allocator<char> >): (0x02000097).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std._String_val<wchar_t,std::allocator<wchar_t> >): (0x02000099).
2>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (lconv): (0x020000ce).
2>LINK : fatal error LNK1255: link failed because of metadata errors

I have read almost every thread I could find on this issue and have tried:

Clean and rebuild
Move the headers around - there is no reference to windows.h and I have tried moving the #include line around to no effect
Using the /clr flag only on the files that need it in Wrapper.DLL (this happens to be all the files in the project). The problem is that the public method in Native.DLL that needs to be invoked by Wrapper.DLL includes a std:string parameter in its signature. This makes it difficult to separate the STL reference out from the scope of the /clr compilation
I am compiling everything (including ITK, the 3rd party lib) with /MDd (and have tried /MD) - changing this setting does not seem to affect things
I do not see /Zp or pragma pack being used anywhere

The only "solution" I can think of is to change the method in Native.DLL to not use std:string as a parameter (e.g. use char* instead). However, to avoid the use of STL in any C++/CLI wrappers hardly seems like a solution. There must be a better way!

Note: I am aware of the article on how to "debug" these issues (link), but unless I'm mistaken, I think I know the source of the issue is the std:string.

Yes, I rebuild both the native and wrapper projects whenever I try out a new "fix". — Kohanz, Apr 01 '13 at 15:02
How did you migrate the project? Just auto-converted from VS2008? — SomeWittyUsername, Apr 01 '13 at 15:03
We use CMake to generate our VS project and solution files. So I changed the CMake target to "Visual Studio 10 Win64" from "Visual Studio 9 Win 64". The solution file generated was usable without having to go through the conversion wizard. — Kohanz, Apr 01 '13 at 15:07
Well, I'd use divide and conquer here. Don't see a better way than manually creating a solution/projects and starting to add items into it and checking at each step whether it builds correctly — SomeWittyUsername, Apr 01 '13 at 15:10
BTW, check this out: http://stackoverflow.com/questions/11990095/lnk2022-metadata-operation-inconsistent-layout-information-in-duplicated-types — SomeWittyUsername, Apr 01 '13 at 15:11

score 4 · Accepted Answer · answered Apr 01 '13 at 15:58

I figured it out.

I had made a syntax change in one of the CMake files that I thought to be functionally identical to what was happening before (essentially I was using a CMake convenience variable). However, this of course had unintended consequences and the resulting project files were NOT the same.

Specifically, the Wrapper.DLL project was now linking to the 3rd party ITK libs that it did not need to link to at all (only the Native.DLL needs these).

After changing the CMake back and generating the project correctly, the dreaded LNK2022 went away. I only have myself to blame for all those hours wasted...

Ahh, looks like you figured it out anyway! – aardvarkk Apr 01 '13 at 16:01 — aardvarkk, Apr 01 '13 at 16:01

LNK 2022: Inconsistent layout information, after migrating to VS2010

1 Answers1

Linked