Prelinking relative relocations in shared objects

[Ian Lance Taylor]

Jan Vroonhof <jan.vroonhof@insignia.com> writes:

> > The relocations probably exist because the ELF linking rules permit
> > overriding a symbol in a shared library.  Therefore, all references to
> > global symbols from a shared library require a relocation, whether the
> > symbol is defined in the same shared library or not.
> 
> Yes, I know. However this shared library almost only contains one big object
> that is linked using -r from multiple objects and thus such rules do not apply.

No, the rules still apply, assuming that the symbols are globally
visible (i.e., you didn't use --retain-symbols-file or some such
option).  Just because the reference is within a single object doesn't
mean that the linker can remove the relocation when building a shared
library.

> > You can stop this by using -Bsymbolic, which tells the linker that all
> > references to symbols defined in the same shared library are to be
> > resolved locally.
> 
> As I wrote in my original mail (I probably wasn't very clear), I tried
> this but it doesn't seem to make any difference for my linker (which
> is collect2 inside gcc 2.25). Should I try newer versions?

That doesn't indicate which version you are using, so I don't know.
collect2 is a wrapper around the real linker, and you didn't indicate
which version of the real linker you are running.

> To me it seems as if -Bsymbolic only sets a flag that makes the
> runtime linker behave differently.

-Bsymbolic does set a flag.  It normally also eliminates relocations
for references within the same shared library.  It is possible that
this isn't implemented for ARM; it requires some processor specific
work, and I don't know if that work has been done for ARM.

Ian