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.

Reply via email to