https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858
--- Comment #2 from Matthew Krupcale <mkrupcale at matthewkrupcale dot com> ---
I can confirm that I'm still observing this when building multilib bootstrap
GCC 4.8.3 using GCC 9.2.1 on Fedora 30[1,2]. I tried to verify this issue when
building GCC 6.4.1 (GLIBCXX_3.4.22, CXXABI_1.3.10), but it looks like it may
not require ABI from GCC 9.2.1 (i.e. GLIBCXX_3.4.26, CXXABI_1.3.11) and thus
does not fail in this way. So this likely is currently only observable when
building GCC < 5 which does not have CXXABI_1.3.9 with GCC >= 5. However, this
could change in the future if the host executables e.g. cc1{,plus}, lto1 ever
use features which change ABI.
Is it possible to verify that this is an issue on a theoretical level? When I
mentioned the issue on IRC, there was uncertainty as to how this situtation
would arise because it was suspected that the stage1 host programs already used
the build libstdc++. However, I do not believe this is the case because the
current Makefile adds at all stages the target libstdc++ to LD_LIBRARY_PATH and
thus ends up using the target libstdc++ (after it has been built) during stage1
target modules section, despite the fact that the stage1 host programs depend
on the build libstdc++. The above patches try to fix this.
Is there any additional information I can provide to help confirm or refute
this issue?
[1] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc/build/1040355/
[2] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc/build/1040368/
