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.
Related
My Xcode project has different build configurations, and they define different preprocessor macros. Autocomplete doesn't work in #ifdef blocks that are ignored by the current preprocessor flags, so I want to control which build configuration Xcode uses for autocomplete. How does Xcode decide?
After some experimenting, here's what the rules appear to be (on Xcode 13.0 beta 13A5155e):
If a configuration named Debug exists, it is used.
Otherwise, the configuration in the "Use for command line builds" menu is used.
Interestingly this entirely ignores the configuration(s) selected in the current scheme. Autocomplete still works if you delete every scheme.
When building a static library which contains duplicate definition of a function, MSVC++ 2013 gives me just a warning:
LNK4006 "... already defined in ... second definition ignored"?
I'm afraid that a warning is too easy to miss. Is it possible to make MSVC++ 2013 to report an error and fail the build if multiple definitions for the same function is found (in different .cpp files)?
Note that the reverse of the solution suggested here (i.e. Project Settings > linker > uncheck 'Force file output') is not applicable because that's for an executable, but in this question a static library is in focus thus no "linker" project option.
There doesn't seem to be a way to treat specific warnings as errors. You can however treat every linker warning as error:
Go to: Project Properties -> Linker -> General -> Treat Linker Warnings As Errors and switch it to Yes (/WX).
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...
In XCode 4.5, my preprocessor macro gets ignored when defined at target level, but honored if defined at project level. It's a simple symbol definition (RESTKIT_GENERATE_SEED_DB) to be used in #ifdef. Using "levels" display, XCode shows my symbol in the resolved section. Also, I have double-checked that my current scheme is running the Debug config where macro is defined.
This was a newbie mistake. The setup was that I had two targets, one with the macro defined and one without. The reason the macro was not picked up at target level was that I never ran that target. I thought that you ran it by selecting the target in the target list under TARGETS. I realize now that in order to run a target you must select it the scheme menu next to where you select the device target.
Here's a different one from the usual confusion over duplicate symbol errors... :-)
I'm working on some legacy Mac code in an Xcode project that has the same global, "trace", defined in several different source files - for instance:
File1.c: SInt32 trace;
File2.c: Boolean trace;
etc. It's clear the original author meant them to have file-specific scope, but just neglected to prefix any of these lines with "static". That's fine, easy enough to fix.
But I'm kind of shocked the linker isn't flagging these! It looks to me like Xcode's linker (I presume gnu ld) only emits duplicate symbol warnings or errors for functions, that are linked into the code segment - but not global variables that are linked into the data segment. Instead, it silently conflates them, which is causing bugs.
So... how do I convince Xcode to emit link errors for duplicate global variables? Or get this information in some other way that can be a routine part of my build?
Well, I thought I'd answered my own question... :-)
I posted earlier:
So if you're using Xcode with LLVM GCC
4.2, go to the build settings dialog, find the "LLVM GCC 4.2 - Code
Generation" section, and check the "No
Common Blocks" checkbox. This enables
the compiler's "-fno-common" option,
and changes the object file generation
so that ld will choke and emit an
error if you have two globals in
different source files with the same
name.
Unfortunately, that doesn't seem to solve all instances. It seems to work fine if all the globals have the same type.
But the example in the question is taken straight from the code, where a variable named "trace" is defined as a global in two different files with two different types. And that's still not caught by the build system when I check that checkbox.