Dynamic loading problem
duncan.coutts at worcester.oxford.ac.uk
Fri Apr 30 19:00:31 EDT 2004
On Fri, 2004-04-30 at 17:36, Simon Marlow wrote:
> On 30 April 2004 11:26, Duncan Coutts wrote:
> > Could someone remind me what the remaining issues are in getting ghc
> > to build Haskell modules/packaged into unix .so shared libraries?
> It might be possible to do this, but only if you want to do
> dlopen()-style linking at runtime. Linking a haskell binary against
> Haskell .so libraries still isn't possible - I had another look at this
> recently, and although one of the obstacles has been removed, there are
> others (details available on request).
Details would be interesting.
> Any remaining issues to do with dlopen()ing a Haskell .so library are
> probably to do with CAFs. The dynamically loaded code needs to call
> newDynCAF() instead of newCAF() in a CAF's entry code - this is normally
> arranged by the RTS linker, but for a .so you'll have to do it some
> other way, like getting the compiler to emit the different call, or
> doing some CPP magic (but only for -fvia-C). Any reasonable patches to
> implement this will be incorporated.
Does that involve changing what reference get linked to which symbols or
would it be a matter of finding a bunch of symbols & calling them after
doing a dlopen() ? Another way of asking the same thing is can the
calling newDynCAF be done in a separate phase (ie after dlopen()) or is
it intimately part of the linking process?
There seem to be several people interested in doing plug-in systems with
dynamically loaded modules. I just came across this report:
More information about the Glasgow-haskell-users