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 jos...@codesourcery.com