Re: Dynamic libraries by default and GHC 7.8
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
interaction.
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.
Cheers,
Simon
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@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply to: