Re: [bug-gnulib] New GNULIB glob module?

[Paul Eggert]

Derek Price <derek@ximbiot.com> writes:

>>But let's step back a second. Why are we worried about building
>>gnulib glob.c under glibc? It will never happen, right? So perhaps
>>we needn't worry about this problem at all.
>
> Won't it?  I thought the idea was that when you and I settled on
> something that looked good I would attempt to send it back to the libc
> folks so that the files wouldn't need to be maintained separately.

Yes, that's the idea, but that's a different scenario.  In that
scenario we are building glob.c as part of glibc, so _LIBC is 1.  I am
talking about the scenario where glob.c is part of a user program
(i.e., glob.c is imported from gnulib), and where the C library is
glibc, but we are compiling glob.c anyway.  Will that ever happen?

Answering my own question: yes it will, in general, because perhaps
the gnulib version fixes a bug that's in the glibc version, and the
user wants the gnulib version.  So we should worry about this.
And (as far as I can see) the simplest fix is to do this:

#if defined _LIBC || HAVE_SYS_CDEFS_H
# include <sys/cdefs.h>
#endif

with the appropriate change to glob.m4 to define HAVE_SYS_CDEFS_H.