Re: Making gcc -no-canonical-prefixes the default?
On 31 January 2011 01:20, Gerald Pfeifer wrote: > On Fri, 28 Jan 2011, Ian Lance Taylor wrote: >> 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 . > > I am quite sure that the current behavior where one can have a symlink > point to an installation of GCC anywhere else (outside of any path even) > has been in place for quite a bit longer than 2003. Thanks for the notes and archaeology. My guess is that because it's easier, symlinking a single gcc binary is more common than symlinking a complete gcc tree. > On Sat, 29 Jan 2011, Dave Korn wrote: >> I think the case which is particularly common is the alternatives >> system, which has a chain of symlinks finally pointing to a real gcc. >> (That works just fine with the current default, AFAIK, although that >> may be only because the real gcc is in $PATH?) > > Nope, only the symlink(s) need to be in the path. And indeed this > usecase that you and also Joseph describe is how I've been using it > for many years. > > Given that this has een default behavior for so long (more than a > decade from what I can tell), I'd recommend not changing it. That would be as good a reason as any for not changing it. Thanks for the clarification. The patch in http://gcc.gnu.org/PR29931 uses... heuristics to detect if the gcc driver is a single symlink or part of a symlink farm (Florian Weimer's suggestion above). The patch has never been fully accepted, though; any known reason? I believe it will handle the two main use cases reliably. Combining it with -[no-]canonical-prefixes flags as overrides would cover all cases unambiguously. If heuristics aren't deemed reliable enough, another option is to set a default with a -no-canonical-prefixes-default configure flag. Less flexible because it's baked in to gcc, but simpler. On balance the PR29931 patch approach with -[no-]canonical-prefixes overrides seems to me like it will lead to least trouble in future. It also closes a long-standing gcc PR. Any dissent? Other options? Thanks. -- Google UK Limited | Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ | Registered in England Number: 3977902
Re: Making gcc -no-canonical-prefixes the default?
On Fri, 28 Jan 2011, Ian Lance Taylor wrote: > 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 . I am quite sure that the current behavior where one can have a symlink point to an installation of GCC anywhere else (outside of any path even) has been in place for quite a bit longer than 2003. On Sat, 29 Jan 2011, Dave Korn wrote: > I think the case which is particularly common is the alternatives > system, which has a chain of symlinks finally pointing to a real gcc. > (That works just fine with the current default, AFAIK, although that > may be only because the real gcc is in $PATH?) Nope, only the symlink(s) need to be in the path. And indeed this usecase that you and also Joseph describe is how I've been using it for many years. Given that this has een default behavior for so long (more than a decade from what I can tell), I'd recommend not changing it. Gerald
Re: Making gcc -no-canonical-prefixes the default?
* Ian Lance Taylor: > 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. Couldn't you check both locations and use the one that works?
Re: Making gcc -no-canonical-prefixes the default?
On 28/01/2011 23:05, Ian Lance Taylor wrote: > 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. I think the case which is particularly common is the alternatives system, which has a chain of symlinks finally pointing to a real gcc. (That works just fine with the current default, AFAIK, although that may be only because the real gcc is in $PATH?) cheers, DaveK
Re: Making gcc -no-canonical-prefixes the default?
Simon Baldwin 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
Re: Making gcc -no-canonical-prefixes the default?
On Fri, 28 Jan 2011, Simon Baldwin wrote: > A quick question about -no-canonical-prefixes... > > 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. I think the point of the default is that you can create a symlink in your PATH to a single gcc binary in a tree installed elsewhere, and that will work OK because the symlink is resolved before locating the rest of the tree. Certainly I use such symlinks for convenient access to installations of different GCC versions. -- Joseph S. Myers jos...@codesourcery.com
Making gcc -no-canonical-prefixes the default?
A quick question about -no-canonical-prefixes... 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? Thanks. -- Google UK Limited | Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ | Registered in England Number: 3977902
