Re: How to handle breakages when the size of a class in a shared lib increases?
Hi Pierre,
On Tue, Jul 11, 2023 at 04:10:49PM +0200, Pierre Gruet wrote:
> Dear Mentors,
>
> I maintain a package that builds a shared library. I uploaded a new upstream
> version of it to Debian, with no removed symbols, no ABI change... Fine.
> Unfortunately, it turns out fields were added to some class (of which size
> thus increased) in the shared library, so that binaries built against a
> previous version of it now segfault as they are not allocating enough space.
>
> Of course, rebuilding the reverse dependencies fixes the segfaults.
> How should we handle such situation in Debian? Quoting Policy 8.1:
>
> The SONAME and binary package name need not, and indeed normally
> should not, change if new interfaces are added but none are removed or
> changed, since this will not break binaries linked against the old
> shared library. Correct versioning of dependencies on the newer shared
> library by binaries that use the new interfaces is handled via the
> symbols or shlibs system.
>
> So my understanding is that no SONAME change and no transition are needed,
> although the rdeps indeed have to be rebuilt as their binaries _are_ broken
> by the new version of the library.
In short: ABI change is not limited to removing symbols.
Your library broke ABI by adding members, and would have required a SONAME
bump.
There is some guide what you can and cannot do in terms of ABI:
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C++
There is a tool to check for breakage: https://lvc.github.io/abi-compliance-checker/
(it is in Debian: https://tracker.debian.org/pkg/abi-compliance-checker)
--
Cheers,
tobi
Reply to: