[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGw6cBv2it9bBh93J234JC4fTL==AtMoVYuagEB_t70jRB0Zig@mail.gmail.com>
Date: Wed, 13 May 2020 11:48:57 -0700
From: Michael Forney <mforney@...rney.org>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Re: [musl-cross-make] [PATCH v2] litecross: Fix system
header dir when building native toolchains
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.
For a cross toolchain we currently have:
gcc binary: /some/path/bin/gcc
sysroot: ../x86_64-linux-musl
native system header dir: ../x86_64-linux-musl/usr/include
musl header install directory: ../x86_64-linux-musl/include
For a native toolchain we currently have:
gcc binary: /some/path/bin/gcc
sysroot: ../
native system header dir: ../usr/include
musl header install directory: ../include
So --with-native-system-header-dir=/include will indeed search where
the headers actually are, wherever the toolchain might have been
relocated.
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.
