From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6BC2B3857359; Mon, 29 May 2023 18:10:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6BC2B3857359 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685383800; bh=dtjI5l1D/ZZyh4DU7Lr3kKw85SQbEXExsliIyfwBdTc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aYIuJHTUR43HnlE16qceSxkcozFQzcBQQ1ONfyAKsCG3bm7e1hKfJvU8+lBopIyCw Dm85c/Nhf/wsqPX5n8kslXILOrSGEQCuqTDqeLqFJ5x+OWTZr5TbGRegRelMj+Rg3b 4c5Ky789RuWwqw5OPq2RG6cLL58kgQauaulTLUZo= From: "mkrupcale at matthewkrupcale dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++ Date: Mon, 29 May 2023 18:10:00 +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: unknown X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: mkrupcale at matthewkrupcale dot com X-Bugzilla-Status: UNCONFIRMED 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: 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=3D87858 --- Comment #12 from Matthew Krupcale --- I've updated the patch to include the target libstdc++ path on LD_LIBRARY_P= ATH only after stage1 for both host and target module exports--that is, previou= sly, the patches only modified the LD_LIBRARY_PATH exports for target modules, whereas the new version does the same for host modules as well. This fixes = an issue I found while building GCC 7 on RHEL 9 in which the gotools host modu= le failed to build with similar ABI issues as described in this thread. See my copr repos [1,2] for both GCC 7 and 8 now both building with the respective patches on multiple OS (RHEL 9, Fedora 37, 38), architectures (aarch64, ppc64le, s390x, x86_64), and host GCC versions (11.3, 12.2, 13.0). (In reply to Libor Bukata from comment #4) > We also cannot build older GCC versions with GCC 11 nightly (commit > 8a6a62614a8ae) on Solaris Trunk: > ... >=20 > GLIBCXX_3.4.29 is a new addition to libstdc++.so.6 that is not available = in > older libstdc++.so.6 libraries of GCC 7, 9, and 10. Without the patches, I did also observe the issue Libor Bukata saw in comme= nt #4 while building GCC 7 or 8 with GCC 11. (In reply to Ed Gar from comment #9) > I confirm that the issue persists even when using either patch suggested = by > Matthew Krupcale. I was unable to reproduce your build issue with my patches. [1] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc-7/build/5787271/ [2] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc-8/build/5798225/=