We are using a library by another vendor, which apparently was compiled with the wrong flags, namely _ITERATOR_DEBUG_LEVEL = 0 in 32bit-Debug-mode. While I have already filed a bug report with them, I need an intermediate solution. We do not use stl ourselves, so I am free to change this flag for the subproject that uses said library. But I cannot figure out how to do so. What I tried an didn't work:
/D_ITERATOR_DEBUG_LEVEL=0
> LINK : warning LNK4044: unrecognized option '/D_ITERATOR_DEBUG_LEVEL=0'; ignored
#define _ITERATOR_DEBUG_LEVEL 0
> Nothing happens
What's the proper syntax or option to get the project to compile without checked iterators?
Found the solution.
Project Pages / Configuration Properties / C,C++ / Preprocessor / Preprocessor Definitions.
Add "_ITERATOR_DEBUG_LEVEL=0" in there worked.
Just as additional information :
Project Pages / Configuration Properties / C,C++ / Preprocessor / Preprocessor Definitions and set the preprocessor macro _ITERATOR_DEBUG_LEVEL to one of the following depending on the target :
_ITERATOR_DEBUG_LEVEL = 0 // disabled (for release builds)
_ITERATOR_DEBUG_LEVEL = 1 // enabled (if _SECURE_SCL is defined)
_ITERATOR_DEBUG_LEVEL = 2 // enabled (for debug builds)
Related
Lets say I have a solution S1 with two projects pdep and pmaster, respectively creating a static and dynamic library. I have the configurations:
release win32 : produces pdep.lib
debug win32 : produces pdepd.lib
release x64 : produces pdepx64.lib
debug x64 : produces pdepx64d.lib
pmaster link configuration is done by Configuration Properties -> Linker -> Input -> Additional Dependencies
No #pragma comment(lib ) in the code. No common properties references.
What I observe :
In s1 with both pdep and pmaster the command line for the linker is fine. ie /LIBPATH:"c:\pdep\lib\x64\Release" "pdepx64.lib"
In a solution S2 freshly created by clicking on the project pmaster, I always have an additional line with an absolute path to a specific version of pdep, regardless of the configuration. ie /LIBPATH:"c:\pdep\lib\x64\Release" "pdepx64.lib" "c:\pdep\lib\pdepd.lib"
How does the linker in S2 derives the additional option "c:\pdep\lib\pdepd.lib"? How do I get rid of it?
Multiple possibilities:
Common Properties -> References
Link Library Dependencies in Linker or Librarian section. This assumes that Project Dependencies have been setup.
#pragma comment(lib...) is playing some role
You can flatten the project file using msbuild with a preprocess flag. Then load that into a plain text or xml editor. Look at the linker command and see what $(properties) hold the options, and then look at where that is being set.
With msbuild you can also use more verbose logging and it will report which conditions are evaluated and such.
Some projects in my solution produce this linker warning:
MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
I'm using Visual Studio 2013 Update 3. I haven't yet been able to identify anything particular to those projects that could cause this.
What is it about those projects that produces this?
I've looked at this: http://msdn.microsoft.com/en-us/library/k669k83h.aspx
but I'm not aware we are using any CLR, managed code, /LN or /NOASSEMBLY.
I had the same problem, so I did some research.
According to https://msdn.microsoft.com/en-us/library/0zza0de8.aspx :
If you compile your program with /GL and /c, you should use the /LTCG
linker option to create the output file.
So the message can be a bit misleading - the problem is not the MSIL .netmodule, but modules compiled with /GL
When using /GL, you tell the compiler to delay the generation of some code namely around function bounderies, in order to optimise them. LTCG instruct the linker to generate (and optimise) the missing code. Otherwise, the program will not run as expected.
Basically, the two switches should be used together (when used). They apply to different parts of the build: one for compilation and the other one for link.
For completeness:
/GLis controlled from Configuration Properties > C/C++ > Optimization > Whole Program Optimization
/LTCG is controlled from Configuration Properties > Linker > Optimization > Whole Program Optimization
On later versions,
/LTCG is controlled from Configuration Properties > Linker > Optimization > Link Time Code Generation / Use Link Time Code Generation (/LTCG)
I have encountered the same error and spent quite a lot of time trying to fix it. Finally, I figured out that it appeared due to the use of "Whole Program Optimization" option in one of my dependency libraries.
By default, this option is set to "Yes" in newly created projects. When I changed it to "No" and recompiled all dependencies, the warning disappeared. I have purely native C++ solution without any managed code.
To fix, open project settings of all dependency projects and check setting:
Configuration Properties > C/C++ > Optimization > Whole Program Optimization
Make sure it is set to "No" everywhere.
I find the same error goes away by telling the linker about /GL setting you have used:
Set ...
Configuration Properties/Linker/Optimization/Link Time Code Generation
To ...
One of the non-Default settings
Maybe https://msdn.microsoft.com/en-us/library/xbf3tbeh.aspx is of some use?
Neil
This message shows a lot, which is really raising suspicion. I use a property sheet which tells both /GL and /LTCG. The project isn't using any external libraries. And I get this message, which doesn't make any sense. It disappears, if I go to the project properties and specify "Use Link Time Code Generation" again from there. It doesn't change the command line or anything, but just makes VC happy...
I just created a new cocoa project on Xcode 4.3.3. The preprocessor macros for the Apple LLVM compiler 3.1 settings have a DEBUG=1 $(inherited) value assigned. I removed it and add it again, and now I'm getting an error when compiling :
clang: error: no such file or directory: 'DEBUG=1'
I search for the value on the project settings and I saw that the value is also defined in "Other warning flags"
My questions are:
What is the difference between just having DEBUG vs DEBUG=1?
What does $(inherited) do?
What is it also doing on the other warning flags?
First, if you're getting a compilation error, then you most likely put the macro back in the incorrect place in the project settings. Please ensure you've put it into the Debug configuration branch of the Preprocessor Macros item under the Apple LLVM compiler x.x - Preprocessing section.
For your other questions:
The first version just defines the macro DEBUG so it's essentially empty. You can test for whether it exists or does not exist, but not much. The second sets it to 1 so that the preprocessor can actually do comparisons like #if DEBUG && SHOULD_DIE_ON_ERROR where you might abort if the application comes across some validation error, but only if SHOULD_DIE_ON_ERROR is set and 1 and you're running in debug mode.
The $(inherited) just brings in other macros you're inheriting from further up the chain. So if your project defines some items and your target defines some more, the target gets the project's settings as well without having to re-define them.
It shouldn't be effecting the warning flags at all. If anything, it determines code paths in header files you include (like the cocoa frameworks) which may use different implementations for things or may add debugging information to data structures, or whatever.
I have a third party project in my Xcode workspace (it's a dependency for my main project) and I want Xcode to ignore all build warnings from that third party project.
Preferably I'd like to ignore all build warnings for the Vendor/* group in my project since that's where I put all my third party code.
Possible?
Yes, it's possible, but only if you compile the third-party files in a separate target. This way, you can set different compiler flags.
Let's say your main target is an application. You defined your build settings, as well as the compiler warning flags.
Now you want to use some third-party sources. You import them into your project, but they generate warning. You could of course change your main target's settings, but I'm pretty sure you want to keep your own settings.
Simply create an additional target in your project, which is a static library.
Removes the third-party files from your main target, and add them to the library.
In your main target's build phases, link your application with the static library.
This way, you'll be able to use the third-party code in your application, while having different compiler settings for third-party code.
It is possible on a per file basis, see the blog entry at http://blog.bluelightninglabs.com/2011/12/suppressing-xcode-warnings-on-a-per-file-basis/
To summarize: Use the compiler flags on the “Build phases” tab.
Go to Build Phases > Compile Sources. Optionally filter the list. Select the ones you want to exclude and then double click in the blank area under the Compiler Flags column. Add -w and hit return:
if you are worried only about warning via inclusion, then you can wrap your include statements in this:
#pragma clang diagnostic push
// in reality, you will likely need to disable *more* than Wmultichar
#pragma clang diagnostic ignored "-Wmultichar"
#include <TheirLibrary/include.h>
#pragma clang diagnostic pop
if you also want to disable the build warnings it generates, then you can use -w or GCC_WARN_INHIBIT_ALL_WARNINGS = YES for the third party target which you link to or bundle.
ideally, you will file reports with the vendor if it is closed. if it is open, then maybe you should just patch it yourself.
I wonder, whether it is possible to suppress warnings coming from included library files, while showing all solution-file warnings in Visual Studio?
I have a solution that uses stingray library. When I build the solution I keep getting numerous warnings from stingray files, so I am loosing warnings from my files (that are actually in solution and that I own and edit). For me there is no value in included warnings, since I cannot edit those files, but I do need to see all my warnings.
Is there any way I could do it?
Added after first answer:
Sorry for being not clear - I am not building third party library - I am linking the libraries they provided, but I am including their headers in my own - as a results I have numerous warnings in "file included from..." - is there any way to sort that out?
--
Thanks in advance
#pragma warning(push ,3)
# include third-party h-files
#pragma warning(pop)
Another way:
#pragma warning(disable: 4507 4510)
# include third-party h-files
#pragma warning(default: 4507 4510)
Open your third party library's project properties, you can minimize your warning level in build tab.