Dynamic libraries and GHCi

Simon Marlow marlowsd at gmail.com
Mon May 17 04:18:17 EDT 2010

On 17/05/2010 04:48, PHO wrote:
> From: Simon Marlow<marlowsd at gmail.com>
> Subject: Dynamic libraries and GHCi
> Date: Mon, 10 May 2010 10:06:21 +0100
>> We had planned to switch to using a dynamically-linked GHCi for 6.14.1
>> (see http://hackage.haskell.org/trac/ghc/ticket/3658), which on the
>> whole seems like the right direction to be heading in, since we reduce
>> the dependence on our own RTS linker.
>> The dynamically-linked GHCi works, and passes all the tests.  It also
>> starts up faster than the statically linked one, at least on Linux,
>> possibly due to a combination of the system linker being faster than
>> ours and it doing on-demand linking.  That's the good news.
> In fact, it's now mandatory for all Mach-O platforms (seemingly
> including i386-apple-darwin the Tier-1 platform) to completely switch
> to dynamically-linked GHCi, as those platforms started failing to
> build static GHCi libraries that are needed by dph packages' use of
> TemplateHaskell.
> For patches and details, see:
> http://hackage.haskell.org/trac/ghc/ticket/3260#comment:5
> http://hackage.haskell.org/trac/ghc/ticket/3594#comment:1

Ok, but the dynamically-linked GHCi only works by accident right now, 
because we are loading objects compiled against the static version of 
the packages but linking them against the dynamic versions.  This will 
result in link errors or crashes eventually.

> But currently there is one problem with "GhcShared=YES": with this
> option, the stage-2 compiler gets linked dynamically but the
> corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH,
> thus ./inplace/bin/ghc-stage2 doesn't run at all. I could work around
> this by manually symlinking all the dynamic libraries to ./inplace/lib
> and setting (DY)LD_LIBRARY_PATH to there, but obvisouly there should
> be a solution better than this.

On Linux we link the binary using -rpath (I know OS X doesn't have 
-rpath).  This is another issue we need to resolve before we can switch 
to a dynamically-linked GHCi.

Basically there's a fair bit to do to make a dynamic GHCi a reality, and 
before we can do anything there are some tricky decisions to make.


More information about the Glasgow-haskell-users mailing list