[PATCH] Use the LTO linker plugin by default

[Richard Biener]

On Sat, 8 Mar 2014, Rainer Orth wrote:

> Richard Biener <rguenther@suse.de> writes:
> 
> > The following patch addresses the common (?) issue of people
> > omitting -flto from the linker command-line which gets more
> > severe with GCC 4.9 where slim LTO objects are emitted by
> > default.  The patch simply _always_ arranges for the linker
> > plugin to be used, so if there are any (slim) LTO objects
> > on the link LTO will be done on them.  Similarly the
> > non-linker-plugin path in collect2 is adjusted.
> >
> > You can still disable this by specifying -fno-lto on the 
> > linker command-line.
> >
> > One side-effect of enabling the linker-plugin by default
> > (for HAVE_LTO_PLUGIN == 2) is that collect2 will then
> > use the configured plugin ld rather than the default ld.
> > Not sure if that is desired.
> >
> > Comments?
> 
> This patch broke Solaris bootstrap with GNU ld: when linking stage1
> libgcc, the lto plugin is used.  It has been built with -shared and thus
> depends on libgcc_s.so.1.  There's no instance of libgcc_s shipped with
> the system, thus when trying to link the stage1 libgcc_s, the lto plugin
> fails to load: chicken and egg ;-(

Ouch.  But as lto-plugin is a host module it should link against
the host libgcc, no?  During stage1, that is.  So the question is
why does it use the gcc/ compiler....?

For me it's using the host gcc:

gcc -DHAVE_CONFIG_H -I. -I/space/rguenther/tramp3d/trunk/lto-plugin 
-I/space/rguenther/tramp3d/trunk/lto-plugin/../include -DHAVE_CONFIG_H 
-Wall -g -c /space/rguenther/tramp3d/trunk/lto-plugin/lto-plugin.c  -fPIC 
-DPIC -o .libs/lto-plugin.o
/bin/sh ./libtool --tag=CC --tag=disable-static  --mode=link gcc -Wall -g  
-module -bindir /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0  
-static-libstdc++ -static-libgcc  -o liblto_plugin.la -rpath 
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0 lto-plugin.lo 
-Wc,../libiberty/pic/libiberty.a
libtool: link: gcc -shared  .libs/lto-plugin.o    
../libiberty/pic/libiberty.a   -Wl,-soname -Wl,liblto_plugin.so.0 -o 
.libs/liblto_plugin.so.0.0.0

but maybe _that_ is the issue for you? (see also how it uses
-static-libgcc, for me it doesn't even depend on libgcc_s)

stage1 libgcc is a target library, so it trying to use LTO is fine.

> The solution/workaround seems to be to link stage1 libgcc_s with
> -fno-lto (which works if done manually).  Unfortunately, there's
> currently no way to pass in additional ldflags from the toplevel,
> depending on stage; not even toplevel LDFLAGS is used in SHLIB_LINK.

As said, I'm not sure your analysis is correct.

Richard.