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 11:48:57AM -0700, Michael Forney wrote:
> On 2020-05-13, Rich Felker <dalias@libc.org> 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