On Tue, 7 May 2002, jean-frederic clere wrote: > > 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. > > But we have to deliver the apr.so corresponding to mod_jk.so. > > Pier is right... That is more easy to link apr staticly to mod_jk. Having to > deliver 2 files instead 1 will only bring more problems.
If you use Apache2 with mod_jk.so, then you _have_ a version of libapr.so. Having 2 variations of the apr code will bring more problems. If you don't use Apache2, jk2 will require you install a libapr.so - the same version that is shiped/taged with Apache2. First, you may install apache2 later :-) And second, that's the only stable/tested/deterministic version of APR that exist. If APR1.0 is released in the meantime, we'll have to decide what to do, but I hope an Apache2.1 will be released at that time too. If we would use Glib/Qt/NSPR - we would use the same mechanism, you would install one of those libarary ( each having one common goal with APR - of shielding you against OS-specific code ). > > 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'. > > We need one mod_jk.so for each version of apache2. Of course. But mod_jk for Apache1.3 should use the same version of APR as mod_jk for Apache2. And preferably the same binary. Apache1.3 doesn't include apr, so we can treat libapr as any other external library that a module depends on. Same for IIS - apr.dll from Apache2 is the stable/tested version, that's the API we use in jk2 until another stable release of apr is available. It may be tough to require IIS users to install Apache2, since apr.dll is not distributed separately ( but I can live with that :-). So we may have to include apr.dll and the headers in the jk distribution for IIS. That's my opinion at least - I don't see myself using/supporting a system where diferent components use different variation of a library. Autoconf is not a deterministic process - especially if you use a binary distribution, where the binaries may have been built on different machine. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
