On Thu, 28 Nov 2019, Maciej W. Rozycki wrote: > > > > Rather, it's a suffix (as in SYSROOT_SUFFIX_SPEC, no command-line option > > to print it), > > Do you mean that there's no option to print SYSROOT_SUFFIX_SPEC on its > own or that no option prints it as a path component? If the latter, then > I think it's an awful shortcoming, because there's no reasonable way for > a given GCC compilation to determine the layout expected.
There is no option to print the results of expanding SYSROOT_SUFFIX_SPEC on its own. You can use -print-sysroot to print the full sysroot used, including the suffix. > Is it that with $toolexeclibdir we have say: > > /usr/mips64el-st-linux-gnu/ > +-> lib/ > | +-> 2e/ > | \-> 2f/ > +-> lib32/ > | +-> 2e/ > | \-> 2f/ > \-> lib64/ > +-> 2e/ > \-> 2f/ Yes. > whereas `--sysroot=/path/to/sysroot' expects: > > /path/to/sysroot/ > +-> 2e/ > | +-> lib/ > | +-> lib32/ > | \-> lib64/ > \-> 2f/ > +-> lib/ > +-> lib32/ > \-> lib64/ Yes. This latter structure is currently one that GCC can *use* but never *installs* anything into. > If my understanding as expressed above is correct, then I think the way > to move forward with this change will be to rename the option to > `--with-toolexeclibdir=' or suchlike (and adjust documentation > accordingly) so that it avoids the ambiguity of "sysroot" and is in line > with the usual `--bindir=', `--libdir=', etc. or less usual > `--with-slibdir=' options where people can adjust the various installation > directories according to their requirements or preferences. Yes, that seems a plausible approach. -- Joseph S. Myers jos...@codesourcery.com
