3

I've got a CLI code wrapping a C++ DLL.
When i try to compile it in debug mode, i get the following error:

Error 22 error LNK2022: metadata operation failed (8013118D) :

Inconsistent layout information induplicated types .... MSVCMRTD.lib (locale0_implib.obj)

The weird thing is that on Release mode it compiles OK and works OK.
The only difference i can see that causes the problem is when i change:

Configuration Properties -> C/C++ -> Code Generation -> Runtime Library

When it's set to: Multi-threaded Debug DLL (/MDd) it throws the error.
When it's set to: Multi-threaded DLL (/MD) it compiles fine.

The same settings work for all the other DLLs in the project (CLI and C++) and they inherit the same properties.

I'm using VS2010.

So, how can i solve this ?

And can I get some explanation to WHY this is happening ?

Update:

I've basically tried changing every option in the project's properties with no luck.

I've read somewhere that this might be caused from duplicate declarations of a type of the same name.
But in the CLI file i'm calling std::string etc. explicitly from std.

  • Renaming the objects didn't work

Any other ideas ?

Update:

A few error copy-pastes:

error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std._String_val<char,std::allocator<char> >): (0x02000097).  E:\MyProject....\MSVCMRTD.lib(locale0_implib.obj)   DllName


error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (std._String_iterator<char,std::char_traits<char>,std::allocator<char> >): (0x02000091).  E:\MyProject....\MSVCMRTD.lib(locale0_implib.obj)   AnotherDllName

Note that the MSVCMRTD.lib file is actually a MS file used for compilation and isn't actually in my project (nor should be)

Update

If you this helps, here's the linker command line:

/OUT:"E:\blah.CLI.dll" /INCREMENTAL /NOLOGO /LIBPATH:"e:\blah\Output\" /LIBPATH:"E:\blah\lib_64" /LIBPATH:"blah\Lib_64\" /DLL "e:\Otheblaf.lib" /MANIFEST /ManifestFile:"x64\Debug\blah.CLI.dll.intermediate.manifest" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"E:\blah.CLI.pdb" /SUBSYSTEM:WINDOWS /OPT:NOREF /OPT:NOICF /PGD:"E:\blah.CLI.pgd" /TLBID:1 /DYNAMICBASE:NO /FIXED:NO /MACHINE:X64 /ERRORREPORT:QUEUE

And the release that does work:

/OUT:"E:\blah.CLI.dll" /INCREMENTAL:NO /NOLOGO /LIBPATH:"E:\blah\" /LIBPATH:"E:\blah\Output\" /LIBPATH:"E:\blah\lib_64" /DLL "Configuration.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" "E:\blah.lib" /MANIFEST /ManifestFile:"blah.CLI.dll.intermediate.manifest" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"E:\blah.CLI.pdb" /SUBSYSTEM:WINDOWS /OPT:REF /OPT:ICF /PGD:"E:\blah.CLI.pgd" /LTCG /TLBID:1 /DYNAMICBASE /FIXED:NO /MACHINE:X64 /ERRORREPORT:QUEUE

Yochai Timmer
  • 48,127
  • 24
  • 147
  • 185
  • 3
    You've already asked this, *exact* same question. Surely you've discovered something else since then? – Hans Passant Jan 30 '11 at 09:47
  • Nope, there was no answer whatsoever, thought I'd resurface this. I haven't found a solution yet. (And "Just use /MD and it will compile") is not an answer. – Yochai Timmer Jan 30 '11 at 09:51
  • Does this answer help? http://stackoverflow.com/questions/810827/lnk2022-metadata-operation-failed-driving-me-insane/826679#826679 - I'm trying to work out where to start looking. – mcdave Feb 02 '11 at 05:25
  • I've tried removing the "Incremental Build" ... didn't work. thanks – Yochai Timmer Feb 02 '11 at 08:06
  • This ageing KB article gives some clues as to where the error comes from: http://support.microsoft.com/kb/324088. It'd be good to see your linker command line, as well as all compiler commands. – Reuben Scratton Feb 05 '11 at 23:47
  • I've tried renaming the classes (easy with refactoring) , didn't help. I'll add the linker command line when i get back to the office. – Yochai Timmer Feb 07 '11 at 12:57
  • 1
    Here is another SO post dealing with almost the same question: http://stackoverflow.com/questions/3909470/lnk2022-error-when-using-clr , perhaps the answers there will help you. – Doc Brown Mar 08 '11 at 12:20

6 Answers6

2

Are you using custom make-files or customized compiler paramterers when building the projects? This could screw with projects in unimaginable ways.

[a] It is possible that the pragma pack setting during the building of that DLL was set as custom compiler setting which caused the structures in windows standard headers to be packed incorrectly causing the mismatch in sizes. Easy to fix .. check for -Zp settings for cl.exe
This situation may solve cases where the structure is one of your own custom structures or classes.

http://msdn.microsoft.com/en-us/library/xh3e3fd0%28v=VS.71%29.aspx

[b] Another case where this can happen is when one of the header files is including windows standrd headers and the pragma pack hasn't been restored. This then propogates the incorrect pack info to the standard headers causing same problems as above. Generally easy to solve by including all (over simplified way tho) windows headers first so they get skipped later on.

Hope this helps.

Yochai Timmer
  • 48,127
  • 24
  • 147
  • 185
chkdsk
  • 1,187
  • 6
  • 20
  • Including the standard windows std header in the problematic CLI header file actually did work in one of my CLI projects. – Yochai Timmer May 02 '11 at 12:51
  • I was having this exact issue using the C++ libjson from a CLR project. Disabling JSON_LESS_MEMORY (which sets pragma pack) fixed it. Thanks! – A. Wilcox May 26 '12 at 05:31
1

Finally got a solution:

In the end it was a problem in boost::lexical_cast<std:string>

There's a bug with .Net object using certain std:: objects. (in my case std::string as is shown in the error message).

This is because when they created this framework, they've re-invented some classes (std::string is one of them) but didn't do it properly in the debug version.
The class's signature is a bit different.

MSDN Related Article - Ambiguous References

So, the solution is to "hide" buggy classes from the .NET object.

Create a C++ level wrapper class that will wrap the original class's functions and cast the buggy class types to other class types that compile correctly.

Make sure that in the wrapper class's header there's no references or includes to the buggy class type. (Can be done with careful Forward reference/decleration)
With VS2010 you can compile the unmanaged wrapper .cpp file explicitly without /clr.

Then you can use the wrapper class properly with the managed ref class.

Another option

replace lexical_cast<std::string> with:

ostringstream os;
os << i;
return os.str();
Yochai Timmer
  • 48,127
  • 24
  • 147
  • 185
0

I had this linking error when I converted my projects to 64 bit. My fix was Configuration Properties > C/C++ > Code Generation > Struct Member Alignment > 16 Bytes (/Zp16)

JayC
  • 39
  • 4
  • The OP (original poster) already found a solution in another spot. What does this add to the problem's understanding? How does it work with the given solution? When you re-open a discussion, you should provide the rationale and contrast. – Prune Nov 30 '15 at 22:49
  • That is dangerous. You're changing the alignment of all structures in the project. This means that any other project that links to that project need to compile in the same way. This would be very restrictive. – Yochai Timmer Dec 01 '15 at 08:36
-1

Make sure to clean up the build before compiling to debug mode.

Dan Paradox
  • 1,350
  • 1
  • 11
  • 14
-1

I hope this link will be helpful for you. In this MSDN has suggested to run 'ildasm –tokens' on the object files to find which types have the tokens listed in error_message, and look for differences.

Here are some inputs on ildasm exe.

user001
  • 444
  • 5
  • 10
-1

I found that the WINVER used in my project differed from the one used in the library I was linking to. Synchronizing these constants solved the problem for me.

JGeerWM
  • 810
  • 10
  • 16