Re: [patch driver]: Fix relocatable toolchain path-replacement in driver

[Kai Tietz <ktietz70 at googlemail dot com>]

2013/9/11 Joseph S. Myers <joseph@codesourcery.com>:
> On Wed, 11 Sep 2013, Kai Tietz wrote:
>
>> This change fixes a quirk happening for relocated toolchains.  Driver
>> remembers original-build directory
>
> The original *build* directory should never be known to the driver; only
> the *configured* prefix.
>
> This area is complicated and subtle; you need to be very careful and
> precise in the analysis included in any patch submission related to it.
> Get things absolutely clear in your head and then write a complete,
> careful, precise self-contained explanation of everything relevant in GCC,
> as if for an audience not at all familiar with the code in question.

That I agree on, and it took me some time to find this.

>> in std_prefix variable for being able later to modify path.  Sadly
>> this std_prefix variable gets modified
>> later on, and so update_path can't work any longer as desired.  This
>
> You don't say what "as desired" is.  prefix.c contains a long description
> of *what* the path updates are, but no explanation of *why* or any overall
> design; it appears to be something Windows-specific.

Well it might be Windows specific.  It shows its bad side on Windows
due old build-prefix remains on translation and leads to the try to
access an invalid path.  That isn't necessarily a problem as long as
the drive-letter exists.  Otherwise user gets system-failures by this.
 I am pretty sure that it isn't related to make_relative_path, as
otherwise we would see same behavior on other targets, too.

> update_path should, as I understand it, always be called with PATH being a
> relocated path (one that has had the configured prefix converted to the
> prefix where the toolchain is in fact installed, using
> make_relative_prefix, or that doesn't need any relocation, e.g. a path
> passed with a -B option).  In incpath.c, for example, you see how a path
> is computed using make_relative_prefix before update_path is called.
> Thus, it is correct for std_prefix to be the relocated prefix rather than
> the unrelocated one.

I understand this different.  See here translate_name function (used
by update_path).  If path is empty it falls back to PREFIX (not
std_prefix).  So I understand that this routine tries to cut off
compiled in prefix from paths and replaces it by key's path.  But
well, I might got this wrong.
The bad point about all this on native Windows targets is the use of
msys and its stupid auto-magic PATH-translation (means it converts
simply everything what it sees to begin with a slash ...).  By this it
might be that it is indeed a Windows specific thing here.
Nevertheless one I think we need to address ...


> If there is a bug, I'd say it's in whatever code is calling update_path
> without having first done the make_relative_prefix relocation on the path
> being passed to update_path.  Thus, it is that caller that you need to
> fix.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

Regards,
Kai