Re: LTO setup

[Markus Trippelsdorf <markus at trippelsdorf dot de>]

On 2016.02.03 at 15:28 +0100, Fabio Coatti wrote:
> In data martedì 2 febbraio 2016 19:54:22, Markus Trippelsdorf ha scritto:
> > On 2016.02.02 at 18:35 +0100, Fabio Coatti wrote:
> 
> > > I get many of them, so it is likely that object files are not stripped;
> > > however the issue is that exported symbols are far less in LTO build,
> > > and, as example, flightgear fails to compile due to missing symbols; it
> > > builds fine with plib compiled without lto.
> > 
> > The libplibfnt.a should only contain compressed GIMPLE code when build
> > with -flto.
> > 
> > See also https://gcc.gnu.org/wiki/LinkTimeOptimizationFAQ
> 
> 
> ok, thanks; I'm still struggling to understand why the linking fails, even 
> with your suggestion. It would be useful a way to list symbols present in a .o 
> and .a file, to make sure that object files are created fine.
> From what I read, gcc-nm (or even nm in latest versions) should do that, 
> however running it on libplibfnt.a (to use the same examples) shows only few 
> symbols, way fewer than on no-lto build.
> So, now my question is: is it ok for nm not to show all the symbols or should 
> it show also those related to gimple code?
> Interesting enough, "strings" run against libplibfnt.a shows all symbols, but 
> with some differences:
> 
> If I grep strings for a symbols shown by nm, like this:
> # nm /usr/lib/libplibfnt.a | grep ZN7fntFontC2Ev
> 00000000 T _ZN7fntFontC2Ev
>          U _ZN7fntFontC2Ev
> 
> I get the following result:
> # strings /usr/lib/libplibfnt.a | grep ZN7fntFontC2Ev
> _ZN7fntFontC2Ev
> .gnu.lto__ZN7fntFontC2Ev.73e0594a6663c7f3
> 
> while doing the same for asymbol not shown by nm:
> strings /usr/lib/libplibfnt.a | grep ZL23Fixed8x13_Character_12
> 
> I get the following output (for a lto-built lib)
> # strings /usr/lib/libplibfnt.a | grep ZL23Fixed8x13_Character_123
> .gnu.lto__ZL23Fixed8x13_Character_123.78e9fac11ab52f79
> 
> Quite different, as it is shown only as .gnu.lto
> 
> does this means that the lib itself is built correctly with lto flag, and it is 
> a problem in the build phase of the program requiring the static lib? If this 
> is the case, the behaviour of nm, not showng .lto symbols is it correct?

Local read only data sections are normally not shown for -flto build
archives.

But it should normally all work just fine. What is the exact error you
get when you use libplibfnt.a (build with -flto) later on?

-- 
Markus