public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: "Ludovic Courtès" <ludovic.courtes@inria.fr>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: libstdc++ search path while building GCC
Date: Mon, 27 Jul 2020 17:32:10 +0100	[thread overview]
Message-ID: <CAH6eHdT183pF3xrMRf-waOQk=9k08jwCfgMijrie7BzXUFHNjg@mail.gmail.com> (raw)
In-Reply-To: <87lfjbgua3.fsf@inria.fr>

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>.

  reply	other threads:[~2020-07-27 16:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22 20:38 Ludovic Courtès
2020-07-27 16:32 ` Jonathan Wakely [this message]
2020-07-28 14:15   ` Ludovic Courtès
2020-07-28 14:21     ` Jonathan Wakely
2020-07-28 14:25       ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH6eHdT183pF3xrMRf-waOQk=9k08jwCfgMijrie7BzXUFHNjg@mail.gmail.com' \
    --to=jwakely.gcc@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=ludovic.courtes@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).