From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6128A3856250; Mon, 23 May 2022 15:27:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6128A3856250 From: "amonakov at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36 Date: Mon, 23 May 2022 15:27:52 +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: amonakov at gcc dot gnu.org X-Bugzilla-Status: WAITING 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: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2022 15:27:52 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105688 Alexander Monakov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amonakov at gcc dot gnu.org --- Comment #12 from Alexander Monakov --- (In reply to Andrew Pinski from comment #7) > /usr/bin/ld: > /tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: > version `GLIBCXX_3.4.30' not found (required by /usr/bin/ld) >=20 >=20 > The problem is not realted to GCC directly but rather ld being linked > against a newer version of libstdc++ and now you just compiled an older > version of libstdc++ and that is in the LD_LIBRARY_PATH some how ... Whi= ch > should not happen .... Could libtool be erroneously populating LD_LIBRARY_PATH? > If anything this should be reported to binutils and have ld (I suspect go= ld > here) use -static-libstdc++ -static-libgcc while linking just the same way > GCC does. No, this doesn't make sense, ld shouldn't work around wrong LD_LIBRARY_PATH setting.=