On Thu, Dec 11, 2003 at 06:08:11PM +0100, Michael Lampe wrote:
>David Dawes wrote:
>
>>>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
My gcc 2.95.3 on FreeBSD searches only /usr/include implicitly.
>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
>fi
>
>if 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
>
>-----
We already do that for the freetype library. I'm not sure why we
didn't for the includes -- probably to try to make sure that the
correct freetype headers get included. Anyway, I'm testing a patch
that does this for freetype includes and installs our ft2build.h in a
better place.
>Would obviously solve the xterm build problem. As would removing
>'-I/usr/include'.
Not if there happened to be an "error.h" in one of the other -I
paths used in its build.
>> 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?
That's not the point. What needs to be tested is that a header
elsewhere (under one of the other -I paths) doesn't get erroneously
included instead of the one under /usr/include.
As I said, those interested in making sure that this works correctly
should test it and post the results here.
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
