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

[Daniel Jacobowitz <drow at mvista dot com>]

On Tue, Mar 18, 2003 at 02:03:32PM -0500, Hans-Peter Nilsson wrote:
> 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 don't agree at all.  "maybe just the gcc binary was moved" is a sort
of relocation that requires us to read the user's mind.  We're not in
that business, are we?

> - 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.

Yes, I agree that this should work, but...

> 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.

I don't agree with this as a solution.  This is the same problem as
Alan reported.  Basically, we have three cases:
  - Using the compiler from its installation location
  - Using the compiler from a moved installation
  - Using the compiler from the build tree

I want the first two to behave identically with appropriate relocation. 
The third is the one I consider to be a special case.  That should be
fixed by flags in the build environment and testsuite, not by changing
behavior of the other two cases.

Do you have an example of an installed, relocated tree that you think
justifies searching the original prefix?  I can't think of one.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer