Do the gcc people give a reason for not allowing a system directory to be "blessed" with -I?
I wouldn't call it a "reason", but the manual puts it like this:
"(...) the option is ignored to ensure that the default search order for system directories and the special treatment of system headers are not defeated".
OK, I see. This is to prevent system directories being searched before directories containing gcc-specific replacements for system headers.
Even worse. Current CVS fails to build xterm with gcc 2.95.3 because of this '-I/usr/include':
gcc -c -O2 -march=i686 -fomit-frame-pointer -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I../../exports/include -I/usr/include -I/usr/include/freetype2 -I../../exports/include/X11 -I../.. -I../../exports/include -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -I. -DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT -DXFREE86_FT2 -DPROJECTROOT=/opt/XFree86-4.4 charproc.c
In file included from charproc.c:123:
/usr/include/error.h:26: parse error
This is because gcc now includes /usr/include/error.h instead of error.h from programs/xterm.
One should never put an explicit '-I/usr/include' or '-I/usr/local/include' in CFLAGS because this can lead to all sorts of strange behaviour.
The same holds for '-L/usr/lib' or '-L/usr/local/lib' in LDFLAGS.
Michael
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
