[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with libtool implementation of osf style versioning
From: |
Rainer Orth |
Subject: |
Re: Problems with libtool implementation of osf style versioning |
Date: |
Fri, 14 Jun 2002 21:02:19 +0200 (MEST) |
Rainer Orth writes:
> > > If there's agreement that this change (primarily the encoding of the major
> > > version in the SONAME) is reasonable, I'll post a patch to implement this.
> > Against 1.4 and HEAD?
>
> I can probably do so: the change will be almost identical, only the
> affected files change.
Since there were no further comments, here are the proposed patches for
HEAD and the 1.4 branch.
A few additional comments are in order:
* I noticed that there's only one other user of the osf verion_type:
sco3.2v5*. They already used an soname_spec with $major appended, but
for some reason $major in ltmain.in didn't start with a dot, so this led
to SONAMEs like libsome.so6 on that platform. I very much doubt this was
intentional, so I added the leading dot which could break that platform.
If anyone cares, one might to leave $major as is and use the dot only for
osf[345].
* Unlike my original proposal, this patch doesn't revert the order of
compatible major versions in the IVERSION field (set with -set_version).
I'm doing this on the following rational:
In the old implementation of the osf versioning scheme, two compatible
major versions looked like this (taking my example from the inital mail):
osf Files SONAME IVERSION
0:0:0 lib.so lib.so.0.0.0 lib.so 0.0.0:0.0
1:0:1 lib.so lib.so.1.1.0 lib.so 1.1.0:0.0:1.0
A binary linked against 1:0:0 would record the rightmost version number
from the IVERSION field (1.0 in this example). Even if it only used
functions from interface 0, it would fail to run against a 0:0:0 library
since that one doesn't provide version 1.0.
If one reverted the ordering as I had proposed originally
0:0:0 lib.so lib.so.0 lib.so.0.0.0 lib.so.0 0.0.0:0.0
1:0:1 lib.so lib.so.0 lib.so.0.1.0 lib.so.0 1.1.0:1.0:0.0
one gets a different failure scenario: a binary linked against 1:0:1
(thus recording version 0.0) but using interface one functions would seem
to be runnable against a 0:0:0 library, but fail at runtime since the
version 1 symbols cannot be resolved.
So both variants lead to erroneous failures, but I think it's better to
stay with the original scheme and err on the safe side.
This patch has been tested with libtool HEAD on alpha-dec-osf4.0f (both cc
and gcc 3.1) with no testsuite failures.
Rainer
Wed Jun 12 22:09:50 2002 Rainer Orth <address@hidden>
* libtool.m4 (osf[345]): Append $major to soname_spec.
Reflect this in library_names_spec.
* ltmain.in (osf): Prefix $major with . for use as extension.
Index: libtool.m4
===================================================================
RCS file: /home/cvs/libtool/libtool.m4,v
retrieving revision 1.258
diff -u -p -r1.258 libtool.m4
--- libtool.m4 1 Jun 2002 14:09:50 -0000 1.258
+++ libtool.m4 14 Jun 2002 18:40:53 -0000
@@ -1367,8 +1367,8 @@ osf3* | osf4* | osf5*)
version_type=osf
need_lib_prefix=no
need_version=no
- soname_spec='${libname}${release}.so'
- library_names_spec='${libname}${release}.so$versuffix
${libname}${release}.so $libname.so'
+ soname_spec='${libname}${release}.so$major'
+ library_names_spec='${libname}${release}.so$versuffix
${libname}${release}.so$major $libname.so'
shlibpath_var=LD_LIBRARY_PATH
sys_lib_search_path_spec="/usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc
/usr/lib /usr/local/lib /var/shlib"
sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
Index: ltmain.in
===================================================================
RCS file: /home/cvs/libtool/ltmain.in,v
retrieving revision 1.298
diff -u -p -r1.298 ltmain.in
--- ltmain.in 13 Jun 2002 11:01:47 -0000 1.298
+++ ltmain.in 14 Jun 2002 18:40:53 -0000
@@ -2685,7 +2685,7 @@ EOF
;;
osf)
- major=`expr $current - $age`
+ major=.`expr $current - $age`
versuffix=".$current.$age.$revision"
verstring="$current.$age.$revision"
Index: libtool.m4
===================================================================
RCS file: /home/cvs/libtool/libtool.m4,v
retrieving revision 1.166.2.39
diff -u -p -r1.166.2.39 libtool.m4
--- libtool.m4 6 May 2002 15:02:58 -0000 1.166.2.39
+++ libtool.m4 14 Jun 2002 18:47:33 -0000
@@ -2239,8 +2239,8 @@ os2*)
osf3* | osf4* | osf5*)
version_type=osf
need_version=no
- soname_spec='${libname}${release}.so'
- library_names_spec='${libname}${release}.so$versuffix
${libname}${release}.so $libname.so'
+ soname_spec='${libname}${release}.so$major'
+ library_names_spec='${libname}${release}.so$versuffix
${libname}${release}.so$major $libname.so'
shlibpath_var=LD_LIBRARY_PATH
sys_lib_search_path_spec="/usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc
/usr/lib /usr/local/lib /var/shlib"
sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
Index: ltmain.in
===================================================================
RCS file: /home/cvs/libtool/ltmain.in,v
retrieving revision 1.259.2.23
diff -u -p -r1.259.2.23 ltmain.in
--- ltmain.in 6 May 2002 14:51:24 -0000 1.259.2.23
+++ ltmain.in 14 Jun 2002 18:47:34 -0000
@@ -2323,7 +2323,7 @@ compiler."
;;
osf)
- major=`expr $current - $age`
+ major=.`expr $current - $age`
versuffix=".$current.$age.$revision"
verstring="$current.$age.$revision"