bug#26398: GNU LIB build fails on macOS 10.12.4

[Paul Eggert]

Zack Weinberg wrote:

> This patch is incomplete.

Yes, it was the Emacs patch, not the Gnulib patch. I'll attach a complete Gnulib 
patch.

> If gnulib cannot use __nonnull in
> getopt_{core,ext}.h, then there is no point trying to define it in
> getopt_cdefs.h.

Good point, I've removed that in the attached.

> And you're going to need to put snippet/arg-nonnull
> back in the module file for this to work at all, aren't you?

Yes, that's in the attached patch.

> From glibc's point of view, I think it would be better if
> getopt_core.h and getopt_ext.h simply assumed _GL_ARG_NONNULL to be
> available; we can add it to either our getopt.h wrapper or to
> sys/cdefs.h - I don't want to make that call unilaterally.

By "our getopt.h wrapper" do you mean a file in glibc but not in Gnulib? If so, 
this doesn't affect Gnulib. I suspect _GL_ARG_NONNULL logically belongs in 
sys/cdefs.h but it should also work to put it into the getopt.h wrapper.

> (Do you
> know of a complete list of _GL_ macros that may appear in _public_
> header files?)

I don't know of an explicit list. You can look at all the .h files listed in the 
Files: sections of gnulib/modules/snippet/*. For example, the 
snippet/arg-nonnull module defines _GL_ARG_NONNULL, the snippet/_Noreturn module 
defines _Noreturn, and so forth. There are quite a few such macros, and (as 
_Noreturn indicates) they don't all begin with _GL_.

I installed the attached into Gnulib and merged it into Emacs, and am boldly 
marking the Emacs bug (Bug#26398) as done. I think there still needs to be some 
changes done on the proposed change to glibc, to define _GL_ARG_NONNULL 
somewhere for glibc.

0001-getopt-port-recent-getopt-changes-to-macOS.patch
Description: Text Data