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. (b) If the configure-time prefix does not exist, but is under an NFS mount, the compiler will cause automount traffic, NFS timeouts, etc. (c) In searching for files, the compiler will make a lot of stat calls, measurably slowing down a relocated compiler. 2. If we search only location (i.e., for a relocated compiler, search only the installation-time prefix), we get a different set of issues: (a) As you say, a single sysroot (or other toolchain components) cannot as easily shared across compiler installations. However, I think it's clear that the problems in (1) are more severe than the problems in (2), on several grounds: * The problems in (1) are demonstrably annoying to people; CodeSourcery has several customer complaints about different customers related to this issue. All of (1a), (1b), and (1c) have been reported to us. (1a) is particularly nasty; users got totally incorrect behavior out of the compiler because the compiler was searching a configure-time prefix that happened to contain unrelated files. * The problems in (2) can be worked around by (for example) using a symlink to place the sysroot in both installation prefixes. These are actions that can be taken by system administrators at installation-time; they have no affect on ordinary users. * The problems in (1) are due to an implicit behavior of the compiler that empirically violates the principle of least surprise. If you get a tarball full of binaries, and unpack it in /home/mitchell/install, why would you expect it to search /opt/distributor, /tmp/buildroot, etc.? * No non-GCC compiler searches a "configure-time prefix". The only locations relevant are "well-known paths" (like /usr/include) and the installation-time prefix. So, GCC's model is confusing to users coming from other compilers. This is not a definitive argument, but it should carry weight unless there is some strong argument in favor of GCC's current behavior. * I suspect that the problems in (2) are relative rare while the problems in (1) are relatively common. A lot of users download binary distributions and install them somewhere convenient; relatively few try to do complicated things involving partially shared installations, and those users are probably more expert. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
