_ITERATOR_DEBUG_LEVEL error in visual studio

I am trying to compile JRTPLIB in Visual Studio 2010 on windows 7. It's been a true n开发者_如何学Pythonightmare... but I'm atleast narrowing down the problems.

This is left.

Error   3   error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in client.obj   C:\Users\Johan-bar\Documents\Visual Studio 2010\Projects\client\client\jrtplib.lib(rtpsession.obj)  client

I googled a ton and the cause seems to be one is compiled in debug mode while the other is compiled in release mode.

I am aiming to compile a Release executable because I want to test on different computers.

1) Which one is not in Release mode, JRTPLIB or client(mine, the one which is trying to compile)?

2) How does one change the ITERATOR_DEBUG_LEVEL? Both are using Runtime Library /MT and preprocessor definitions WIN32, _MT, along with the defaults I guess.

Cheers

Compile everything you use with -D_ITERATOR_DEBUG_LEVEL=0 option. It is so by default in VS 2010 Release mode, but some things are still built with other options and so are not binary compatible.

In older visual studios there was _SECURE_SCL and i am not sure if some of code may still use it. Put somewhere (say into stdafx.h) a static check that these match.

#if _ITERATOR_DEBUG_LEVEL == 0 && _SECURE_SCL != 0 
#error _SECURE_SCL != 0 when _ITERATOR_DEBUG_LEVEL == 0 
#endif 

If you want to see what value _ITERATOR_DEBUG_LEVEL has then you can use some #pragma message in code to tell you.

The solution:

Project Pages >> Configuration Properties >> C,C++ >> Preprocessor >> Preprocessor Definitions

Add _ITERATOR_DEBUG_LEVEL=0 in there worked. See also: How to set _ITERATOR_DEBUG_LEVEL in VS2010?

I found another way to generate these errors.

I was using the Visual Studio 2010 batch build to build all possible combinations of platform and configuration and I was getting these errors. Looking at the output revealed that batch build was not honoring the project dependencies -- hence linking a stale library from the Release build witha freshly compiled Debug obj file.

Several lines later in the build output it built the Debug version of the library.

Doing the "batch build" by hand (i.e. manually selecting the various combinations of platform and configuration) produced a clean build.

Moral: Do not use Visual Studio 2010 batch build. I don't know if they've fixed this in later versions of VS.