[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[mkrupcale at matthewkrupcale dot com]

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/

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[libor.bukata at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

Libor Bukata <libor.bukata at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |libor.bukata at oracle dot com

--- Comment #4 from Libor Bukata <libor.bukata at oracle dot com> ---
We also cannot build older GCC versions with GCC 11 nightly (commit
8a6a62614a8ae) on Solaris Trunk:

/builds/gcc_nightly_full_build/components/gcc10/build/amd64/./gcc/xgcc
-shared-libgcc
-B/builds/gcc_nightly_full_build/components/gcc10/build/amd64/./gcc -nostdinc++
-L/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/src
-L/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/src/.libs
-L/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/libsupc++/.libs
-B/usr/gcc/10/x86_64-pc-solaris2.11/bin/
-B/usr/gcc/10/x86_64-pc-solaris2.11/lib/ -isystem
/usr/gcc/10/x86_64-pc-solaris2.11/include -isystem
/usr/gcc/10/x86_64-pc-solaris2.11/sys-include -fno-checking  -m32 -x c++-header
-nostdinc++ -g -O2  -m32 
-I/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/include/x86_64-pc-solaris2.11
-I/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/include
-I/builds/gcc_nightly_full_build/components/gcc10/gcc-10.2.0/libstdc++-v3/libsupc++
 -O2 -g -std=gnu++0x
/builds/gcc_nightly_full_build/components/gcc10/gcc-10.2.0/libstdc++-v3/include/precompiled/stdc++.h
\
-o x86_64-pc-solaris2.11/bits/stdc++.h.gch/O2ggnu++0x.gch
ld.so.1: cc1plus: fatal: libstdc++.so.6: version 'GLIBCXX_3.4.29' not found
(required by file
/builds/gcc_nightly_full_build/components/gcc10/build/amd64/gcc/cc1plus)
ld.so.1: cc1plus: fatal:
/builds/gcc_nightly_full_build/components/gcc10/build/amd64/gcc/cc1plus:
mismatched ELF symbol versioning
xgcc: fatal error: Killed signal terminated program cc1plus

GLIBCXX_3.4.29 is a new addition to libstdc++.so.6 that is not available in
older libstdc++.so.6 libraries of GCC 7, 9, and 10.

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Best way to support this really is to build a 4.8 cross compiler and then build
a canandian cross GCC 4.8 and then bootstrap a 4.8.x using that newly build
canandian cross compiler.

New enough GCC uses -static-libstdc++ and that avoids the shared library
problem mentioned here.

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[mkrupcale at matthewkrupcale dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

--- Comment #6 from Matthew Krupcale <mkrupcale at matthewkrupcale dot com> ---
(In reply to Andrew Pinski from comment #5)
> Best way to support this really is to build a 4.8 cross compiler and then
> build a canandian cross GCC 4.8 and then bootstrap a 4.8.x using that newly
> build canandian cross compiler.

I'm not sure I follow exactly because I wasn't trying to build a cross
compiler, although I suppose once you have a GCC 4.8 compiler built (cross or
not), you wouldn't have a problem building 4.8.x with it in theory. But the
problem is building that initial GCC 4.8 (cross or not) with the newer GCC
version.

> New enough GCC uses -static-libstdc++ and that avoids the shared library
> problem mentioned here.

This won't help during stage1 of the bootstrap build if you don't have the
static libstdc++ library installed on the build host. Once the static libstdc++
library is built, this problem won't happen during the later stages. For
stage1, however, GCC will currently attempt to use the build host libstdc++ and
its newer symbols for building host executables. When the old libstdc++ is
built then--and in the absence of a static libstdc++ on the build host--the
host executables will fail to load due to the old libstdc++ being on
LD_LIBRARY_PATH and lacking the newer symbols required by the host executables.

Note that as far as I'm aware, this issue still exists in modern versions of
GCC and is not exclusive to building only GCC 4.8. As shown by comment 3 and
comment 4, this problem is demonstrable by building GCC v8.2.1 or v10 with GCC
11 and possibly other versions. I was also able to confirm in comment 3 that my
patch for GCC 8.2 did resolve the issue when building with GCC 11.

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Matthew Krupcale from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > Best way to support this really is to build a 4.8 cross compiler and then
> > build a canandian cross GCC 4.8 and then bootstrap a 4.8.x using that newly
> > build canandian cross compiler.
> 
> I'm not sure I follow exactly because I wasn't trying to build a cross
> compiler, although I suppose once you have a GCC 4.8 compiler built (cross
> or not), you wouldn't have a problem building 4.8.x with it in theory. But
> the problem is building that initial GCC 4.8 (cross or not) with the newer
> GCC version.


You misunderstood.  Building a cross compiler and a canadian cross is so the
new 4.8 compiler is NOT exposing to the bootstrap issue you mentioned.

4.8 and 8.x are no longer maintained so fixing those are out of the question.
stage1 of gcc does not require the LD_LIBRARY_PATH to be set at all and stage 2
and 3 will use -static-libstdc++.

Of course LD_LIBRARY_PATH shouldn't be needed these days.

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[mkrupcale at matthewkrupcale dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

--- Comment #8 from Matthew Krupcale <mkrupcale at matthewkrupcale dot com> ---
(In reply to Andrew Pinski from comment #7)
> You misunderstood.  Building a cross compiler and a canadian cross is so the
> new 4.8 compiler is NOT exposing to the bootstrap issue you mentioned.

Fair enough, that seems likely to work as well. But you still need to build
that initial compiler with the newer compiler.

> 4.8 and 8.x are no longer maintained so fixing those are out of the question.

I'm not suggesting to patch 4.8 or 8.x series. I'm suggesting that the issue
still likely exists on the latest GCC. Of course you won't be able to verify
that unless you intentionally create some new ABI in libstdc++ which is also
used by the host programs and then try to build the old ABI libstdc++ with the
the new one on the build host. That's why it took so long to verify that GCC 8
had the issue (as well as all versions between 4.8 and 8) and is likely still
in the latest version.

> stage1 of gcc does not require the LD_LIBRARY_PATH to be set at all

I may be using the wrong name--perhaps it's not LD_LIBRARY_PATH specifically,
but the effect is similar. My patch actually modifies the RPATH_ENVVAR to not
include the target libstdc++ path during stage1 of the bootstrap since the
stage1 host binaries depend on the build host libstdc++. Then in stages 2 and 3
the RPATH_ENVVAR can include the target libstdc++ path and build successfully.

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[edgargar at unam dot mx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

Ed Gar <edgargar at unam dot mx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |edgargar at unam dot mx

--- Comment #9 from Ed Gar <edgargar at unam dot mx> ---
I confirm that the issue persists even when using either patch suggested by
Matthew Krupcale. I am tried to compile gcc 8.2.0 using gcc 11.3.1 on Fedora 34
following the command:

cd gcc-8.2.0
contrib/download_prerequisites
patch -b < makefile.patch
cd ../build-gcc-82
../gcc-8.2.0/configure --prefix=/usr/local/gcc82 --program-suffix=82
--enable-languages=c,c++,fortran --disable-multilib --disable-libstdcxx-pch
--with-system-zlib
make

where makefile.patch is either of the proposed patches. After a while the
building process produces the following error:

make[5]: Entering directory '/root/build-gcc-8.2/x86_64-pc-linux-gnu/libgomp'
makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000  -I
../../../gcc-8.2.0/libgomp/../gcc/doc/include -I ../../../gcc-8.2.0/libgomp -o
libgomp.info ../../../gcc-8.2.0/libgomp/libgomp.texi
/bin/sh ./libtool --tag=CC   --mode=compile /root/build-gcc-8.2/./gcc/xgcc
-B/root/build-gcc-8.2/./gcc/ -B/usr/local/gcc82/x86_64-pc-linux-gnu/bin/
-B/usr/local/gcc82/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/gcc82/x86_64-pc-linux-gnu/include -isystem
/usr/local/gcc82/x86_64-pc-linux-gnu/sys-include    -DHAVE_CONFIG_H -I.
-I../../../gcc-8.2.0/libgomp  -I../../../gcc-8.2.0/libgomp/config/linux/x86
-I../../../gcc-8.2.0/libgomp/config/linux
-I../../../gcc-8.2.0/libgomp/config/posix -I../../../gcc-8.2.0/libgomp
-I../../../gcc-8.2.0/libgomp/../include  -Wall -Werror -ftls-model=initial-exec
-Wc,-pthread  -g -O2 -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c -o alloc.lo
../../../gcc-8.2.0/libgomp/alloc.c
libtool: compile:  /root/build-gcc-8.2/./gcc/xgcc -B/root/build-gcc-8.2/./gcc/
-B/usr/local/gcc82/x86_64-pc-linux-gnu/bin/
-B/usr/local/gcc82/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/gcc82/x86_64-pc-linux-gnu/include -isystem
/usr/local/gcc82/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-8.2.0/libgomp -I../../../gcc-8.2.0/libgomp/config/linux/x86
-I../../../gcc-8.2.0/libgomp/config/linux
-I../../../gcc-8.2.0/libgomp/config/posix -I../../../gcc-8.2.0/libgomp
-I../../../gcc-8.2.0/libgomp/../include -Wall -Werror -pthread
-ftls-model=initial-exec -g -O2 -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c
../../../gcc-8.2.0/libgomp/alloc.c  -fPIC -DPIC -o .libs/alloc.o
/root/build-gcc-8.2/./gcc/cc1:
/root/build-gcc-8.2/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6:
version `GLIBCXX_3.4.29' not found (required by /root/build-gcc-8.2/./gcc/cc1)

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[mkrupcale at matthewkrupcale dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

--- Comment #10 from Matthew Krupcale <mkrupcale at matthewkrupcale dot com> ---
Created attachment 55186
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55186&action=edit
GCC 7 post stage1 libstdc++ path export patch

This patch is for GCC 7 and exports the target libstdc++ path on
LD_LIBRARY_PATH only after stage1 for both host and target modules.

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[mkrupcale at matthewkrupcale dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

Matthew Krupcale <mkrupcale at matthewkrupcale dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #44945|0                           |1
        is obsolete|                            |

--- Comment #11 from Matthew Krupcale <mkrupcale at matthewkrupcale dot com> ---
Created attachment 55187
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55187&action=edit
GCC 8 post stage1 libstdc++ path export patch

This patch is for GCC 8 and exports the target libstdc++ path on
LD_LIBRARY_PATH only after stage1 for both host and target modules.

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[mkrupcale at matthewkrupcale dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

--- Comment #12 from Matthew Krupcale <mkrupcale at matthewkrupcale dot com> ---
I've updated the patch to include the target libstdc++ path on LD_LIBRARY_PATH
only after stage1 for both host and target module exports--that is, previously,
the patches only modified the LD_LIBRARY_PATH exports for target modules,
whereas the new version does the same for host modules as well. This fixes an
issue I found while building GCC 7 on RHEL 9 in which the gotools host module
failed to build with similar ABI issues as described in this thread.

See my copr repos [1,2] for both GCC 7 and 8 now both building with the
respective patches on multiple OS (RHEL 9, Fedora 37, 38), architectures
(aarch64, ppc64le, s390x, x86_64), and host GCC versions (11.3, 12.2, 13.0).

(In reply to Libor Bukata from comment #4)
> We also cannot build older GCC versions with GCC 11 nightly (commit
> 8a6a62614a8ae) on Solaris Trunk:
> ...
> 
> GLIBCXX_3.4.29 is a new addition to libstdc++.so.6 that is not available in
> older libstdc++.so.6 libraries of GCC 7, 9, and 10.

Without the patches, I did also observe the issue Libor Bukata saw in comment
#4 while building GCC 7 or 8 with GCC 11.

(In reply to Ed Gar from comment #9)
> I confirm that the issue persists even when using either patch suggested by
> Matthew Krupcale.

I was unable to reproduce your build issue with my patches.

[1] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc-7/build/5787271/
[2] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc-8/build/5798225/

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eyalroz1 at gmx dot com

--- Comment #13 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
*** Bug 113177 has been marked as a duplicate of this bug. ***

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |xry111 at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-12-30

--- Comment #14 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Confirm as this has been asked via gcc-help multiple times.

A possible work around is to install the static libstdc++ (libstdc++.a)
provided by the distro.  But this is not documented anywhere and it's still
just a work around, not a fix.

Note that patches should be sent to gcc-patches@gcc.gnu.org instead of (or in
addition to) posting here.  The patches in bugzilla generally do not get any
review seriously.

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[eyalroz1 at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858

--- Comment #15 from Eyal Rozenberg <eyalroz1 at gmx dot com> ---
Note that:

* in apt-based distributions such as Debian, the relevant package would be
lib32stdc++-dev , or a similar name with the GCC version, e.g.
lib32stdc++-11-dev .

* Even when this particular issue is worked-around, the GCC build may still
fail for another reason (e.g. incompatibility of the sanitizer library with
your newer system see bug 113181).