mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2'

Manu Evans picture Manu Evans · Feb 23, 2014 · Viewed 18.9k times · Source

Building with VS2010, I'm building a lib that causes many of these link errors:

error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2'

Resulting in a situation where I have to ship both a release and a debug version of my lib. I have no reason to ship a debug version of the lib, and it just bloats the binary distribution. But client code built in debug refuses to link against my release lib.

I've seen this question appear before, but they don't seem to be asking the right question. I understand what this error is, and why I'm getting it (well, sort of; I'm not sure precisely what emits the dependency. Do you?), but what I want to know is how to eliminate this dependency from occurring in my lib?

Similarly to libs which complain when conflicting CRT's are used, which can be prevented with /Zl (Omit default library name from object files), surely there's a way to prevent this dependency from being emitted into my libs too?

I simply want to produce a single optimised lib, which is capable of linking against either debug or release code. It's not important for client code to debug the lib. Almost no 3rd party libraries ship with distinct debug and release versions. How is it that vendors avoid this problem?

Does anyone know precisely what causes this link dependency, and how to I either disable it entirely, or factor it out of my code?

Answer

Hans Passant picture Hans Passant · Feb 23, 2014

You are linking some code that was compiled with debug build settings with iterator debugging enabled with some other code that was compiled with release build setting.

This link error stops you from blowing your leg off like that. Well, both legs, left arm and index finger of your right hand, you'll have to operate the mouse with your chin. The runtime errors you get from, say, std::string objects having a different layout are very hard to diagnose. Heap corruption is a nasty problem, about the worst to debug. You have to recompile the code with identical settings, no other way.