On Mon, 10 Mar 2014, Rainer Orth wrote: > Richard Biener <rguent...@suse.de> writes: > > > 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 > > It does use the host compiler for me, too.
So then if it succeeds to link to a shared libgcc_s then why is it not able to find that later? Maybe you miss setting of a suitable LD_LIBRARY_PATH to pick up the runtime for your host compiler? > > 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) > > But as you can see above, libtool, being its usual helpful self, simply > drops -static-libgcc ;-( If I use -Wc,-static-libgcc, all seems fine. > > If -shared results in linking with libgcc_s.so.1 depends on the target. Of course. Richard.
