On Tue, 7 May 2002, Pier Fumagalli wrote: > "[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?)
We either don't use APR, or use the APR that is included with Apache2.0. For our purpose, that's the only 'stable' APR we can refer to, otherwise we'll be in a maintainance nightmare where everyone will have his own version/variation of APR. But not using APR with Apache1.3 is another choice - using 'native' apache1.3 pools for example instead of APR pools, native apache1.3 maps, etc will be even slightly better ( and using the same code as jk1 will be good too ) > > 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... Yes - that's the main reason for using a single libapr.so. If you have 2 programs using different libapr.so, say with different locking mechanisms - they'll not work togheter, each will use a different lock. > 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... The version that was shiped with Apache2.0 is stable and I think that's what we should use with jk2. We may have to change our code when Apache2.1 is released - but coding against one API in jk2 ( i.e. APR-head ) and using it with Apache2 ( with another APR API ) is looking for trouble. The idea that you can release a product without some parts still changing is crazy. I understand Apache2's APR is not called APR1.0 because people don't want to support that particular API in future - but we can't ship jk2 with dependencies on APR-head ( whatever that is ). Even if APR1.0 is released, we should use it only when a stable release of Apache2.x with APR1.0 is made. > > 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)... I believe the main benefit of using shared libraries is not saving memory, but having consistency - the same code will be used in Apache2 and jk2. You can't get into a situation when Apache2 is locking in one way, and jk2 in another way. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
