OSF versioning and large current/revision/age

[Tim Mooney]

All-

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.

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.  ;-)

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?  Does anyone have
any recollection of why that decision was made?  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.

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.

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.

Comments and suggestions welcome,

Tim
--
Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164