On 17/05/2010 04:48, PHO wrote:
From: Simon Marlow<marlo...@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.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
