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