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