On 2016.02.02 at 18:35 +0100, Fabio Coatti wrote: > In data martedì 2 febbraio 2016 13:01:06, Markus Trippelsdorf ha scritto: > > > > 3) the most problematic one: whenever a static lib (.a) is produced, > > > compilations depending on it always fails, complaining about missing > > > symbols. I tried every "solution" that I found (placing plugin in right > > > directory, using wrappers for ar/nm/ranlib and so on, to no avail. > > > some examples are plib (plib.sourceforge.net) qtdeclarative, etc. > > > It seems that many symbols are not present in lto-built libs, however I'm > > > not able to fix the issue, so I'm wondering if this could be an issue > > > with my setup or the package itself that can't be built with LTO. Again, > > > a very short test case to check if my setup is fine would be really > > > helpful. > > > > This should be fixed by the symlink in lib/bfd-plugins. > > Thanks for your answer; I've followed your advices (and others on the blog) > and I think I can assume that lto is applied: using git-shell the size is > greatly reduced when compiling with lto turned on. I created the symlink as > suggested. > > However, I see a behaviour that I can't understand with static libs (.a). > > As example, I built plib both with lto and without. > The result puzzles me: > LTO > size 531792 > nm libplibfnt.a | wc -l: 105 > > NO-LTO > size 153604 > nm libplibfnt.a | wc -l: 809 > > The size can be justified by this error: > x86_64-pc-linux-gnu-strip: /var/tmp/portage/media-libs/plib-1.8.5- > r1/image/usr/lib64/st1bAIiB/slMODinst.o: plugin needed to handle lto object > > 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 -- Markus
