public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/108630] New: build failure with LTO enabled
@ 2023-02-01 13:06 a.heider at gmail dot com
2023-02-01 13:09 ` [Bug libstdc++/108630] " a.heider at gmail dot com
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: a.heider at gmail dot com @ 2023-02-01 13:06 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/108630] build failure with LTO enabled
2023-02-01 13:06 [Bug libstdc++/108630] New: build failure with LTO enabled a.heider at gmail dot com
@ 2023-02-01 13:09 ` a.heider at gmail dot com
2023-02-01 13:22 ` a.heider at gmail dot com
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: a.heider at gmail dot com @ 2023-02-01 13:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
--- Comment #1 from Andre Heider <a.heider at gmail dot com> ---
Forgot to mention:
CXXFLAGS_FOR_TARGET="$CFLAGS_FOR_TARGET"
Obviously :)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/108630] build failure with LTO enabled
2023-02-01 13:06 [Bug libstdc++/108630] New: build failure with LTO enabled a.heider at gmail dot com
2023-02-01 13:09 ` [Bug libstdc++/108630] " a.heider at gmail dot com
@ 2023-02-01 13:22 ` a.heider at gmail dot com
2023-02-01 20:55 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: a.heider at gmail dot com @ 2023-02-01 13:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
--- Comment #2 from Andre Heider <a.heider at gmail dot com> ---
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/108630] build failure with LTO enabled
2023-02-01 13:06 [Bug libstdc++/108630] New: build failure with LTO enabled a.heider at gmail dot com
2023-02-01 13:09 ` [Bug libstdc++/108630] " a.heider at gmail dot com
2023-02-01 13:22 ` a.heider at gmail dot com
@ 2023-02-01 20:55 ` redi at gcc dot gnu.org
2023-02-02 10:30 ` a.heider at gmail dot com
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2023-02-01 20:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |build, lto
Ever confirmed|0 |1
Last reconfirmed| |2023-02-01
Status|UNCONFIRMED |NEW
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/108630] build failure with LTO enabled
2023-02-01 13:06 [Bug libstdc++/108630] New: build failure with LTO enabled a.heider at gmail dot com
` (2 preceding siblings ...)
2023-02-01 20:55 ` redi at gcc dot gnu.org
@ 2023-02-02 10:30 ` a.heider at gmail dot com
2023-02-06 14:13 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: a.heider at gmail dot com @ 2023-02-02 10:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
--- Comment #3 from Andre Heider <a.heider at gmail dot com> ---
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
;)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/108630] build failure with LTO enabled
2023-02-01 13:06 [Bug libstdc++/108630] New: build failure with LTO enabled a.heider at gmail dot com
` (3 preceding siblings ...)
2023-02-02 10:30 ` a.heider at gmail dot com
@ 2023-02-06 14:13 ` redi at gcc dot gnu.org
2023-02-28 13:11 ` redi at gcc dot gnu.org
2023-03-03 9:35 ` redi at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2023-02-06 14:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
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++.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/108630] build failure with LTO enabled
2023-02-01 13:06 [Bug libstdc++/108630] New: build failure with LTO enabled a.heider at gmail dot com
` (4 preceding siblings ...)
2023-02-06 14:13 ` redi at gcc dot gnu.org
@ 2023-02-28 13:11 ` redi at gcc dot gnu.org
2023-03-03 9:35 ` redi at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2023-02-28 13:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=92192
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/108630] build failure with LTO enabled
2023-02-01 13:06 [Bug libstdc++/108630] New: build failure with LTO enabled a.heider at gmail dot com
` (5 preceding siblings ...)
2023-02-28 13:11 ` redi at gcc dot gnu.org
@ 2023-03-03 9:35 ` redi at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2023-03-03 9:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-03-03 9:35 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-01 13:06 [Bug libstdc++/108630] New: build failure with LTO enabled a.heider at gmail dot com
2023-02-01 13:09 ` [Bug libstdc++/108630] " a.heider at gmail dot com
2023-02-01 13:22 ` a.heider at gmail dot com
2023-02-01 20:55 ` redi at gcc dot gnu.org
2023-02-02 10:30 ` a.heider at gmail dot com
2023-02-06 14:13 ` redi at gcc dot gnu.org
2023-02-28 13:11 ` redi at gcc dot gnu.org
2023-03-03 9:35 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).