On Thu, Aug 5, 2021, at 8:30 AM, Michael Matz wrote:
> 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 :)
Right. I meant stripping off the `cpu-vendor-os-` (conventionally) that ld and
as are prefixed with. stripping off leading directories is easier.
> > 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.
Yes there is no actual conflict. Our originally wrapper scripts may have been
confused about this at some point but that's on us.
>
> > 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.
Right.
>
> > 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.
OK I agree with that. so if someone passes -B$x, how about looking for
- $x/$machine/$version/$prog
- $x/$machine/$prog
- $x/$machine-prog
- $x/prog
so no prefixing in the subdir, only in the main dir?
($libexecsubdir is morally $libexec being a search dir + subdir IIRC)
> > I now have some patches for this change I suppose I could also submit.
>
> Even better :)
Great!
I will continue improving my patch based on the above. In the meantime, I
posted https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576725.html which
is a small cleanup that, while helping with my changes, doesn't change the
behavior and I hope is good in any event.
