16

I'm having a new-to-me linker error in a project I'm working with:

1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std.basic_string<char,std::char_traits<char>,std::allocator<char> >): (0x0200004e).
1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std.basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >): (0x02000075).
1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std._String_iterator<char,std::char_traits<char>,std::allocator<char> >): (0x02000091).
1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std._String_const_iterator<char,std::char_traits<char>,std::allocator<char> >): (0x02000092).
1>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).
1>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).

We're using Visual Studio 2010 in Windows 7.

This project used to compile. It's a C++/CLI DLL wrapper around some unmanaged code, and thus includes Common Language Runtime Support. The thing that has changed is that an external static library that we linked to was "updated". We're now getting this error when we try to compile the project that links to it.

Microsoft's "help" for this issue is to "run ildasm –tokens on the object files to find which types have the tokens listed in error_message, and look for differences". Then I checked this page and noticed that the /tokens option is only valid for .exe and .dll files... but this is a linker error, so my .dll file isn't made yet!

I've tried running things like ildasm -tokens AssemblyInfo.obj, but the only thing that happens is that a window opens up with this incredibly helpful error message:

Thanks Microsoft

Thanks Microsoft!

I'm not really sure how to continue troubleshooting this issue. A Release build works properly -- it's only the Debug that's messed up. So somewhere in the mix I guess the std::string type is of a different size or something...

Any ideas?

aardvarkk
  • 14,955
  • 7
  • 67
  • 96
  • 4
    I sometimes get this error when I change a header file, and the compiler doesn't recompile all the code files it should. You probably already did this, but a Clean and Full Rebuild might help. – David Yaw Aug 16 '12 at 15:16
  • @DavidYaw Thanks for the recommendation -- I've been doing full rebuilds with no success. I think I'm on the trail of something here though... – aardvarkk Aug 16 '12 at 15:29

3 Answers3

17

Alright, so I solved it! There was another SO question that was actually a big help. It ended up linking to this article, which had a bit more detail about the problem. Basically it's some issue with the standard library strings getting compiled in both managed and unmanaged code. The solution was to only enable the CLR on files which required it. In detail, here's what I did:

  1. Removed the /clr switch which applied to the whole project
  2. Selected the two .cpp files that actually required the CLR, and manually selected /clr under C/C++ -> General -> Common Language RunTime Support.
  3. Switched the whole project to Program Database /Zi from Program Database for Edit and Continue /ZI. This got rid of warnings, because I think /clr support appeared to disable incremental linking, and then my native code was throwing warnings because it was trying to use Edit and Continue.
  4. I then got some ExtensionAttribute warnings, which I fixed by adding the following switches to my /clr-enabled files: /clr:nostdlib /AI"%ProgramFiles%\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
  5. In Debug builds, I had to disable a bunch of debug options on the /clr-enabled files. Specifically, under C/C++ -> Code Generation, I set Enable Minimal Rebuild to No (/RM-), and Basic Runtime Checks to Default. This got rid of a bunch of warnings also.
  6. In Debug and Release builds, set Enable C++ Exceptions to No on the clr-enabled files.

Hope this helps!

aardvarkk
  • 14,955
  • 7
  • 67
  • 96
  • I'm having the same problem, but in my case the reference to needs to be in the managed file as well (unless we change our API). Is there any other way around the issue? – Kohanz Apr 01 '13 at 12:31
  • 1
    The only thing I could recommend is trying to somehow split up your managed/unmanaged code through the use of a dynamically linked library, perhaps? This happened to work for me, but I'm not sure how well it generalizes... – aardvarkk Apr 01 '13 at 16:00
  • I was doing this already (but it's a good tip nonetheless). As you saw, I was mistakenly linking the managed library to unneeded unmanaged libraries, needlessly causing the LNK2022. – Kohanz Apr 01 '13 at 17:17
  • It is also caused by discrepancies between included `#defines` like `WINVER` or `_WIN32_WINNT` – JB. Mar 24 '15 at 15:32
  • I did the reverse, where I deactivated /clr only for the .cpp files that did not need it. – Matthew Grivich Feb 25 '19 at 23:25
  • 1
    @JohnGrabanski Removed the dead link... a bit late. – aardvarkk Feb 26 '19 at 17:56
  • I found that in my case it was as simple as turning off CLR for two files I had just added to the project and doing a rebuild. – Pete Magsig Dec 14 '21 at 23:08
2

Seems like my Visual Studio was in some broken state. I was the only one getting that error. I had no changes. I recheck out the project on the side and it was fixed. Maybe it was a problem with my user files.

Rubarb
  • 85
  • 2
  • In my case I had just upgraded the .vcxproj to VS2015 after having previously built it in VS2013. Clean -> Rebuild fixed it. – Overlord Zurg Jul 08 '16 at 18:13
2

The fix for me was to set Configuration Properties -> C/C++ -> Code Generation -> Struct Member Alignment -> 16 Bytes (/Zp16)

JayC
  • 39
  • 4
  • this solution solved a similar problem by me, namely the Inconsistent field declarations in duplicated types – Aak Sep 01 '17 at 11:12