Haskell executables dynamic vs static linking

Garrett Mitchener garrett.mitchener at gmail.com
Fri Feb 28 13:57:48 UTC 2014

Okay, thanks for the info.

I'm a little leery of the alternatives framework.  I've had to deal with
that with java, and it's complicated because there are several
implementations of java that don't get packaged consistently with each
other.  As in some alternatives provide X, Y, and Z, and some provide W, X,
and Y, and figuring all that out has been frustrating.  What your proposing
probably wouldn't be as bad since the alternative Haskell packages would be
coming from the same source and would presumably be exactly consistent with
each other.

But, if the dynamic executable packages are working, are parallel static
packages necessary?

Another issue is the experimental nature of a lot of Haskell packages: I
recently had to make a lot of minor updates to my simulation because of a
change in the aeson package, which is itself under fairly heavy
development.  We can probably link dynamically to well-established Haskell
libraries with no problem, but the more experimental ones could result in
the usual trap that executable foo requires the new features in libbar-5
but executable baz hasn't been updated yet and requires libbar-4 ...  From
what I can tell, GHC and Cabal are better at dealing with multiple
coexisting versions of packages than RPM and Yum are.

Just thinking out loud here...

On Thu, Feb 27, 2014 at 8:36 PM, Jens Petersen <petersen at redhat.com> wrote:

> Thanks for your reply.
> There's something in the Fedora packaging guidelines about not packaging
> static libraries.
> There is...
> There is also something about it being ok for Haskell packages
> in the Haskell Packaging Guidelines we made. :)
> Current ghc stable releases only support Linux shared libs on ia32 arch's.
> ie all Haskell executables on other archs are statically linked to Haskell
> libs anyway.
> I believe ocaml also links its executables statically to ocaml libs.
> I don't think we can drop Haskell static libraries any time soon,
> but for ghc-7.8 (Fedora 21) I am thinking to subpackage them
> since ghc-pkg no longer screams about missing static libs.
> (ghc-7.8 uses dynmically linking internally by default though
> which somewhat complicates its use of non-exported libs.)
>  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.
> It works just fine - it is what ghc does by default and has been doing
> forever. :)
> To link dynamically you have to give the -dynamic option to ghc.
> As I wrote, afaik other distros do not distribute dynamically linked
> Hasklell executables.
> Anyway my question was more about providing both for some packages in an
> optimal way.
> Jens
> $ cat > Main.hs
> main = putStrLn "hi"
> $ ghc Main
> :
> $ ldd Main | grep libHS
> $ ghc Main -dynamic
> :
> $ ldd Main | grep libHS | wc -l
> 4
> $
> _______________________________________________
> 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/20140228/3f0862a1/attachment.html>

More information about the haskell mailing list