On 2016.02.02 at 11:01 +0100, Fabio Coatti wrote: > I'm trying to setup a working environment to compile and link with LTO > enabled, however I'm facing some issues that I can't be sure to have properly > fixed or resolved, no matter what googling I'm performing :) > > Environment: > gcc (Gentoo 5.3.0 p1.0, pie-0.6.5) 5.3.0 > ld di GNU (Gentoo 2.25.1 p1.1) 2.25.1 > AR="/usr/bin/gcc-ar" > NM="/usr/bin/gcc-nm" > RANLIB="/usr/bin/gcc-ranlib" The wrappers are unnecessary. Just create a symlink to /usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/liblto_plugin.so.0.0.0 in /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/ and you're ready to go. > flags, both for gcc and ld: -flto=4 -fuse-linker-plugin > What puzzles me: > > 1) Is there any way to state if LTO is producing the expected outcome or falls > back to non-optimized code? The ideal should be some hello.c test compilation, > I guess. You can follow the "Prerequisities" steps from Honza's blog post: http://hubicka.blogspot.com/2014/09/linktime-optimization-in-gcc-part-3.html > 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. -- Markus
