Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains

[Rich Felker <dalias@libc.org>]

On Wed, May 13, 2020 at 01:18:05AM -0700, Michael Forney wrote:
> On 2020-05-10, Rich Felker <dalias@libc.org> 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