[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool versioning

From: Jef Driesen
Subject: Re: libtool versioning
Date: Mon, 03 May 2010 09:08:14 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100423 Lightning/1.0pre Thunderbird/3.0.4

On 02/05/10 03:33, Bob Friesenhahn wrote:
On Sun, 2 May 2010, Jef Driesen wrote:

I'm trying to understand the libtool current:revision:age versioning scheme.
I think I understand how it works, but I noticed that filename of the shared
library seems to get different numbers (current-age.age.revision). Is that

The filename generation is dependent on the OS.  It is usually best
not to pay any attention to the filenames at all unless you are
switching from some other existing numbering scheme and need to avoid
a collision.  I keep these notes in my configure script (taken from
various libtool related documentation) so that I remember how things

The reason why I found the filename confusing, is because in the article I was looking at, they make it look like the libtool version c:r:a ends up in the filename as "".

I have seen this a couple of other places as well. As a newbe to the libtool versionning scheme, it took me a while to figure out what was really going on. Very confusing.

# Here are a set of rules to help you update your library version
# information:
#  1. Start with version information of `0:0:0' for each libtool library.
#  2. Update the version information only immediately before a public
#     release of your software. More frequent updates are unnecessary, and
#     only guarantee that the current interface number gets larger faster.
#  3. If the library source code has changed at all since the last update,
#     then increment revision (`c:r:a' becomes `c:r+1:a').
#  4. If any interfaces have been added, removed, or changed since the last
#     update, increment current, and set revision to 0.
#  5. If any interfaces have been added since the last public release, then
#     increment age.
#  6. If any interfaces have been removed since the last public release,
#     then set age to 0.

Shouldn't step #6 included "changed" as well as "removed"? If you change the interface (for example modifying function parameters), backwards compatibility is broken too. But only "removed" is listed here.

Personally, I think the last three steps are easier to understand when written as if cases, rather than steps:

1. Interface unchanged: C:R+1:A
2. Interface changed in a backwards compatible way: C+1:0:A+1
3. Interface changed and backwards compatibility is broken: C+1:0:0

If find this more intuitive because it's more similar with the typical major.minor.micro scheme, where minor and micro are equivalent with age and revision. Only the major number is really different from the libtool current number, because that last one is increased with every interface change.

One of the reasons why I would like to know the filename is that I'm also
building a Windows DLL (it's a cross platform library) where I would like to
include a version resource. And one of the fields in a Windows version
resource is the "OriginalFilename". It seems that dlls get filename
libfoo-x.dll, where x is the number current-age. Is that correct?

It is true that Windows does not support useful versioning and is not
able to select among DLLs based on an interface version.  It seems
that your analysis is correct.

Thanks for the info.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]