Date: Wed, 13 May 2020 01:18:05 -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-10, Rich Felker <dalias@...c.org> wrote: > On Sun, May 10, 2020 at 01:35:23PM -0700, Michael Forney wrote: >> My understanding was that musl-cross-make toolchains (native or cross) >> were meant to be self-contained units, so the include directory >> relative to the sysroot is always /include. > > This is true for cross compilers, which were the original only > in-scope task of musl-cross-make. Adding NATIVE=y mode was a quick > hack that was later fleshed out somewhat, but there was never any > real design behind how it should work, and it shows. I'm not really > sure whether it should be a proper native compiler for the target, or > effectively a sysrooted self-targeting cross compiler that runs on the > target. In some sense these are two different things and the user > should be aware of which one they're requesting/getting.... Again, forgetting NATIVE=1 compilers entirely, this still fixes a bug for cross-compilers that is currently hidden by the fact that the sysroot (/$TARGET) happens to match the gcc tool directory. >> Merging a native toolchain into / can't work, even using the default >> /usr/include search directory, because you'd still have musl headers >> installed into /include, so the compiler would be unable to find the >> musl headers (this is the same reason why you currently need the usr >> -> . symlink). To support something like this, I think you'd need to >> make the prefix configurable. > > I think the symlink is just missing (not done via the same rule as for > cross compilers because the sysroot base is different for a non-cross > compiler). I don't quite understand what you mean here, or why you think a symlink should be necessary in the first place. The sysroot base doesn't matter here; for both native and cross toolchains, musl-cross-make installs musl headers to $SYSROOT/include ($OUTPUT/include for native, and $OUTPUT/$TARGET/include for cross). 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. What I meant above is that if you were to try to merge a musl-cross-make toolchain into /, you'd have two separate directories, /include containing the toolchain headers, and /usr/include containing the system library headers. gcc would only search for headers in /usr/include, and you couldn't use a symlink since both are separate directories with separate contents. To support this, you'd need to set --prefix=/usr and install musl headers to $SYSROOT/usr/include, but I think this is probably out of scope of musl-cross-make (at least, out of scope of this patch). Also note that the proposed patch does not conflict with a change like this, you'd just set --with-native-system-header-dir=$(PREFIX)/include instead. > At least relative to what I remember of my original intent. > But I'm doubtful that this was well thought out at all since the only > real intent at the time I added it was "can I make a compiler run on a > nommu j2?" where I didn't want to bootstrap a whole distro or have > anything serious actually compiled on the target where it would have > been prohibitively slow. I get that you're unhappy with the current state of musl-cross-make and NATIVE=1, and sure, there are probably some improvements to be made, but I think you're making this out to be trickier than it actually is. Once you have time to take a closer look at this, I think you'll find that it really is a simple issue of gcc searching the wrong directory by default.
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.