Date: Wed, 13 May 2020 14:55:52 -0400 From: Rich Felker <dalias@...c.org> To: Michael Forney <mforney@...rney.org> Cc: musl@...ts.openwall.com Subject: Re: Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains On Wed, May 13, 2020 at 11:48:57AM -0700, Michael Forney wrote: > On 2020-05-13, Rich Felker <dalias@...c.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. 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 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.) Rich
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.