[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGw6cBuGHa3KUhHCnKx5U5Wqh1awPKFwDhRiM5W8e7rL+1Cqhw@mail.gmail.com>
Date: Wed, 13 May 2020 12:34:23 -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:
> On Wed, May 13, 2020 at 11:48:57AM -0700, Michael Forney wrote:
>> 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 believe that a sysroot is necessary for making a relocatable
toolchain, but it doesn't matter if it is /, /$TARGET, or something
else. If you build with --with-sysroot, gcc will look for headers
relative to itself, and will not look in /.
What doesn't seem to be possible is a "half-relocatable" toolchain,
where it searches both in /include relative to the relocated sysroot,
and /usr/include on the target system. Perhaps there is some trick or
patch that could make this work.
> 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.)
But until this NATIVE=y refactoring, shouldn't we fix native
toolchains to at least be able to find musl headers? It seems your
intention is to search for headers in both /usr/include and
$SYSROOT/include, but currently, neither of those is searched, only
$SYSROOT/usr/include which does not exist.
My patch is intended to just fix this incorrect path, not to change
the meaning of NATIVE=y. Such a change should probably involve
coordination of Zach van Rijn and Laurent Bercot, both of whom
distribute pre-built native toolchains (currently containing a usr ->
. symlink). Consumers of those toolchains probably expect a
self-contained, relocatable toolchain, since that's what they are
currently getting.
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.
