On Wed, 12 Mar 2014, Rainer Orth wrote: > Richard Biener <rguent...@suse.de> writes: > > > 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? > > For the same reason that we use -static-libstdc++ to avoid this issue > for libstdc++.so. I've always considered gcc's tendency to build > binaries that don't run by default a major annoyance, all the weasel > wording in the FAQ nonwithstanding. I hope to finally do something
True, but if your host compiler builds sth then it's the host compiler installs business to make sure it can run ... (and thus make the libgcc_s it links to available or only provide a static libgcc_s). For this particular case at least. Note that I'm not against linking against static libgcc_s for lto-plugin. The -static-libstdc++ we use is just because during bootstrap picking up the correct libstdc++ was deemed too hard to implement and thus the easy way out was -static-libstdc++. > about it for 4.10/5.0 (btw., any word on what the next release is going > to be?). I guess for the simple reason of not breaking scripts we'll go for 5.0 (and very much hope the libstdc++ ABI issue will solve itself in time). I've also suggested to drop the major/minor version difference and go with 5.x, 6.x, 7.x releases going forward. We can have a bikeshedding BOF at the Cauldron. Richard.
