[PATCH v2] Add `--with-install-sysroot=' configuration option
Maciej W. Rozycki
macro@wdc.com
Fri Nov 22 23:43:00 GMT 2019
On Wed, 20 Nov 2019, Joseph Myers wrote:
> > Thanks for your concern, however again, AFAICT this change is tangential
> > to any sysroot suffix, which necessarily has to be already included in the
> > multilib OS directory as given by `-print-multi-os-directory', so that it
> > gets embedded within $toolexeclibdir for the purpose of target library
> > installation across the relevant subdirs, as per this excerpt from
> > `configure' code right after the assignments quoted in the example above:
> >
> > multi_os_directory=`$CC -print-multi-os-directory`
> > case $multi_os_directory in
> > .) ;; # Avoid trailing /.
> > *) toolexeclibdir=$toolexeclibdir/$multi_os_directory ;;
> > esac
> >
> > or otherwise the existing arrangement where
> > toolexeclibdir='$(toolexecdir)/lib' wouldn't have worked either (and
> > neither would in the native case where toolexeclibdir='$(libdir)').
> >
> > Does this answer clear your concern? OK to apply with the documentation
> > thinko fixed?
>
> The answer explains the reasoning behind the design of the option (i.e.,
> the design that means it's not particularly useful with sysroot suffixes,
> because the user would still need to relocate libraries manually to the
> correct suffixed sysroot). It is indeed the case that making a version
> useful with sysroot suffixes would not simply be a configuration change
> but involve changes in the compiler driver to disentangle two different
> uses of multilib OS directory suffixes.
I think I am confused now about your mention of the existence of two
different uses here. This may be because it's been a while since I worked
with a MIPS toolchain configuration and my memory may have started to
fade. So at this point I'll appreciate if you enlighten me a bit.
As I recall the MIPS sysroot setup (please correct me if I got something
wrong here) was like:
/path/to/somewhere/
+-> lib/
+-> lib32/
+-> lib64/
+-> usr/
| +-> lib/
| +-> lib32/
| \-> lib64/
+-> el/
| +-> lib/
| +-> lib32/
| +-> lib64/
| \-> usr/
| +-> lib/
| +-> lib32/
| \-> lib64/
+-> sof/
| +-> lib/
| +-> lib32/
| +-> lib64/
| +-> usr/
| | +-> lib/
| | +-> lib32/
| | \-> lib64/
| \-> el/
| +-> lib/
| +-> lib32/
| +-> lib64/
| \-> usr/
| +-> lib/
| +-> lib32/
| \-> lib64/
.
.
.
and the use of `--sysroot=/path/to/somewhere' combined with the required
multilib selection options, such as `-EL -mabi=64 -msoft-float' would make
the GCC driver point the linker at the right set of directories to use for
libraries to be linked against. For the options given here these would be
/path/to/somewhere/sof/el/lib64 and /path/to/somewhere/sof/el/usr/lib64.
For RISC-V targets the structure so far is much simpler and for the Linux
target amounts to:
/path/to/somewhere/
+-> lib32/
| +-> ilp32/
| \-> ilp32d/
+-> lib64/
| +-> ilp64/
| \-> ilp64d/
\-> usr/
+-> lib32/
| +-> ilp32/
| \-> ilp32d/
\-> lib64/
+-> ilp64/
\-> ilp64d/
NB I have deliberately omitted header files from this consideration; these
could or could not be shared among multilibs depending on the particular
target although as I recall and agree with the desire was to have a single
shared set of headers living under /path/to/somewhere/usr/include/.
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.
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.
I have no immediate access to a MIPS toolchain (not at least one with
multilib support configured), but I have made a quick experiment with my
RISC-V toolchain (configured with the sysroot at `$prefix/sysroot') and
things appear to work as I described, e.g.:
$ riscv64-linux-gnu-gcc -print-multi-lib
.;
lib32/ilp32;@march=rv32imac@mabi=ilp32
lib32/ilp32d;@march=rv32imafdc@mabi=ilp32d
lib64/lp64;@march=rv64imac@mabi=lp64
lib64/lp64d;@march=rv64imafdc@mabi=lp64d
$ riscv64-linux-gnu-gcc -print-multi-directory
lib64/lp64d
$ riscv64-linux-gnu-gcc -print-search-dirs | grep libraries | sed 's/.*=//;s/:/\n/g' | xargs readlink -f
$prefix/lib/gcc/riscv64-linux-gnu/10.0.0/lib64/lp64d
$prefix/riscv64-linux-gnu/lib64/lp64d
$prefix/sysroot/lib64/lp64d
$prefix/lib/gcc/riscv64-linux-gnu/10.0.0
$prefix/lib/gcc
$prefix/riscv64-linux-gnu/lib
$prefix/sysroot/lib64/lp64d
$prefix/sysroot/usr/lib64/lp64d
$prefix/sysroot/lib
$prefix/sysroot/usr/lib
$
$ riscv64-linux-gnu-gcc -march=rv32imafdc -mabi=ilp32d -print-search-dirs | grep libraries | sed 's/.*=//;s/:/\n/g' | xargs readlink -f
$prefix/lib/gcc/riscv64-linux-gnu/10.0.0/lib32/ilp32d
$prefix/riscv64-linux-gnu/lib32/ilp32d
$prefix/sysroot/lib32/ilp32d
$prefix/lib/gcc/riscv64-linux-gnu/10.0.0
$prefix/lib/gcc
$prefix/riscv64-linux-gnu/lib
$prefix/sysroot/lib32/ilp32d
$prefix/sysroot/usr/lib32/ilp32d
$prefix/sysroot/lib
$prefix/sysroot/usr/lib
$
$ riscv64-linux-gnu-gcc --sysroot=/tmp -march=rv32imafdc -mabi=ilp32d -print-search-dirs | grep libraries | sed 's/.*=//;s/:/\n/g' | xargs readlink -f
$prefix/lib/gcc/riscv64-linux-gnu/10.0.0/lib32/ilp32d
$prefix/riscv64-linux-gnu/lib32/ilp32d
/tmp/lib32/ilp32d
/tmp/usr/lib32/ilp32d
$prefix/lib/gcc/riscv64-linux-gnu/10.0.0
$prefix/lib/gcc
$prefix/riscv64-linux-gnu/lib
/tmp/lib32/ilp32d
/tmp/usr/lib32/ilp32d
/tmp/lib
/tmp/usr/lib
$
Now /path/to/somewhere might well be what we call the tooldir, i.e.
$exec_prefix/$target_noncanonical, however this is somewhat inconvenient;
first because it is hardcoded, and second because there is other stuff
held there, starting from cross-executables for the host. Which is how I
came up with my change, whose intent is to separate /path/to/somewhere
from the tooldir for the purpose of library installation at GCC build time
and make it configurable.
I am fairly sure I have described the directory structures quite
accurately for one of the uses you have referred to. So would you please
remind me what the other use is and what exactly it is used for?
> However, it's not enough to answer the question about the semantics of the
> option on the mailing list. The question is a natural one for anyone who
> knows about sysroot suffixes and is reading the documentation of the
> option. And so *the actual GCC documentation proposed to be committed*,
> not just explanations on the mailing list that people reading that
> documentation won't see, needs to say explicitly that the OS directory
> suffix is appended to lib/ in the *unsuffixed* sysroot, so that all
> libraries get installed in the same sysroot even if suffixes are in use.
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
`--with-install-sysroot=' `configure' script's options as well. All we
currently have is this paragraph:
"'--sysroot=DIR'
Use DIR as the logical root directory for headers and libraries.
For example, if the compiler normally searches for headers in
'/usr/include' and libraries in '/usr/lib', it instead searches
'DIR/usr/include' and 'DIR/usr/lib'."
in the GCC manual, which carefully omits the matter of multilibs and based
on my experience is only ever accurate for configurations that do not use
multilibs.
So what I think we need is a section or a paragraph of a manual, probably
the GCC manual or as a shared piece, that would describe what a sysroot is
and how it drives library and header lookups in the presence of multilibs.
Then we could refer to that part of the manual from the descriptions of
the individual options, whose interpretation of the sysroot argument is
supposed to be really the same (well, with the minor variation that
`--with-install-sysroot=' does not have a separate usr/ subdirectory in
addition to /, although in principle it could; cf. the `--with-slibdir='
option in libgcc/). Having that embedded with the description of one of
the relevant options only would IMO be quite odd.
Also given my apparent confusion with how sysroots work I may not be the
best person to try documenting them, or at least it looks like I will
require considerable guidance with making a description that is actually
accurate.
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
role of a trigger for the discovery of the lack of suitable sysroot
documentation. Unless you think there is actually a functional issue of
any kind with the change itself that is.
Questions, comments, thoughts?
Maciej
More information about the Gcc-patches
mailing list