[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200513185551.GZ21576@brightrain.aerifal.cx>
Date: Wed, 13 May 2020 14:55:52 -0400
From: Rich Felker <dalias@...c.org>
To: Michael Forney <mforney@...rney.org>
Cc: musl@...ts.openwall.com
Subject: Re: Re: [musl-cross-make] [PATCH v2] litecross: Fix system
header dir when building native toolchains
On Wed, May 13, 2020 at 11:48:57AM -0700, Michael Forney wrote:
> On 2020-05-13, Rich Felker <dalias@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
