Haskell executables dynamic vs static linking

[Garrett Mitchener]

My first reaction is that if static linking is necessary or very helpful
for the compiler-documentation tool chain, that's probably okay.  But for
other programs, I think it might cause problems.  I've had trouble with
static linking in a few of my own programs.  For instance, I have one that
uses the BerkeleyDB package, and I had to edit the SPECs and rebuild the
RPMs for libdb and libffi to produce static libraries so I could statically
link my final program.  There's something in the Fedora packaging
guidelines about not packaging static libraries.  I don't know how well it
would work to link with Haskell libraries statically and others dynamically
-- I'm not even sure how to tell ghc to do that.

-- Garrett Mitchener



On Thu, Feb 27, 2014 at 4:18 AM, Jens Petersen <petersen at redhat.com> wrote:

> 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.
> _______________________________________________
> haskell mailing list
> haskell at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/haskell
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/haskell/attachments/20140227/4299bd2f/attachment.html>