Re: New cpp0 warning in 3.1 breaks configure (autoconf)

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[H}kan Hjort]

A.k.a "changing search order for system directory"

Let me try to exemplify.  The following configure script will fail
if --with-breakme=/usr/include (or any other default system include
path, like /usr/local/include on most systems) is given.
This is new with GCC 3.1.  
To complicate things further BSD does not have /usr/local/include as a
default include directory so testing for that and excluding it will not
work.

--begin configure.in--
AC_INIT(configure.in)
AC_PROG_CC

dnl First one to force it to figure out that gcc -E is a good preprocessor
AC_CHECK_HEADER(stdlib.h)

saved_CPPFLAGS=$CPPFLAGS

AC_ARG_WITH(breakme, 
  [  --with-breakme=path   specify a location of the headers files to use ], 
  CPPFLAGS="$CPPFLAGS -I$withval")

AC_CHECK_HEADER(string.h,,[AC_MSG_ERROR([Didn't find string.h])])

CPPFLAGS=$saved_CPPFLAGS

AC_OUTPUT(Makefile)
--end configure.in--

Running this (after autoconf) as shown below ends with an error.

>$ ./configure --with-breakme=/usr/local/include
...
checking for string.h... no
configure: error: Some thing is seriously messed up

>$ tail -8 config.log 
configure:875: checking for string.h
configure:885: gcc3 -E  -I/usr/local/include conftest.c >/dev/null 2>conftest.out
cpp0: warning: changing search order for system directory "/usr/local/include"
cpp0: warning:   as it has already been specified as a non-system directory
configure: failed program was:
#line 880 "configure"
#include "confdefs.h"
#include <string.h>

Here is another message http://gcc.gnu.org/ml/gcc/2001-07/msg00470.html
from last year that takes up the problem with this 'default on' no way
to turn it off warning. (Not exatly the same problem but..)
And reports in that thread of extra failurs in the testsuite from this
change.

Further evidens of problems with these warnings can be found here
http://gcc.gnu.org/ml/gcc-bugs/2002-04/msg00149.html

Where can the forbidden directories be found?  
(Guessing based on gcc -v -E ..., /usr/local/include /usr/include)
 
Is there anyway to get rid of this warning?   Why is it on by default?

How are one supposed to workaround this in configure scripts?

-- 
HÃ¥kan Hjort
d95hjort@dtek.chalmers.se

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Phil Edwards]

On Sat, Jun 08, 2002 at 12:44:07AM +0200, H}kan Hjort wrote:
> And reports in that thread of extra failurs in the testsuite from this
> change.

Yep.

> Further evidens of problems with these warnings can be found here
> http://gcc.gnu.org/ml/gcc-bugs/2002-04/msg00149.html
> 
> Where can the forbidden directories be found?  
> (Guessing based on gcc -v -E ..., /usr/local/include /usr/include)

Pretty much.  Any of the "standard system" directories on a particular
platform, also (IIRC) any of the include directories under the --prefix
directory.  Which means you must be careful installing symlinks to the
compiler.

> Is there anyway to get rid of this warning?

Nope.

> Why is it on by default?

Nobody knows.

> How are one supposed to workaround this in configure scripts?

You can't.  I changed my local copy of the compiler sources to no longer
warn about it.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Neil Booth]

Phil Edwards wrote:-

> > Is there anyway to get rid of this warning?
> 
> Nope.
> 
> > Why is it on by default?
> 
> Nobody knows.
> 
> > How are one supposed to workaround this in configure scripts?
> 
> You can't.  I changed my local copy of the compiler sources to no longer
> warn about it.

Since this appears to be causing pain to many people, and no-one seems
to be willing to defend the warning when people ask about it on the
mailing lists, I suggest this is the best course of action for the
mainline source too.

Neil.

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Russ Allbery]

Neil Booth <neil@daikokuya.demon.co.uk> writes:

> Since this appears to be causing pain to many people, and no-one seems
> to be willing to defend the warning when people ask about it on the
> mailing lists, I suggest this is the best course of action for the
> mainline source too.

Is there any way to warn about /usr/include without warning about
/usr/local/include?  Packages that add -I/usr/include are buggy and the
maintainers need to fix them, whether they realize that or are willing to
face it or not.  I have no sympathy there.  But -I/usr/local/include is
less obviously wrong.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[DJ Delorie]

> Since this appears to be causing pain to many people, and no-one seems
> to be willing to defend the warning when people ask about it on the
> mailing lists, I suggest this is the best course of action for the
> mainline source too.

I've argued for such a change before also.

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Jonathan Lennox]

Russ Allbery writes:
> Is there any way to warn about /usr/include without warning about
> /usr/local/include?  Packages that add -I/usr/include are buggy and the
> maintainers need to fix them, whether they realize that or are willing to
> face it or not.  I have no sympathy there.  But -I/usr/local/include is
> less obviously wrong.

Would it be possible to warn explicitly about -I inclusion of directories
that have fixincluded headers?  I think a message such as
     cpp0: warning: directly searching directory /usr/include, which has
           fixincluded headers

would be clearer to people.

Or, alternately, could the preprocessor just automatically translate
-I/usr/include into -IPREFIX/whatever/include -I/usr/include?

-- 
Jonathan Lennox
lennox@cs.columbia.edu

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Fergus Henderson]

On 10-Jun-2002, DJ Delorie <dj@redhat.com> wrote:
> 
> > Since this appears to be causing pain to many people, and no-one seems
> > to be willing to defend the warning when people ask about it on the
> > mailing lists, I suggest this is the best course of action for the
> > mainline source too.
> 
> I've argued for such a change before also.

I agree.  I'd also like to see it on the gcc 3.1 branch.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Loren James Rittle]

In article <20020610060256.GA3949@daikokuya.demon.co.uk> you write:

>> > Why is it on by default?

>> Nobody knows.

> Since this appears to be causing pain to many people, and no-one seems
> to be willing to defend the warning when people ask about it on the
> mailing lists, I suggest this is the best course of action for the
> mainline source too.

Well, I was a day late but I attempted to defend it over in gcc-bugs
before I saw this gcc list traffic.

I think the current behavior is worth defending since skipping fixed
system headers can cause serve cascading problems that are hard to
debug by the user.

The warning be improved to only report when a wrong header was
actually found due to the user-provided change to the search path.
However, I don't know if "randomly" kicking in (depending on exact
port and system header, etc) is better than an absolute warning.

Regards,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Marc Espie]

In article <200206112213.g5BMDp3L044244@latour.rsch.comm.mot.com> you write:
>I think the current behavior is worth defending since skipping fixed
>system headers can cause serve cascading problems that are hard to
>debug by the user.

Of course, this does assume the compiler and fixincludes are always right.

>The warning be improved to only report when a wrong header was
>actually found due to the user-provided change to the search path.
>However, I don't know if "randomly" kicking in (depending on exact
>port and system header, etc) is better than an absolute warning.

This is an area where too smart behavior can be very, very annoying.

There's nothing more annoying than knowing the compiler is wrong, in
one very specific case, for a whole large set of reasons, and being
unable to shup the compiler up.

If you keep the warning, give people a way to shut the warning down
completely, along the lines of `yes, I know what I'm doing, and stop
getting in my way.'

See, gcc ISN'T in charge of the operating system. And there are valid
reasons to do things in different ways (and the validity of those reasons
may be very relative to the community. Like, some BSD community may wish
to do things differently than the Linux crowd)

A set of headers can be a very complex things indeed. And the way headers
interact in complex systems can be a real maze.

I do spend a lot of time porting various software to OpenBSD.  And the most
annoying part of that job is working around various pieces of subtly broken
`automagic' software that assumes too much and needs to be shut up.

If gcc can be somewhat flexible and GET OUT OF THE WAY, it means it gets
easier for me to do that porting work.

And yes, I know what I'm doing. And even if I don't and you know better,
I don't have to care.  So either you give me the way to shut the warning
nicely, or I'll shut it brutally, by patching it out of existence all the
time.


And BTW, this configure trouble comes precisely from the fact that the
BSD mindshare is somewhat different: we bundle the compiler, so on our
systems, as the system compiler, it does NOT look under /usr/local.
Okay, it's not the behavior of the ports system. It's integrated in gcc
source (-DXXX_NATIVE), and if it ever were to disappear in the FSF sources,
rest assured it would stay in the BSD ports.

Woah... sorry if it sounds like a rant.

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Alexandre Oliva]

On Jun 11, 2002, Marc Espie <espie@quatramaran.ens.fr> wrote:

> In article <200206112213.g5BMDp3L044244@latour.rsch.comm.mot.com> you write:
>> I think the current behavior is worth defending since skipping fixed
>> system headers can cause serve cascading problems that are hard to
>> debug by the user.

> Of course, this does assume the compiler and fixincludes are always right.

-I/usr/include is always wrong.  -isystem /usr/include might be
acceptable.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Marc Espie]

On Tue, Jun 11, 2002 at 07:58:54PM -0300, Alexandre Oliva wrote:
> On Jun 11, 2002, Marc Espie <espie@quatramaran.ens.fr> wrote:
> 
> > In article <200206112213.g5BMDp3L044244@latour.rsch.comm.mot.com> you write:
> >> I think the current behavior is worth defending since skipping fixed
> >> system headers can cause serve cascading problems that are hard to
> >> debug by the user.

> > Of course, this does assume the compiler and fixincludes are always right.

> -I/usr/include is always wrong.  -isystem /usr/include might be
> acceptable.

Well, the problem stemmed from /usr/local/include in the first place.
Entirely different beast.

See what I mean about different assumptions ?

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Phil Edwards]

On Tue, Jun 11, 2002 at 07:58:54PM -0300, Alexandre Oliva wrote:
> On Jun 11, 2002, Marc Espie <espie@quatramaran.ens.fr> wrote:
> > In article <200206112213.g5BMDp3L044244@latour.rsch.comm.mot.com> you write:
> >> I think the current behavior is worth defending since skipping fixed
> >> system headers can cause serve cascading problems that are hard to
> >> debug by the user.
> 
> > Of course, this does assume the compiler and fixincludes are always right.
> 
> -I/usr/include is always wrong.  -isystem /usr/include might be
> acceptable.

Let me throw out an idea:

Ignore -I/usr/include.  Silently, even.  Warn only if -Wfoo is given
(for whatever value of foo).

More generally, ignore -I's of STANDARD_INCLUDE_DIR ("/usr/include"
by default).  Or maybe, anything in the cpp_include_defaults array.
Give a diagnostic only if the user asks for one, because otherwise there
is nothing the user can do about it.

We can recover from parsing errors and continue.  Why can't we recover from
command-line user errors and continue?


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Loren James Rittle]

In article <200206112233.g5BMXmM30365@quatramaran.ens.fr> you write:

> And yes, I know what I'm doing. And even if I don't and you know better,
> I don't have to care.  So either you give me the way to shut the warning
> nicely, or I'll shut it brutally, by patching it out of existence all the
> time.
[...]
> Woah... sorry if it sounds like a rant.

IMHO, that is OK.  I enjoy your view on the topic, but I think it is
from a perspective of someone that upgrades "the system compiler" not
from a user that installs a new version of gcc on his older OS
release.  The FSF release is obviously structured, by default, to
accommodate the later use more so than the former.  I.e. we put more
burden on the few people that can take it because they understand
subtle configuration issues instead of the masses that just want a
reasonable upgrade for their system.

[Neil asked for someone to defend the warning.  I will attempt to do
 so but I am mainly doing so only since I recall the arguments of the
 time and how it was resolved.  Also, because I usually attempt to
 keep my gcc user hat on while I patch gcc.  And, Mark has challenged
 all gcc developers to do so in the past.]

The issues are different and we need to also think about it
recognizing the difference in perspective.  I took me a while to
understand that some post from your perspective and others post from
the user perspective.  There is nothing wrong with it especially when
people are clear on which perspective they are coming from.  To
resolve the difference in perspective allow me to add more context to
my argument:

The warning is on by default in the FSF sources (at the moment at
least ;-) as people will obtain the sources and install them as an
non-vendor endorsed upgrades to their system (in that mode, it might
well "fix" or "supplement" your perfect system headers ;-).

If you make gcc your system compiler and don't fix headers (and/or did
it in place thus there is no parallel tree of headers), then as "we"
(i.e. I think this is just the party line on the matter) tell everyone
who uses gcc as a system compiler, you are free to change the compiler
as long as it is marked with different version information than would
be reported from an official FSF release...

It might well be that when installed as a system compiler, the warning
is not really helpful.  I am unwilling to judge that; but, then again,
I don't have to since you have final authority as a system compiler
guy for xBSD.  You have the right to brutally shut up that warning.

It might also cause more harm than good when configured from FSF
sources to uprgade a system compiler.  However, we are talking about
an *informational warning* here, not an error, right?

It is autoconf, in some configurations (since I have yet to ever see
it, I suspect that it must be a user-provided clause not default
autoconf-generated files), that is checking gcc with -I... and not
accepting/ignoring such warnings gracefully (granted, they were not
known to exist at the time the autoconf files were written - thus I
think we should attempt to help any maintainers of such packages fix
their usage).

Independent of that, Phil has clarified a *different* failure mode
with the warning.  He can reproduce the warning without the user
providing any -I switches.  I grant that would be mightly annoying.
Let us not mix Phil's case (I think it has to do with how he attempted
to install gcc) with the other that affects some autoconf-based projects.

But what am I missing about the autoconf case?  I have a fairly good
memory without studying the list on the matter but this is from
memory: We knew about that exact case when the change was made to FSF
gcc sources.  We knew that users of gcc that provided -I/usr/include
were doing something they may not have understood to cause other
cascading errors (i.e. thus the importance of the warning).

It seems a shame to have shipped a version that was designed to
encourage some users to clean up their act only to fall back and
remove a very useful warning...  (the bulk of the pain will have
already been paid by the time we release 3.1.1, thus removing the
warning now only allow errant -I uses to return unchecked)

Regards,
Loren

PS, none of this should be taken to point a finger at any project that
added -I/usr/include.  At the time they did so, it may not have been
as big a problem.  And the gcc manual may not have warned as strongly
about it or at all.

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Daniel Jacobowitz]

On Tue, Jun 11, 2002 at 07:11:48PM -0400, Phil Edwards wrote:
> On Tue, Jun 11, 2002 at 07:58:54PM -0300, Alexandre Oliva wrote:
> > On Jun 11, 2002, Marc Espie <espie@quatramaran.ens.fr> wrote:
> > > In article <200206112213.g5BMDp3L044244@latour.rsch.comm.mot.com> you write:
> > >> I think the current behavior is worth defending since skipping fixed
> > >> system headers can cause serve cascading problems that are hard to
> > >> debug by the user.
> > 
> > > Of course, this does assume the compiler and fixincludes are always right.
> > 
> > -I/usr/include is always wrong.  -isystem /usr/include might be
> > acceptable.
> 
> Let me throw out an idea:
> 
> Ignore -I/usr/include.  Silently, even.  Warn only if -Wfoo is given
> (for whatever value of foo).
> 
> More generally, ignore -I's of STANDARD_INCLUDE_DIR ("/usr/include"
> by default).  Or maybe, anything in the cpp_include_defaults array.
> Give a diagnostic only if the user asks for one, because otherwise there
> is nothing the user can do about it.
> 
> We can recover from parsing errors and continue.  Why can't we recover from
> command-line user errors and continue?

Heck, the warning I want to get out of all this are includes of what
STANDARD_INCLUDE_DIR and the equivalent for /usr/local/include would be
in a native compiler, when using a cross compiler.  Readline in the GCC
source tree does this sometimes, for instance.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Zack Weinberg]

On Tue, Jun 11, 2002 at 08:03:12PM -0400, Daniel Jacobowitz wrote:
> > 
> > We can recover from parsing errors and continue.  Why can't we recover from
> > command-line user errors and continue?
> 
> Heck, the warning I want to get out of all this are includes of what
> STANDARD_INCLUDE_DIR and the equivalent for /usr/local/include would be
> in a native compiler, when using a cross compiler.  Readline in the GCC
> source tree does this sometimes, for instance.

I can't figure out what this means.  The warning I want to get out of
this is includes? Huh?

More generally, let me say that I'm just now overhauling the way -I
and friends work for other reasons, and I'm happy to implement
whatever behavior people actually want.  However, y'all have to hash
out what the behavior should be and tell me, first.  I don't have an
opinion here and I don't particularly care about the debate.  Just
find something everyone likes, then tell me what it is, and I'll write
the code.

Well, I do have a meta-opinion, which is that a solution that is not
acceptable to people in *all* of the camps of GCC users isn't gonna
fly.  Make it work for BSD, make it work for Linux, make it work for
native use on proprietary operating systems, make it work for cross
compiles to embedded targets, I'm sure there are more.

zw

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Daniel Jacobowitz]

On Tue, Jun 11, 2002 at 05:59:36PM -0700, Zack Weinberg wrote:
> On Tue, Jun 11, 2002 at 08:03:12PM -0400, Daniel Jacobowitz wrote:
> > > 
> > > We can recover from parsing errors and continue.  Why can't we recover from
> > > command-line user errors and continue?
> > 
> > Heck, the warning I want to get out of all this are includes of what
> > STANDARD_INCLUDE_DIR and the equivalent for /usr/local/include would be
> > in a native compiler, when using a cross compiler.  Readline in the GCC
> > source tree does this sometimes, for instance.
> 
> I can't figure out what this means.  The warning I want to get out of
> this is includes? Huh?

I must be getting tired...

The case that I very much want to see a warning in is:
powerpc-unknown-linux-gcc -I/usr/include foobar.c

Ditto for -I/usr/local/include.

These generally come from -I$(prefix)/include, which is an install
directory properly and not a build directory.  This is an amazingly
common error, and my local patch to warn about it (a stupid patch,
which just hardcodes /usr and /usr/local) has been very successful.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Alexandre Oliva]

On Jun 11, 2002, Marc Espie <espie@nerim.net> wrote:

> On Tue, Jun 11, 2002 at 07:58:54PM -0300, Alexandre Oliva wrote:
>> On Jun 11, 2002, Marc Espie <espie@quatramaran.ens.fr> wrote:
>> 
>> > In article <200206112213.g5BMDp3L044244@latour.rsch.comm.mot.com> you write:
>> >> I think the current behavior is worth defending since skipping fixed
>> >> system headers can cause serve cascading problems that are hard to
>> >> debug by the user.

>> > Of course, this does assume the compiler and fixincludes are always right.

>> -I/usr/include is always wrong.  -isystem /usr/include might be
>> acceptable.

> Well, the problem stemmed from /usr/local/include in the first place.
> Entirely different beast.

> See what I mean about different assumptions ?

Same difference to me.  -I/usr/local/include is wrong too, since
/usr/local/include is a system header directory.  -Iing it may not be
as evil as /usr/include, but it's still a bad idea IMO.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Marc Espie]

In article <ord6ux41ab.fsf@livre.redhat.lsd.ic.unicamp.br> you write:
>On Jun 11, 2002, Marc Espie <espie@nerim.net> wrote:
>
>> On Tue, Jun 11, 2002 at 07:58:54PM -0300, Alexandre Oliva wrote:
>>> On Jun 11, 2002, Marc Espie <espie@quatramaran.ens.fr> wrote:
>>> 
>>> > In article <200206112213.g5BMDp3L044244@latour.rsch.comm.mot.com>
>you write:
>>> >> I think the current behavior is worth defending since skipping fixed
>>> >> system headers can cause serve cascading problems that are hard to
>>> >> debug by the user.
>
>>> > Of course, this does assume the compiler and fixincludes are always right.
>
>>> -I/usr/include is always wrong.  -isystem /usr/include might be
>>> acceptable.
>
>> Well, the problem stemmed from /usr/local/include in the first place.
>> Entirely different beast.
>
>> See what I mean about different assumptions ?
>
>Same difference to me.  -I/usr/local/include is wrong too, since
>/usr/local/include is a system header directory.  -Iing it may not be
>as evil as /usr/include, but it's still a bad idea IMO.

No, it's not. Not everywhere. See ? you are making assumptions that are
false.

On some BSD systems, /usr/local is the place for *local* stuff, and the
system compiler (a version of gcc) does not look in /usr/local.
Hence, the porting framework does add -I/usr/local/include to configure
invocations for this compiler.

...And this fails with a gcc non-system compiler that looks under /usr/local,
and produces a warning because of that.

Repeat after me: you don't own /usr/local/include.
Repeat after me: you don't own /usr/local/include.
Repeat after me: you don't own /usr/local/include.

gcc may install its headers there. It may run fixincludes on /usr/include
stuff and put its fixed set under /usr/local, but it doesn't own 
/usr/local/include. Other packages do install stuff there. They have a
right to.

And that will possibly be non-fixed includes, because it can get installed
after gcc, for instance.

If you want a header location that truely belongs to gcc, name it. Ada
does things correctly there.

In fact, I see a similar misconception in libtool: libtool is far too smart
in trying to deduce things about the internal working of some compilers (and
is unable to treat it correctly as a black box). Hence, it falls on its nose
with multilibs.

Exact same misconception. Same disastrous results.

I have nothing against that warning per-se, as long as I can get a simple way
to shut it up.

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Alexandre Oliva]

On Jun 12, 2002, Marc Espie <espie@quatramaran.ens.fr> wrote:

>> Same difference to me.  -I/usr/local/include is wrong too, since
>> /usr/local/include is a system header directory.  -Iing it may not be
>> as evil as /usr/include, but it's still a bad idea IMO.

> No, it's not. Not everywhere. See ? you are making assumptions that are
> false.

If you get a warning, it means /usr/local/include is regarded as a
system header by GCC, in which case -I/usr/local/include is evil.
When GCC does not search /usr/local/include by default, then
-I/usr/local/include is obviously ok.

> Repeat after me: you don't own /usr/local/include.
> Repeat after me: you don't own /usr/local/include.
> Repeat after me: you don't own /usr/local/include.

you don't own /usr/local/include :-D

(please don't get me wrong, this is just the kind of silly joke I'd
make in such a situation, no offense intended :-)

> gcc may install its headers there. It may run fixincludes on /usr/include
> stuff and put its fixed set under /usr/local, but it doesn't own 
> /usr/local/include.

Right.  It doesn't even fix headers in /usr/local/include.  That's not
the issue.  The issue is whether it searches /usr/local/include by
default and whether it treats headers it finds there as system headers
or not.  IMO, if GCC searches a directory as a system header and you
tell it otherwise, you should get a warning.  At the very least, to
inform you that the flag is probably unnecessary.

> In fact, I see a similar misconception in libtool: libtool is far too smart
> in trying to deduce things about the internal working of some compilers (and
> is unable to treat it correctly as a black box). Hence, it falls on its nose
> with multilibs.

I agree.  There is a problem in there.  Libtool should probably just
use gcc -shared and be done with it.  On systems it doesn't work, just
refrain from creating shared libraries.  But it's hard to touch what
is (mostly?) working.  Especially when you don't have time nor access
to the affected systems to test.

> I have nothing against that warning per-se, as long as I can get a
> simple way to shut it up.

Doesn't -w disable all warnings, this one included?  If not, it
should.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Jason R Thorpe]

On Wed, Jun 12, 2002 at 02:05:07PM +0200, Marc Espie wrote:

 > >Same difference to me.  -I/usr/local/include is wrong too, since
 > >/usr/local/include is a system header directory.  -Iing it may not be
 > >as evil as /usr/include, but it's still a bad idea IMO.
 > 
 > No, it's not. Not everywhere. See ? you are making assumptions that are
 > false.
 > 
 > On some BSD systems, /usr/local is the place for *local* stuff, and the
 > system compiler (a version of gcc) does not look in /usr/local.
 > Hence, the porting framework does add -I/usr/local/include to configure
 > invocations for this compiler.

Erm, doesn't GCC actually consider ${prefix}/include to be a system
include directory?  I.e. it's not "/usr/local/include", it just happens
that /usr/local is the default for ${prefix}.

This is why I always use a prefix which I dedicate entirely to mainline GNU
toolchain bits I'm working on, e.g. --prefix=/usr/local/gnu.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>
	...at USENIX...

Re: New cpp0 warning in 3.1 breaks configure (autoconf)

[Andris Pavenis]

On Wednesday 12 June 2002 06:35, Alexandre Oliva wrote:
> >
> > Well, the problem stemmed from /usr/local/include in the first place.
> > Entirely different beast.
> >
> > See what I mean about different assumptions ?
>
> Same difference to me.  -I/usr/local/include is wrong too, since
> /usr/local/include is a system header directory.  -Iing it may not be
> as evil as /usr/include, but it's still a bad idea IMO.

There more. If for example /usr/X11R6/include is specified in C_INCLUDE_PATH
(or accordingly CPLUS_INCLUDE_PATH for C++) it is also treated as system 
header directory. So I'm getting warning when -I/usr/X11R6/include is 
specified in command line. Perhaps it would be better to  limit this warning 
to list of system include directories before adding ones from C_INCLUDE_PATH 
or CPLUS_INCLUDE_PATH (or even to ones which are processed by fixincludes)

Andris