Bug#639015: [Pkg-haskell-maintainers] libffi soname change upcoming
marlowsd at gmail.com
Thu Sep 29 12:39:26 CEST 2011
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.
More information about the Glasgow-haskell-users