Xi Ruoyao wrote on 06/15/2018 11:57 AM:
On 2018-06-15 11:31 +0200, U.Mutlu wrote:
I tried to use -flto in CXXFLAGS_FOR_TARGET. It successfully built the compilers,
but later when trying to use the compilers, the linker reported an error about
something missing and aborted the linking.
PR 48200 renders shared libraries with versioned symbols (".symver") unusable if it
was built with -flto. libstdc++ is affected.
Of course the rationale was to optimize the compiler itself.
So, the question is: does it not make any sense to use -flto for the build itself?
(Or should one specify -flto in some of the other config variables like
CXXFLAGS_FOR_BUILD and/or the ...FLAGS vars maybe?)
Use --with-build-config=bootstrap-lto.
"C(XX)FLAGS_FOR_BUILD=-flto" also makes sense (see PR 59893). But you should use
--disable-shared and build the shared libraries w/o LTO, at least for now to
workaround PR 48200. And you should use patch to workaround PR 60160.
Thanks, also for the useful references.
The patch is somewhat old (from 2014), and applies only partially
to the latest repo revision (I have to analyse it further yet).
The build finishes, but gives such warnings:
BFD: tsan_clock.o: plugin needed to handle lto object
...
BFD:
.libs/libtsan.lax/libsanitizer_common.a/sanitizer_symbolizer_libbacktrace.o:
plugin needed to handle lto object
...
And compiling a C++ program with this newly generated compiler
gives the said libstdc++ link errors:
/usr/local/gcc-latest/lib/gcc/x86_64-linux-gnu/9.0.0/../../../../lib64/libstdc++.so:
undefined reference to `std::istream::ignore(long)'
/usr/local/gcc-latest/lib/gcc/x86_64-linux-gnu/9.0.0/../../../../lib64/libstdc++.so:
undefined reference to `std::basic_istream<wchar_t, std::char_traits<wchar_t>
>::ignore(long)'
collect2: error: ld returned 1 exit status
But, I'd skipped the bootstrap process (via --disable-bootstrap).
Is it necessary for this to work?
