[gnutls-devel] symbol and library versioning

[Andreas Metzler]

On 2017-08-11 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
> On Thu, 2017-08-10 at 14:21 +0200, Andreas Metzler wrote:
[...]
>>> As such for every symbol introduced on a particular version, we
>>> create an entry in libgnutls.map based on the version and containing
>>> the new symbols. For example, if in version 3.6.3 we introduce
>>> symbol gnutls_xyz, the entry would be:
 
>>> GNUTLS_3_6_2 { global: gnutls_xyz; } GNUTLS_3_6_1;
 
>>> where GNUTLS_3_6_1 is the last version that symbols were introduced,
>>> and indicates a dependency of 3.6.2 to symbols of 3.6.1.

>> This has not been a problem with the old approach. 

> Do you refer to the text above or the backporting issue?

Hello,
I was refering to the backporting issue ("Backporting new symbols to an
old version which is soname compatible is not allowed"). e.g.
gnutls_pkcs7_get_embedded_data_oid() was backported to 3.4.17 from
3.5.6.

Afaiui this would be forbidden/impossible now.  If 3.4.17 exported
gnutls_pkcs7_get_embedded_data_oid at GNUTLS3_4_17 then 3.4.17 and 3.5.6.
would have been ABI incompatible, an upgrade from 3.4.x to 3.5.x would
require a rebuild of all binaries using
gnutls_pkcs7_get_embedded_data_oid.
I am not sure about the problems caused by doing it the other way round
(3.4.17 exporting gnutls_pkcs7_get_embedded_data_oid at GNUTLS3_5_6) but I
guess rpm's dependency tracking might stumble. - Or would the
differently chained version definitions (GNUTLS3_5_6 depending on
GNUTLS3_4_8 or GNUTLS3_5_5 respectively) break the ABI?

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'