On Feb 4, 2009, at 1:25 AM, Stephen Northcott wrote: I can only guess. If the option "Predictive Compilation" is checked, try without it. You'll find this option in Xcode Peferences -> Building pane.
I actually tracked it down to a class instance being created one way based on an .h file with some compiler #defines in it.
And the cpp having a different version of / ignoring those definitions. No idea how, but it presented repeatedly in XCode with the initial instance of the class when created having addresses offset by 4 bytes from those that the same class functions understood to be the case!
i.e. Some kind of #define bug IMO.
A Clean All will solve it, but the next incremental build it comes back.
Obviously it's not a bug throughout gcc / XCode as it would have been picked up before by others I am sure.
I think it has something to do with the size / organization of my project, or some kind of corruption somewhere.
Sorry to be late to this discussion, it's my unfortunate habit to sleep between 3am and 6am PST.
If you have a header file that is #included by two different source files, and you change it, and you rebuild, and one source file gets recompiled but the other does not, that a) will wreak havoc in your built application (as you've discovered) and b) would be considered a bug in Xcode.
But.
It does depend on the exact path of the header file, and how your project is finding/referring to it. Xcode and the gcc compiler do use slightly different rules for searching for files and for determining what to rebuild. You may have tripped into one of these cases, and it would be helpful for you to file a bug at http://bugreporter.apple.com with full details[1] of the issue.
One thing in specific that would make this expected behavior, and not a bug, is if the header file is placed in a location known to be used by system header files. To reduce disk access and speed up dependency checking, Xcode does not check the modification dates of system headers on each build. Because system headers generally don't change between OS/SDK installs, it's pretty wasteful to scan thousands of modification dates on every build just to find that things are the same as they've always been. So if your header file happens to be in, say. /usr/include, that would be a known cause of your difficulty.
There may be other causes, which is why we'd like to see a bug report.
Chris
[1] On the Fragility of Simplified Examples
When you simplify a problem for the sake of asking a question about it, human nature is to simplify it to the elements you understand and think ought to work. This generally means that you describe what's correct and omit what's incorrect. For example, you'll substitute a metasyntactic variable for the actual variable, thereby concealing the conflict with a reserved word. Or you'll imply that the problem happens in all configurations, when the real problem is that you changed a setting in one configuration but are actually using another.
Providing specific, complete, and thorough details of the problem gets faster and better solutions. In fact, the act of making a specific, complete, and thorough description of the problem usually helps you solve it yourself in the first place and makes you a better programmer. |