[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The case of libkmod's .so versioning attempts, and induced collisions
From: |
Jan Engelhardt |
Subject: |
The case of libkmod's .so versioning attempts, and induced collisions |
Date: |
Tue, 7 Feb 2012 01:35:49 +0100 (CET) |
User-agent: |
Alpine 2.01 (LNX 1266 2009-07-14) |
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:
commit e479598b7d19ae7be45bf5329d6e4df32d646c16
diff --git a/Makefile.am b/Makefile.am
index 69ab986..172d2ff 100644
--- a/Makefile.am
+++ b/Makefile.am
-LIBKMOD_CURRENT=4
+LIBKMOD_CURRENT=2
LIBKMOD_REVISION=0
-LIBKMOD_AGE=3
+LIBKMOD_AGE=0
(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".
They base their decision on the assumption that libtool on Linux always
uses the "MAJOR = CURRENT - AGE" computation scheme, and that it would
therefore be ok to go from C=4,A=3 to C=2,A=0 just so that they have a
nice sequence of libkmod.so.1, libkmod.so.2, because they do not seem to
like the appearance of libkmod.so.5 in their system which would be
emitted if C=5,A=0 had been chosen.
It is my position that assuming any particular scheme for MAJOR chosen
by libtool should not be relied upon, just as assumptions in general are
a habit with a certain badness level, depending on the situation.
The following patch tries to exemplify the problem that compiling both
kmod v2 and kmod v5 will cause colliding libkmod.so.2s to be emitted
that have different interfaces.
Sinister voices will claim my libtool would be broken, but would it be?
Who is to say that I cannot have a Linux kernel-based system, and use
e.g. BSD's MAJOR scheme instead? Every src package that adheres to
libtool versioning (i.e. as per libtool.info) should not have a problem
regardless of how CURRENT/AGE is encoded in the filename.
---
libltdl/config/ltmain.m4sh | 8 +-------
libltdl/config/ltmain.sh | 8 +-------
2 files changed, 2 insertions(+), 14 deletions(-)
Index: libtool-2.4.2/libltdl/config/ltmain.m4sh
===================================================================
--- libtool-2.4.2.orig/libltdl/config/ltmain.m4sh
+++ libtool-2.4.2/libltdl/config/ltmain.m4sh
@@ -6626,7 +6626,7 @@ func_mode_link ()
versuffix=".$current.$revision";
;;
- freebsd-elf)
+ freebsd-elf | linux)
major=".$current"
versuffix=".$current"
;;
@@ -6660,12 +6660,6 @@ func_mode_link ()
versuffix="$major.$revision"
;;
- linux) # correct to gnu/linux during the next big refactor
- func_arith $current - $age
- major=.$func_arith_result
- versuffix="$major.$age.$revision"
- ;;
-
osf)
func_arith $current - $age
major=.$func_arith_result
Index: libtool-2.4.2/libltdl/config/ltmain.sh
===================================================================
--- libtool-2.4.2.orig/libltdl/config/ltmain.sh
+++ libtool-2.4.2/libltdl/config/ltmain.sh
@@ -7413,7 +7413,7 @@ func_mode_link ()
versuffix=".$current.$revision";
;;
- freebsd-elf)
+ freebsd-elf | linux)
major=".$current"
versuffix=".$current"
;;
@@ -7447,12 +7447,6 @@ func_mode_link ()
versuffix="$major.$revision"
;;
- linux) # correct to gnu/linux during the next big refactor
- func_arith $current - $age
- major=.$func_arith_result
- versuffix="$major.$age.$revision"
- ;;
-
osf)
func_arith $current - $age
major=.$func_arith_result
- The case of libkmod's .so versioning attempts, and induced collisions,
Jan Engelhardt <=