Bug#639015: [Pkg-haskell-maintainers] libffi soname change upcoming

Joachim Breitner nomeata at debian.org
Sat Aug 27 14:04:32 CEST 2011

Hi Simon,

Am Donnerstag, den 25.08.2011, 10:58 +0100 schrieb Simon Marlow:
> On 24/08/2011 13:12, Joachim Breitner wrote:
> > Am Mittwoch, den 24.08.2011, 12:44 +0200 schrieb Matthias Klose:
> >>> The question that has to be answered first is: Assume the libraries do
> >>> not depend on libffi themselves, and only ghc does. Now you update
> >>> libffi and ghc gets rebuilds, what will happen:
> >>>
> >>>   A) The haskell ABIs stay the same, the existing library packages can
> >>> still be used. Great.
> >>>
> >>>   B) The haskell ABIs change. We’ll have to binNMU all Haskell libraries,
> >>> but oh well, not bad thanks to BD-Uninstallable-support in wanna-build
> >>> and autosigning.
> >>>
> >>>   C) The haskell ABIs do not change, but the old library builds are
> >>> broken nevertheless. Big mess. Hard to recover from, because builds are
> >>> not ordered automatically any more. Needs lots of NMUes and Dep-Waits.
> >>
> >> sorry, I don't get the `C' case. why should these be broken by a libffi or
> >> libgmp change?
> >
> > Maybe it’s an unrealistic example, but I could imagine that ghc some
> > data type (size) defined by libffi is used when generating code for a
> > haskell library under the assumption that it has the same structure/size
> > in the run time system and/or other used haskell libraries.
> >
> > But instead of making blind guesses, maybe GHC upstream can enlighten
> > us: Is it safe to build ghc and a Haskell library, then upgrade libffi
> > to a new version (with soname bump), rebuild ghc, but use the previous
> > library build?
> So there might be difficulties because we build static libraries.  E.g. 
> the RTS would have been built against the previous libffi, but would 
> then be linked against the new one, which might be ABI-incompatible. 
> Shared libraries would notice the upgrade and use the old ABI, but 
> static libraries won't.
> How is this supposed to work, incidentally?  I just checked the Drepper 
> document about shared libraries and he doesn't seem to mention this 
> problem.  How do other packages with static libraries deal with this?

In Debian, we only build Haskell libraries still exclusively statically.

I’m not sure if I got your conclusion: Do you expect problems if the RTS
and libraries were built against different versions of libffi, or not?


Joachim "nomeata" Breitner
Debian Developer
  nomeata at debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata at joachim-breitner.de | http://people.debian.org/~nomeata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20110827/52508a04/attachment.pgp>

More information about the Glasgow-haskell-users mailing list