This is the mail archive of the
mailing list for the GCC project.
Re: [patch driver]: Fix relocatable toolchain path-replacement in driver
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Kai Tietz <ktietz70 at googlemail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 11 Sep 2013 19:27:33 +0000
- Subject: Re: [patch driver]: Fix relocatable toolchain path-replacement in driver
- Authentication-results: sourceware.org; auth=none
- References: <CAEwic4Z=6YQNyaB7p+J-0by6ejDQtn1FrUD4ZACz4=TP+bjmwg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1309111510380 dot 23762 at digraph dot polyomino dot org dot uk> <CAEwic4ZwR0YZ28Dw0CcHf=PHJZ65OFbBwn1EB-NVDMtbdqk0-w at mail dot gmail dot com>
On Wed, 11 Sep 2013, Kai Tietz wrote:
> > 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.
It doesn't really make sense to me for there to be a mixture of direct
replacement of the configure-time prefix based on keys, and first
replacing the configure-time prefix with the install location and then
replacing that based on keys.
I think the most appropriate design is as I said: make_relative_prefix,
and nothing else, deals with replacing the configure-time prefix with the
install location, and then prefix.c deals with any subsequent replacements
of the install location. On that basis, translate_name should be using
std_prefix not PREFIX, and any callers of these prefix.c interfaces that
pass paths still using the configure-time prefix should be fixed so that
the make_relative_prefix substitution occurs first.
You've found evidence of an inconsistency. A fix needs to be based on a
clear design - a clear understanding of what sort of paths should be used
where and what interfaces should translate them to other kinds of paths -
rather than just locally changing the paths used in one particular place
without a basis for arguing that the change fits a coherent design and so
won't cause problems elsewhere.
Joseph S. Myers