shared object from object files not compiled with -fPIC - 32 vs. 64 bit

[Shachar Shemesh]

I have recently came across a surprising difference between 32 and 64
bit platforms (we are, of course, talking about Intel: X86 vs.
X86_64/AMD64).

On 32 bit platforms, if you try to link object files not compiled with
-fPIC (say, a static library), the compilation passes. On further
investigation, what happens is that the actual library is loaded with
the text segment writable and copy-on-write, and then the relocation
table, which is linked into the shared object, is used to fix the actual
code so it runs.

As an aside, I'm a bit ambivalent about this trick. On the one hand,
this creates a block of unshared memory, in direct contrast to the
promise of shared libraries. On the other, this means that the more
efficient position dependent code is being used. As far as I can tell,
if your shared library is used by few programs simultaneously, and those
programs typically run for a long time with one load, then this trick
might actually give you better performance than -fPIC.

One way or the other, this trick simply doesn't work with 64 bit. On
AMD64, if one of the object files you are trying to link was not
compiled with -fPIC, then the linker will fail:
> relocation R_X86_64_PC32 against symbol `function' can not be used
> when making a shared object; recompile with -fPIC
This is particularly painful when the static library in question is a
proprietary third party (please don't start with the rants about
proprietary vs. free. I know).

My particular predicament was solved by asking, and receiving, the
vendor for a -fPIC compiled version of their library (still static, but
compiled with -fPIC). Still, I'm wondering why the difference. I don't
see any hardware difference between the platforms that makes this trick
(which, like I said, is sometimes desirable even when you have the
source code) impossible under 64bit.

Anyone?
Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com