[Bug libstdc++/108630] New: build failure with LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630 Bug ID: 108630 Summary: build failure with LTO enabled Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: a.heider at gmail dot com Target Milestone: --- This is happening when attempting to build a cross compiler with: CFLAGS_FOR_TARGET="-flto=auto -ffat-lto-objects" LDFLAGS_FOR_TARGET="-flto=auto -fuse-linker-plugin" The assembler errors out when building libstdc++ with: Error: invalid attempt to declare external version name as default in symbol `_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv@@GLIBCXX_3.4.5' The build succeed when building with an additional --enable-symvers=no on top. libstdc++ may need the same treatment as seen e.g. here: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=f4be26838dc9937a4ae3e9cf4fbec50efd7786a2
[Bug libstdc++/108630] build failure with LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630 --- Comment #1 from Andre Heider --- Forgot to mention: CXXFLAGS_FOR_TARGET="$CFLAGS_FOR_TARGET" Obviously :)
[Bug libstdc++/108630] build failure with LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630 --- Comment #2 from Andre Heider --- Additionally, LDFLAGS_FOR_TARGET isn't part of the configure help: ./configure --help|grep FOR_TARGET LD_FOR_TARGET is, attempting to shove LTO in there yields other problems (or I am be doing it wrong). I only found LDFLAGS_FOR_TARGET via grep. If that isn't by intention it would be nice to add it there too.
[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160
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=108630
With --enable-symvers=no 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 compile
it with -fno-lto." I tried this patch:
diff -ur a/libgcc/Makefile.in b/libgcc/Makefile.in
--- a/libgcc/Makefile.in2022-08-19 10:09:54.664689148 +0200
+++ b/libgcc/Makefile.in2023-02-01 21:56:50.561528520 +0100
@@ -301,7 +301,7 @@
CRTSTUFF_CFLAGS = -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 that
patch correct and worth commiting?
[Bug libstdc++/108630] build failure with LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630 --- Comment #3 from Andre Heider --- While this is a libstdc++ related LTO issue, there's at least another libgcc one, see the linked bug #60160. With the workaround here and the patch there the LTOed target libraries look alot more sane, but I can't judge if that solves everything that needs to be solved. Based on some light testing on qemu that's at least a "works for me now" state ;)
[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160 --- Comment #9 from Andre Heider --- See also https://github.com/rui314/mold/issues/977 mold v1.10.1 can't handle crt files which are built with LTO enabled. But it sounds more like LTO on crt as-is produces the wrong thing? __EH_FRAME_BEGIN__.lto_priv.0 resides in .eh_frame then.
