Maintained by: NLnet Labs

[Unbound-users] libunbound version number

Ondřej Surý
Fri Aug 17 09:11:53 CEST 2012


On Thu, Aug 16, 2012 at 5:37 PM, Mariano Absatz - gmail
<el.baby at gmail.com> wrote:
> On Thu, Aug 16, 2012 at 12:09 PM, W.C.A. Wijngaards <wouter at nlnetlabs.nl>
> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Mariano,
>>
>> On 08/16/2012 04:45 PM, Mariano Absatz - gmail wrote:
>> > Hi,
>> >
>> > Is there some kind of correlation between the libunbound version
>> > number and the Unbound package version number?
>> >
>> > I had previously compiled Unbound 1.4.13 and the library files I
>> > got in /usr/local/lib included libunbound.so.2.13.0
>> >
>> > I just compiled the latest Unbound 1.4.18 and the new library file
>> > is libunbound.so.2.1.3
>> >
>> > It's not so strange that the library has a different versioning
>> > from the package, however, 2.1.3 looks like older than 2.13.0.
>> >
>> > Has the library gone backwards? Did the versioning scheme changed?
>>
>> It uses GNU libtool versioning, shared library versions:
>>
>> http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html
>>
>> unbound version has libtool version current:revision:age
>> 1.4.13 has 2:13:0
>> 1.4.18 has 3:3:1
>>
>> Because, at 1.4.14, the ub_version() call is added to the library,
>> making a new version (which is binary compatible with the previous
>> version).  So, there is a symlink for libunbound.so.2 binary API
>> (thus, existing programs continue to link and run).
>>
>> The shared library numbers represent the library API.
>>
>
> OK, but shouldn't the main binary be called  libunbound.so.3.1 (or something
> like that) instead of libunbound.so.2.1.3? That is, then you can symlink it
> from libunbound.so.2 and so on.

No, it shouldn't. The ABI is still backwards compatible, there's no
reason for SONAME bump.

Please go read the document Wouter has mentioned for further
information on library versioning.

O.
-- 
Ondřej Surý <ondrej at sury.org>