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
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 using VS 2017, .net Framework 7, stylecop 5.0. I imported it in '.csproj' file of all projects, so that stylecop builds automatically when the solution is built. It does show stylecop warnings when i built the solution.
When i right-click solution ->click "Run stylecop", I get more warnings than when I build normally.
Why doesn't it show when i build normally? Am I missing any commands?
I used this:
Import Project="..\packages\StyleCop.MSBuild.5.0.0\build\StyleCop.MSBuild.targets" Condition="Exists('..\packages\StyleCop.MSBuild.5.0.0\build\StyleCop.MSBuild.targets')"
This is often due to Visual Studio being considerate. It will only compile source files that have changed since the last build. Therefore only the Stylecop issues in those files are reported. When you run Stylecop specifically it will assess all c# source files.
Try doing a rebuild rather than build and see if the numbers add up.
Has anyone done this before ? I am not able to get it to work.
Following are my steps:
Download the windows package from link
I can run qfuzzylite (gui-tool) without any problem. Now I want to use the fuzzylite lib in my Visual Studio + Qt Integration Project.
In the CMake GUI I give fuzzylite source folder as the input folder and select Visual Studio 2010 as the compiler.
I am able to generate the Visual Studio fuzzylite solution in CMake without any errors.
Then, I tried to build the Visual Studio solution, but it fails with some weird errors. However, it does generate the fuzzylite-dbg.lib file (which I need).
Then I use this lib file and the fuzzylite.dll and include the path to the Headers in the VS Project. The project builds without any errors.
Now in the code I am doing
fl::Engine* engine = new fl::Engine("simple-dimmer");
This fails with the following exception:
exception text: bad allocation
exception type: class std::bad_alloc
Thank you for your detailed steps, but the solution seems to be a bit random (or weird as you put it). Unless more information is provided about the error, I strongly discourage the use of such a solution to attempt any fix to fuzzylite.
If you are running into problems, I strongly encourage you to report the problem in the forums at http://www.fuzzylite.com, where I and others will be very happy to help you.
As for the compiling errors, fuzzylite treats warnings as errors. A warning that is being raised in fuzzylite 4.0 when compiled using Visual Studio (not from console via nmake), and potentially in previous versions, is warning C4702, which refers to unreachable code. You can fix this by adding in file fl/fuzzylite.h the following line within the #ifdef FL_WINDOWS (together other #pragmas):
#pragma warning(disable:4702) //Ignore unreachable code
If the library was not built correctly, errors are bound to happen during runtime.
Ok, got it :)
Here are the steps for future reference:
Download the windows package from link
In the CMake GUI I give fuzzylite source folder as the input folder and select Visual Studio 2010 as the compiler. Now, if you want to use the lib in Debug mode tick the FL_DEBUG box (this is where I went wrong)
Now on clicking "generate", it will generate 5 projects:
ALL_BUILD
fl-bin
fl-shared
fl-static
INSTALL
ZERO_CHECK
Now in the Project properties in fl-bin, shared and static go to the Project Properties. In C/C++ go to Preprocessor get rid of the space in FL_DATA="mm.dd.yyyy " to "mm.dd.yyyy" (weird).
The solution should build fine and will generate fuzzylite-dbg.dll and fuzzylite-dbg.lib in the lib folder.
Use these files in your VC Project by adding the fuzzy-dbg.lib as the linker input and place the dll in the solution folder. Give the path "path\to\fuzzylite\fuzzylite." to the Include Directories.
Do the same process for Release mode (don't tick the FL_DEBUG flag)
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']
This is an incredibly basic question, but how do I start a new CUDA project in Visual Studio 2008? I have found tons and tons of documentation about CUDA related matters, but nothing about how to start a new project. I am working with Windows 7 x64 Visual Studio 2008 C++. I would really like to find some sort of really really basic Hello World app to just get a basic program compiling and running.
Edit:
I tried your steps Tom. I setup a console app. I then deleted the default .cpp it drops in and copied over the three files from the template project just to have something to compile. When I compile that, template_gold.cpp complained about not having stdafx.h included, so i included that. Now the build fails with this:
1>------ Build started: Project: CUDASandbox, Configuration: Debug x64 ------
1>Compiling...
1>template_gold.cpp
1>Linking...
1>LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol main referenced in function __tmainCRTStartup
1>D:\Stuff\Programming\Visual Studio 2008\Projects\CUDASandbox\x64\Debug\CUDASandbox.exe : fatal error LNK1120: 1 unresolved externals
1>Build log was saved at "file://d:\Stuff\Programming\Visual Studio 2008\Projects\CUDASandbox\CUDASandbox\x64\Debug\BuildLog.htm"
1>CUDASandbox - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
NOTE With the release of version 3.2 of the CUDA Toolkit, NVIDIA now includes the rules file with the Toolkit as opposed to the SDK. Therefore I've split this answer into two halves, use the correct instructions for your version of the Toolkit.
NOTE These instructions are valid for Visual Studio 2005 and 2008. For Visual Studio 2010 see this answer.
CUDA TOOLKIT 3.2 and later
I recommend using the NvCudaRuntimeApi.rules file (or NvCudaDriverApi.rules if using the driver API) provided by NVIDIA, this is released with the toolkit and supports the latest compiler flags in a friendly manner. Personally I would advise against using the VS wizard, but only because I really don't think you need it.
The rules file (installed into the Program Files\Microsoft Visual Studio 9.0\VC\VCProjectDefaults directory) "teaches" Visual Studio how to compile and link any .cu files in your project into your application.
Create a new project using the standard MS wizards (e.g. an empty console project)
Implement your host (serial) code in .c or .cpp files
Implement your wrappers and kernels in .cu files
Add the NvCudaRuntimeApi.rules (right click on the project, Custom Build Rules, tick the relevant box), see note 1
Add the CUDA runtime library (right click on the project and choose Properties, then in Linker -> General add $(CUDA_PATH)\lib\$(PlatformName) to the Additional Library Directories and in Linker -> Input add cudart.lib to the Additional Dependencies), see notes [2] and [3]
Optionally add the CUDA include files to the search path, required if you include any CUDA files in your .cpp files (as opposed to .cu files) (right click on the project and choose Properties, then in C/C++ -> General add $(CUDA_PATH)\include to the Additional Include Directories), see note [3]
Then just build your project and the .cu files will be compiled to .obj and added to the link automatically
Some other tips:
Change the code generation to use statically loaded C runtime to match the CUDA runtime; right click on the project and choose Properties, then in C/C++ -> Code Generation change the Runtime Library to /MT (or /MTd for debug, in which case you will need to mirror this in Runtime API -> Host -> Runtime Library), see note [4]
Enable syntax highlighting using the usertype.dat file included with the SDK, see the readme.txt in <sdk_install_dir>\C\doc\syntax_highlighting\visual_studio_8
I'd also recommend enabling Intellisense support with the following registry entry (replace 9.0 with 8.0 for VS2005 instead of VS2008):
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\Languages\Language Services\C/C++]
"NCB Default C/C++ Extensions"=".cpp;.cxx;.c;.cc;.h;.hh;.hxx;.hpp;.inl;.tlh;.tli;.cu;.cuh;.cl"
Incidentally I would advocate avoiding cutil if possible, instead roll your own checking. Cutil is not supported by NVIDIA, it's just used to try to keep the examples in the SDK focussed on the actual program and algorithm design and avoid repeating the same things in every example (e.g. command line parsing). If you write your own then you will have much better control and will know what is happening. For example, the cutilSafeCall wrapper calls exit() if the function fails - a real application (as opposed to a sample) should probably handle the failure more elegantly!
CUDA TOOLKIT 3.1 and earlier
I would use the Cuda.rules file provided by NVIDIA with the SDK, this is released alongside the toolkit and supports the latest compiler flags in a friendly manner. Personally I would advise against using the VS wizard, but only because I really don't think you need it.
The rules file (in the C\common directory of the SDK) "teaches" Visual Studio how to compile and link any .cu files in your project into your application.
Create a new project using the standard MS wizards (e.g. an empty console project)
Implement your host (serial) code in .c or .cpp files
Implement your wrappers and kernels in .cu files
Add the Cuda.rules (right click on the project, Custom Build Rules, browse for the rules file and ensure it is ticked)
Add the CUDA runtime library (right click on the project and choose Properties, then in Linker -> General add $(CUDA_LIB_PATH) to the Additional Library Directories and in Linker -> Input add cudart.lib to the Additional Dependencies), see note [2] below
Optionally add the CUDA include files to the search path, required if you include any CUDA files in your .cpp files (as opposed to .cu files) (right click on the project and choose Properties, then in C/C++ -> General add $(CUDA_INC_PATH) to the Additional Include Directories)
Then just build your project and the .cu files will be compiled to .obj and added to the link automatically
Some other tips:
Change the code generation to use statically loaded C runtime to match the CUDA runtime, right click on the project and choose Properties, then in C/C++ -> Code Generation change the Runtime Library to /MT (or /MTd for debug, in which case you will need to mirror this in CUDA Build Rule -> Hybrid CUDA/C++ Options), see note [4]
Enable syntax highlighting using the usertype.dat file included with the SDK, see the readme.txt in <sdk_install_dir>\C\doc\syntax_highlighting\visual_studio_8
I'd also recommend enabling Intellisense support with the following registry entry (replace 9.0 with 8.0 for VS2005 instead of VS2008):
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\Languages\Language Services\C/C++]
"NCB Default C/C++ Extensions"=".cpp;.cxx;.c;.cc;.h;.hh;.hxx;.hpp;.inl;.tlh;.tli;.cu;.cuh;.cl"
Incidentally I would advocate avoiding cutil if possible, instead roll your own checking. Cutil is not supported by NVIDIA, it's just used to try to keep the examples in the SDK focussed on the actual program and algorithm design and avoid repeating the same things in every example (e.g. command line parsing). If you write your own then you will have much better control and will know what is happening. For example, the cutilSafeCall wrapper calls exit() if the function fails - a real application (as opposed to a sample) should probably handle the failure more elegantly!
NOTE
You can also use a Toolkit-version-specific rules fule e.g. NvCudaRuntimeApi.v3.2.rules. This means that instead of looking for the CUDA Toolkit in %CUDA_PATH% it will look in %CUDA_PATH_V3_2%, which in turn means that you can have multiple versions of the CUDA Toolkit installed on your system and different projects can target different versions. See also note [3].
The rules file cannot modify the C/C++ compilation and linker settings, since it is simply adding compilation settings for the CUDA code. Therefore you need to do this step manually. Remember to do it for all configurations!
If you want to stabilise on a specific CUDA Toolkit version then you should replace CUDA_PATH with CUDA_PATH_V3_2. See also note 1.
Having mismatched version of the C runtime can cause a variety of problems; in particular if you have any errors regarding LIBCMT (e.g. LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs) or multiply defined symbols for standard library functions, then this should be your first suspect.
What a great question!! For all the CUDA documentation out there, this is something that I've always thought was an obvious omission... In fact, I'm really glad I found this post, because after using CUDA for quite a while, I still hadn't found an official, correct way to get VS to produce a CUDA program from scratch.
When I've needed to start a new CUDA program, I've always just copied and modified the "template" example from the SDK directory. This may not be exactly what you're looking for, because it doesn't start fresh, but it is a quick way to get a CUDA-capable project working in VS with all the correct project/file names...
Make a copy of the "template" example from the SDK, and rename the directory -- the only necessary contents in the directory are source code and VS .sln and .vcproj files
Rename both .sln and .vcproj files
Open the .sln file in a text editor, and rename the Project variable and .vcproj filename in the 3rd line of the file
Open the .vcproj file in a text editor, and rename the Name and RootNamespace variables in the first few lines of the file
Open the project with VS, and open the Property Pages (right click on the project name in the solution explorer pane, select "Properties")
Change the Output File name in the Property Pages (under Configuration Properties -> Linker -> General) ... Before I change the filename, I select "All Configurations" from the Configuration pull-down and "x64" from the Platform pull-down, since I'm on a 64-bit system
Change the Program Database File name in the Property Pages (under Configuration Properties -> Linker -> Debugging) ... Before I change the filename, I select "Debug" and "x64" in the pull-downs.
Install CUDA VS wizard. It will setup VS and add CUDA Project to the "new project" menu.
Make sure that you have x64 compiler installed (must be checked during VS install).
Check if you have x64 libs, includes, nvcc dir and in the search path.
Create new project using CUDA template.
Change project type to x64 and CUDA setting to Native (if you have nv cuda-enabled card) or emulation otherwise.
The template will create custom build rules that compile .cu files with nvcc and other files with default compiler.
if, vs is trying to compile .cu files with C/C++ compiler, click on that file in solution explorer and disable compilation for that files (red dot on file's icon)
Additional info about installing CUDA wizard on VS2008 can be found here and here
[edit]
If you don't want to use wizard you have to setup CUDA lib/include/nvcc paths manually and add custom build rules to each new CUDA program. For additional info how to do it take a look at Tom's Answer.
You may want to take a look at this guide: http://www.programmerfish.com/how-to-run-cuda-on-visual-studio-2008-vs08/