Discussion:
GNU LIB build fails on macOS 10.12.4
(too old to reply)
Paul Eggert
2017-04-08 08:24:46 UTC
Permalink
Raw Message
[Following up on http://bugs.gnu.org/26398 and CC'ing bug-gnulib and Zack Weinberg.]
./getopt_core.h:91:79: error: expected ';' after top level declarator
extern int getopt (int ___argc, char *const *___argv, const char *__shortopts)
Can you please send the preprocessor output for the failed compilation?
That is, try running "make V=1". If the failed command looks like this:

clang -c -Dthis -Dthat -Dtheother fstatat.c

then run this command:

clang -E -Dthis -Dthat -Dtheother fstatat.c >fstatat.i

and send a copy of fstatat.i as an attachment.

Also, can you find out which .h file defined __THROW and __nonnull in your
environment? I have the sneaking suspicion that it's some .h file other than
getopt_cdefs.h.

Thanks.
Paul Eggert
2017-04-08 09:38:21 UTC
Permalink
Raw Message
They __THROW and __nonnull are defined in „getopt_cdefs.h“.
Thanks, I think I see the problem. Either the compiler or some macOS header does
"#define __nonnull _Nonnull", and this collides with glibc's use of __nonnull.
Presumably Clang uses _Nonnull as a type qualifier and some Clang headers use
__nonnull as an alias for _Nonnull.

Please try the attached patch against Emacs master. If it works I plan to
install it into Emacs and propagate it into Gnulib.
Harald Maier
2017-04-08 10:31:11 UTC
Permalink
Raw Message
Yes, this fixes the problem and compilation works without errors.

Harald
They __THROW and __nonnull are defined in „getopt_cdefs.h“.
Thanks, I think I see the problem. Either the compiler or some macOS header does "#define __nonnull _Nonnull", and this collides with glibc's use of __nonnull. Presumably Clang uses _Nonnull as a type qualifier and some Clang headers use __nonnull as an alias for _Nonnull.
Please try the attached patch against Emacs master. If it works I plan to install it into Emacs and propagate it into Gnulib.
<emacs.diff>
Zack Weinberg
2017-04-08 15:24:54 UTC
Permalink
Raw Message
Post by Paul Eggert
Please try the attached patch against Emacs master.
If it works I plan to install it into Emacs and propagate
it into Gnulib.
This patch is incomplete. If gnulib cannot use __nonnull in
getopt_{core,ext}.h, then there is no point trying to define it in
getopt_cdefs.h. 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?

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. (Do you
know of a complete list of _GL_ macros that may appear in _public_
header files?)

zw
Paul Eggert
2017-04-09 08:03:30 UTC
Permalink
Raw Message
Post by Zack Weinberg
This patch is incomplete.
Yes, it was the Emacs patch, not the Gnulib patch. I'll attach a complete Gnulib
patch.
Post by Zack Weinberg
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.
Post by Zack Weinberg
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.
Post by Zack Weinberg
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.
Post by Zack Weinberg
(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.

Loading...