https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
--- Comment #6 from Jonathan Wakely ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
--- Comment #4 from Jonathan Wakely ---
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++.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
Jonathan Wakely changed:
What|Removed |Added
Keywords||build, lto
Ever confirmed|0
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
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 :)
