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