[Pkg-haskell-maintainers] libffi soname change upcoming

Simon Marlow marlowsd at gmail.com
Thu Aug 25 11:58:53 CEST 2011

On 24/08/2011 13:12, Joachim Breitner wrote:
> Hi,
> 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?


More information about the Glasgow-haskell-users mailing list