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

[Michael Forney <mforney@mforney.org>]

On 2020-05-13, Rich Felker <dalias@libc.org> wrote:
> On Wed, May 13, 2020 at 11:48:57AM -0700, Michael Forney wrote:
>> 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 believe that a sysroot is necessary for making a relocatable
toolchain, but it doesn't matter if it is /, /$TARGET, or something
else. If you build with --with-sysroot, gcc will look for headers
relative to itself, and will not look in /.

What doesn't seem to be possible is a "half-relocatable" toolchain,
where it searches both in /include relative to the relocated sysroot,
and /usr/include on the target system. Perhaps there is some trick or
patch that could make this work.

> 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.)

But until this NATIVE=y refactoring, shouldn't we fix native
toolchains to at least be able to find musl headers? It seems your
intention is to search for headers in both /usr/include and
$SYSROOT/include, but currently, neither of those is searched, only
$SYSROOT/usr/include which does not exist.

My patch is intended to just fix this incorrect path, not to change
the meaning of NATIVE=y. Such a change should probably involve
coordination of Zach van Rijn and Laurent Bercot, both of whom
distribute pre-built native toolchains (currently containing a usr ->
. symlink). Consumers of those toolchains probably expect a
self-contained, relocatable toolchain, since that's what they are
currently getting.