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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
