LTO setup

[Markus Trippelsdorf]

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