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.
