Bruno Haible <bruno <at> clisp.org> writes:
>
> Albert Chin wrote:
> > The patch below would work around this and disable #include_next on this
> > platform.
> >
> > --
> > albert chin (china <at> thewrittenword.com)
> >
> > -- snip snip
> > diff --git a/m4/include_next.m4 b/m4/include_next.m4
> > index 08c63db..f0f947b 100644
> > --- a/m4/include_next.m4
> > +++ b/m4/include_next.m4
> > @@ -30,6 +30,7 @@ AC_DEFUN([gl_INCLUDE_NEXT],
> > mkdir conftestd1 conftestd2
> > cat <<EOF > conftestd1/conftest.h
> > #define DEFINED_IN_CONFTESTD1
> > +#include <stdio.h>
> > #include_next <conftest.h>
> > #ifdef DEFINED_IN_CONFTESTD2
> > int foo;
>
> Many thanks! Much appreciated. Applied with some comments, like this:
>
> 2008-09-04 Albert Chin <bug-gnulib <at> mlists.thewrittenword.com>
> Bruno Haible <bruno <at> clisp.org>
>
> * m4/include_next.m4 (gl_INCLUDE_NEXT): Add check whether #include_next
> also works after #include directives.
Unfortunately, this compiler and the IBM compiler on aix4.3.3 and aix6.1.0 (but
strangely, not 5.1, 5.2 or 5.3) have another peculiar behaviour which breaks on
some headers when include_next.m4 determines that #include_next doesn't work.
$ echo '#include <stdio.h>' > conftest.c
$ xlc -E conftest.c | grep stdio
#line 73 "/usr/include/stdio.h"
int __stdioid;
#line 259 "/usr/include/stdio.h"
#line 374 "/usr/include/stdio.h"
#line 398 "/usr/include/stdio.h"
#line 434 "/usr/include/stdio.h"
$ echo '#include <dirent.h>' > conftest.c
$ xlc -E conftest.c | grep dirent
struct dirent {
extern struct dirent *readdir(DIR *);
extern int readdir_r(DIR *, struct dirent *, struct dirent **);
extern int scandir(const char *, struct dirent ***,
int (*)(struct dirent *),
It seems that the compiler sometimes forgets the #line directives. I've no idea
how to fix this reliably, and have resorted to setting cache values at configure
time whenever it breaks.
If there's anything else I can do to help nail this down, don't hesitate to ask.
Cheers,
Gary
