Dynamic libraries by default and GHC 7.8

Simon Marlow marlowsd at gmail.com
Wed Nov 28 10:09:58 CET 2012

On 27/11/12 23:28, Joachim Breitner wrote:
> Hi,
> Am Dienstag, den 27.11.2012, 14:52 +0000 schrieb Ian Lynagh:
>> 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
> here comes the obligatory butting in by the Debian Haskell Group:
> Given the current sensitivity of the ABI hashes we really do not want to
> have Programs written in Haskell have a runtime dependency on all the
> included Haskell libraries. So I believe we should still link Haskell
> programs statically in Debian.
> Hence, Debian will continue to provide its libraries built the static
> way.
> Building them also in the dynamic way for the sake of GHCi users seems
> possible.

So let me try to articulate the options, because I think there are some 
dependencies that aren't obvious here.  It's not a straightforward 
choice between -dynamic/-static being the default, because of the GHCi 

Here are the 3 options:

(1) (the current situation) GHCi is statically linked, and -static is
     the default.  Uses the RTS linker.

(2) (the proposal, at least for some platforms) GHCi is dynamically
     linked, and -dynamic is the default.  Does not use the RTS linker.

(3) GHCi is dynamically linked, but -static is the default.  Does not
     use the RTS linker.  Packages must be installed with -dynamic,
     otherwise they cannot be loaded into GHCi, and only objects
     compiled with -dynamic can be loaded into GHCi.

You seem to be saying that Debian would do (3), but we hadn't considered 
that as a viable option because of the extra hoops that GHCi users would 
have to jump through.  We consider it a prerequisite that GHCi continues 
to work without requiring any extra flags.


> Open question: What should GHC on Debian do when building binaries,
> given that all libraries are likely available in both ways – shared or
> static. Shared means that all locally built binaries (e.g. xmonad!) will
> suddenly break when the user upgrades its Haskell packages, as the
> package management is ignorant of unpackaged, locally built programs.
> I’d feel more comfortable if that could not happen.
> Other open question: Should we put the dynamic libraries in the normal
> libghc-*-dev package? Con: Package size doubles (and xmonad users are
> already shocked by the size of stuff they need to install). Pro: It
> cannot happen that I can build Foo.hs statically, but not load it in
> GHCi, or vice-versa.
> I still find it unfortunate that once cannot use the .so for static
> linking as well, but that is a problem beyond the scope of GHC.
> Greetings,
> Joachim
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

More information about the Glasgow-haskell-users mailing list