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.