libtool
[Top][All Lists]
Advanced

[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"
 



reply via email to

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