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.
Never /usr/local/include?? That's ridiculous. How are you deciding which ones are allowed and which are not?
The point is (I'm refering to gcc here) that /usr/local/include and /usr/include are searched by default but in this order:
<explicitly given includes first> /usr/local/include /usr/lib/gcc-lib/i486-linux/2.95.3/../../../../i486-linux/include /usr/lib/gcc-lib/i486-linux/2.95.3/include /usr/include
In this order you normally get what you expect. For example, if you have a more recent version of some library installed in /usr/local than in /usr. Putting '-I/usr/include' in CFLAGS changes this order and produces unexpected results, especially if you don't do it yourself but some 'foo-config --clags'. Another example is the above xterm build error.
I think this is the real reason why newer gcc's simply ignore '-I/usr/include'
Besides, most sane 'foo-config' scripts contain for that very reason something like this:
----- from freetype-config -----
if test "$echo_cflags" = "yes" ; then
cflags="-I${prefix}/include/freetype2"
if test "${prefix}/include" != "/usr/include" ; then <==
echo -I${prefix}/include $cflags
else
echo $cflags
fi
fiif test "$echo_libs" = "yes" ; then
libs="-lfreetype -lz"
if test "${exec_prefix}/lib" != "/usr/lib" ; then <==
echo -L${exec_prefix}/lib $libs
else
echo $libs
fi
fi-----
'-I/usr/local/include' and '-L/usr/local/lib' seem, on second thought, not to be a problem.
If you use these and have local headers that might conflict,
I guess every unix has /usr/include/error.h
then you must put -I. in explicitly first. Then there is no ambiguity. I'd say that's what needs to happen for xterm/Imakefile.
Would obviously solve the xterm build problem. As would removing '-I/usr/include'.
If someone wants to try builds that currently rely on -I/usr/include and make sure they work correctly when they are removed, please do, and send reports of any problems.
Which systems do not search in /usr/include automatically?
Michael
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
