Re: header search path change with 2003-03-02 commit

[Hans-Peter Nilsson <hp at bitrange dot com>]

I was about to report the below breakage separately, but I'll
jump into this thread instead.  Please excuse.

On Tue, 18 Mar 2003, Daniel Jacobowitz wrote:
> On Tue, Mar 18, 2003 at 11:06:08PM +1030, Alan Modra wrote:
> > gcc-3.3 adds the extra paths in cppinit.c:init_standard_includes near
> > line 829.  ie. A suitable entry in cpp_include_defaults gets added
> > with _both_ the "translated versions of the GNU directories" and the
> > untranslated version.  This code seems to be missing from mainline
> > c-incpath.c:add_standard_paths.
>
> As Neil said, it's not missing - it was deliberately removed.  The
> reasoning is that if we start with a compiler installed in /A, and
> move it to /B, searching /A/include is almost always the wrong thing to
> do - they're likely to be the header files for a different version,
> etc.

I think /A should still be be searched as a fallback, as long as
you can't *prove* that *all files* are moved (like, by finding
them at the relocated place).  For example, the use of the -B
option or finding "gcc" or "xgcc" somewhere else does not mean
everything has moved; it just implies a new include-path that
should be preferred over previous ones.  Maybe just the gcc
binary was moved!  If not, there's breakage, as happened to my
test-installations.  Repeatable and hopefully sane example
follows.

- I compile and install a unified tree (binutils, newlib, gcc)
for --target=mmix-knuth-mmixware (or supposedly any other
buildable target from simtest-howto.html) with --prefix=/foo.
The build tree may be removed (not the installation).

- I build for the same target, from a source-tree with *gcc
only*, but the *same prefix*, --prefix=/foo (prepending PATH
with /foo/bin).

- I *test* this second tree (again, prepending PATH with
/foo/bin).  Note, no moves whatsoever of the trees involved.
Unfortunately, the include headers from the installed tree are
not found.  The first error is as as above,
gcc.c-torture/compile/990625-1.c.

This is presumably an interaction of your patches together with
the -B... option from the test harness and the fact that newlib
installs headers in /foo/mmix-knuth-mmixware/include, not
/foo/lib/gcc-lib/mmix-knuth-mmixware/3.4/include.  So, the
../..-stuff by which /foo/mmix-knuth-mmixware/include is found
is disabled, and only GCC:s own headers are found; no other
headers are found.

This *should* work.  Do you agree?

This works on the 3.3 branch and supposedly all previous
releases.  I'd say it's part of the tree-of-compiler-parts
philosophy that it's possible to just build and test the part
you're changing: gcc.  Hey, saving for major changes, I should
actually be able to build and test against a tree built for an
older release, for example 3.3 vs. 3.4, since the important bits
are overridden by the new bits.

I really think the installed prefix should be searched, as a
fallback after trying any supplied paths (e.g. -isystem, -B)
and relocating along the path of the compiler binary.

brgds, H-P