"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> If we use apr, I think ( a bit strongly ) that
> we should use exactly the same library as apache2 does.
If that's provided with Apache 2.0... What if it's not provided with the
web-server (AKA, apache 1.3?)
> APR libs should/could be installed in /usr/lib, /usr/include,
> and considered 'system' ( like glib, qt, nspr, etc ).
> If you build a non-threaded version, it shouldn't be
> called libapr.so in any case.
I strongly disagree with that, considering the bazillion of options that you
have in building APR, and the different features that the library _can_
support (but doesn't all times)...
Even when building Apache 2.0 the APR library is built differently depending
on _how_ you build your Apache 2.0...
Consider that all other projects using them are building APR in their
sources as Apache 2.0 and WebApp does (namely, SubVersion and in the future
PostGreSQL)...
> Also I think the version that comes with Apache2's
> binary is to be considered the 'reference' - since Apr
> was not released independently, the apache2 package can
> be considered as the 'dependency'.
It has never been released indipendently because of the API changes that
(are still) going on to some extent... Look at the APR_ATOMICS, or the
locking which got completely rewritten few months ago...
>>> Should we use static build apr (like does webapp) ?
>>> In all case should the apr for 1.3 must be with
>>> or without pthread ?
>
> Static apr may be a workaround, but I would avoid that if
> possible. libapr.so should be a 'deterministic' entity,
> if someone has a problem we should know he uses a certain
> version.
I believe that the dynamic build of libapr is better if you have plugins
that your code needs to read: when you compile those, you link them against
a library, rather than to a binary (which you can't easily do anyway)...
Pier
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
