On Sat, 8 Mar 2014, Rainer Orth wrote: > 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 ;-(
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.
