Re: gcc 3.2's cpp breaks configure scripts

[H}kan Hjort <d95hjort at dtek dot chalmers dot se>]

John David Anglin wrote:
> The gcc warning is correct in the cases that I have examined.  I don't
> believe that configure should be adding include directories to CPPFLAGS
> that are already being searched as system directories by gcc.  This
> changes the include search order as noted in the warning and may
> cause unexpected results.
>
Ah but which are theses directories?  There is no way to know as far
as I can see.  (If you don't fancy doing some rather serious parsing
of either the specfile, the output from -dumpspecs or from gcc -v -E).

Since some thimes for example /usr/local/include will be a system
directory and some times not.

[snip]
> There may be some debate as to what directories gcc should treat
> as "system" directories.  However, configure shouldn't change
> the default search order of gcc without good reason, irrespective
> of whether the directories are truly system directories or not.
> this affects gcc's mechanism to fix headers.

Ehh.. not everyone installs every pice of software out there in /usr
so then you need to tell configure where to find the stuff, and it in
turn needs to add the -I and -L / -R flags.

Now if user says that 'oh I have libjpeg installed in /usr/local', 
should I then add -I/usr/local/include to CPPFLAGS or not?

If I do so on a standard Linux system it will fail becuse of:
cpp0: warning: changing search order for system directory "/usr/local/include"
cpp0: warning:   as it has already been specified as a non-system directory

on the other hand if I don't then on a FreeBSD system it will fail with:
conftest.c:4:17: jpeglib.h: No such file or directory

[snip]
> Possibly, if gcc provided a simpler way to print the search order,
> the autoconf macro authors could be persuaded not to append these
> directories to CPPFLAGS.  The reasons to do this are documented.
> Turning the warning off is not the correct solution, although there
> may be some circumstances in which it is emitted when it shouldn't
> be.

Or if there where autoconf macros that handled all of this instead of
each package having the code to let users specify if/where a dependecy
can be found.  Then trying to work out if the path must or must _not_
be added.

The fact that there still are many configure scripts out there that now
fail just because of this, still stands.  The only way to turn of this
warning is with -w  'Inhibit warning messages'.
I don't know if adding that to CPPFLAGS will cause any other averse 
affects.

-- 
Håkan Hjort