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/