[Bug bootstrap/105688] GCC breaks build process if bootstrapping a downgraded GCC (was "GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found")

["jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=41818
                 CC|                            |jason at gcc dot gnu.org

--- Comment #46 from Jason Merrill <jason at gcc dot gnu.org> ---
The problematic line in the toplevel Makefile is

        $(RPATH_ENVVAR)=`echo "$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed
's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \

The patch for PR22340 moved this from POSTSTAGE1_HOST_EXPORTS to HOST_EXPORTS,
but didn't mention that in its ChangeLog.   Which extended this issue to stage1
builds as well.

The rationale for doing this at all seems to be in order to make a just-built
tool find the just-built shared libraries that it links agains, but this also
affects pre-built tools that link against other versions of the same libraries.

And it doesn't justify adding target libraries in stage1.

For bfd/opcodes, it would seem better to set LD_LIBRARY_PATH in exec-tool.in so
that it only affects those tools specifically.  But if the new gcc links
against shared libmpc and such, that won't work, since if we set
LD_LIBRARY_PATH for gcc it's also set for the other tools it calls.

A fix for various system binutils might be to use exec-tool.in to splice out
the build directory from LD_LIBRARY_PATH.  But again, that won't help with my
system gcc.

I'm not sure what the best approach is for stage2+, where you might need to
load the previous libstdc++ for just-built tools.  I guess the splicing in
exec-tool.in would cover that as well, and in that case we don't need to worry
about system gcc.

For the moment I think I'm just going to propose reverting that bit of the
PR22340 fix.