VS 2015 has a new flag /Zc:threadSafeInit that directs the compiler to generate code to make function local statics thread safe. However, I am unable to get this directive to take effect in my IDE. If I set it as Additional Options in the compiler command line property sheet, I get the following warning during build:
1>cl : Command line warning D9025: overriding '/Zc:threadSafeInit' with '/Zc:threadSafeInit-'
I don't see any instance of the latter anywhere in my project property sheets or .vcxproj files.
Anybody can guess what is going on here? Is there a possibility /Zc:threadSafeInit is conflicting with some other compiler option?
Related
I am getting the warning message "cl : Command line warning D9035: option 'Gm' has been deprecated and will be removed in a future release" while building my project with Visual Studio 2017 latest update 15.9.2. How to resolve this warning?
Try selecting <inherit from parent or project defaults> for the Enable Minimal Rebuild option (under C/C++ > Code Generation). After this, the option should show No (/Gm-), not in bold. Make sure you do this for your project(s) (you could have several projects in the solution), and all property pages they inherit from.
I had the same problem using Visual Studio 2019, in the end the problem was in a second project I had in the same solution, that had the option set to Yes (/Gm).
According to the documentation
You may safely remove this option from your projects.
Project > Properties > Configuration Properties > C\C++ > Code Generation >
set the Enable Minimal Rebuild to no, and there is no warning.
Happened for me too. Did not manage to fix it through UI.
In the end I searched for "MinimalRebuild" in all project files and removed it manually - that helped
Properties > C\C++ > Code Generation > Enable Minimal Rebuild: DELETE value - and there is no warning.
UI did not work for me either. In the .vcxproj file search: "MinimalRebuild" I had missed a second one under Debug|Win32
just add this above your deprecated function
#pragma warning (disable : 4996);
example
#pragma warning (disable : 4996);
your_deprecated_function();
I'm creating a project with openframeworks (the full source is here: https://github.com/morphogencc/ofxAsio/tree/master/example-udpreceiver), and the empty project seems to compile fine.
I added the ASIO library, and a few header classes, and now the project seems to be give me the following error:
1>------ Build started: Project: example-udpreceiver, Configuration: Debug x64 ------
1> main.cpp
1>cl : Command line error D8049: cannot execute 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\c1xx.dll': command line is too long to fit in debug record
1>cl : Command line error D8040: error creating or communicating with child process
I couldn't find any examples of error D8049 on stackoverflow or even on Microsoft's pages, and google turned up painfully few results. The only remotely useful one was this github issue:
https://github.com/deplinenoise/tundra/issues/270
But I'm still not sure what's causing the problem. Is anyone familiar with this error, and can recommend a method for troubleshooting what's causing it?
thanks in advance!
For me, working with UE4, this was an intermittent error.
I added "bLegacyPublicIncludePaths = false;" to the innermost block of project.Build.cs and recompiled without errors.
Then I removed that line and compiled again w/o errors.
The error message suggested adding "DefaultBuildSettings = BuildSettingsVersion.V2;" to project.Target.cs which worked.
This is a bit of a weird sounding error, as it is from essentially internally generated data. However, you do have control over that. Taking the error message at face value, you probably have many/lots of defined symbols passed in on the command line (or the the ones you do have have lengthy definitions), or you may have some lengthy file paths.
If you look under the project properties, one of the selections under the C++ section is "Command Line", which will show you exactly what gets passed to the compiler. When you view that you can see where you have many or lengthy parameters, and then make changes to shorten them.
Too many defines? Put them in a header (possibly stdafx.h) and include them that way.
Long file paths? Shorten the paths, put the files somewhere else, or set up file system aliases to your real directories that use shorter paths.
I get the title's error (said to be in file "cl" line 1) but I got no idea of the meaning...
I imported the projet via the .pro file (I need to use visual studio and Qt, because I'm using CONDITION_VARIABLE and Qt only allows his own QWaitCondition. and using QWaitCondition is not an option for me).
The option /W is used to select a warning level for the compiler. But you also have to specify which level you want.
Sometimes VS autos/locals/watches break and instead of variables/values all I have is different kinds of:
CXX0029: Error: not struct pointer
CXX0033: Error: error in OMF type information
CXX0072: Error: type information missing or unknown
CXX0025: Error: operator needs class/struct/union
Rebuilding project, cleaning PDB/NCB etc doesn't solve it. What can I do?
Look at this Microsoft support note on: FIX: CXX0033 Error in OMF Type from Forward Class Declaration
Once you fix the PCH problem cited in the support note, I think all your errors will go away.
There is in fact a solution that lets you keep using precompiled headers: check out this more recent KB article and the documentation of the /Yl switch - which seems specifically tailored to this error.
Just add to the stdafx.cpp (or your own custom /Yc file) command line '/Ylxxxx', where xxxx stands for an arbitrary function name in your lib.
I recently faced symptoms identical to yours (in VS2010), and that solved it for me.
Are you trying to debug the "release" build? If so, many local variables will not exist as "debuggable" elements. You can get around this (if you must debug the release build) by debugging at the assembly level and look at the register values (vs. stack values, where auto/local would be in the debug build) and cast them appropriately in the "watch window".
Otherwise, build the Debug build and debug that build version. You'll get assertions where preconditions are not met, relevant/irrelevant stuff dumped to your output window, and more straight-forward debug single stepping.
It helped me to switch from using a program database (/ZI) to "c7 compatible" (/Z7). Switching off precompiled headers did not make a difference. Neither did rebuilding.
I can inhibit many warnings in Visual Studio 2005 SP1 in the C/C++ Advanced property page, which causes the IDE to use the /wd switch on the command line which invokes the compiler. However, when I try to inhibit warning 4200 (nonstandard extension used : zero-sized array in struct/union), it still appears when I compile. (Of course it's justified; I'm just not in a position to fix the code, nor would it be worth bothering, because it's generated, and the warning is entirely benign under the circumstances.) Does anybody happen to know if this is a bug in the compiler? Or might there be something I can do about it?
To completely disable the warning in the file you can add the following to the top of the file
#pragma warning(disable:2400)
If you want some more flexibility other than a blanket disable for the file, the following page lists several other more fine grained options.
http://msdn.microsoft.com/en-us/library/2c8f766e(VS.80).aspx
It's unclear based on your information as to whether or not it's a bug in the compiler or a configuration issue. I would lean towards a configuration issue, specifically conflicting compiler options that is making it difficult to suppress the warning.
EDIT
OP mentioned they can't control the generated code so they can't directly include the pragma. If that's the case then try this trick. Say the file name is Generated.cpp. No longer include Generated.cpp as one of the files to compile. Instead create a new file called Example.cpp with the following contents
#pragma warning(disable:2400)
#include "Generated.cpp"
Now you'll get the text of Generated.cpp with the disabled warning by only compiling Example.cpp.
You mean like with pragma?
#pragma warning( disable : 2400 )