Re: should we search $prefix/include ?

["H . J . Lu" <hjl at lucon dot org>]

On Sat, Jun 09, 2001 at 05:59:03PM -0700, Per Bothner wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
> > Please file a high-priority PR so that I don't forget about it.
> 
> I tried.  However, gccbug complained about setting the priority high.
> 
> > And, I agree with you that searching $prefix/include makes sense.
> > Would you mind preparing a patch, and beginning the testing cycle, so
> > that we can know whether or not that works?
> 
> Well, it is possible the correct patch might be controversial.
> 
> The table of standard search directories is in cppdefault.c,
> which contains:
> 
> #ifdef LOCAL_INCLUDE_DIR
>     /* /usr/local/include comes before the fixincluded header files.  */
>     { LOCAL_INCLUDE_DIR, 0, 0, 1 },
> #endif
> 
> The Makefile.in defines:
>    -DLOCAL_INCLUDE_DIR=\"$(includedir)\" \
> and
>         # Directory in which to put localized header files. On the systems with
>         # gcc as the native cc, `local_prefix' may not be `prefix' which is
>         # `/usr'.
>         # NOTE: local_prefix *should not* default from prefix.
>         local_prefix = @local_prefix@
>         ...
>         # Directory to search for site-specific includes.
>         includedir = $(local_prefix)/include
> However, configure defines:
>         includedir='${prefix}/include'
> but $includedir@ is not used.
> 

FYI, the include directory has been broken for years. The only reasons
it hasn't bitten many people are

1. gcc is not usually used as a system compiler.
2. Most people compile gcc as a system compiler with "make bootstrap".

Unfortunately, it was not true for

1. The original Linux ia64 toolchain maintained by Red Hat.
2. When you compile gcc as a system compiler via candian cross.

I alway apply a patch to toplevel to remove includedir. Passing
includedir to gcc only makes senses when gcc is used as cross
compiler.



H.J.