Comment # 10 on bug 1120894 from Richard Biener

(In reply to Michael Matz from comment #9)
> (In reply to Richard Biener from comment #6)
> > 
> >  --as-needed -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc
> > --as-needed -lgcc_s --no-as-needed
> > /usr/lib64/gcc/x86_64-suse-linux/8/crtend.o
> > /usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64/crtn.o
> 
> Already here is the problem: there is --as-needed --as-needed --no-as-needed
> --as-needed --no-as-needed.  In the "old" model every automatically
> introduced --as-needed had to come with a paired --no-as-needed, and the
> above cmdline doesn't follow that.  It worked by accident because in reality
> the as-needed didn't nest ...
> 
> >  --as-needed -lgcc --push-state --as-needed -lgcc_s --pop-state -lpthread
> > -lc -lgcc ...
> 
> ... which it now (via push/pop) does.  If "--as-needed -lgcc" would have
> been paired with the proper "--no-as-needed" we wouldn't have the problem. 
> That is, if any combination of compile options make it so that the linker is
> called with an unequal number of as-needed vs. no-as-needed then this is a
> GCC bug.
> 
> Martin: no, please don't hack the package, it's a toolchain problem.
> 
> Richi: if configuring or patching binutils to have as-needed by default
> doesn't make a difference, either way GCC would need to change somehow.  As
> per above I think our GCC spec files are simply wrong and miss a
> no-as-needed somewhere.

I don't think it makes a difference in the end since --as-needed is defaulted
to on with SUSE package builds.  But yes, the nesting is bogus somehow,
will report upstream.