SCO/bugfix patch 10 of 10: --version-info improvement

[Kean Johnston]

Patch 10 of 10 attached ...

Rationale:

I expect a lot of resistance to this patch :) Let me just start of by
saying that I already know most of the objections why you dont want to
explicitly name a shared library. However, it is a very useful option
and I hope to explain why.

I have encountered at least two applications so far that do a realpath()
on a shared library, and then check the SONAME to ensure that they match
a compile-time constant. I know, the applications are retarded. But
libtool is a program that is supposed to make creating shared libraries
easier, and having the ability to actually have control over things like
the SONAME make it more generically useful, and caters for situations
that we may not have forseen. The current scheme uses soname_spec as the
sole mechanism for setting the SONAME for a shared library. This is
a calculated name based on the current library version. However, as
a programmer, I may know that even though shared library version Y
has some incompatible interfaces relative to version X, that those
chages are a pure superset of X. Thus, I want the new version Y to
also be available to old programs that linked against version X. The way
you would *want* to do this is with a simple symlink during packaging.
99.999% of the time, that will suffice. Only really stupid applications
that do crap like realpath() and checking the SONAME will fail. Its a tiny
corner case, but this patch provides a mechanism for covering it. I can't
really see a downside to this, to be honest.

2005-10-24  Kean Johnston  <address@hidden>

        * ltmain.in: Provide a mechanism for explicitly setting the value
        of SONAME in a shared library using an optional 4th argument to
        --version-info.

        * doc/libtool.texi: Document it.

Index: ltmain.in
===================================================================
RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v
retrieving revision 1.334.2.91
diff -u -3 -p -r1.334.2.91 ltmain.in
--- ltmain.in   18 Oct 2005 07:26:05 -0000      1.334.2.91
+++ ltmain.in   30 Oct 2005 21:22:25 -0000
@@ -3067,10 +3081,16 @@ EOF
        set dummy $vinfo 0 0 0
        IFS="$save_ifs"
 
-       if test -n "$8"; then
+       if test -n "$9"; then
          $echo "$modename: too many parameters to \`-version-info'" 1>&2
          $echo "$help" 1>&2
          exit $EXIT_FAILURE
+       fi
+
+       if test -n "$8"; then
+         override_soname=$5
+         soname_spec="$override_soname"
+         library_names_spec="$override_soname $library_names_spec"
        fi
 
        # convert absolute version numbers to libtool ages

Index: doc/libtool.texi
===================================================================
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.134.2.13
diff -u -3 -p -r1.134.2.13 libtool.texi
--- doc/libtool.texi    29 Aug 2005 11:11:41 -0000      1.134.2.13
+++ doc/libtool.texi    30 Oct 2005 21:22:25 -0000
@@ -1318,11 +1318,13 @@ If @var{output-file} is a program, then 
 uninstalled shared libtool libraries.  If @var{output-file} is a
 library, then only create a static library.
 
address@hidden -version-info @var{current}[:@var{revision}[:@var{age}]]
address@hidden -version-info 
@var{current}[:@var{revision}[:@var{age}[:@var{override}]]]
 If @var{output-file} is a libtool library, use interface version
 information @var{current}, @var{revision}, and @var{age} to build it
 (@pxref{Versioning}).  Do @strong{not} use this flag to specify package
-release information, rather see the @samp{-release} flag.
+release information, rather see the @samp{-release} flag.  For those
+very rare cases where you absolutely @emph{must} provide an explict
+library name, you can specify an @var{override} name.
 
 @item -version-number @var{major}[:@var{minor}[:@var{revision}]]
 If @var{output-file} is a libtool library, compute interface version