[Bug libstdc++/108630] New: build failure with LTO enabled

[Bug libstdc++/108630] New: build failure with LTO enabled

[a.heider at gmail dot com]

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

[a.heider at gmail dot com]

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 :)

[Bug libstdc++/108630] build failure with LTO enabled

[a.heider at gmail dot com]

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.

[Bug libstdc++/108630] build failure with LTO enabled

[redi at gcc dot gnu.org]

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

[Bug libstdc++/108630] build failure with LTO enabled

[a.heider at gmail dot com]

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
;)

[Bug libstdc++/108630] build failure with LTO enabled

[redi at gcc dot gnu.org]

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++.

[Bug libstdc++/108630] build failure with LTO enabled

[redi at gcc dot gnu.org]

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.

[Bug libstdc++/108630] build failure with LTO enabled

[redi at gcc dot gnu.org]

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.