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 13585 invoked from network); 13 May 2020 14:38:14 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 May 2020 14:38:14 -0000 Received: (qmail 13993 invoked by uid 550); 13 May 2020 14:38:12 -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 13975 invoked from network); 13 May 2020 14:38:11 -0000 Date: Wed, 13 May 2020 10:37:59 -0400 From: Rich Felker To: Michael Forney Cc: musl@lists.openwall.com Message-ID: <20200513143759.GV21576@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> 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 01:18:05AM -0700, Michael Forney wrote: > On 2020-05-10, Rich Felker wrote: > > On Sun, May 10, 2020 at 01:35:23PM -0700, Michael Forney wrote: > >> My understanding was that musl-cross-make toolchains (native or cross) > >> were meant to be self-contained units, so the include directory > >> relative to the sysroot is always /include. > > > > This is true for cross compilers, which were the original only > > in-scope task of musl-cross-make. Adding NATIVE=y mode was a quick > > hack that was later fleshed out somewhat, but there was never any > > real design behind how it should work, and it shows. I'm not really > > sure whether it should be a proper native compiler for the target, or > > effectively a sysrooted self-targeting cross compiler that runs on the > > target. In some sense these are two different things and the user > > should be aware of which one they're requesting/getting.... > > Again, forgetting NATIVE=1 compilers entirely, this still fixes a bug > for cross-compilers that is currently hidden by the fact that the > sysroot (/$TARGET) happens to match the gcc tool directory. > > >> Merging a native toolchain into / can't work, even using the default > >> /usr/include search directory, because you'd still have musl headers > >> installed into /include, so the compiler would be unable to find the > >> musl headers (this is the same reason why you currently need the usr > >> -> . symlink). To support something like this, I think you'd need to > >> make the prefix configurable. > > > > I think the symlink is just missing (not done via the same rule as for > > cross compilers because the sysroot base is different for a non-cross > > compiler). > > I don't quite understand what you mean here, or why you think a > symlink should be necessary in the first place. The sysroot base > doesn't matter here; for both native and cross toolchains, > musl-cross-make installs musl headers to $SYSROOT/include > ($OUTPUT/include for native, and $OUTPUT/$TARGET/include for cross). 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. 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. > 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. Again, this is for a real native compiler. Cross-to-self should be different. Again, it's clear that none of this was thought out when I quickly added the option. > I get that you're unhappy with the current state of musl-cross-make > and NATIVE=1, and sure, there are probably some improvements to be > made, but I think you're making this out to be trickier than it > actually is. Once you have time to take a closer look at this, I think > you'll find that it really is a simple issue of gcc searching the > wrong directory by default. No, it's a complex matter of it using the wrong paths entirely. Rich