Dynamic libraries by default and GHC 7.8
marlowsd at gmail.com
Wed Nov 28 10:09:58 CET 2012
On 27/11/12 23:28, Joachim Breitner wrote:
> Am Dienstag, den 27.11.2012, 14:52 +0000 schrieb Ian Lynagh:
>> The various issues are described in a wiki page here:
>> 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
> Building them also in the dynamic way for the sake of GHCi users seems
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.
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users