Re: master b99ec5d 3/3: Work around __has_attribute bug in clang 3.4

[Paul Eggert]

On 1/23/21 2:11 AM, Mattias Engdegård wrote:
> 23 jan. 2021 kl. 01.46 skrev Paul Eggert <eggert@cs.ucla.edu>:
>
> > Perhaps someone who can build on macOS directly can provide more info about the 
> > problem. I had no problem building with clang 11.0 on Ubuntu but Apple's clang 
> > is special.
>
> Apple's clang seems to come with a builtin
>
> #define __nonnull _Nonnull
>
> which clashes with the the one in lib/cdefs.h. Perhaps we should call it 
> something else.

Thanks for the diagnosis. Although calling it something else would 
obviously work, it would require renaming __nonnull everywhere within 
Gnulib (and eventually Glibc), and that would be entirely contrary to 
the intent of the Apple macro - which was to encourage compatibility 
with GNU code. As I understand things Apple's __nonnull keyword used to 
mean something else but collided with GNU's __nonnull macro, so they 
renamed the keyword and put in a backward-compatibility macro for old 
Applish code, but we don't need that macro and can just use __nonnull 
for our own use.

I attempted to fix the problem by installing the attached patch into 
Gnulib, and then merged Gnulib into Emacs master. Please give it a try, 
as I don't use macOS and so did not check the patch directly.

Phillip is correct in theory that Gnulib (application code) should avoid 
messing with reserved identifiers, but theory doesn't exactly equal 
practice here because we also want to minimize differences between 
Gnulib and Glibc.

0001-libc-config-port-to-Xcode-7.patch
Description: Text Data