https://sourceware.org/bugzilla/show_bug.cgi?id=31615
--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Alan Modra from comment #7) > This results in no reload of libm.so.6. If libm.so.6 is reloaded (post > e7e05a9dd0) ldexp is already an indirect symbol to a defweak versioned sym > from libc.so.6, and attempting to mash in the duplicated libm.so ldexp > results in a u.i.link loop back to itself. We don't normally try to > override symbols like that, but you could argue it is a long-standing bug in > _bfd_generic_link_add_one_symbol that case is not handled gracefully. Before my commit, ldexp@@GLIBC_2.2.5 in libc.so.6 is used even when it is also defined in libm.so.6. After my commit, ldexp@@GLIBC_2.2.5 in libm.so.6 is used. However, info->hash->undefs_tail == &h->root isn't handled properly. -- You are receiving this mail because: You are on the CC list for the bug.
