http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31798
Rich Felker <bugdal at aerifal dot cx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugdal at aerifal dot cx
--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
This does seem to be real, so please reopen it. The problem is that the final
command line to the linker looks like:
... $(objs) -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed $(endfiles)
Assuming the main program itself does not do any division or call raise, the
first -lgcc does not pull in __div0, and the -lc does not pull in raise.
However, if any function from libc which does get pulled in performs division,
then a reference to __div0 is generated, and the second -lgcc pulls in __div0,
which contains a reference to raise. This reference is never resolved.
It seems the intent is that link_gcc_c_sequence uses --start-group and
--end-group to avoid this problem when -static is used. However, this does not
cover the case where no libc.so exists at all, and libc.a is all that's
available. I wonder why the --start-group logic is only used for static linking
and not unconditionally, since it should be a no-op for shared libraries
anyway.
FYI, I have received new reports of this bug from musl users, one who wanted to
have libc.so be used but who installed it in the wrong location causing libc.a
to get used instead, but the rest were users doing purely static-linked systems
with no shared libraries at all.
