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

[Rich Felker <dalias@libc.org>]

On Sun, May 10, 2020 at 01:35:23PM -0700, Michael Forney wrote:
> Thanks for your response, Rich.
> 
> On 2020-05-10, Rich Felker <dalias@libc.org> wrote:
> > Sorry I haven't had the time/attention to devote to this. I think
> > there's still a major mismatch in expectations -- the system you
> > install this native compiler onto is not going to have its include
> > files in /include but the standard /usr/include, among a lot of other
> > things.
> 
> 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....

> 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). At least relative to what I remember of my original intent.
But I'm doubtful that this was well thought out at all since the only
real intent at the time I added it was "can I make a compiler run on a
nommu j2?" where I didn't want to bootstrap a whole distro or have
anything serious actually compiled on the target where it would have
been prohibitively slow.

Rich