Loading package GHC in GHCi

[Simon Marlow]

On 09 January 2005 06:50, 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.
> 
> 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.
> 
> What do you think of this proposal? I haven't implemented it yet
> because the alternative - that of simply removing the conflicting
> symbols from package ghc might be what you want.  My temporary fix for
> getting package ghc to load into GHCi is just this - I strip the
> symbols that overlap between the RTS and package ghc.  However, this
> means that the code that was supposed to be overridden in the RTS is
> no longer being overridden.  Although this works this doesn't seem to
> be what we want.

I'm not keen on adding new syntax to package.conf for this.  We
shouldn't rely on the overriding behaviour - it's non-portable anyway.

I think the best solution is for these hooks to be replaced by variables
containing function pointers, in the same way as the "hooks" in
RtsMessages.c.  The user program has to override main() in order to set
them, but this is done portably by using the -no-hs-main option to GHC,
and a standard main() is pretty small.

Cheers,
	Simon