Re: [PATCH v2] Add `--with-install-sysroot=' configuration option
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
Re: [PATCH v2] Add `--with-install-sysroot=' configuration option
On Fri, 22 Nov 2019, Joseph Myers 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.
Thanks for the pointer.
> > 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),
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.
> > 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.
Can you please show me the two directory layouts, one for `--sysroot='
and the other for `--with-install-sysroot=' aka $toolexeclibdir, say for
the `mips64el-st-linux-gnu' target, and where exactly in GCC installation
(if anywhere) the `--sysroot=' layout is used?
Is it that with $toolexeclibdir we have say:
/usr/mips64el-st-linux-gnu/
+-> lib/
| +-> 2e/
| \-> 2f/
+-> lib32/
|+-> 2e/
|\-> 2f/
\-> lib64/
+-> 2e/
\-> 2f/
whereas `--sysroot=/path/to/sysroot' expects:
/path/to/sysroot/
+-> 2e/
| +-> lib/
| +-> lib32/
| \-> lib64/
\-> 2f/
+-> lib/
+-> lib32/
\-> lib64/
(and then GCC applies the former scheme to the directories pointed to by
the `-B' and `-L' options and the latter scheme to the directory pointed
to by the `--sysroot=' option)?
> > 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).
Thank you for all your input.
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.
Then on top of this an option like `--enable-sysroot-for-toolexeclibdir'
can be discussed in the future, that would switch $toolexeclibdir to the
proper sysroot layout, whether `--with-toolexeclibdir=' has been used or
not. Such an option will necessarily have to rely on the presence of a
GCC option to print SYSROOT_SUFFIX_SPEC/STARTFILE_PREFIX_SPEC for the
multilib selected.
If we agree on this plan, I'll post an update patch.
Maciej
Re: [PATCH v2] Add `--with-install-sysroot=' configuration option
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
Re: [PATCH v2] Add `--with-install-sysroot=' configuration option
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
Re: [PATCH v2] Add `--with-install-sysroot=' configuration option
On Wed, 20 Nov 2019, Maciej W. Rozycki wrote: > > But even then, if you configure GCC using "--with-sysroot" or > > "--with-build-sysroot", both of those paths are the top-level sysroot, to > > which the sysroot suffix gets appended before GCC uses it for any purpose, > > unless you explicitly build using --no-sysroot-suffix. So I still think > > it's natural for a user of GCC's configure scripts to expect the new > > option, like the other sysroot-related configure options, also to be one > > to which the per-multilib sysroot suffix gets appended before GCC uses it. > > And if it's not like that, the documentation needs to say so explicitly. > > 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. 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. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH v2] Add `--with-install-sysroot=' configuration option
On Tue, 19 Nov 2019, Joseph Myers wrote:
> > > 4. How does this interact with sysroot suffixes (again, this should be
> > > made clear in the documentation)?
> >
> > There is no interaction, the patch merely changes where the libraries are
> > installed. If the installation sysroot directory chosen is not one known
> > by the GCC driver, then the newly-installed target libraries won't be
> > automatically used (that of course can be changed with the appropriate use
> > of the `-B', `-L' and `--sysroot=' driver options).
>
> Perhaps the "sysroot" phrasing of the option name is confusing.
>
> The documentation in install.texi says "@var{dir} rather than
> @option{$@{gcc_tooldir@}/lib}". If that means, for example, that when
> "-print-multi-os-directory" prints "../lib64" the libraries are installed
> in $dir/../lib64 (so you'd pass --with-install-sysroot=/some/where/lib
> rather than --with-install-sysroot=/some/where), it's definitely not a
> sysroot. If in fact $dir/lib/../lib64 would be used, the documentation
> should say so.
Documentation thinko here, thanks for your meticulousness! Indeed that
has to read "@option{$@{gcc_tooldir@}}" as per example code:
case ${with_install_sysroot} in
no)
toolexeclibdir='$(toolexecdir)/lib'
;;
*)
toolexeclibdir=${with_install_sysroot}/lib
;;
esac
where "@var{dir}" does get interpreted as a sysroot (as was also
previously shown by my use example).
> But even then, if you configure GCC using "--with-sysroot" or
> "--with-build-sysroot", both of those paths are the top-level sysroot, to
> which the sysroot suffix gets appended before GCC uses it for any purpose,
> unless you explicitly build using --no-sysroot-suffix. So I still think
> it's natural for a user of GCC's configure scripts to expect the new
> option, like the other sysroot-related configure options, also to be one
> to which the per-multilib sysroot suffix gets appended before GCC uses it.
> And if it's not like that, the documentation needs to say so explicitly.
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?
Maciej
Re: [PATCH v2] Add `--with-install-sysroot=' configuration option
On Mon, 18 Nov 2019, Maciej W. Rozycki wrote:
> > 4. How does this interact with sysroot suffixes (again, this should be
> > made clear in the documentation)?
>
> There is no interaction, the patch merely changes where the libraries are
> installed. If the installation sysroot directory chosen is not one known
> by the GCC driver, then the newly-installed target libraries won't be
> automatically used (that of course can be changed with the appropriate use
> of the `-B', `-L' and `--sysroot=' driver options).
Perhaps the "sysroot" phrasing of the option name is confusing.
The documentation in install.texi says "@var{dir} rather than
@option{$@{gcc_tooldir@}/lib}". If that means, for example, that when
"-print-multi-os-directory" prints "../lib64" the libraries are installed
in $dir/../lib64 (so you'd pass --with-install-sysroot=/some/where/lib
rather than --with-install-sysroot=/some/where), it's definitely not a
sysroot. If in fact $dir/lib/../lib64 would be used, the documentation
should say so.
But even then, if you configure GCC using "--with-sysroot" or
"--with-build-sysroot", both of those paths are the top-level sysroot, to
which the sysroot suffix gets appended before GCC uses it for any purpose,
unless you explicitly build using --no-sysroot-suffix. So I still think
it's natural for a user of GCC's configure scripts to expect the new
option, like the other sysroot-related configure options, also to be one
to which the per-multilib sysroot suffix gets appended before GCC uses it.
And if it's not like that, the documentation needs to say so explicitly.
--
Joseph S. Myers
jos...@codesourcery.com
[PATCH v2] Add `--with-install-sysroot=' configuration option
Provide means, in the form of a `--with-install-sysroot=' configuration option, to override the default installation directory for target libraries, otherwise known as $toolexeclibdir. This is so that it is possible to get newly-built libraries, particularly the shared ones, installed in a common sysroot, so that they can be readily used by the target system as their host libraries, possibly over NFS, without a need to manually copy them over from the currently hardcoded location they would otherwise be installed in. The name of the configuration option is chosen such as to give it a meaning, rather than referring to obscure $toolexeclibdir. Arguments are interpreted as with the `--with-sysroot=' option. The default is the current value of $toolexeclibdir, so in the absence of the option from the invocation of the `configure' script the installation location for target libraries remains unchanged from the current arrangement. In the presence of the `--enable-version-specific-runtime-libs' option and for configurations building native GCC the option is ignored. config/ * install-sysroot.m4: New file. gcc/ * doc/install.texi (Cross-Compiler-Specific Options): Document `--with-install-sysroot' option. libada/ * Makefile.in (configure_deps): Add `install-sysroot.m4'. * configure.ac: Handle `--with-install-sysroot='. * configure: Regenerate. libatomic/ * configure.ac: Handle `--with-install-sysroot='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * testsuite/Makefile.in: Regenerate. libffi/ * configure.ac: Handle `--with-install-sysroot='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * include/Makefile.in: Regenerate. * man/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. libgcc/ * Makefile.in (configure_deps): Add `install-sysroot.m4'. * configure.ac: Handle `--with-install-sysroot='. * configure: Regenerate. libgfortran/ * configure.ac: Handle `--with-install-sysroot='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. libgo/ * configure.ac: Handle `--with-install-sysroot='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * testsuite/Makefile.in: Regenerate. libgomp/ * configure.ac: Handle `--with-install-sysroot='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * testsuite/Makefile.in: Regenerate. libhsail-rt/ * configure.ac: Handle `--with-install-sysroot='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. libitm/ * configure.ac: Handle `--with-install-sysroot='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * testsuite/Makefile.in: Regenerate. libobjc/ * Makefile.in (aclocal_deps): Add `install-sysroot.m4'. * aclocal.m4: Include `install-sysroot.m4'. * configure.ac: Handle `--with-install-sysroot='. * configure: Regenerate. liboffloadmic/ * plugin/configure.ac: Handle `--with-install-sysroot='. * plugin/Makefile.in: Regenerate. * plugin/aclocal.m4: Regenerate. * plugin/configure: Regenerate. * configure.ac: Handle `--with-install-sysroot='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. libphobos/ * m4/druntime.m4: Handle `--with-install-sysroot='. * m4/Makefile.in: Regenerate. * libdruntime/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. libquadmath/ * configure.ac: Handle `--with-install-sysroot='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. libsanitizer/ * configure.ac: Handle `--with-install-sysroot='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * asan/Makefile.in: Regenerate. * interception/Makefile.in: Regenerate. * libbacktrace/Makefile.in: Regenerate. * lsan/Makefile.in: Regenerate. * sanitizer_common/Makefile.in: Regenerate. * tsan/Makefile.in: Regenerate. * ubsan/Makefile.in: Regenerate. libssp/ * configure.ac: Handle `--with-install-sysroot='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate.
