Re: GCC 2.95 does not look in /usr/local/include

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <19990727153515.97D6857BA@ocean.lucon.org> you write:

>> Just in case someone wonders why gcc 2.95 does not find their headers in
>> /usr/local/include when prefix != /usr/local I'd suggest to take a look at
>> http://egcs.cygnus.com/ml/gcc-patches/1999-07/msg00488.html or
>> http://egcs.cygnus.com/ml/gcc-patches/1999-05/msg00477.html.  I won't
>> report this bug a third time, but IMHO it is still enough time to fix it
>> before the release.


>I sent a patch many years for Linux to make gcc as the vendor compiler and
>it was accepted. However, egcs didn't have the patch and I sent it again.
>This time I was told egcs wouldn't be used as the vendor compiler and
>someone might even remove my patch from the gcc subdirectory. That might be
>ok since there was gcc 2.7.2.3. Now egcs == gcc. My patch should go in.

>Here is the patch again.

OpenBSD is exactly in the same situation, and I don't think this is a good
idea. I definitely don't want such a change for OpenBSD.

Who is going to use that `feature' ?  A knowledgeable user doesn't need it,
he can read the documentation and decide to override the system compiler.

I'm quite afraid about mad experimenters... people who will get a new version
of gcc and decide to try it instead of their old compiler... the kind
who doesn't read the doc, and will simply compile gcc, and be VERY surprised
when his old trusty compiler simply vanished.

And then, there are people who build egcs on lots of different distinct
systems. Having the compiler show up in different places without any option
change is confusing at best... So they will make an habit of explicitly
specifying --prefix every time.

Finally, is there a precedent of an FSF package that installs under /usr
as a default ?

More generally, overriding the system compiler is a dangerous step that
should not be taken lightly.  On OpenBSD, for instance, there are issues
that creep up each time the compiler is upgraded... some low-level tools
such as crunch or installboot that handle binary code directly may get
confused as the code changes (these tools are usually maintained on a
keep-it-simple basis: they just have to recognize what will show up in actual
code, and it's easy to update them when needed... if you know your way around
the system)... which is why we try to provide an experimental user compiler
package that can be used to get new-fangled C++ features and toy about, but
that is distinct from the system compiler (rule: don't fuck your users up)

I would very much like to know what benefit your patch brings, in practical
terms.