[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: master b99ec5d 3/3: Work around __has_attribute bug in clang 3.4
Date: Sat, 23 Jan 2021 11:42:28 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]