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 <[EMAIL PROTECTED]> * 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. [EMAIL PROTECTED] -version-info @var{current}[:@var{revision}[:@var{age}]] [EMAIL PROTECTED] -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