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

[Alexandre Oliva <aoliva at redhat dot com>]

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