httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: cvs commit: apache-2.0/src/lib/apr/include apr.hw
Date Thu, 02 Nov 2000 20:43:57 GMT
On Thu, Nov 02, 2000 at 03:15:08PM -0500, Jeff Trawick wrote:
> Greg Stein <> writes:
> > There are two reasons to deal with this, as I outlined before, but I'll
> > clarify here:
> > 
> > 1) shared library to improve system resource usage
> > 2) shared library because multiple pieces of a program refer to it
> > 
> > We all know about (1). It is (2) which is also important. Subversion uses
> > APR and a part of it (mod_dav_svn) will be loaded into the Apache
> > executable. Binding both to a shared library makes this work. Consider what
> > has happened with Expat: Perl's XML::Parser::Expat gets loaded into the
> > Apache process and barfs because Apache and the Perl module both supply
> > Expat names to the process. The solution for this was to move to having both
> > pieces refer to a shared library.
> [I guess] I follow now...  I'm not sure what all the implications are...

hehe... that is what I started the thread with, but then we had to go
through this detour...

> subversion (or at least mod_dav_svn) is going to need to be built with
> the same (or compatible) level of APR include files as Apache since (I
> guess) they will be passing APR objects back and forth (e.g., pools)...


> What about subversion and Apache shipping APR with their sources?  Is
> this going to happen?  Is subversion going to have versions
> synchronized with Apache versions so that they all get along with the
> same level of APR...

At the moment, each are planning to ship APR with their sources because APR
is not yet a separate project that can be retrieved independently. However,
I *do* believe that both projects would include an APR 1.whatever pristine
copy of the library in their distribution. We don't want users to have to
download and build two separate tarballs (we can help them).

But let's also look at the possibility of an APR already installed on the
system. It is entirely reasonable to assume that it has been installed into
/usr/local/xxx and that we point the config process at that (or heck, it
looks for it and falls back to the included copy).

Back to the original point: SVN and Apache can simply require APR 1.0 and
operate fine, wherever APR may have come from. They stay in sync through the
simple fact that they are using the same version of APR. No big deal there.
But if we have a copy built somewhere else on the box, then we should try
and hope that we can work with it, rather than having to config/build a
private copy.

And given that, the changes that I've suggested (multiple entry points and
allowing an app to work with all features enabled (e.g threading)) will help
us towards that point.


Greg Stein,

View raw message