#3658: Dynamically link GHCi on platforms that support it
---------------------------------+------------------------------------------
Reporter: simonmar | Owner:
Type: task | Status: new
Priority: high | Milestone: 7.2.1
Component: GHCi | Version: 6.10.4
Keywords: | Testcase:
Blockedby: | Difficulty: Unknown
Os: Unknown/Multiple | Blocking: 781
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by simonmar):
This has just become more important since we ran into an arbitrary limit
in the OS X object file format: [http://www.haskell.org/pipermail/cvs-
ghc/2010-September/055908.html].
Here's a rough plan of action:
* measure the performance impact of dynamic linking. If the impact is
too much, fixing that is a blocking issue. We can't ship a separate
static GHC binary, because GHC needs to use TH, so GHC itself has to be
dynamic.
* make a build system switch to enable dynamic-by-default
* make GHC report whether it is a dynamic-default compiler, in the --info
output.
* modify Cabal to use --enable-*-dynamic and --disable-library-vanilla,
if GHC is dynamic.
* implement loading of object files by first calling 'gcc -shared' (or
equiv. ld command line), and then `dlopen()`. Measure the performance
impact of that. Figure out whether we need to cache the results of `gcc
-shared` or regenerate them into `$TMPDIR` each time.
* enable dynamic-by-default for some platforms.
* Later: we need to track ways properly in Cabal and the package
database.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3658#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
