apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Suitability for shared-library use?
Date Mon, 21 Aug 2006 02:37:33 GMT
CrusadingKNIGHT wrote:
> Hello, I recently noticed APR would be a good candidate for an
> abstraction library, since it's much smaller than almost all of
> the alternatives, and is quite mature. However, the UNIX
> compiling page mentions that "APR is not quite ready to be
> installed as a system-wide shared library". I'm just wondering
> why this is the case, and what, if any corner cases I should be
> prepared for if I attempt to use it as a shared library.

Provided you 1) ensure that your application does not install an older
version, and 2) doesn't install a version that is less capable, or has
fewer features enabled than the original one, then the current version
1.2.x -is- installed as a shared library on many platforms.

apr-1-config lets you determine these details of the current installation.

Right now apr and apr-1 are commonly installed as system libraries.  The
trouble would come in if you have a build that is gpl-ed (by including
gdbm support, for example) and you rebuild without that support.  Now,
if one of your APR apps supported it, you just broke a different app :)

That said, feel free to use it either in your own project's lib or on the
few platforms which support it already, as a system lib.

When we 'break it' significantly - and it's no longer binary compatible,
it will become libapr-2.so and gain a apr-2-config script :)  So you
shouldn't ever have problems moving forwards, I suspect that warning is
reasonably out-of-date.


Mime
View raw message