From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7326 invoked from network); 13 May 2020 18:56:07 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 May 2020 18:56:07 -0000 Received: (qmail 1639 invoked by uid 550); 13 May 2020 18:56:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1620 invoked from network); 13 May 2020 18:56:05 -0000 Date: Wed, 13 May 2020 14:55:52 -0400 From: Rich Felker To: Michael Forney Cc: musl@lists.openwall.com Message-ID: <20200513185551.GZ21576@brightrain.aerifal.cx> References: <20181107064957.1137-1-mforney@mforney.org> <20200323043456.13327-1-mforney@mforney.org> <20200510163555.GU21576@brightrain.aerifal.cx> <20200510215257.GW21576@brightrain.aerifal.cx> <20200513143759.GV21576@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains On Wed, May 13, 2020 at 11:48:57AM -0700, Michael Forney wrote: > On 2020-05-13, Rich Felker wrote: > > What the sysroot dir is for a cross toolchain is an implementation > > detail of the cross compiler toolchain. It's not part of any larger > > filesystem on the target. > > All the paths I'm talking about are relative to the relocatable > sysroot. Whenever I speak of $SYSROOT, I mean the dynamically > determined sysroot path relative to the compiler binary. The larger > filesystem on the target is irrelevant here. > > > For a native compiler, the include path is supposed to be the normal > > native one. For a self-targeting cross compiler (one possible > > interpretation of native that wasn't my intent) it's not. These should > > probably be distinct supported cases. > > Okay, but this is not how it works currently, and does not seem to be > how people expect it to work. Both native and cross compilers search > for headers in $SYSROOT/usr/include, where $SYSROOT is determined > relative to the compiler binary. /usr/include on the actual system > root is not considered. > > >> Currently, gcc is searching for headers in $SYSROOT/usr/include, as it > >> does by default, but we can configure gcc to instead search > >> $SYSROOT/include (where the headers actually are) by using > >> --with-native-system-header-dir=/include. > > > > "Where they actually are" is a mistake. There is no intent to put > > /include on the target system at all. It was probably a mistake to > > even make this sysrooted the way it is but I don't know the right way > > to do it. Maybe it's just turning off sysroot. Toolchain headers > > should be relative to the toolchain install location so that you can > > install it wherever you want (/opt, /usr/local, ~, whatever) while > > native system headers should be searched in the standard locations. > > I think you are misunderstanding what the "native system header dir" > is. Here's the gcc documentation: > > --with-native-system-header-dir=dirname > > Specifies that dirname is the directory that contains native system header > files, rather than /usr/include. This option is most useful if you > are creating > a compiler that should be isolated from the system as much as possible. It > is most commonly used with the --with-sysroot option and will cause GCC > to search dirname inside the system root specified by that option. > > It is not relative to /, it is relative to the sysroot, which is > determined dynamically based on the location of the compiler binary. Yes, and what that means is that use of sysroot is just completely wrong for NATIVE=y. I was under the impression that sysroot was necessary for making a relocatable toolchain but I've since come to believe that was a misconception. Is that so? I think it would work to pass --with-native-system-header-dir=/include for cross and "self-targeting cross" compilers and that this would allow dropping the usr symlink for these cases, and to make NATIVE=y stop using sysroot at all (and not use this option). (NATIVE=y should be more than just $HOST=$TARGET.) Rich