libstdc++ search path while building GCC

libstdc++ search path while building GCC

[Ludovic Courtès]

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
  ./configure && make

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.  However, during libstdc++ configure, the host GCC’s
<bits/c++config.h> is not found, 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?

Thanks,
Ludo’.

¹ More details at <https://issues.guix.gnu.org/42392#2>.

Re: libstdc++ search path while building GCC

[Jonathan Wakely]

On Wed, 22 Jul 2020 at 21:39, Ludovic Courtès <ludovic.courtes@inria.fr> 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>.

Re: libstdc++ search path while building GCC

[Ludovic Courtès]

Hi,

Jonathan Wakely <jwakely.gcc@gmail.com> skribis:

> On Wed, 22 Jul 2020 at 21:39, Ludovic Courtès <ludovic.courtes@inria.fr> 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?

Thanks for your feedback!

Ludo’.

Re: libstdc++ search path while building GCC

[Jonathan Wakely]

On Tue, 28 Jul 2020 at 15:15, Ludovic Courtès <ludovic.courtes@inria.fr> wrote:
>
> Hi,
>
> Jonathan Wakely <jwakely.gcc@gmail.com> skribis:
>
> > On Wed, 22 Jul 2020 at 21:39, Ludovic Courtès <ludovic.courtes@inria.fr> 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.

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.

Re: libstdc++ search path while building GCC

[Jonathan Wakely]

On Tue, 28 Jul 2020 at 15:21, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Tue, 28 Jul 2020 at 15:15, Ludovic Courtès <ludovic.courtes@inria.fr> wrote:
> >
> > Hi,
> >
> > Jonathan Wakely <jwakely.gcc@gmail.com> skribis:
> >
> > > On Wed, 22 Jul 2020 at 21:39, Ludovic Courtès <ludovic.courtes@inria.fr> 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.