Updates to --with-sysroot support

[Daniel Jacobowitz]

On Wed, Nov 06, 2002 at 06:49:05PM -0200, Alexandre Oliva wrote:
> On Nov  6, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > On Wed, Nov 06, 2002 at 04:04:04PM -0200, Alexandre Oliva wrote:
> >> On Nov  6, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> >> 
> >> > It can't affect compiles within the build tree; this is only applied to
> >> > the list of include directories in cpp_include_defaults.  None of those
> >> > are originally pointing into the build tree.
> >> 
> >> Point is, when we run ./xgcc -B./, gcc takes ./ as bindir, and
> >> tries to relocate everything else from that.
> 
> > But the only things it will relocate in this code are the in the
> > installed copy of $(gcc_tooldir).  Should we be searching that from
> > inside the build directory?  My hunch says no.
> 
> Point is it will relocate ${prefix}/include into say ../include.

Nope.  ${prefix}/include isn't affected at all by my change.  There's
three sets of relocation going on right now and I'm not entirely sure
what one of them (the oldest I think) does, so I left it alone...

 - Sysrooting.
 - The -iprefix code, which I did change.  This only affects things
starting in $(gcc_tooldir).
 - The call to update_path() in prefix.c, which honors Windows registry
keys and then does black magic with other cases.

> 
> >> > Blech, I knew I forgot something.  Yes, here's the install.texi patch;
> >> > it deletes the unpleasant bit that got me started on this in the first
> >> > place, and documents the relocation.
> >> 
> >> Err...  So is it going to be relocated even if it's outside
> >> exec_prefix or prefix.  I don't like this.
> 
> > That's not changed by my patch: it will be relocated if the call to
> > make_relative_prefix you added succeeds.  If that's not what you wanted
> > in the first place then you should probably control it at that call
> > site...
> 
> I think make_relative_prefix used to prevent such relocations, and I
> believe you've now made it more lax in what it accepts and tries to
> relocate.  But then, I may be entirely wrong in this assumption.  If
> so, I apologize.

I didn't change the behavior of make_relative_prefix at all, except for
fixing the number of ".."'s it inserted in one case.  Does just what it
used to.  Which does mean that if you had:
  --prefix=/opt/a/b/c/d/e
  --with-sysroot=/opt/f
and you run:
  /baz/a/b/c/d/e/bin/gcc
It'll look in:
  /baz/f/usr/include

Of course, if you run:
  /baz/bin/gcc
It'll probably end up looking in /usr/include.  Ugh ugh ugh ugh ugh.  I
didn't introduce this but I suppose we should fix it!  Suggested
behavior?  Constrain relocation to if the sysroot starts with $prefix?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer