Derek Price <[EMAIL PROTECTED]> writes: >>Why do we need to include <sys/types.h> here? All we need is size_t, >>right? And stddef.h gives us that. > > If I don't, I get the following error: > > In file included from glob.c:23: > glob.h:107: error: syntax error before "struct" > In file included from /usr/include/errno.h:36, > from glob.c:25: > /usr/include/bits/errno.h:38: error: syntax error before "extern"
Sorry, I can't debug that, since I don't have the exact version you do. In the latest version you sent, we have code that looks like this: #ifdef _LIBC # include <sys/cdefs.h> #else # include <sys/types.h> # include <stddef.h> # undef __size_t # define __size_t size_t #endif __BEGIN_DECLS First, already we have something bogus: that __BEGIN_DECLS. It must be protected by "#ifdef _LIBC", since random C environments don't have it. Similarly for __END_DECLS. Second, that <sys/types.h> ought to be unnecessary. We need only size_t, and <stddef.h> provides that. If we need <sys/types.h> for some other reason on your platform, let's figure out why that is, and attack its root source rather than the symptoms. (The rest of this message does that, I think.) > Hrm. Tracing this a little farther, it is only <features.h>, or even > the <sys/cdefs.h>, OK, here's what's happening, I think. Every glibc header includes <features.h> (and thus <sys/cdefs.h>) first thing, and this defines a whole bunch of stuff. If you attempt to declare libc-related stuff without including <features.h> first, bad things happen. The simplest fix would be to do something like this: #if defined _LIBC || HAVE_SYS_CDEFS_H # include <sys/cdefs.h> #endif with the appropriate change to glob.m4. 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. > I copied and pasted this comment and the #undef block > from the glob.c file. It was previously placed just prior to the > #include of <glob.h>. This looked the better place for it since I > assumed that we wouldn't want applications using the GNULIB glob module > to issue lots of redefinition warnings. OK, but in general this problem cannot be fixed in glob_.h. If the application includes our glob.h and then the buggy system files, it will still lose big-time. I tracked down these #undefs to this patch: http://sourceware.org/cgi-bin/cvsweb.cgi/libc/posix/Attic/glob.c.diff?r1=1.20&r2=1.21&cvsroot=glibc which has this ChangeLog entry in glibc: Thu Jan 21 20:12:25 1993 Roland McGrath ([EMAIL PROTECTED]) * posix/glob.c: Put #includes of <glob.h> and <fnmatch.h> after all system includes, in case one of them has conflicting defns of FNM_* or GLOB_*, so we will redefine. #undef FNM_* and GLOB_* before including our headers. I have heard of this problem occurring with <fnmatch.h> -- indeed, <fnmatch_.h> documents that it occurs with HP-UX A.08.07 -- but it's not clear to me that the problem every actually occurred with <glob.h>. Perhaps Roland made the change for <glob.h> simply as a precaution, because it had happened with <fnmatch.h>. Also, the problem, if it occurred with glob.h, was a long time ago, and perhaps we need not worry about it any more. HP-UX 8.07 was released in 1992, and HP hasn't supported it for many years. I doubt whether people are building new GNU software for it any more. With that in mind, how about if we simply remove those #undef's? If the problem recurs we can put them back in again. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib