Derek Price <[EMAIL PROTECTED]> 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. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
