[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion library version numbers

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-10-09 21:30:45 CEST

Greg Hudson <ghudson@MIT.EDU> writes:

> On Sat, 2004-10-09 at 13:29, Philip Martin wrote:
>> $ objdump -p objdump -p libsvn_fs-1.so|grep SONAME
>> SONAME libsvn_fs-1.so.0
>> Is that .so.0 correct? Should it be .so.1?
> If we are following http://apr.apache.org/versioning.html then we don't
> use the libtool major version number, instead making our major version
> part of the library name. (This way you can explicitly link against a
> particular major version of the library.)
>> Is libsvn_fs-1.so.0.0.0 correct? Should it be
>> libsvn_fs-1.so.1.2.0?
> If we are following the above-referenced document, then it should be
> libsvn_fs-1.so.0.2.0. But I don't know if there's any particular value
> in that, since the trailing ".2.0" isn't part of the soname.
> In fact, it seems like it would be detrimental; if you install svn 1.0
> and then install svn 1.1, you'd have leftover gunk from the 1.0
> installation which isn't used by either the compile-time or run-time
> linkers. (And you wouldn't have the corresponding headers to use those
> old libraries either.)

Removing the old versions would be the job of a distribution's package
management system. I agree it would be a problem for anyone
installing from source.

It appears that we have reduced an X.Y.Z triplet, as used by
libfoo.so.X.Y.Z, down to a single X as used by libfoo-X.so. I guess
that works so long as we follow our ABI versioning rules.

I wonder if we should start using ELF symbol versioning within the
libraries? I guess the test suite might need tweaking as I think it
calls one or two internal library functions.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 9 21:34:54 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.