[PATCH v2] Add `--with-install-sysroot=' configuration option

[Joseph Myers]

On Fri, 22 Nov 2019, Maciej W. Rozycki wrote:

>  As I recall the MIPS sysroot setup (please correct me if I got something 
> wrong here) was like:

Yes, that's the sort of layout you get with sysroot suffixes.  See 
gcc/config/mips/{st.h,t-st} for an example.

>  Then the right-hand side of /path/to/somewhere (except for usr/) is what 
> gets printed by `-print-multi-directory' or the left-hand side of output 
> from `-print-multi-lib', e.g. `sof/el/lib64' for the example above.  

Rather, it's a suffix (as in SYSROOT_SUFFIX_SPEC, no command-line option 
to print it), followed by a directory such as /lib64 that comes from 
STARTFILE_PREFIX_SPEC.  (Until MULTILIB_OSDIRNAMES / 
-print-multi-os-directory were added, I think STARTFILE_PREFIX_SPEC was 
the main mechanism for using directories such as /lib64; once the multilib 
OS directory mechanism was added, STARTFILE_PREFIX_SPEC was needed much 
less, but is still relevant for this sysroot use case, along with some 
linker configuration in binutils to teach it about such directories.)

> Similarly `-print-multi-os-directory' prints a directory path relative to 
> a lib/ subdirectory to the sysroot, so that would be `../sof/el/lib64' 
> respectively.

Rather, it's a path relative to the (non-sysroot, before your patch) 
directory where the compiler installs the libraries.  See e.g. t-st using 
paths such as ../lib64/2f.

>  Well, I agree we need to have this stuff documented beyond what we 
> currently have, but I think it applies equally to all the sysroot options 
> we have, including both the `--sysroot=' GCC driver's option, and the 
> `--with-sysroot=', `--with-build-sysroot=' and the newly-proposed 

All three of those refer to the top-level sysroot path, to which a sysroot 
suffix is appended based on SYSROOT_SUFFIX_SPEC (unless 
--no-sysroot-suffix is used).

> `--with-install-sysroot=' `configure' script's options as well.  All we 
> currently have is this paragraph:

But this is a path relative to which SYSROOT_SUFFIX_SPEC isn't used at 
all.

>  And last but not least: do we want to hold my proposed change hostage to 
> a sysroot handling documentation improvement?  It does not appear fair to 
> me as the situation with said documentation is not a new problem nor one 
> specific to this newly-added option, and the new option merely played the 

The proposed new option is, as far as I know, the first one introducing 
this new kind of sysroot option (one for which the suffix from 
SYSROOT_SUFFIX_SPEC is never added).

-- 
Joseph S. Myers
joseph@codesourcery.com