From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4387E385841D; Wed, 24 Jan 2024 19:14:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4387E385841D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706123653; bh=XaEJ57OtudMZuxfpXPhNc/D1TFL0FuhHC7DEkft84jo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ejync3cvU+AbKexbMMnIv5q5aYu6hPpNEZiDOKrkZ6dDhYRG7X1xAxGlt26cLYT/m iEyTPXl6rJuWitP0+LKJJvhn3rfvRK0d5m0JyucOgorl4feD861IY0C37WDpa5ULoU viFOwIC/bYnuoi/Nt2wdErcQkgjSkj5LNHEe1wRA= From: "jason at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [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") Date: Wed, 24 Jan 2024 19:14:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Version: 11.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jason at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105688 Jason Merrill changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=3D41818 CC| |jason at gcc dot gnu.org --- Comment #46 from Jason Merrill --- The problematic line in the toplevel Makefile is $(RPATH_ENVVAR)=3D`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_EXPOR= TS, but didn't mention that in its ChangeLog. Which extended this issue to st= age1 builds as well. The rationale for doing this at all seems to be in order to make a just-bui= lt tool find the just-built shared libraries that it links agains, but this al= so affects pre-built tools that link against other versions of the same librar= ies. 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.i= n 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 wo= rry about system gcc. For the moment I think I'm just going to propose reverting that bit of the PR22340 fix.=