I've just moved over a Visual Studio (C++) solution over to another computer, setup all the directories and settings as far as I can see, and did a clean/rebuild on the solution. I get the error above on a bunch of .obj's on compile, not sure what to do about it.
It seems that you are mixing object files built with different settings. Try to do a full clean rebuild and check all project file settings to make sure that the _ITERATOR_DEBUG_LEVEL macro is the same (e.g., you are not mixing debug and release built objects).
In some cases, mixing the options in
Properties>Configuration Properties>C/C++>Code Generation>Runtime
Library
Between included Library(ies) and currently working project
can cause this problem.
Depending on usage set it as /MD or /MT or /MDd or /MTd uniformly across all projects.
Mixing binaries (object files) is one reason; another (which I encountered) is the false definition of the _DEBUG macro in the release build. _DEBUG is not a standard macro, but used by Microsoft.
After editing the .vcxproj-file in Emacs I mistyped _DEBUG instead of NDEBUG for the release, and encountered precisely the same build error.
I have been trying to solve this issue for five days. The Point Cloud Library (PCL) code builds successfully in debug mode but fails in release mode.
I have reconfigured my library several times but it didn't help. I found the problem was that the release version was inheriting _DEBUG so I unchecked it under project properties >> Preprocessor >> Processor Definitions and it was solved.
I found out (oddly) that _CRT_NON_CONFORMING_SWPRINTFS causes it. When I remove it, I don't get "_iterator_debug_level value '0' doesn't match value '2'" but instead the following warning:
Error 6 error C4996: '_swprintf': swprintf has been changed to conform with the ISO C standard, adding an extra character count parameter. To use traditional Microsoft swprintf, set _CRT_NON_CONFORMING_SWPRINTFS.
After trying to solve issue for several days in a debug version of my VS2019 project. Setting the Project >> Properties >> C/C++ >> Processor _HAS_ITERATOR_DEBUGGING=0 definition worked for me.
In my particular case, I encountered this error when using Conan with CMake while following their tutorial. When I generated the Visual Studio project, it built fine in Release mode but threw this error in Debug mode.
The solution was to generate a separate Visual Studio project with Debug libraries:
mkdir debug && cd debug
conan install --build=missing .. -s build_type=Debug
cmake ..
Can repeat the same in Release mode: change directory in line #1 and in line #2 use any one of ['None', 'Debug', 'Release', 'RelWithDebInfo', 'MinSizeRel']
Related
I've just moved over a Visual Studio (C++) solution over to another computer, setup all the directories and settings as far as I can see, and did a clean/rebuild on the solution. I get the error above on a bunch of .obj's on compile, not sure what to do about it.
It seems that you are mixing object files built with different settings. Try to do a full clean rebuild and check all project file settings to make sure that the _ITERATOR_DEBUG_LEVEL macro is the same (e.g., you are not mixing debug and release built objects).
In some cases, mixing the options in
Properties>Configuration Properties>C/C++>Code Generation>Runtime
Library
Between included Library(ies) and currently working project
can cause this problem.
Depending on usage set it as /MD or /MT or /MDd or /MTd uniformly across all projects.
Mixing binaries (object files) is one reason; another (which I encountered) is the false definition of the _DEBUG macro in the release build. _DEBUG is not a standard macro, but used by Microsoft.
After editing the .vcxproj-file in Emacs I mistyped _DEBUG instead of NDEBUG for the release, and encountered precisely the same build error.
I have been trying to solve this issue for five days. The Point Cloud Library (PCL) code builds successfully in debug mode but fails in release mode.
I have reconfigured my library several times but it didn't help. I found the problem was that the release version was inheriting _DEBUG so I unchecked it under project properties >> Preprocessor >> Processor Definitions and it was solved.
I found out (oddly) that _CRT_NON_CONFORMING_SWPRINTFS causes it. When I remove it, I don't get "_iterator_debug_level value '0' doesn't match value '2'" but instead the following warning:
Error 6 error C4996: '_swprintf': swprintf has been changed to conform with the ISO C standard, adding an extra character count parameter. To use traditional Microsoft swprintf, set _CRT_NON_CONFORMING_SWPRINTFS.
After trying to solve issue for several days in a debug version of my VS2019 project. Setting the Project >> Properties >> C/C++ >> Processor _HAS_ITERATOR_DEBUGGING=0 definition worked for me.
In my particular case, I encountered this error when using Conan with CMake while following their tutorial. When I generated the Visual Studio project, it built fine in Release mode but threw this error in Debug mode.
The solution was to generate a separate Visual Studio project with Debug libraries:
mkdir debug && cd debug
conan install --build=missing .. -s build_type=Debug
cmake ..
Can repeat the same in Release mode: change directory in line #1 and in line #2 use any one of ['None', 'Debug', 'Release', 'RelWithDebInfo', 'MinSizeRel']
I am trying to use the DirectXTex library for my project. I cloned it from GitHub and built it using the Visual Studio 2019 solution for desktop, with the exact same code generation settings as in my own project. It works fine for debug configurations, but when I build on release, an error message similar to this occurs:
_ITERATOR_DEBUG_LEVEL: Value 2 of (some DirectXTex .obj) is conflicting with value 0 of (my own .obj)
which goes along with this message:
Runtime library: MTd_StaticDebug of (some DirectXTex .obj) is conflicting with MT_StaticRelease of (my own .obj)
This is strange, because I set the runtime library of both projects to Multithreaded (/MT) for release and Multithreaded-Debug (/MTd) for debug. I have done some research and found this article that covers this exact problem, but none of those solutions work for me. I tried the following:
See if _DEBUG preprocessor is defined in release mode build of DirectXTex for some reason (it is not)
Try to set both project settings to Multithreaded-DLL
Checked if all code generation settings are really the same (debug and release)
Checked if I use the correct library build for debug and release
Made a clean new build in case my .obj files are older versions
None of these worked. But it compiles and works fine for release if I set the runtime library of my own project to Multithreaded-Debug for release mode aswell. This is obviously not an ideal solution.
What I also don't understand is that the DirectXTex library seems to build the release configuration of DirectXTex with MT_StaticDebug (at least the error message indicates that), although I explicitly set its runtime library to Multithreaded (/MT) for release. How can I fix this?
The DirectXTex_Desktop_2019.vcxproj in the GitHub repo is set to use /MDd for Debug and /MD for Release. Using the DLL-based Visual C++ runtime is recommended for numerous reasons over static CRT linking.
With that said, if you are using static linking, then you should verify that in each Platform/Configuration combination that they are set correctly as it seems like you don't have /MTd set in all of Debug configurations cases. For example, do you have both x86 and x64 platforms in your project?
I am new to CMake, and I want to set _ITERATOR_DEBUG_LEVEL to 0 for Release build, and 2 for Debug build, to fix issues when trying to compile a project that depends on other projects.
Error:
_iterator_debug_level value '2' doesn't match value '0' (this is for Release Win32 build, where the main project has the value disabled(0) and the project that it is dependent on has it enabled for some reason, somewhere)
I do not have a C/C++ properties section in the main project since it is a Utility project that depends heavily on CMake. Hence I need to fix this through CMake options only.
Can anyone point me to the way of setting visual studio option via CMake?
add_definitions(-D_ITERATOR_DEBUG_LEVEL=0)
in CMakeLists.txt seems to work
add_definitions is deprecated. Use add_compile_definitions to specify the iterator debug level in CMakeLists.txt.
add_compile_definitions($<$<CONFIG:Debug>:_ITERATOR_DEBUG_LEVEL=1>)
I'm building a DLL in C++ VS2010.
I've changed the value of the DEBUG TargetName by adding a "d", so that the definition of "TargetName" is now "$(ProjectName)d".
Everything builds just fine - all DEBUG build filenames have a postfixed "d" - this is so both debug & release files can live in one directory (this project is a tiny part of a HUGE set of projects).
However, when I press F7 with a DEBUG target, the project always builds. For example, lets say my project is called "MyProj". In RELEASE I'm generating "MyProj.dll" and all the other files (MyProj.lib/.exp/.pdb/...) - in DEBUG its "MyProjd.dll" etc. All these files look fine in their respective directories, but VS always builds in DEBUG on F7. In RELEASE, VS correctly determines that the project is up-to-date and does nothing.
So I enabled debug tracing in VS using <system.diagnostics> in devenv.exe.config to set CPS=4 and restarted VS. Using (sysinternals) DebugView I can see that the DEBUG rebuild is triggered because VS is checking for "MyProj.lib" & "MyProj.exp" rather than "MyProjd.lib" & "MyProjd.exp", i.e. its checking for the wrong files (which don't exist), so a build is always initiated.
Is this a known issue or is there some setting to get round this? Setting /IMPLIB does not help at all - this seems to be a problem in the "make" side of VS - the correct files are always built (if unnecessarily!) so this is an annoyance rather than a major issue...
Thanks
Nick
I've seen this behavior before as well. Not sure which is the required step, but I resolved by:
build -> "clean solution"
exit Visual Studio
delete the pre-compiled headers and output folders (think I deleted the .sdf as well)
rebuild everything
I'm using Visual Studio 2005 (32-bit) on a Windows XP system. I've got a C++ project that I build from the command line (in a batch file) that uses devenv.exe to launch the build. Here's an example of how it gets launched:
{path_to_devenv.exe} my_solution.sln /rebuild "Debug|Win32" /out my_logfile.txt
Within the code for this project, we use a few pragma statements to disable some extraneous warnings that we don't want to see:
#pragma warning ( disable : 4521 4522 )
// Some code here
#pragma warning ( default : 4521 4522 )
When the project is built in the debug configuration from the IDE, these warnings do not show up in the build output. When the same project is built from the command line, the warnings do show up in our log file (which we specified with the /out command line parameter). When building in release, the warnings do not show up in either case.
Is there something different about driving VS 2005 through devenv.exe that causes the pragma to be ignored in the debug case? Why should these warnings show up in one world and not the other?
Frankly the only reason I can see this happening is when the pragmas aren't seen.
Check
the build configuration (are you building Debug|Win32 from within the IDE too?)
and especially the include paths (are they the same; perhaps see whether the environment contains other settings)
are you doing a full rebuild from within the IDE? I wouldn't rule out that you usually don't see the warnings in the IDE, because you usually do an incremental build and the related sources don't need to be built. Check whether you get the same errors when doing a full rebuild in the IDE
If you are desperate for clues, you can always keep the result of preprocessing using both variants and compare them. The 'keep preprocessed source' option is hidden somewhere under the 'Preprocessor' C++ build settings.
Good luck