From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 71793385842B; Thu, 2 Feb 2023 08:39:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 71793385842B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1675327153; bh=mysPIgpeuTPMQRi5ubhk5PJL6AgkV4umEsBG+Bp0JJE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pgzpdytrWHUTUS8kw3iYWBtIOF2bt3r5j+3wyajW3rn4c4O0/q5f40y+QIiHkL3hZ soNFwcMucEUPrPGcPM68xk77aBE7KEUK+GGm6OQqGq+kkzHlwYBPf1URedyge7HV+l NZ3I9sTS/M/vep/6TwLJ8mnHe4aEklPJEq3d6K5s= From: "a.heider at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET Date: Thu, 02 Feb 2023 08:39: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: 4.9.0 X-Bugzilla-Keywords: build, lto X-Bugzilla-Severity: enhancement X-Bugzilla-Who: a.heider at gmail dot com 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: 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=3D60160 Andre Heider changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |a.heider at gmail dot com --- Comment #8 from Andre Heider --- I tried this too, and so far I ran into this build failure: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108630 With --enable-symvers=3Dno as a workaround the build succeeds with a shared libstdc++. If I build the target's toolchain libraries with LTO (using {C,CXX,LD}FLAGS_FOR_TARGET), some userland apps fail to link with mold: mold: error: undefined symbol: __EH_FRAME_BEGIN__.lto_priv.0 Where as bfd links without errors. As per this bug's description "1. crtstuff.c: perhaps it'd be better to com= pile it with -fno-lto." I tried this patch: diff -ur a/libgcc/Makefile.in b/libgcc/Makefile.in --- a/libgcc/Makefile.in 2022-08-19 10:09:54.664689148 +0200 +++ b/libgcc/Makefile.in 2023-02-01 21:56:50.561528520 +0100 @@ -301,7 +301,7 @@ CRTSTUFF_CFLAGS =3D -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \ $(NO_PIE_CFLAGS) -finhibit-size-directive -fno-inline -fno-exceptions \ -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize \ - -fbuilding-libgcc -fno-stack-protector $(FORCE_EXPLICIT_EH_REGISTRY) \ + -fbuilding-libgcc -fno-stack-protector -fno-lto $(FORCE_EXPLICIT_EH_REGISTRY) \ $(INHIBIT_LIBC_CFLAGS) $(USE_TM_CLONE_REGISTRY) And then the mold linker can build the userland apps in question too. I only saw this later, but that's one hunk of the patch in comment #4. Is t= hat patch correct and worth commiting?=