Bug#639015: [Pkg-haskell-maintainers] libffi soname change upcoming
nomeata at debian.org
Sat Aug 27 14:04:32 CEST 2011
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
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
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the Glasgow-haskell-users