Dynamic loading under GHCi - haskell

Question

I need to be able to load Haskell modules dynamicaally, and evaluate expressions in the context of dynamically-loaded modules.
Hint does it; the problem is, it doesn't work under GHCi, on Windows at least.
cygwin-bash> ghci HintTest.hs
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Ok, modules loaded: Main.
Prelude Main>
Prelude Main> main
[... lots of "Loading package" messages snipped]
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
_debugLn
whilst processing object file
C:\PROGRAM FILES (X86)\HASKELL PLATFORM\2013.2.0.0\lib\ghc-prim-0.3.0.0\HSghc-prim-0.3.0.0.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 get the same error when using GHC modules directly, as shown in GHC/As a library.
As a compiled program, HintTest runs just fine.
Is there anything that can bee done about this?
I don't ever need to run my program stand-alone; always using GHCi is sufficient. It would also be nice if the program could use GHCi itself as the interpreter and not its own copy of GHC. That is, I'd like to be able to do something like this:
do
context <- loadToGhci "MyModule.hs"
inContext context "MyModule.myFunction 2 5"
and when I return to the REPL, MyModule is magically loaded to it. context is meant to be some kind of monad that carries GHCi state.
Update The same code works on Linux. Perhaps it's a Windows-specific bug in GHC. Can it be worked around?
Update 2
Here's the full log
Prelude Main> main
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package Win32-2.3.0.0 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package old-locale-1.0.0.5 ... linking ... done.
Loading package time-1.4.0.1 ... linking ... done.
Loading package syb-0.4.0 ... linking ... done.
Loading package random-1.0.1.1 ... linking ... done.
Loading package filepath-1.3.0.1 ... linking ... done.
Loading package directory-1.2.0.1 ... linking ... done.
Loading package process-1.1.0.2 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package hpc-0.6.0.0 ... linking ... done.
Loading package hoopl-3.9.0.0 ... linking ... done.
Loading package haskell-src-1.0.1.5 ... linking ... done.
Loading package old-time-1.1.0.1 ... linking ... done.
Loading package Cabal-1.16.0 ... linking ... done.
Loading package binary-0.5.1.1 ... linking ... done.
Loading package bin-package-db-0.0.0.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package ghc-7.6.3 ... linking ... done.
Loading package extensible-exceptions-0.1.1.4 ... linking ... done.
Loading package MonadCatchIO-mtl-0.3.0.5 ... linking ... done.
Loading package ghc-mtl-1.0.1.2 ... linking ... done.
Loading package ghc-paths-0.1.0.9 ... linking ... done.
Loading package utf8-string-0.3.7 ... linking ... done.
Loading package hint-0.3.3.7 ... linking ... done.
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
_debugLn
whilst processing object file
C:\PROGRAM FILES (X86)\HASKELL PLATFORM\2013.2.0.0\lib\ghc-prim-0.3.0.0\HSghc-prim-0.3.0.0.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.

Answer 1

You're trying to dynamically load the bytecode interpreter and runtime into the bytecode interpreter and runtime. Whether this works will depend on how the underlying C libraries are linked on your system -- which is very platform dependent.
In particular, C symbols will be duplicated unless special care is taken when linking, when you load the various RTS modules the second time, which will lead to linker errors.