Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 May 2020 12:34:23 -0700
From: Michael Forney <>
To: Rich Felker <>
Subject: Re: Re: [musl-cross-make] [PATCH v2] litecross: Fix system
 header dir when building native toolchains

On 2020-05-13, Rich Felker <> 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.