On Tue, Feb 27, 2018 at 02:01:06PM +0100, Nikos Mavrogiannopoulos wrote:
Hi, When we initially introduced symbol versioning in nettle we bundled all symbols from the library in a single version. That means that new symbols added to a release like nettle_get_hashes() may cause issues like this: https://bugzilla.redhat.com/show_bug.cgi?id=1549190
The underlying issue is in rpm-based systems which detect which symbols exist in which library version based on the version. That way, when a dependency is tracked, the version with the right symbol will be retrieved. Debian-based systems work differently so that shouldn't affect it.
To address these problems in gnutls, I follow these additional rules in to having a map file: https://gitlab.com/gnutls/gnutls/blob/master/CONTRIBUTING.md#symbol-and-libr...
You mention here that symbol versioning lets you expose multiple symbols with the same name, but different versions, as is commonly seen with glibc.
That is correct, but beware that this trick only works on platforms using certain linkers. In particular Windows linker scripts will not support this. In fact windows doesn't support versioning at all - you just have a single flat list of exported symbols. For libvirt we just take the list of versioned symbols & merge them into a list suitable for Wndows DLL linking. So while using versioned symbols is fine if you only ever export one symbol for a given name, you should wary of relying on the ability to export the same name twice with different versions as that's non-portable.
which in turn comes from libvirt: https://www.berrange.com/posts/2011/01/13/versioning-in-the-libvirt-library/
That of course adds overhead on releases.
IME, this per-release versioning has not actually caused any notable overhead on libvirt's upstream development. At worst, you get contributors sending patches with old versions and have to point out to update the patch to use the correct next version number.
The only overhead we experianced falls on downstream vendors, if they try to fork the library ABI/API, by backporting new symbols to older releases. You can't make the backported symbol use the old version number, as that will cause an ABI incompatibilty if you later rebase to the new version. Using the new version number on the backported symbol, gives a false record of the ABI, as it makes the old version appear to support the new version's ABI whereas in fact it only supports 1 out of potentially many APIs from the new version.
For libvirt we simply refuse to do backporting of APIs in distros where I am involved of maintenence. If someone needs a newer API, libvirt just has to be rebased to the suitable version.
Regards, Daniel