| Message ID | yddr46arp3n.fsf@lokon.CeBiTec.Uni-Bielefeld.DE |
|---|---|
| State | New |
| Headers | show |
On Mon, 10 Mar 2014, Rainer Orth wrote: > Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes: > > > It does use the host compiler for me, too. > > > >> 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. > > The following patch implements this. The override is necessary to avoid > LDFLAGS passed in from the toplevel to replace the Makefile value. > > Bootstraps on i386-pc-solaris2.10 and x86_64-unknown-linux-gnu are now > well beyond stage1. Ok for mainline if they pass? If we go that route I wonder if we should rely on the toplevel passing -static-libgcc but instead force -static-libgcc for the plugin anyway? (conditional on compiling with GCC, of course) Thanks, Richard. > Thanks > Rainer > > > 2014-03-10 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> > > * Makefile.am (comma): New variable > (LDFLAGS): Prefix -static-libgcc with -Wc.
Richard Biener <rguenther@suse.de> writes: > On Mon, 10 Mar 2014, Rainer Orth wrote: > >> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes: >> >> > It does use the host compiler for me, too. >> > >> >> 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. >> >> The following patch implements this. The override is necessary to avoid >> LDFLAGS passed in from the toplevel to replace the Makefile value. >> >> Bootstraps on i386-pc-solaris2.10 and x86_64-unknown-linux-gnu are now >> well beyond stage1. Ok for mainline if they pass? > > If we go that route I wonder if we should rely on the toplevel passing > -static-libgcc but instead force -static-libgcc for the plugin > anyway? (conditional on compiling with GCC, of course) That would mean either duplicating the test from the toplevel or adding a test for gcc in lto-plugin. Either is ugly, so I'd like to avoid it if possible. It occured to me that some of the complexcity would go away if gcc just accepted and stripped -Wc (which is currently a libtool-only option), but even if so we'd have to deal with gcc's that don't have this for a long time. Rainer
# HG changeset patch # Parent baa4e95100d168dd4133db86c265fd35739647aa Fix Solaris bootstrap with GNU ld/LTO diff --git a/lto-plugin/Makefile.am b/lto-plugin/Makefile.am --- a/lto-plugin/Makefile.am +++ b/lto-plugin/Makefile.am @@ -15,6 +15,10 @@ libexecsub_LTLIBRARIES = liblto_plugin.l gcc_build_dir = ../$(host_subdir)/gcc in_gcc_libs = $(foreach lib, $(libexecsub_LTLIBRARIES), $(gcc_build_dir)/$(lib)) +# Need to protect -static-libgcc from libtool +comma = , +override LDFLAGS = $(patsubst -static-libgcc,-Wc$(comma)-static-libgcc,@LDFLAGS@) + # Can be removed when libiberty becomes a normal convenience library Wc=-Wc,