Richard Biener <rguent...@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 ;-(

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.

        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Reply via email to