9:10 a.m.
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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/haskell