On Fri, Mar 10, 2006 at 05:15:53PM -0600, Peter Samuelson wrote:
> Debian subversion builds will soon be moving to apr 1.2, in lockstep
> with Debian apache2. (Because of mod_dav_svn, we have no choice.) We
> know this will occasion an ABI change to libsvn, so this requires
> changing the embedded SONAMEs of the libraries. (See footnote for a
> quick introduction to SONAMEs.)
>
> I note that subversion currently has no particular notion of library
> versions - which I suppose is OK since you're committed to never
> changing the ABI incompatibly - but it's probably better to be
> explicit. Anyway, libtool generates its own default SONAMEs:
>
> $ objdump -p /usr/lib/libsvn_client-1.so.0 | grep SONAME
> SONAME libsvn_client-1.so.0
>
> I'll need to adjust this in some way, to denote the ABI change caused
> by the new apr. I'll do it myself on Debian if I have to, but I'd
> prefer to avoid this, as it'll create a gratuitous incompatibility
> between Linux distributions. E.g., if Fedora also decides to build
> subversion 1.3 with apr 1.2, our binaries won't work on Fedora, or vice
> versa, unless they happen to make the *same* change to the SONAME
> strings that I do.
I considered this issue when I updated the Fedora packaging for APR 1.x.
I think the correct answer is that any application which links against
libsvn* must also link directly against (i.e. have a DT_NEEDED for)
libapr. The Subversion API does not isolate applications from APR ABI
changes, so this doesn't seem unreasonable - <app which uses SVN> has a
direct dependency on the APR ABI version; so app needs a DT_NEEDED for
the libapr SONAME.
Making every library SONAME be a product of the exported ABI version of
every dependant library would get quickly unmanageable. You'd also have
to embed the apr-util ABI version in the SVN sonames; and the apr-util
ABI version must also probably embed the OpenLDAP ABI version because of
the apr_ldap.h mess; etc etc. Yet there's absolutely no practical gain
to adding all this complexity: when you want to update to an APR package
which has a new ABI, you still have to update exactly the same set of
packages.
The Debian libtool patch which Justin mentions is certainly related to
this: libtool will by default ensure that the libapr* dependency is
leaked upwards to any application which links against libsvn*.la. That
is the desirable behaviour in this case; and it's exactly why this
behaviour should not be changed globally, but needs to be decided
per-library and per-dependency.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 11 18:43:54 2006