[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how to check for binary compability?



Jonas Meurer <jonas@freesources.org> writes:

> At packaging mimelib1 from standalone-source I patched the sources to
> use strncpy/strncat instead of strlcpy/strlcpy along with several
> other changes.
>
> Now I tried to check for binary compability with libmimelib1c2a packages
> from kdepim 3.5.9 sources. To do that, I compared the output of
> 'objdump -T /usr/lib/libmimelib.so.1 | grep \\.text | cut -b62-'
>
> Unfortunately there are differences. Now I simply don't know if these
> differences render the package binary incompatible, or whether they
> don't matter at all.

Additions do not break binary compatibility in shared libraries, so the
only concern is with the removals:

> -strlcpy
> -mkstemps
> -strlcat
> -_ZN8DwStringixEm

The new version of the library is no longer exporting its internal
portability functions.  This is good -- libraries should not export
unrelated symbols.  However, if any of its dependencies happened to
depend on those internal symbols (using the versions provided by the
library lazily rather than providing their own), you would break them.

I don't have a good feel for how likely that is for this particular
library.  In general, removal of internal symbols that were never part
of the public API is often done without a bump in the SONAME and just
fixing any dependent packages that break, but ideally it's nice to know
what might break.  Debian Developers with access to the Lintian lab on
gluck can search through the objdump output for clues, although we don't
have a simple script to do that.  I'm not sure what to recommend to
people who don't have access to a fully populated Lintian lab.

More concerning is the last symbol removal, which indicates that the
library has removed:

    DwString::operator[](unsigned long)

which was present in the previous version.  Is this also an internal
symbol or was it part of the published API?

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: