Prelinking relative relocations in shared objects

[Jan Vroonhof <jan dot vroonhof at insignia dot com>]

[Please CC. I do read the list, but only via the mail archive]

I have seen over the past few month quite a few mails on the gcc/binutils/glibc lists
about effort to reduce the number of dynamic relocations in shared libraries, in particular
glibc that are similar to this situation below.

Unfortunately I am a bit at a loss of where things are and for which
benefits bleeding edge tools are needed. Maybe 

We have a rather big .so for linux/arm we want to reduce the
ondisk/flash footprint of. It is currently produced using gcc 2.95.x for various x.
A substantial part of its on disk size is in the .rel.* sections.

Presumably this is because we are NOT compiling -fPIC for performance reasons (the difference
is much higher than I expected for arm).

However, looking at the contents of the .rel sections, about 50% of
the relocations are R_ARM_PC24, and a substantial part of those are
reference to symbols inside the same .so.  So it would seem to me that
these references could be fixedup at .so creation time (modulo symbol
lookup rules, but neither -Bdynamic nor linking the objects into one
object using -r first seems to have any effects).

Is my reasoning flawed? Is there any way of persuading the toolchain
to do this automatically?

Jan