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

[Simon Marlow]

On 27/08/2011 13:04, Joachim Breitner wrote:
> 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?

Sorry for the delay, just going through my inbox and I think I missed 
your message before.

To answer your question: yes I would expect problems.  My question was: 
how do other (non-Haskell) packages on Debian that contain static 
libraries deal with this problem?  We should follow whatever approach is 
used by others.

Cheers,
	Simon