From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BAA7B3857824; Sat, 24 Jul 2021 22:07:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BAA7B3857824 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: Sat, 24 Jul 2021 22:07:07 +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: RESOLVED X-Bugzilla-Resolution: WONTFIX 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 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: Sat, 24 Jul 2021 22:07:07 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D87858 --- Comment #6 from Matthew Krupcale = --- (In reply to Andrew Pinski from comment #5) > Best way to support this really is to build a 4.8 cross compiler and then > build a canandian cross GCC 4.8 and then bootstrap a 4.8.x using that new= ly > build canandian cross compiler. I'm not sure I follow exactly because I wasn't trying to build a cross compiler, although I suppose once you have a GCC 4.8 compiler built (cross = or not), you wouldn't have a problem building 4.8.x with it in theory. But the problem is building that initial GCC 4.8 (cross or not) with the newer GCC version. > New enough GCC uses -static-libstdc++ and that avoids the shared library > problem mentioned here. This won't help during stage1 of the bootstrap build if you don't have the static libstdc++ library installed on the build host. Once the static libst= dc++ library is built, this problem won't happen during the later stages. For stage1, however, GCC will currently attempt to use the build host libstdc++= and its newer symbols for building host executables. When the old libstdc++ is built then--and in the absence of a static libstdc++ on the build host--the host executables will fail to load due to the old libstdc++ being on LD_LIBRARY_PATH and lacking the newer symbols required by the host executab= les. Note that as far as I'm aware, this issue still exists in modern versions of GCC and is not exclusive to building only GCC 4.8. As shown by comment 3 and comment 4, this problem is demonstrable by building GCC v8.2.1 or v10 with = GCC 11 and possibly other versions. I was also able to confirm in comment 3 tha= t my patch for GCC 8.2 did resolve the issue when building with GCC 11.=