On 2018-06-15 15:16 +0200, U.Mutlu wrote:
> 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?
Seems I was wrong about --disable-shared. It could not suppress libstdc++.so
but suppressed the LTO plugin.
Do not use --disable-shared. Then generated libstdc++.so *would* be broken
(because of PR 48200). Then build GCC again w/o CXXFLAGS_FOR_TARGET=-flto, and
install the working libstdc++.so.
Or try to hack libstdc++ building system, use "-flto -ffat-lto-objects" to
compile .cc to .o, and use "-fno-lto" for *shared* library libstdc++.so.
(Maybe also other shared libraries of GCC).
I'm trying to resolve PR 48200, but no much progress now.
--
Xi Ruoyao <ryxi@xxxxxxxxxxxxxxxxx>
School of Aerospace Science and Technology, Xidian University
