Mark Mitchell wrote: > Sent: Monday, July 24, 2006 4:59 AM > > Andrew Pinski wrote: > > > > On Jul 14, 2006, at 1:17 PM, Carlos O'Donell wrote: > > > >> We currently search both the relocated compilers prefix and the > >> originally configured prefix. Should a relocated compiler be > >> searching both directories? > > > > Yes because someone might have just relocated the compiler > but not the > > rest of the tools. The main use of this is that untar a common > > sysroot and use different > > versions of the compiler which normally would be installed > under that > > common location. > > There are benefits and costs in either direction. > > 1. If we search both locations (i.e., for a relocated > compiler, search the configured-time prefix and the > installation-time prefix), we get the following set of problems: > > (a) If the configure-time prefix exists (for unrelated > reasons) the compiler finds files in the configure-time > prefix, even though neither the system administrator or user > expects that. >
1(a) is reported quite reguarly on mingw32 user lists. I think I hit it myself when I first started comparing different versions of the compiler. This is a typical scenario on windows Configure-time prefix set to /mingw by binary release manager User installs in C:\mingw A new release is made available. Configure-time prefix is again /mingw, since the release manger just reused the old build script. User chooses to install in, say, C:\gcc-3.4.5-2\mingw, to keep thing from getting confused. The new compiler, run from C:, looks in /mingw first and gets it wrong. Confused user reports a bug. So my response to "Should a relocated compiler be searching both directories on mingw32?", would be No, preferably only the relative-prefix. The --enable-win32-registry option, combined with an install-time regedit script, could still be used to force a common, absolute 'sysroot'. Danny
