[Top][All Lists]

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

Re: The case of libkmod's .so versioning attempts, and induced collision

From: Bob Friesenhahn
Subject: Re: The case of libkmod's .so versioning attempts, and induced collisions
Date: Mon, 6 Feb 2012 20:03:41 -0600 (CST)
User-agent: Alpine 2.01 (GSO 1266 2009-07-14)

On Tue, 7 Feb 2012, Jan Engelhardt wrote:

Much to my disappointment, I found that the newly-released libkmod v5
has made the following non-trivial change to its source tree, the latter
of which I want to bring to attention:
[stuff removed]
(The numbers are directly fed into libtool's -version-info argument.) As
you can see, the CURRENT number was decreased, which, according to
common libtool sense, is not something that one should normally do. Why
do I care? Well, I happen to be active in toying with system tools
(especially the ones I have to use sooner or later), as well as distro
packaging, with a preference to get things right.

Unfortunately, I was unable to convince the kmod people of this fact.
Kay Sievers and Lucas De Marchi's argumentation is that (a) kmod is
linux-only and (b) there has 'never been a' before, or even
something about (c) not caring about GNU/"the mess that libtool is".

Hopefully your intention is only to illustrate what projects should not do and not to submit a patch. This libkmod project seems to be less than two months old and perhaps the developers still have a bit to learn about library versioning.

While libtool does compute the name to apply to the library (using ELF rules), build-time (ld) and run-time ( linking is done via standard system tools and so they determine how the naming gets used.

ELF is where the rules come from, not libtool. Libtool tries to make it easy to follow the ELF rules while working as best as possible with other schemes.

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

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