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

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

 



Hi Bob

[ Please don't remove CC ]

On Tue, Feb 7, 2012 at 12:03 AM, Bob Friesenhahn
<bfriesen@xxxxxxxxxxxxxxxxxxx> wrote:
> 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 libkmod.so.2' 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.

Yes. We can always learn. It seems that this is not the case here.
There are other projects releasing like this and no one pointed out to
a reasonable argument against it. That means these arguments are not
valid in our case:

a) It's not what libtool's manual says to do
b) In other architectures major number is not always c - a.

That's because libkmod (like in other projects that do the same
release scheme) we are very tied to Linux, and being portable is not a
concern.

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

No, quite the opposite. It doesn't follow libtool's manual, but it
does follow "ELF rules", ld and ld.so. On a API and ABI break the
soname is bumped according to libtool rules. And it doesn't matter if
it goes from libkmod.so.1 to libkmod.so.151 or if it goes to
libkmod.so.2. soname was bumped. major was bumped. Skipping all the
numbers between the majors seems like craziness.


>
> 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.

As far as I understand, we are following "ELF rules". We are just not
following what libtool manual says.



Regards,
Lucas De Marchi
--
To unsubscribe from this list: send the line "unsubscribe linux-modules" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux