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 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?
Is it possible to set certain header files to be compiled under "Release" mode in Visual Studio with CMake?
Scenario:
The entire project is set up with CMake (not generating proj/sln files, pointing directly at the project's directory)
We are bringing in a header-only dependency via CMake that runs quite fast when ran in Release mode, however, it does not run as fast when ran in debug mode.
Is it possible to set this dependency to build in release mode while the rest of the application runs in Debug mode? If this is not possible are there any work arounds?
For reference I am using Visual Studio 2019 Community 16.1.6
Well, header files are not compiled, only included.
So to disable a header in debug build, the DEBUG macro should be enough:
#ifdef DEBUG
#include "problematic_header.h"
#endif
Of course, you'll also have to disable any functionality using declarations from this header.
(Posting comment to answer the question)
For anyone else that may stumble upon this, Richard is 100% right about header files not being compiled, however, i was able to get the speed I was looking for an still use the debugger by switching "Configuration Type" to "RelWithDebInfo" under CMakeSettings.json.
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'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']