apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Hudson <ghud...@MIT.EDU>
Subject apr pkgconfig use (apr.pc vs. apr-1.pc)
Date Tue, 29 Jun 2004 19:11:30 GMT
Imagine a library downstream from apr (say, Subversion) is trying to
follow the APR versioning guidelines
(http://apr.apache.org/versioning.html) in order to provide a stable
platform for third-party applications and libraries.

To do this, the downstream library must define the major version of
its upstream dependencies.  If Subversion links against any old
version of APR it can find on the system, then the following sequence
of builds and installs breaks rapidsvn:

  APR 0.9
  svn 1.0
  APR 1.0
  svn 1.1

because, although the APR soname has changed, the svn soname has not,
but it's exporting a different ABI (in relation to apr_off_t).

If that problem seems far from home, the same problem is going to
happen with {APR 0.9} {httpd 2.0.49} {plugin} {APR 1.0} {httpd

The solution to this problem is for the downstream library to rigidly
define the major version of its upstream dependencies.  That's why
GNOME packages install things like libgnome-2.0.pc.  (Which is
overboard; "2" would have been fine, and if you check you'll find that
the "2.0" didn't change for libgnome 2.2 or 2.4 or 2.6.  But that's a
detail.)  It is only this discipline which has allowed GNOME to manage
the GNOME 1 to 2 transition as gracefully as it did.  (It's true that
GNOME 1 didn't use versioned library names or pkgconfig, but by
changing all the library names and adopting pkgconfig, GNOME 2
effectively created a separate universe, which is exactly the correct
thing for a major version upgrade, and is exactly the point of using
different library and pkgconfig names for a major version upgrade.)

So, please change the recently added pkgconfig support to install
apr-1.pc, so that upstream packages will run "pkg-config --libs apr-1"
instead of just looking for any old version of APR.  By itself, that
won't help with the APR 0.9 to APR 1.x transition, but it will help
with APR 1.x to APR 2.x.

Separately, I will request that APR remove apr-config from APR 1.0 and
later in order to correctly manage the APR 0.9 -> APR 1.0 transition,
but I bet that won't fly.

View raw message