lib/clean-temp.c has:
...
#include <errno.h>
#include <fcntl.h>
and lib/fcntl.in.h has:
#ifndef _GL_FCNTL_H
@PRAGMA_SYSTEM_HEADER@
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
/* The include_next requires a split double-inclusion guard. */
[EMAIL PROTECTED]@ @NEXT_FCNTL_H@
On AIX 5.3:
$ cd /tmp/z
$ cat clean-temp.c
#include <fcntl.h>
$ xlc -I. -E clean-temp.c >/dev/null
[[ clean compile ]]
On AIX 6.1:
$ cd /tmp/z
$ cat clean-temp.c
#include <fcntl.h>
$ xlc -I. -E clean-temp.c >/dev/null
"./fcntl.h", line 25: 1506-299 (S) Maximum #include nesting depth of 255 has
been exceeded.
"./fcntl.h", line 26: 1506-299 (S) Maximum #include nesting depth of 255 has
been exceeded.
"./fcntl.h", line 27: 1506-299 (S) Maximum #include nesting depth of 255 has
been exceeded.
"./fcntl.h", line 29: 1506-299 (S) Maximum #include nesting depth of 255 has
been exceeded.
This is with the IBM v9.0 C compiler. To determine exactly what files
are being included by the compiler:
$ xlc -I. -qsource -qshowinc clean-temp.c
This generates clean-temp.lst in the existing directory, showing what
files are included. From AIX 5.3:
$ xlc -I. -qsource -qshowinc clean-temp.c
$ egrep -e '| #include' clean-temp.lst | egrep -e '<fcntl.h>'
1 | #include <fcntl.h>
1 29 | #include_next <fcntl.h>
>From AIX 6.1:
$ xlc -I. -qsource -qshowinc clean-temp.c
$ egrep -e '| #include' clean-temp.lst | egrep -e '<fcntl.h>'
1 | #include <fcntl.h>
1 29 | #include_next <fcntl.h>
22 29 | #include_next <fcntl.h>
26 29 | #include_next <fcntl.h>
30 29 | #include_next <fcntl.h>
34 29 | #include_next <fcntl.h>
38 29 | #include_next <fcntl.h>
42 29 | #include_next <fcntl.h>
46 29 | #include_next <fcntl.h>
50 29 | #include_next <fcntl.h>
54 29 | #include_next <fcntl.h>
58 29 | #include_next <fcntl.h>
62 29 | #include_next <fcntl.h>
...
Compiler bug? It seems like #include_next isn't working. Oddly, if I
modify fcntl.h so it's just:
#include_next <fcntl.h>
then everything works. But, if I precede the #include_next with other
#include directives, the error above occurs. Definitely seems like a
compiler bug. The #include directive seems to be resetting the order of
the search paths.
--
albert chin ([EMAIL PROTECTED])
