[Stefan Sperling]
> Is there a particular reason why library versioning isn't already
> being done?
Library versioning is somewhat complex, but the part we care about here
is the ABI label, which on ELF is called the "SONAME" (shared object
name). This is a string that takes the form "libsvn_wc-1.so.0", and
libtool builds this string from -version-info. On the installed system
the same string will exist as a symlink to the appropriate library
implementing this interface, and that's how the ELF runtime linker
finds it. The runtime linker doesn't care what the string is or what
it looks like, except to look for it as a filename (usually a symlink).
Until libsvn_* change their ABI in an incompatible way, it is not
appropriate to change the SONAMEs. Such changes will not be done for
any Subversion 1.x. (Well, except that some people now want to
officially recommend building libsvn for use with Apache 2.2, which
would probably cause memory corruption crashes in applications which
are not recompiled, but that change is not tied to a specific svn
release.)
libtool goes to a lot of trouble to set library search paths while you
compile and run your application, so that it uses libraries inside the
build tree instead of system copies. This feature is known to be
broken in Debian as a side effect of another more important libtool
fix[*], but last I heard it worked fine on other platforms. I guess it
is possible that libtool is broken everywhere now for some reason. It
always was a difficult feature to support properly.
[*] http://bugs.debian.org/291641. Both libtool and GNU ld have been
blamed as the root cause of this bug, which is exposed through a
libtool change. Nobody seems eager to step in and hack a
fix/workaround into libtool or ld, perhaps because both packages
are intimidating.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Received on Wed Dec 5 02:17:12 2007