Bug 108630 - build failure with LTO enabled
Summary: build failure with LTO enabled
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 12.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: build, lto
Depends on:
Blocks:
 
Reported: 2023-02-01 13:06 UTC by Andre Heider
Modified: 2023-03-03 09:35 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2023-02-01 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andre Heider 2023-02-01 13:06:41 UTC
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
Comment 1 Andre Heider 2023-02-01 13:09:38 UTC
Forgot to mention:
CXXFLAGS_FOR_TARGET="$CFLAGS_FOR_TARGET"

Obviously :)
Comment 2 Andre Heider 2023-02-01 13:22:22 UTC
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.
Comment 3 Andre Heider 2023-02-02 10:30:43 UTC
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 ;)
Comment 4 Jonathan Wakely 2023-02-06 14:13:34 UTC
The uses of .symver in src/c++98/compatibility.cc are hard to change, so this isn't going to be fixed any time soon.

I suggest simply not using LTO for libstdc++.
Comment 5 Jonathan Wakely 2023-02-28 13:11:56 UTC
(In reply to Jonathan Wakely from comment #4)
> I suggest simply not using LTO for libstdc++.

LTO will almost certainly break src/c++98/globals_io.cc so I don'tthink we can support building libstdc++ with LTO for now.
Comment 6 Jonathan Wakely 2023-03-03 09:35:10 UTC
(In reply to Jonathan Wakely from comment #5)
> LTO will almost certainly break src/c++98/globals_io.cc so I don'tthink we
> can support building libstdc++ with LTO for now.

And would probably break the fake dependency we create in std::thread creation, where we pass &pthread_create to an extern function inside the library, which doesn't use it. With LTO the fact it's unused would be visible, and the link-time dependency would be removed.