This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: New cpp0 warning in 3.1 breaks configure (autoconf)
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.