On 27/11/12 14:52, Ian Lynagh wrote:
GHC HEAD now has support for using dynamic libraries by default (and in particular, using dynamic libraries and the system linker in GHCi) for a number of platforms.
This has some advantages and some disadvantages, so we need to make a decision about what we want to do in GHC 7.8. There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default. We would like to make these as soon as possible, so that GHC 7.6.2 can ship with a Cabal that works correctly.
The various issues are described in a wiki page here: http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
If you have a few minutes to read it then we'd be glad to hear your feedback, to help us in making our decisions
It's hard to know what the best course of action is, because all the options have downsides. Current situation: * fast code and compiler * but there are bugs in GHCi that are hard to fix, and an ongoing maintenance problem (the RTS linker). * binaries are not broken by library updates Switching to dynamic: * slower code and compiler (by varying amounts depending on the platform) * but several bugs in GHCi are fixed, no RTS linker needed * binaries can be broken by library updates * can't do it on Windows (as far as we know) Perhaps we should look again at the option that we discarded: making -static the default, and require a special option to build objects for use in GHCi. If we also build packages both static+dynamic at the same time in Cabal, this might be a good compromise. Static by default, GHCi is dynamic: * fast code and compiler * GHCi bugs are fixed, no maintenance problems * binaries not broken by library updates * we have to build packages twice in Cabal (but can improve GHC to emit both objects from a single compilation) * BUT, objects built with 'ghc -c' cannot be loaded into GHCi unless also built with -dynamic. * still can't do this on Windows Cheers, Simon