Re: [Pkg-haskell-maintainers] libffi soname change upcoming
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?
Removing the libffi dependencies from the haskell libraries makes C possible and only helps with A. So until someone investigates this, I’d rather err on the safe side, leave the dependencies in, and fix the issue by rebuilding all haskell libraries when you upload the new ffi soname to unstable.
well, with binNMU orgies like this you'll pull in any new or tightened dependencies for shared libraries. Not depending on these unused libraries does avoid this.
True. I agree that it would be nice and worthwhile to remove the libffi dependency from the libraries, but only if it is actually safe and scenario C is guaranteed not to happen. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
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? Cheers, Simon
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? Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
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
Hi, Am Donnerstag, den 29.09.2011, 11:39 +0100 schrieb Simon Marlow:
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?
To answer your question: yes I would expect problems.
Thanks for your assessment. Matthias, I hope you understand why I would not drop the libffi dependencies from the Haskell packages; better safe than sorry. I can supervise the resulting binNMU-orgy, if you prefer.
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.
I’m actually not sure if we have this situation (various interdepending static libraries dynamically linking libffi). OCAML might be in a similar situation, but it seems that they don’t use libffi. Their packages do, however, all seem to have a dependency on libc6 which corresponds to our situation. Only that a so-name bump of libc is probably less frequent than one in libffi... Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
participants (2)
-
Joachim Breitner -
Simon Marlow