On Thu, 11 Apr 2002, jean-frederic clere wrote: > > The 'idealistic' goal was to do that transparently - using System.load(), > > so that the user will not have to set LD_LIBRARY_PATH. We would set > > aprHome in jk2.properties - and that's it. > > Something like ld.config or crle also helps.
It's the same thing. My point is that I can't find any method to avoid requiring a setup where all libraries can be available and in path. I can get it to work on some platforms, sometimes, with lots of pain. It seems Sun can't either - the java_wrapper does set the LD_LIBRARY_PATH before starting java ( look at 'java' content, it's a script on solaris and linux ). The problem applies to both 'directions' - C loading java and Java loading C. In the first case, libjvm.so and all other java libs that are needed should be in LD_LIBRARY_PATH, in the second libapr and all the libs we use should be there. On some OSes and some libraries it is possible to avoid that - and that's what we tried to do in the jni worker and in our java native code. But it is not reliable - it depends on too many factors. My proposal is to give up - and explicitely require that LD_LIBRARY_PATH is set, or ld.config, or libapr.so and libjkjni.so are installed in /usr/lib or JAVA_HOME/jre/lib/i386 or any equivalent situation. The shell scripts are easy to modify ( we'll just require an extra 'APR_HOME' and include it in LD_LIBRARY_PATH if set ). For non-shell users we'll just make it explicit that LD_LIBRARY_PATH must be set to use the native code. For the JNI worker we'll make it explicit that JAVA_HOME and LD_LIBRARY_PATH including the java libs are required before starting apache ( or IIS,etc). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
