http://bugzilla.novell.com/show_bug.cgi?id=1120894
http://bugzilla.novell.com/show_bug.cgi?id=1120894#c10
--- Comment #10 from Richard Biener
(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. -- You are receiving this mail because: You are on the CC list for the bug.