Re: Making gcc -no-canonical-prefixes the default?

[Ian Lance Taylor <iant at google dot com>]

Simon Baldwin <simonb@google.com> writes:

> By default, gcc calls realpath() on prefixes generated relative to
> argv[0] in the gcc driver.  If gcc is held as a "symlink farm" the
> realpath() makes it fail (absent a lot of messy -B, -L, -isytem and so
> on).  It complains about not finding cc1 or cc1plus in libexec.
>
> -no-canonical-prefixes turns off realpath() to make gcc work cleanly
> when stored this way.
>
> Does anyone know a reason why -no-canonical-prefixes could not become
> the gcc default?  Are there gcc configurations that must have the
> realpath()?  The flag is benign on normally laid out gcc
> installations.
>
> If it did become the default case, would adding a symmetrical
> -canonical-prefixes to turn realpath() back on be worthwhile?

Some archealogy turned up this as the reason canonicalization was
inserted:

http://gcc.gnu.org/ml/gcc/2003-02/msg01121.html
http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01697.html

Also relevant here is http://gcc.gnu.org/PR29931 .

So it seems like people want it both ways.  Some people want to invoke a
symlink which points to the real gcc, which requires canonicalization.
Some people want the real gcc to be a symlink which points elsewhere,
which requires non-canonicalization.  I don't know what the best choice
is.  Neither case seems particularly common to me.

The only argument I can think of is that it is easy to avoid having a
symlink which points to the real gcc.  You can use a tiny shell script
instead.  Whereas it's not that easy to change the other case, if you
had a reason to set things up that way.  So that suggests that we should
change the current default.  But I don't find this argument to be
especially convincing.

Since Gerald made the complaint which introduced the issue, I've CC'ed
him to see if he has any comments.

Ian