LNK2022 and LNK2034 linker errors with version 10.0 of the CRT

Question

Sorry to bother anyone with this question, but I've been researching this for hours, with no resolution yet:

I am porting a rather massive application to the 10.0 CRT (compiler) in Visual Studio 2010. The app is managed C++/CLI that uses /clr. Most of the code is native (95%), with a few managed portions here and there in it.

So my job is to make the switch in the .vcxproj to target the newer 10.0 CRT (i.e. compiler). We were previously using v90, or using the VC compiler that came with VS 2008 SP1.

Ok, so breaking changes? Seems like a bunch actually. I fixed a few iterator issues dealing with sets, which all was all pretty easy.

But these linker errors are killing me. Any help would be appreciated:

1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0001c0).
1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0001c5).
...

1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2034: metadata inconsistent with COFF symbol table: symbol '??0?$allocator@D@std@@$$FQAE@ABV01@@Z' (06000141) has inconsistent metadata with (0A000F75) in identity.obj
1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2034: metadata inconsistent with COFF symbol table: symbol '??0?$allocator@D@std@@$$FQAE@ABV01@@Z' (06000141) has inconsistent metadata with (0A000F76) in ICustAttribCollapseManagerImp.obj
... (repeated hundreds of times)

I went ahead and undecorated the symbol:

??0?$allocator@D@std@@$$FQAE@ABV01@@Z

and got:

public: __thiscall std::allocator<char>::allocator<char>(class std::allocator<char> const &)

So, as I understand it, the msvcmrtd.lib file has this std::allocator compiled one way, and something else in my project settings (#pragma managed ??) is compiled another, different way. But if so, what do I look for? This has been compiling fine for years using the old compilers.

Note: We currently the 3.5 .NET framework (Not sure if that helps or not... I doubt it)

Thanks

Answer 1

This is a hard to diagnose problem, the linker errors stink and are poorly documented. There's a post from Stephan Lavavej, the STL maintainer at Microsoft about it in this thread, bottom of the page. I have to say I don't see much of any advice in it, beyond trying to disable iterator debugging in your project settings (_HAS_ITERATOR_DEBUGGING = 0 in the preprocessor definitons).

You do need to consider a code review. It sure looks like you are compiling STL code into managed code. That works in general (minus the linker hassle) but it is really the wrong thing to do. Leave the STL collection classes to your native code, use the BCL collection classes (List<> etc) in your managed code.