Dynamic linking weirdness

[Simon Marlow]

Wolfgang Thaller wrote:
> On 17-Sep-07, at 7:20 PM, Sven Panne wrote:
> 
>> Now we get a R_X86_64_GOTPCREL and things work as expected. Alas, our GHC
>> Linker can't handle such a relocation,
> 
> That shouldn't be a lot of work. The same relocation is already 
> implemented for Darwin/x86_64.
> 
>> [...] and somehow this has to work even in
>> the non-PIC case. What we currently do in x86_64_high_symbol for the
>> R_X86_64_32 relocation is completely wrong for data references, and 
>> this is
>> even mentioned in the comment.

Yes, we even have a ticket for it:

http://hackage.haskell.org/trac/ghc/ticket/781

> I think that it is next to impossible to implement this correctly. If a 
> symbol is copied into the executable's data section, the references from 
> shared libraries to the symbol have to be updated to point to the new 
> symbol as well. When loading a dynamic library, the system dynamic 
> linker decides whether it needs to do this; unless we ship GHCi with a 
> modified version of ld.so, it will do so only for symbols where a COPY 
> relocation is present.
> 
> My recommendation would be implement the PIC relocations in the 
> ELF/X86_64 linker and then to require -fPIC for GHCi libs on that platform.

Right, but for packages we can compile them as shared libraries and use the 
system linker, so the GHCi linker isn't involved.  So when we have shared 
library support on all major platforms (perhaps 6.8.2) this problem will at 
least partly go away.  It'll still be an issue for loading .o files in 
GHCi, and if this is important then we should do as you suggest and require 
-fPIC.

Sven: one workaround for now is to access your data by calling a C wrapper 
function in a shared library.  This is how we manage to access errno, for 
example.

Cheers,
	Simon