This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Searching configured and relocated prefix.

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
(650) 331-3385 x713

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]