Re: Toolchain relocation

[Dave Murphy <wintermute2k4 at ntlworld dot com>]

Daniel Jacobowitz wrote:
> No, this patch is not correct.  Take a wander through set_std_prefix
> and the call to update_path in add_prefix.
>   
Expected as much :)
> You might want to play around with relocation on a non-MinGW-hosted
> system, for comparison.  Does that work better?  If so, it's likely
> something which does not handle drive letters.  make_relative_prefix
> may need to be taught something about them.
make_relative_prefix seems to handle drive letters fine, I don't believe 
that's the problem.

If a *blank* disk is inserted then the compiler behaves properly so the 
relocation works. It's not dependent on finding anything in the 
configured location.

What's happening here is that the toolchain is still attempting to 
access directories in the configured location (even on my debian box) 
but you only notice a problem if the configured location happens to be a 
removable media device with no media present on windows when you get a 
dialog box asking you to insert a disk.

Looking at set_std_prefix and update_path it appears that std_prefix is 
set to the relocated install directory quite early on (line  3278 of 
gcc.c). update_path only translates the path if it contains std_prefix, 
this section of code in prefix.c

 const int len = strlen (std_prefix);

 if (! strncmp (path, std_prefix, len)
     && (IS_DIR_SEPARATOR(path[len])
         || path[len] == '\0')
     && key != 0)
   {

If I change this code so that it checks against the configured install 
location instead of the new relocated location then update_path does 
indeed translate the paths. It appears to be enough to add

static const char *old_prefix = PREFIX;

and change that section of code to read as follows

 const int len = strlen (old_prefix);

 if (! strncmp (path, old_prefix, len)
     && (IS_DIR_SEPARATOR(path[len])
         || path[len] == '\0')
     && key != 0)
   {

In this case the output from -print-search-dirs is fully translated with 
the exception of the install path which is due to always reporting the 
configured path in line 6306 of gcc.c

     printf (_("install: %s%s\n"), standard_exec_prefix, machine_suffix);

standard_exec_prefix is a constant which refers to the originally 
installed folder, changing this to  gcc_exec_prefix displays the 
relocated install location.

At line 6149 in gcc.c standard_exec_prefix is used to access the specs file

 /* We need to check standard_exec_prefix/just_machine_suffix/specs
    for any override of as, ld and libraries.  */
 specs_file = alloca (strlen (standard_exec_prefix)
              + strlen (just_machine_suffix) + sizeof ("specs"));

 strcpy (specs_file, standard_exec_prefix);
 strcat (specs_file, just_machine_suffix);
 strcat (specs_file, "specs");
 if ( access (specs_file, R_OK) == 0)
   read_specs (specs_file, TRUE);

Changing this to gcc_exec_prefix removes the last of the attempts to 
access anything in the old path as far as gcc is concerned. There are 
still some attempts to find include files in the configured install 
directory which I believe are related to cc1, cc1plus and c-incpath.c 
which I'm currently attempting to grok.

Dave