Re: Using -flto in CXXFLAGS_FOR_TARGET

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux