From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99402 invoked by alias); 22 Nov 2019 23:41:38 -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 99393 invoked by uid 89); 22 Nov 2019 23:41:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.3.1 spammy= X-HELO: esa1.hgst.iphmx.com Received: from esa1.hgst.iphmx.com (HELO esa1.hgst.iphmx.com) (68.232.141.245) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Nov 2019 23:41:36 +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=1574466095; x=1606002095; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=QdRCBGTFSIJcjvuqmAmNHjzr/V2MSh/MLJVPfk+MrgY=; b=W02XkUiVawTc4Kw+Aw4/RbYExawr0CkjSfGOTY2lOmivuOKdO4Q+iEz3 BoggeeHsvdJ1CsDzb/eNhCaJsWs8GWEympnrTsk007EG/MB6Jfcbla99p RXIT99wGZH7hnmmPGwd8E5b2ldgbiXRCjA9EoIbObSt/qlPzwjSfi+153 ve01Bi9zTZj3n6+5G+GbMukChSccRw8wHQFpF+2tp7hnTc3DqvzOgyLVG YuTyc037IrZROyhIv9ucA3marZzo3wsQFn0Hpkzxl48+XTbjeckIi/8FZ E/OUkSCkiFruKcnx99TeBCN7w0dgZxFRPYQ3EU8/RbBWdRJGN9FH/f2r2 Q==; IronPort-SDR: LIbg6/CxK3Ndz/2Lrc3GtTvckvicUVFK1LTfPL01ujRyjRoQ1XqaSRRkcsdpkkaVenzXzgmaSA ag9D2VbfeCmVgS4pkIcG7Yof+stHc/Ba+c9v4WAuQ4SX3G6tt+XFv5lqR+WSdjefyfuUuMF6wf rwecSaG837A2Q8UDaoEdVHj1fCJSk3WtBeEAhCU8QkvkMbVg/kjLW/nidhOY6+4cgsx/1XfgjU lUroOrPF1ydXwzzVj/9jySZmbeh0w+IuXK3x2Zf9ivpbai37isSljFNkvL4MpBHDQ5y5PwYGm5 MQA= Received: from uls-op-cesaip02.wdc.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 23 Nov 2019 07:41:13 +0800 IronPort-SDR: Dr3gGDUkb8E7IKZT/ltA8bsTvSDI74PJwpnm0+mBgJXqoA80PK+0Ks9+ibLbXOrvHmPa17v3is HDboipUafqHOfhc5Slwlmkh4s1vEpdopeSULnmkffROVgHVaqm+NqqO10Xl7+X93+7Wkov9YCS WNX1IY71JRSMcEpmRSp8VWjUvo9SYSBihWyQy9PyPSAtzzIv1JdpYm7nGR5ZW/7JlDPIFeDHty e2w6a5gOKMKT77FWbYV/7tOZfwq7pDSjfRyFHgxyqxkWGxb649+/gMRD5e0yzyXmY705MJVjw7 HKZwV2vBzkZanCOKyc7WWOaX 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; 22 Nov 2019 15:35:58 -0800 IronPort-SDR: A6XnR0G9bwnIU1crbDjyuy0ysVmlrHbIN6WUJaFPqpwunddHsK+McOzWIy36SZ7DicBbmtliHH d/WfLWJyotRXhCteiOBwa+O+t61dYMbv0jpue+WtzJuf9g67Gmth/uyocOGmjGYPLSKBzo4m4E Y2fh5x3XWtCNeHCM9bphQcIbH07BkY66ZNjWtBs6+Z+WbOzAAbqkXWSFvaUZyBMfpErWqrmDZM peYy9nSR66SIR398PHZhro12Ezw8JnlU5+GsPwyA05dlF1qj3niwFn/BftiLNGEmEZfjE04TA1 GLE= 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; 22 Nov 2019 15:41:11 -0800 Date: Fri, 22 Nov 2019 23:41: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/msg00086.txt.bz2 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