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? If you need to override the paths, you need to include *all* the relevant directories. > ./configure && make Don't build in the source dir. See https://gcc.gnu.org/wiki/InstallingGCC > > where /path/to/host/gcc points to the GCC used to build GCC. > > 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. > However, during libstdc++ configure, the host GCC’s > <bits/c++config.h> is not found, Because you only told it to look in two directories, neither of which contains that file. > leading to misdiagnostics like this > (here we’re building GCC 10.1 with GCC 7.5): > > --8<---------------cut here---------------start------------->8--- > configure:19924: checking for float trig functions > configure:19948: /tmp/guix-build-gcc-10.1.0.drv-0/build/./gcc/xgcc -shared-libgcc -B/tmp/guix-build-gcc-10.1.0.drv-0/build/./gcc -nostdinc++ -L/tmp/guix-build-gcc-10.1.0.drv-0/build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/tmp/guix-build-gcc-10.1.0.drv-0/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/tmp/guix-build-gcc-10.1.0.drv-0/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/gnu/store/jrzxs91zhpf6yr5fxisn3jjj7xai8zlk-gcc-10.1.0/x86_64-unknown-linux-gnu/bin/ -B/gnu/store/jrzxs91zhpf6yr5fxisn3jjj7xai8zlk-gcc-10.1.0/x86_64-unknown-linux-gnu/lib/ -isystem /gnu/store/jrzxs91zhpf6yr5fxisn3jjj7xai8zlk-gcc-10.1.0/x86_64-unknown-linux-gnu/include -isystem /gnu/store/jrzxs91zhpf6yr5fxisn3jjj7xai8zlk-gcc-10.1.0/x86_64-unknown-linux-gnu/sys-include -fno-checking -c -fno-builtin -D_GNU_SOURCE conftest.cpp >&5 > In file included from /gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/math.h:36, > from conftest.cpp:122: > /gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/cmath:41:10: fatal error: bits/c++config.h: No such file or directory > 41 | #include <bits/c++config.h> > | ^~~~~~~~~~~~~~~~~~ > compilation terminated. > configure:19948: $? = 1 > configure: failed program was: > > [...] > > | /* end confdefs.h. */ > | #include <math.h> > | int > | main () > | { > | acosf (0); asinf (0); atanf (0); cosf (0); sinf (0); tanf (0); coshf (0); sinhf (0); tanhf (0); > | ; > | return 0; > | } > configure:19962: result: no > --8<---------------cut here---------------end--------------->8--- > > ‘c++config.h’ is not found because it lives in a different directory > that’s not searched, ‘include/c++/x86_64-unknown-linux-gnu’. > (aka. ‘GPLUSPLUS_TOOL_INCLUDE_DIR’). > > So, how’s that supposed to work? I understand this kind of issue is > unlikely to show up on an FHS distro, but still, am I missing something? You should not be using CPLUS_INCLUDE_PATH like that. > > Thanks, > Ludo’. > > ¹ More details at <https://issues.guix.gnu.org/42392#2>.
