Re: RFS: libconfig

[José Luis Tallón <jltallon@adv-solutions.net>]

Jakub Wilk wrote:
> * José Luis Tallón <jltallon@adv-solutions.net>, 2010-04-13, 22:15:
>> [snip]
>> and upstream ships a set of (most basic) debian/libconfig9* files
>>
>> ... but in fact the libraries are compiled as  ".so.8.1.2", which means
>> 8:1:2
>
> This is not how libtool versioning works. (And it is explained how it
> works in the very same file, lib/Makefile.am.) If I'm not mistaken, on
> GNU systems libtool maps "C:R:A" to ".so.V.A.R" where V = C - A.
libconfig 1.4.3 has 9:2:1 -> 9-1 . 1 . 2 = 8.1.2
  for libconfig8 [my soname] or libconfig9 [upstream's]
 where the installed library gets called "libconfig.so.8.1.2" and hence
soname libconfig8, right ?

Whereas libconfig-1.4.4 reads
 VERSION=9:3:0 and yields  "libconfig.so.9.0.3"
>> Re-reading upstream's Changelog, the newly-introduced copy constructor
>> would indeed change the ABI, and hence need a soname bump -- upstream
>> just changed the "micro" version ????
>
> Adding new interfaces does not break ABI.
The problem being that C++'s copy-ctor are special cases: they are
generated by the compiler if absent and inline'd most of the time.
Hence, when a copy-ctor is defined, the ABI of the exported classes changes.
I concur, however, that this change only needn't change libconfig(i.e.
the "plain C" version)'s ABI.

Since upstream changed their "version" soname, we should follow suit.
Hence, we skip the potentially ? troublesome version --- which will now
never even reach unstable -- and get a proper one.
I will use the opportunity to generate and ship some symbols files, to
try and help dpkg.


Thank you for the clarification, Jakob


Regards,

    J.L.