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
_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool
