https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #11 from Michael Matz <matz at gcc dot gnu.org> --- The binutils in our (SUSEs) enterprise codestreams revert certain behaviour changes from upstream in relation to rewriting PC32 to PLT32 relocs (as some old tooling doesn't cope with that). So, our binutils generate a PC32 reloc here. In principle it shouldn't be surprising that a naked 'call mcount' (in comparison to a 'call mcount@plt') emits a direct call, without going via PLT, and that of course doesn't work when mcount is defined in some other DSO. But that's what the compiler requested. That some binutils rewrite this into a PLT-using variant is all nice and such (but actually: is it really?) but the compiler shouldn't go the non-PIC path when -fPIC (which is what the patch in r14-811 changed). Obviously the code in GCC before that revision explicitely wanted to avoid the PLT (by using a direct access to the respective GOT slot). Upstream binutils now silently do emit a route via PLT, our binutils complain. I'm not sure that upstream behaviour is indeed better.
