Re: Shared library versioning

[Lasse Collin]

Thanks for your reply. Unfortunately I think that either you missed my 
point or I misunderstood something. I try to explain my thoughts better 
in this email.

On 2011-06-14 Bob Friesenhahn wrote:
> Libtool can emulate Linux in how it does the numbering but it is not
> able to change how an OS uses that numbering.

If you mean -version-info vs. -version-number, I'm not speaking about 
that. I'm speaking about how "-version-info current:revision:age" is 
converted to an operating system specific library version and how 
Libtool seems to do it incorrectly on some operating systems.

> There are also long-standing traditions associated with various OSs.

Could you elaborate? Could the traditions explain why on some operating 
systems Libtool does library versioning in a way that conflicts with the 
operating system documentation?

> On Fri, 10 Jun 2011, Lasse Collin wrote:
> > It's not clear to me if there is any operating system that requires
> > incrementing the major version when a new symbol is added to the
> > library while keeping backward compatibility (that is, when you do
> > ++current, ++age, revision=0). In this situation, Libtool does
> > increment the major version on several operating systems, but I
> > wonder if it is possible that it has been a misunderstanding when
> > someone read operating system specific docs long time ago.
> 
> While Linux users are used to always upgrading their libraries and
> applications every couple of years, the same is not true for
> "enterprise" commercial OSs.  Due to this, it seem wise to increment
> current when a new interface is added.  There is not much cost
> associated with doing things correctly (++current, ++age) for a well
> maintained library which does not lose/change interfaces.  In this
> case, the older library supporting the same current-age may be
> deleted once the new library is installed.

If I add a new public function to a library and don't modify anything 
else, I should do ++current, ++age, revision=0, right? For example, if 
the previous version of the library uses current:revision:age = 1:3:0, 
adding a new function would make it 2:0:1. On GNU/Linux, this becomes

    libfoo.so.1.0.3 -> libfoo.so.1.1.0

which is fine. On OpenBSD, GNU Libtool does

    libfoo.so.1.3 -> libfoo.so.2.0

while the correct thing, according to the OpenBSD docs, would be this:

    libfoo.so.1.0 -> libfoo.so.1.1

That is, revision isn't visible anywhere. The filename doesn't change if 
only bug fixes have been made and the library ABI hasn't been touched 
(nothing added, removed, or changed). Please read the section 
"Understanding shared libraries number rules" (it's short):

    http://www.openbsd.org/faq/ports/specialtopics.html

Why does GNU Libtool do versioning on OpenBSD in a way that conflicts 
with the OpenBSD documentation? Similar problem applies to other *BSDs, 
probably to HP-UX, and perhaps to some other operating systems too. So 
this isn't specific to OpenBSD, I'm just using OpenBSD as an example.

> The applications are really what care about the library versioning.
> The OS is just there to help with the selection process.

Packagers care about library versions too. Incrementing the major 
version means that packagers need to recompile everything that depend on 
the library. It is annoying if the major version is incremented without 
a reason.

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode