public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@wdc.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org, libffi-discuss@sourceware.org,
	    golang-dev@googlegroups.com, zlib@gzip.org
Subject: Re: [PATCH v2] Add `--with-install-sysroot=' configuration option
Date: Wed, 20 Nov 2019 02:39:00 -0000	[thread overview]
Message-ID: <alpine.LFD.2.21.1911190134470.13542@redsun52.ssa.fujisawa.hgst.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1911190003210.23687@digraph.polyomino.org.uk>

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

  reply	other threads:[~2019-11-20  2:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-14  2:47 [PATCH] " Maciej W. Rozycki
2019-11-14  3:06 ` Joseph Myers
2019-11-18  2:04   ` [PATCH v2] " Maciej W. Rozycki
2019-11-19  0:11     ` Joseph Myers
2019-11-20  2:39       ` Maciej W. Rozycki [this message]
2019-11-20 17:46         ` Joseph Myers
2019-11-22 23:41           ` Maciej W. Rozycki
2019-11-22 23:54             ` Joseph Myers
2019-11-28 20:45               ` Maciej W. Rozycki
2019-11-28 21:06                 ` Joseph Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.21.1911190134470.13542@redsun52.ssa.fujisawa.hgst.com \
    --to=macro@wdc.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=golang-dev@googlegroups.com \
    --cc=joseph@codesourcery.com \
    --cc=libffi-discuss@sourceware.org \
    --cc=zlib@gzip.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).