Library ABI change

[Guido Aulisi]

Hi,
recently serd library changed its ABI adding 1 function without
bumping the soname.
I think adding one function should not be a problem for depending
packages, what do you think about it?

Guido
fas account: tartina

[Zbigniew Jędrzejewski-Szmek]

On Mon, Aug 06, 2018 at 09:30:39AM +0200, Guido Aulisi wrote:
>  Hi,
>  recently serd library changed its ABI adding 1 function without
>  bumping the soname.
>  I think adding one function should not be a problem for depending
>  packages, what do you think about it? 
The change is backwards compatible, so programs linked with the older
library will run without issue with the newer library. But programs
linked with the newer library might crash when run with the older
library (if the program uses the new symbol, it will fail during
symbol resolution).

Looking at serd, it does not use versioned symbols [1], so there's
nothing to tell rpm that a package compiled against the newer lib
cannot be installed with the older lib [*]. If the new package is just
in rawhide, it's probably OK to assume that packages will be updated
at the same time. However, if serd were to be updated in released
Fedora, and then some depend package was rebuild against the new serd
and an update was released for it, users might install just that
update without updating serd, and the app could then crash at
startup. So serd should not be updated in F28 or lower without additional
precautions.


[1] https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html

[2] I'm out of my depth here, and would love for somebody who understands
this to fill in the details:
I see three types of libraries:
- libraries that use symbol versioning like libsystemd. Then each new symbol
  that is added get's it's own version, and this translates into generated
  Provides:
  $ /usr/lib/rpm/elfdeps -P /usr/lib64/libsystemd.so.0.19.0  
  libsystemd.so.0(LIBSYSTEMD_209)(64bit)
  libsystemd.so.0(LIBSYSTEMD_211)(64bit)
  ...
  libsystemd.so.0()(64bit)

  That is clear, because then dependent packages require a specific version,
  e.g. $ rpm -qR xtide | grep systemd
  libsystemd.so.0()(64bit)
  libsystemd.so.0(LIBSYSTEMD_209)(64bit)

- libraries that use just a single-number so-version. Then rpmdeps generates
  Provides based on DT_SONAME.

  serd seems to fall into this category, because
  it is linked as
  [11/13] Linking build/libserd-0.so
  ['/usr/lib64/ccache/gcc', '-shared', '-Wl,-h,libserd-0.so.0',
'src/byte_source.c.3.o', 'src/env.c.3.o', 'src/n3.c.3.o',
'src/node.c.3.o', 'src/reader.c.3.o', 'src/string.c.3.o',
'src/uri.c.3.o', 'src/writer.c.3.o',
'-o/var/tmp/serd/serd-0.30.0/build/libserd-0.so', '-Wl,-Bstatic',
'-Wl,-Bdynamic', '-lm']

  $ rpm -qP serd | grep libserd
  libserd-0.so.0
  libserd-0.so.0()(64bit)

- but then there are libraries which use major-minor-patchlevel versioning,
  as described in https://autotools.io/libtool/version.html.
  But afaics, only the major number, i.e. the so-version finds reflection
  in the executables which link to this library, and there's also no difference
  in Provides.

  For example:
  $ cat a_out.c
  int main() {return 0;}
  $ gcc -Wall a_out.c -o a_out -lmikmod
  $ /usr/lib/rpm/elfdeps -R ./a_out | grep mikmod
  libmikmod.so.3()(64bit)

  So libmikmod has a minor-patchlevel version of .3.0, but seemingly no use is made
  of this. Am I missing something?

Zbyszek

[Daniel P. Berrangé]

On Mon, Aug 06, 2018 at 09:30:39AM +0200, Guido Aulisi wrote:
>  recently serd library changed its ABI adding 1 function without
>  bumping the soname. 
There's totally normal. It merely added to its ABI - it didn't change
existing ABI so nothing will break. soname change is only for when
the library deleted a symbol, or changed API contract of an existing
symbol.

>  I think adding one function should not be a problem for depending
>  packages, what do you think about it? 
Correct, there's no problem. At the very most applications using the new
API would want to explicitly require a particular version of the library
RPM

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Andrey Ponomarenko]

06.08.2018, 12:49, "Daniel P. Berrangé" <berrange(a)redhat.com&gt;:
>  On Mon, Aug 06, 2018 at 09:30:39AM +0200, Guido Aulisi wrote:
> >  recently serd library changed its ABI adding 1 function without
> >  bumping the soname.
>
>  There's totally normal. It merely added to its ABI - it didn't change
>  existing ABI so nothing will break. soname change is only for when
>  the library deleted a symbol, or changed API contract of an existing
>  symbol.
>
> >  I think adding one function should not be a problem for depending
> >  packages, what do you think about it?
>
>  Correct, there's no problem. At the very most applications using the new
>  API would want to explicitly require a particular version of the library
>  RPM
>  
ABI report for Serd:

https://abi-laboratory.pro/?view=timeline&l=serd