https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651
--- Comment #21 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Eric Gallager from comment #20) > (In reply to Dominique d'Humieres from comment #18) > > For the record with darwin15 I had to add > > > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/ > > NSEnumerator.h > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h > > > > from the 10.9 SDK to > > > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h > > /usr/include/objc/NSObject.h > > that seems dangerous Not so dangerous as it seems. Many (most, in fact) of the failures seen from GCC Objective-C are caused by missing support for new features that have been introduced into the vendor's headers. Short list: Apple Blocks, Lightweight Generics, Nullability, Syntactic sugar on ID. I'm working on a set of replacement test-suite headers that allow us to test the things that _do_ work on GCC Objective-C, and expose any real regressions. Tests on Darwin13 and earlier show that we are not in such bad shape as the header fails make it appear. I hope to get these test fixes (there's a set of three PRs related to excess fails on Yosemite+) in place soon - and to back port them to the open branches.