From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98407 invoked by alias); 28 Nov 2019 20:45:33 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 98394 invoked by uid 89); 28 Nov 2019 20:45:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.3.1 spammy=sof, ambiguity, H*Ad:D*googlegroups.com, layouts X-HELO: esa5.hgst.iphmx.com Received: from esa5.hgst.iphmx.com (HELO esa5.hgst.iphmx.com) (216.71.153.144) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Nov 2019 20:45:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1574973933; x=1606509933; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=TqqVbVc34eZxOEo9nDiDChV+AddKFStNY+Kz9Jr9W0A=; b=fOd/jCE7FErWJ25AXE6WGVNHsbi8TxYWjvkoeKdZAlaPK/VG/h/ffiw4 ir2PXpdWMpgKFZj2bZxeVQL16yRReD3WPCPP2+XJvqHiftlBsCZSZt4U/ hQRqwXVx0p121Aw1pcCrylUB86fCdb2TQQRaYqCfkLe9/UHuSvzxJtIzy /1a6FkRYIxOAW3JLToePjaZqvDGuqWmHd3cvSYw4GdGekCMH3cy28NFy5 haDFggwRudr++y4ScXV3tWLTENHHCyrGirXSWQB8aL4JbUe4Gtlcfduqn 16pV1G8NEEtq404SqrXFg72gIT1sx6pY15o0hiKmL2BWcBpY7XUg6evUE g==; IronPort-SDR: fG3g7pDl+qstQOGtV09b3R7Pc4Uh8MOoTFCPLJkTeX791wwVOxOX4brqrubJDladxOpdo9X/Ds i0B0vVSf/IlPyKl7PmItZZuxm2rxem1SCZ6DCE/EoWTC/rovkgMozUPjmfKs+fYX1sOn90qa5H z1AxThvQd7NuvibHVgaHFL2nSC8u7ac8qjGqX3U9Z8cOAWAx6hrIFtTYNgSiUzXlCkQh4HbFoZ xtJxlEX8SIVtBMmGU/RENRikjzmu5D+l04e5LLoTxnJdrCjLqspRrn8XLc6GOth3+vkRnHt0rr FNQ= Received: from h199-255-45-15.hgst.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 29 Nov 2019 04:45:31 +0800 IronPort-SDR: wujaTZg4qolLPazhHu/UDcKkJ5mqRVbfjj19elbuTOhmW7hf8QbncSa5rluymwH7pivH6Jz3om EzKnMInP7I8ScIitct86jVeUuORjnqJjLFu+OEdFTvaPCYdGlN5UE6pwwsdBnEzD2hcYijH7uS AFf0vrNpucf7fM5fHnbSuILs7hDImD5DhoycCP63UwxqXcfw5LMKhHfCE2oWinNHwFzF+Bykk8 7t/lhK2mc7E/pM1KBWXwymjau3E9fuOjfUuvnldVtjSva1do2GcwqBbYnL/blteI7oktEshUSC t9qSvfN/E3N1/k26rSJT0XeG Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2019 12:40:05 -0800 IronPort-SDR: NeSqnHgcSZZ6XJkIBqxGboIljej8z/FBz49NvXzAgIctpJ5k9oppPDAaaj1QPiY8GS8cYRdkE4 RlGEwivu1MU3LgN306C55GVHoXiUwn3kmETLB/KOvv+4zy/MC2Z3PVo63kN2X7Nx/c1h1ZoNr5 7WFWD62YExKTia1IVk5wh3GICrt468h1WgeMocrMlO1XYGSXvvzZdVGI99qXSJKzTS4ayM9uIT /SgxVqyuAx1ZkNKPld0QmYz7dWboyMI/gBo6dIme/ASvXNEMC5Q+zDrLvVr17cGp3bEDJCJXQY 4RQ= WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2019 12:45:29 -0800 Date: Thu, 28 Nov 2019 20:45:00 -0000 From: "Maciej W. Rozycki" To: Joseph Myers 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 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2019/txt/msg00094.txt.bz2 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