2013/9/11 Joseph S. Myers <jos...@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 > jos...@codesourcery.com Regards, Kai
