Loading package GHC in GHCi

[Andre Pang]

On 09/01/2005, at 5:49 PM, Sean Seefried wrote:

> I have managed to build package GHC *and* load it into GHCi.  
> Initially this did not work. When I loaded up ghci with the -package 
> ghc flag I was assaulted with the following error message.
>
>  GHCi runtime linker: fatal error: I found a duplicate definition for 
> symbol
>  _OutOfHeapHook
>  whilst processing object file
>  /Users/sseefried/cvs-ghc/PLUGGABLE/working/ghc/compiler/HSghc.o
>  This could be caused by:
>  * Loading two different object files which export the same symbol
>  * Specifying the same object file twice on the GHCi command line
>  * An incorrect `package.conf' entry, causing some object to be
>  loaded twice.
>  GHCi cannot safely continue in this situation. Exiting now. Sorry.

Just to clarify -- this is exactly the same problem that you posted 
about a day or two earlier?  The error message seems to be the same, 
anyway :).

> I tracked down this symbol in the GHC source and found it in 
> ghc/compiler/parser/hschooks.c.  The purpose of redefining the 
> functions within this file is apparently to improve the quality of the 
> error messages. That is, the symbols generated are meant to override 
> those in the RTS. Unfortunately GHCi doesn't like this at all. At the 
> moment it prohibits loading a symbol that is already in the RTS, which 
> seems very reasonable from a certain perspective - I can see that a 
> duplicate symbol would usually be an error. Except that in the case we 
> really *do* want to load it so that it overrides the old one.
>
> The only solution I can come up with is a modification to the 
> package.conf syntax so that one can specify symbols which are part of 
> the RTS package and the package in question.  We could then modify the 
> dynamic linker of GHC so that these symbols were removed from the 
> RTS's symbol table.  The symbols would then be loaded back in again in 
> with the package thus overriding the old symbols.

This is non-portable, and is only possible due to GHC doing its own 
object loading.  (I'm still not 100% sure whether GHC's linker is able 
unload things on a per-symbol basis, especially portably.)  Even if 
this does work, it won't be possible whenever GHC uses platform-native 
shared libraries, in the far far future :).

It's probably best to follow the other thread for feasible solutions to 
this, since it's already being discussed there.


-- 
% Andre Pang : trust.in.love.to.save  <http://www.algorithm.com.au/>