Date: Wed, 13 May 2020 11:48:57 -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: > 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.
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.