For a long time I was quite "proud" that Fedora Haskell is using dynamic Haskell linking on primary intel architectures (ghc-7.8 should support shared libs also on ARM, but it and cabal 1.18 still default to static linking.) But of course there are pros and cons for dynamic linking against Haskell libraries.
pros: - smaller lighter executables - enforces rebuilding of reverse deps (though this can also be a cons) - makes use of shared libs to share Haskell object code in memory - faster linking
cons: - harder to deploy - less portable - dynamically linked tools makes testing/building (for) newer ghc harder
Today I decided to make hscolour statically linked against Haskell libs in Rawhide. This will make bootstrapping ghc-7.8.1 or snapshots easier for example, or building ghc rpms for any other version. [1]
I think this is less problematic anyway for BinLib packages like hscolour, since ghc-hscolour will pick up any potential dependency breakage anyway.
I would like to have a static executable for cabal-install too. Maybe a cleaner alternative is to provide both a dynamic and a static subpackage, but I am not sure yet on the best way to do that. Using alternatives might be the only realistic way currently perhaps?
Should we do that for more executables packages?
Currently in Fedora because cabal-install is dynamically linked it is some work to build cabal-install for a new ghc version which makes testing newer ghc harder. If we had a statically linked cabal-install package we could just use it with any (recent) version of ghc... ie it would be more portable.
Any thoughts or opinions on this?
AFAIK Fedora is the only big distro that packages executables dynamically linked to Haskell libraries.
Jens
[1] Actually I wish hscolour was just included in ghc. It would make life easier. And likewise cabal-install actually.