public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "mkrupcale at matthewkrupcale dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++
Date: Mon, 21 Dec 2020 18:36:55 +0000 [thread overview]
Message-ID: <bug-87858-4-e59zscdkx9@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-87858-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858
--- Comment #3 from Matthew Krupcale <mkrupcale at matthewkrupcale dot com> ---
I now observe this failure in the following two circumstances building multilib
bootstrap GCC:
- GCC 4.8.3 using GCC 10.2.1-9 on Fedora 33[1]
/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/./gcc/xgcc
-shared-libgcc
-B/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/./gcc
-nostdinc++
-L/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/src
-L/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/src/.libs
-B/usr/x86_64-redhat-linux/bin/ -B/usr/x86_64-redhat-linux/lib/ -isystem
/usr/x86_64-redhat-linux/include -isystem /usr/x86_64-redhat-linux/sys-include
-m32 -x c++-header -nostdinc++ -O2 -g -grecord-gcc-switches -Wformat
-Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic
-fasynchronous-unwind-tables -D_GNU_SOURCE -m32
-I/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/include/x86_64-redhat-linux
-I/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/include
-I/builddir/build/BUILD/gcc-4.8.3-20140911/libstdc++-v3/libsupc++ -O2 -g
/builddir/build/BUILD/gcc-4.8.3-20140911/libstdc++-v3/include/precompiled/stdc++.h
-o x86_64-redhat-linux/bits/stdc++.h.gch/O2g.gch
/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/./gcc/cc1plus:
/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/src/.libs/libstdc++.so.6:
version `CXXABI_1.3.9' not found (required by
/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/./gcc/cc1plus)
- GCC 8.2.1 using GCC 11.0.0-0.7 on Fedora 34[2]
/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/./gcc/xgcc
-shared-libgcc
-B/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/./gcc
-nostdinc++
-L/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/src
-L/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/src/.libs
-L/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/libsupc++/.libs
-B/usr/x86_64-redhat-linux/bin/ -B/usr/x86_64-redhat-linux/lib/ -isystem
/usr/x86_64-redhat-linux/include -isystem /usr/x86_64-redhat-linux/sys-include
-m32 -x c++-header -nostdinc++ -O2 -g -grecord-gcc-switches -Wformat
-Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-D_GNU_SOURCE -m32
-I/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/include/x86_64-redhat-linux
-I/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/include
-I/builddir/build/BUILD/gcc-8.2.1-20181215/libstdc++-v3/libsupc++ -O2 -g
/builddir/build/BUILD/gcc-8.2.1-20181215/libstdc++-v3/include/precompiled/stdc++.h
-o x86_64-redhat-linux/bits/stdc++.h.gch/O2g.gch
/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/./gcc/cc1plus:
/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/src/.libs/libstdc++.so.6:
version `GLIBCXX_3.4.29' not found (required by
/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/./gcc/cc1plus)
Furthermore, the build is successful when applying the aforementioned patches
to their respective versions:
- patched GCC 4.8.3 using GCC 10.2.1-9 on Fedora 33[3]
- patched GCC 8.2.1 using GCC 11.0.0-0.7 on Fedora 34[4]
Thus, I can validate my remarks in comment 0 and comment 2 that this does not
only apply to GCC 4.8.3 but also to other (future) versions of GCC. In
particular, I have now successfully tested the GCC 8.2 patch of comment 1. It
took some time to demonstrate this because, for example, building unpatched GCC
8.2.1 is successful on F33 with GCC 10.2.1-9[2] but fails in this way on F34
with GCC 11.0.0-0.7[2].
As far as I can tell, this issue still applies to the latest GCC. That is,
stage1 host modules attempt to use the stage1 target libstdc++ when they should
instead use the build libstdc++.
[1] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc/build/1843629/
[2] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc-8/build/1843814/
[3] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc/build/1843525/
[4] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc-8/build/1843815/
next parent reply other threads:[~2020-12-21 18:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-87858-4@http.gcc.gnu.org/bugzilla/>
2020-12-21 18:36 ` mkrupcale at matthewkrupcale dot com [this message]
2021-04-01 13:48 ` libor.bukata at oracle dot com
2021-07-24 20:31 ` pinskia at gcc dot gnu.org
2021-07-24 22:07 ` mkrupcale at matthewkrupcale dot com
2021-07-24 22:23 ` pinskia at gcc dot gnu.org
2021-07-24 23:18 ` mkrupcale at matthewkrupcale dot com
2022-06-18 23:13 ` edgargar at unam dot mx
2023-05-29 17:59 ` mkrupcale at matthewkrupcale dot com
2023-05-29 18:00 ` mkrupcale at matthewkrupcale dot com
2023-05-29 18:10 ` mkrupcale at matthewkrupcale dot com
2023-12-30 11:57 ` xry111 at gcc dot gnu.org
2023-12-30 12:02 ` xry111 at gcc dot gnu.org
2023-12-30 19:32 ` eyalroz1 at gmx dot com
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=bug-87858-4-e59zscdkx9@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/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).