Loading package ghc within GHCi

[Simon Marlow]

On 20 December 2004 04:29, Sean Seefried wrote:

> GHCi runtime linker: fatal error: I found a duplicate definition for
> symbol
>     _OutOfHeapHook
> whilst processing object file
>     /usr/local/lib/ghc-6.3/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 see that these symbol is exported by HSrts.o and HSghc.o so it makes
> sense that this error should occur. But since the symbol in HSghc.o
> originally comes from ghc/parser/hschooks.c and its purpose is to
> override the hooks in the RTS it seems strange that this should be an
> error.
> Is there any way that I can suppress this error through use of flags
> in the package.conf for package ghc?

The "hook" idea works with static linking: the RTS provides a default
version of the hook, that can be overriden by a user-supplied function
of the same name.  This is what GHC does.  However, our dynamic linker
doesn't support this kind of overriding.  The system's dynamic linker
does, though: that's why you can still provide your own malloc() and
functions in libc.so will use yours rather than the default one.

We can't really support this in GHC's dynamic linker, because we're
linking in objects that are already partially linked.  I guess we should
probabaly just work around it for now - you could just remove the
OutOfHeapHook() in package ghc, for example.

> I've been told that their may be other good reasons why package ghc
> doesn't load into GHCi by Don Stewart.  What are these reasons
> exactly? My final question is, if GHCi can't load package ghc just
> yet then what are the major issues that would need to be solved
> before it could? 

Problems arise when the are RTS resources used by both the running
GHC's.  For example, both GHC's will try to hook the signal handler for
^C.  If the package ghc tries to do dynamic linking, then lots of things
will go wrong (ie. don't try to compile any template haskell, and
definitely don't try to run GHCi inside GHCi).  I'm sure there are more
things on this list...

Cheers,
	Simon