From: Michael Forney <mforney@mforney.org>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
Date: Wed, 13 May 2020 11:48:57 -0700 [thread overview]
Message-ID: <CAGw6cBv2it9bBh93J234JC4fTL==AtMoVYuagEB_t70jRB0Zig@mail.gmail.com> (raw)
In-Reply-To: <20200513143759.GV21576@brightrain.aerifal.cx>
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.
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.
next prev parent reply other threads:[~2020-05-13 18:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-07 6:49 [musl-cross-make] [PATCH] " Michael Forney
2020-03-23 4:34 ` [musl] [musl-cross-make] [PATCH v2] " Michael Forney
2020-05-09 0:27 ` [musl] " Michael Forney
2020-05-10 16:35 ` Rich Felker
2020-05-10 20:35 ` Michael Forney
2020-05-10 21:52 ` Rich Felker
2020-05-13 8:18 ` Michael Forney
2020-05-13 14:37 ` Rich Felker
2020-05-13 18:48 ` Michael Forney [this message]
2020-05-13 18:55 ` Rich Felker
2020-05-13 19:34 ` Michael Forney
2020-05-13 20:04 ` Laurent Bercot
2020-05-13 21:51 ` Rich Felker
2020-05-14 8:40 ` Laurent Bercot
2020-08-19 21:00 ` Michael Forney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGw6cBv2it9bBh93J234JC4fTL==AtMoVYuagEB_t70jRB0Zig@mail.gmail.com' \
--to=mforney@mforney.org \
--cc=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).