Re: Optional machine prefix for programs in for -B dirs, match ing Clang

[Michael Matz <matz@suse.de>]

Hello,

On Wed, 4 Aug 2021, John Ericson wrote:

> On Wed, Aug 4, 2021, at 10:48 AM, Michael Matz wrote:
> > ... the 'as' and 'ld' executables should be simply found within the 
> > version and target specific GCC libexecsubdir, possibly by being symlinks 
> > to whatever you want.  That's at least how my crosss are configured and 
> > installed, without any --with-{as,ld} options.
> 
> Yes that does work, and that's probably the best option today. I'm just 
> a little wary of unprefixing things programmatically.

The libexecsubdir _is_ the prefix in above case :)

> For some context, this is NixOS where we assemble a ton of cross 
> compilers automatically and each package gets its own isolated many FHS. 
> For that reason I would like to eventually avoid the target-specific 
> subdirs entirely, as I have the separate package trees to disambiguate 
> things. Now, I know that exact same argument could also be used to say 
> target prefixing is also superfluous, but eventually things on the PATH 
> need to be disambiguated.

Sure, which is why (e.g.) cross binutils do install with an arch prefix 
into ${bindir}.  But as GCC has the capability to look into libexecsubdir 
for binaries as well (which quite surely should never be in $PATH on any 
system), I don't see the conflict.

> There is no requirement that the libexec things be named like the bin 
> things, but I sort of feel it's one less thing to remember and makes 
> debugging easier.

Well, the naming scheme of binaries in libexecsubdir reflects the scheme 
that the compilers are using: cc1, cc1plus etc.  Not 
aarch64-unknown-linux-cc1.

> I am sympathetic to the issue that if GCC accepts everything Clang does 
> and vice-versa, we'll Postel's-law ourselves ourselves over time into 
> madness as mistakes are accumulated rather than weeded out.

Right.  I supposed it wouldn't hurt to also look for "${targettriple}-as" 
in $PATH before looking for 'as' (in $PATH).  But I don't think we can (or 
should) switch off looking for 'as' in libexecsubdir.  I don't even see 
why that behaviour should depend on an option, it could just be added by 
default.

> I now have some patches for this change I suppose I could also submit.

Even better :)


Ciao,
Michael.