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.
