Simon Baldwin <sim...@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
