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

Re: [PATCH] libsvn SONAMEs and APR

From: Peter Samuelson <peter_at_p12n.org>
Date: 2006-04-07 08:21:08 CEST

[Justin Erenkrantz]
> Debian purposely disables libtool's implicit linking features - but,
> in all releases we've ever shipped, our distributed GNU libtool's
> will end up implicitly linking to all dependent libraries.

True for libsvn itself, not true for third-party applications unless
*they* use libtool as well. And that's a local decision, or at least a
decision out of the hands of subversion. Certainly on Debian we very
much discourage linking to indirect dependencies; I don't know how
other distributors and administrators handle this.

> Do *any* other projects encode their dependencies in their SONAMEs?
> I sort of doubt it. AFAICT, the GNOME packages don't encode the
> SONAME of glib in there; but libgnome can work off several different
> versions of glib.

I don't think that's quite true. libgtk 2.x and libglib 2.x are
intended to be backward-ABI-compatible in the same way libsvn 1.x is.
gtk 2 requires glib 2; I _believe_ gtk 1 cannot use glib 2. Neither
project has released a version 3 yet. So unless I'm mistaken, the
issue hasn't come up.

Recommended practice is, when publishing an API, to try to make sure
you don't expose any interfaces from third-party libraries in your ABI;
you wrap whatever you need to wrap using your own typedefs and structs
and wrapper functions. This cuts way down on the pain you pass on to
your downstream users, though it requires some trouble, and some
vigilance to make sure you're not inadvertently leaking ABIs you don't
control. (Not counting libc; it's hard to avoid *that*.)

Thus in Debian at least, it is very common for a library to be upgraded
to use libmysql14 instead of libmysql12, or libpng3 instead of libpng2,
without any applications breaking or having to be recompiled.

Obviously the Subversion project chose not to do this for apr, and I do
agree that this was a sound decision - especially the part where you
made this position clear to downstream developers. It wasn't a
mistake, but it _does_ make this a special case. For example, you
don't tell users of libsvn_fs that they have to learn the BDB API;
downstream binaries are free to link or not link -ldb4.x.

Peter

Received on Fri Apr 7 08:21:38 2006

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.