On Tue, 28 Jul 2020 at 15:21, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > > On Tue, 28 Jul 2020 at 15:15, Ludovic Courtès <ludovic.courtes@xxxxxxxx> wrote: > > > > Hi, > > > > Jonathan Wakely <jwakely.gcc@xxxxxxxxx> skribis: > > > > > On Wed, 22 Jul 2020 at 21:39, Ludovic Courtès <ludovic.courtes@xxxxxxxx> wrote: > > >> > > >> Hello, > > >> > > >> While building GCC on a non-FHS distro, we do something like¹: > > >> > > >> export CPLUS_INCLUDE_PATH=/path/to/host/gcc/include/c++:/path/to/host/gcc/include > > > > > > That looks wrong. Why are you doing this? Doesn't your host GCC > > > already know where its headers are? > > > > It does. With Guix, CPLUS_INCLUDE_PATH is automatically populated with > > all the include/ and include/c++/ directories of dependencies, which > > includes GCC’s own libstdc++. We could override that, but I’m trying to > > understand what’s going on. > > > > >> This ensures the host GCC’s C++ headers are found by ‘xgcc’ during > > >> build. > > > > > > Why do you want that to happen? > > > > > > It's wrong in general, but it's specifically wrong in your case > > > because the host compiler is a different version to the one you're > > > trying to build. There is absolutely no guarantee that GCC 10.1 can > > > compile the libstdc++ headers from GCC 7.5, and trying to do so is not > > > supported. > > > > Is it wrong? I’m talking about the first time where > > ‘libstdc++-v3/configure’ runs, which itself checks for C++ features. > > It’s checking for C++ features of the host compiler/C++ library, isn’t it? > > No. Building libstdc++ is done with the GCC that's just been built, > not with the host compiler. > > You can see that for yourself, because te error you showed was running > /tmp/guix-build-gcc-10.1.0.drv-0/build/./gcc/xgcc and that's not the > host compiler, that's the one that's just been built. Also, if the host compiler was used, how would you be able to build libstdc++ for a cross-compiler? You'd end up with a libstdc++.so built for the host, but it's a target library. > I think the problem is that CPLUS_INCLUDE_PATH affects both the host > compiler, and the newly-built one. I don't see how you can use an > environment variable to set include paths to C++ headers that are > valid for both compilers at once. Because no set of libstdc++ headers > is valid for both GCC 7.5 and 10.1 at the same time. If you really must use CPLUS_INCLUDE_PATH then I would suggest creating a wrapper script for the host g++ and then using that as the host compiler: #!/bin/bash export CPLUS_INCLUDE_PATH=/path/to/host/gcc/include/c++:/path/to/host/gcc/include exec /path/to/host/gcc/bin/g++ "$@" Now the environment variable will only be set in the environment of the /path/to/host/gcc/bin/g++ processes, and not the new xgcc processes that are used when building libstdc++ and other target libraries.
