Re: [dpdk-dev] How to manage new APIs added after major ABI release?

[Bruce Richardson <bruce.richardson@intel.com>]

On Tue, Dec 10, 2019 at 05:39:00PM +0100, Thomas Monjalon wrote:
> 10/12/2019 17:20, Luca Boccassi:
> > On Tue, 2019-12-10 at 15:46 +0000, Bruce Richardson wrote:
> > > On Tue, Dec 10, 2019 at 03:03:51PM +0000, Luca Boccassi wrote:
> > > > On Tue, 2019-12-10 at 14:36 +0000, Bruce Richardson wrote:
> > > > > 
> > > > > Related at what to do with adding versions between major ABI
> > > > > versions, when
> > > > > investigating with Kevin the ABI checking we have made an
> > > > > unpleasant
> > > > > discovery:
> > > > > 
> > > > > This minor version bumping from 20.0 to 20.1 has apparently
> > > > > already
> > > > > broken
> > > > > our ABI according to libabigail.
> > > > > 
> > > > > The Gory Details [skip to the end for suggestions to fix]
> > > > > ------------------------------------------------------------
<snip>
> > > > > 
> > > > > Fixing This
> > > > > -----------
> > > > > 
> > > > > To fix this, we need to ensure that the SONAME remains constant
> > > > > across the
> > > > > releases. Therefore, I currently see two options:
> > > > > 
> > > > > 1. keep 20.0 as the version and soname across all releases in
> > > > > 2020,
> > > > > i.e.
> > > > >   just revert the ABIVERSION change patch. Trouble there is how
> > > > > to
> > > > > track
> > > > >   20.02 vs 20.05 etc. etc.
> > > > > 
> > > > > 2. remove the .0, .1 from the SONAMES stored in the libraries.
> > > > > This
> > > > > has the
> > > > >   advantage of keeping the existing planned schemes, but has the
> > > > > really big
> > > > >   downside of breaking ABI compatibility with anyone who has
> > > > > already
> > > > >   compiled with 19.11.
> > > > > 
> > > > > Personally, of the two options - unless someone can come up with
> > > > > a
> > > > > third
> > > > > option - I'd tend towards the second, fixing the builds to remove
> > > > > the
> > > > > .0 in
> > > > > the soname, and releasing that ASAP as 19.11.1 before 19.11 gets
> > > > > widespread
> > > > > adoption. Since this ABI stability is new, teething problems may
> > > > > be
> > > > > expected.
> > > > > 
> > > > > Thoughts and comments?
> > > > > /Bruce
> > > > > 
> > > > > BTW: For meson, the patch for option 2 is just to remove the
> > > > > so_version
> > > > > variable and all references to it from lib/meson.build and
> > > > > drivers/meson.build. Haven't looked into a "make" fix yet.
> > > > 
> > > > Hi,
> > > > 
> > > > With libtool and its (arguably arcane) format, only the first digit
> > > > is
> > > > the ABI current version and gets encoded in the elf header. The
> > > > other
> > > > digits can be used to track compatible minor increments, and are
> > > > mostly
> > > > ignored. On the system a symlink libfoo.so.major ->
> > > > libfoo.so.major.minor is added.
> > > > 
> > > > Eg:
> > > > 
> > > > $ readelf -d /usr/lib/x86_64-linux-gnu/libzmq.so.5.2.3 | grep
> > > > SONAME
> > > >  0x000000000000000e (SONAME)             Library soname:
> > > > [libzmq.so.5]
> > > > $ ls -l /usr/lib/x86_64-linux-gnu/libzmq.so.5
> > > > lrwxrwxrwx 1 root root 15 Dec 31  2014 /usr/lib/x86_64-linux-
> > > > gnu/libzmq.so.5 -> libzmq.so.5.2.3
> > > > 
> > > > Can we do the same? Not sure what the right incantation is for
> > > > Meson,
> > > > but it should be possibly.
> > > > 
> > > 
> > > That's essentially option 2, and it's still an ABI break because
> > > existing
> > > builds of 19.11 have the soname will the full version number in it.
> > > The
> > > default behaviour for meson is exactly how you described it, except
> > > that
> > > previously we needed more exact control over the version info (for
> > > your
> > > dpdk-specific versions in the sonames) and so overrode the soversion
> > > explicitly. The fix for meson is to remove this overriding i.e.
> > > remove
> > > "soversion:" parameter for each shared_library() call.
> > > 
> > >  
> > > > Also, we should leave the current at 20.0 - let's not break
> > > > compatibility already, please :-)
> > > > 
> > > 
> > > If we do this, maybe we can use 20.0.1 and 20.0.2 version numbers?
> > 
> > Yes, that's what I meant - IMHO we should just take the hit and use the
> > slightly weird 20.0 format until next year, and add a third digit for
> > compatible updates. Then for v21 we can drop it.
> 
> I am not sure to understand everything above.
> My understanding is that the soname must include major and minor:
> 	libfoo.major.minor

The filename should have, but the soname should only have the major ABI
version. It's the soname recorded in the elf file that is used by the
linker, which ignores any version suffixes on the .so.

> and the package system must install 2 symlinks:
> 	libfoo.major points to latest installed minor
> 	libfoo points to latest major
> 
> We are missing the symlink libfoo.major in 19.11.0.
> I suggest to just add this symlink in 19.11.1 and 20.02.
> 

Symlinks won't actually help here, as the suffixes are ignored. In a normal
case, where libfoo.so and libfoo.so.x both point to libfoo.so.x.y, linking
against any one of the three filenames will result in the exact same
linkage info in the binary, based on the soname in libfoo.so.x.y. Ideally,
that should be "libfoo.so.x", which remains constant for all values of "y".

> The other question is to know what the internal apps should link?
> Is there any sense linking testpmd to libfoo.major?
> 
Nothing we can do to control this, except ensure correct soname info on
linking the .so.