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. I guess I have something else to fix :) -- Fabio
