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
