mailing list of musl libc
 help / color / mirror / code / Atom feed
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.

  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).