Re: OSF versioning and large current/revision/age

[Ralf Wildenhues]

Hi Tim,

* Tim Mooney wrote on Sun, Dec 19, 2004 at 06:55:18PM CET:
> 
> I just built atk-1.9.0 (part of gtk+) on Friday, and ran into an issue
> with versioning that's making me wonder what kind of problems we may
> encounter in the future.
> 
> Atk's ABI hasn't changed in quite a while, and because of the way it (and
> many other GNU/GNOME packages) increments library versioning, the shared
> library is created (by libtool) with a libtool invokation that includes:
> 
>       -version-info 900:0:900
> 
> First, based on inspection of ltmain.in (from 1.5.10), it looks like
> libtool doesn't currently handle current/revision/age values with four
> or more digits.  That's probably going to be a problem for projects like
> atk.

Yep.

Does anybody know whether using four-digit version numbers is portable
(or, to put the other way round: was there a technical reason for three
digits)?  As this impacts every system libtool supports, this has very
far-reaching implications.  A survey would be necessary before changing
this.

> Second, on platforms that use OSF-style versioning, that -version-info
> argument results in a library creation command line that's almost 11K in
> length; 90% or more of that command line length relates to the
> 
>       test -n "900.900.0:0.0:1.0:.....:899.0:900.0" && \
>       -set_version 900.900.0:0.0:1.0:.....:899.0:900.0
> 
> This results in an IVERSION field in the shared library that's more than
> 5K in length.  At least on Tru64 (I'm not sure about other platforms
> that use OSF-like versioning, such as IRIX) that's not a problem for the
> loader or the executable itself, but it is excessive.  ;-)

Yep.

> Rainer Orth had a good overview of osf versioning vis-à-vis libtool in a
> message to the list a couple years ago:
> 
>       http://lists.gnu.org/archive/html/libtool/2002-06/msg00027.html
> 
> There was a short thread a couple months later, relating to his patch
> waiting to be applied:
> 
>       http://lists.gnu.org/archive/html/libtool/2002-08/msg00044.html
> 
> At the end of that thread, I asked a question that seems to be relevant
> again (still): Why is libtool using both SONAME-style versioning *and*
> internal versioning, for platforms like Tru64 and IRIX?

Erm, changing this would break compatibility.
The best we could do would be to make this a Libtool option.

But other than that, offering the other way looks like a decent idea,
the discussions you mention do not seem to imply otherwise.

> Does anyone have any recollection of why that decision was made?

I'll leave this..

> The archives are silent about it.  I also don't understand why a ".0"
> is being appended to each and every interface ( ${iface} ) that's part
> of $verstring.

..and this for someone more knowledgeable than me to answer.

> In any case, I generally espouse following a particular UNIX flavor's
> conventions for building and installing software, but in the particular
> case of libtool and osf-style versioning, I've long been concerned that
> we might be heading for trouble.  libtool's concepts of current, age,
> interface, et.  al. don't mesh particularly well with IVERSION-style
> versioning, IMHO.
> 
> I'm considering patching libtool so that it *optionally* uses *just*
> soname versioning, similar to Solaris.  That way, the person that's
> actually building software with libtool can decide if they want libtool to
> use the IVERSION field and the soname, or just soname.

If the other maintainers agree, we might adopt this.

> I've only partially been following the thread about libtool and MAKEFLAGS,
> but it looks like there's a possibility of some kind of $(LIBTOOLFLAGS) that
> could be passed to libtool on the command line to control other optional
> behavior.  I had been considering an environment variable that libtool
> would check and parse, but if other optional behavior control is going to
> be via command-line flags, it would seem best if my patch piggybacked on
> that work.

No, I don't think this is a sensible way to go.  IMVHO it would seem
much more appropriate to add a new option to LT_INIT and maybe as well
provide this as a configuration option (not sure about the latter).

Comments appreciated.

Regards,
Ralf