Re: macOS/GCC support policy

[Philipp Stephani]

Am Fr., 2. Aug. 2019 um 16:55 Uhr schrieb Philipp Stephani
<address@hidden>:
>
> Am Fr., 2. Aug. 2019 um 13:51 Uhr schrieb Eli Zaretskii <address@hidden>:
> >
> > > From: Philipp Stephani <address@hidden>
> > > Date: Fri, 2 Aug 2019 12:08:35 +0200
> > > Cc: Alan Third <address@hidden>, address@hidden,
> > >       Emacs developers <address@hidden>
> > >
> > > > What exactly prevents building with GCC on macOS?
> > > >
> > >
> > > I haven't investigated in detail, but when I try to run configure with
> > > GCC 9 from Homebrew, I get the error message
> > >
> > > checking AppKit/AppKit.h usability... no
> > > checking AppKit/AppKit.h presence... yes
> > > configure: WARNING: AppKit/AppKit.h: present but cannot be compiled
> > > configure: WARNING: AppKit/AppKit.h:     check for missing prerequisite 
> > > headers?
> > > configure: WARNING: AppKit/AppKit.h: see the Autoconf documentation
> > > configure: WARNING: AppKit/AppKit.h:     section "Present But Cannot
> > > Be Compiled"
> > > configure: WARNING: AppKit/AppKit.h: proceeding with the compiler's result
> > > configure: WARNING:     ## ------------------------------------ ##
> > > configure: WARNING:     ## Report this to address@hidden ##
> > > configure: WARNING:     ## ------------------------------------ ##
> > > checking for AppKit/AppKit.h... no
> > > configure: error: The include files (AppKit/AppKit.h etc) that
> > > are required for a Nextstep build are missing or cannot be compiled.
> > > Either fix this, or re-configure with the option '--without-ns'.
> >
> > Thanks.  It would be good if someone could investigate what is the
> > problem here (and any other problems, if there are any).
>
> Excerpt from config.log:
>
> configure:10941: checking AppKit/AppKit.h usability
> configure:10941: gcc-9 -c -g3 -O1 -fsanitize=address
> -fsanitize=undefined -fno-omit-frame-pointer -x objective-c     -x
> objective-c  conftest.c >&5
> In file included from
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/os/object.h:101,
>                  from
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/dispatch/dispatch.h:48,
>                  from
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:20,
>                  from
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:17,
>                  from
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:60,
>                  from
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6,
>                  from
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:10,
>                  from conftest.c:142:
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/objc/NSObject.h:22:4:
> error: unknown type name 'instancetype'
>    22 | - (instancetype)self;
>       |    ^~~~~~~~~~~~
>
> (lots of similar errors follow)
>
> This indicates that GCC treats the header as C instead of Objective C.
> Which is interesting because -x objective-c is given explicitly. Does
> GCC need some other flag to force compilation as Objective C?

The behavior difference is indeed trivial to reproduce:

p@p:/tmp$ cat appkit.c
#include <AppKit/AppKit.h>
p@p:/tmp$ clang -c -x objective-c appkit.c 2> /dev/null ; echo $?
0
p@p:/tmp$ gcc-9 -c -x objective-c appkit.c 2> /dev/null ; echo $?
1

Without the redirection GCC prints tons of similar errors.