Oscar, This is all pretty much in a bug I posted to on naygoya.apache.org (#17762).
If you build Apache with all shared modules, then there are some dependencies in apr and aprutil. An ldd from 2.0.46 on Redhat 9 (2.4.20-9) shows the following: ldd /home/apache/lib/libapr-0.so.0.9.4 libdb-4.0.so => /lib/libdb-4.0.so libgdbm.so.2 => /usr/lib/libgdbm.so.2 libldap.so.2 => /usr/lib/libldap.so.2 libexpat.so.0 => /usr/lib/libexpat.so.0 libc.so.6 => /lib/tls/libc.so.6 libpthread.so.0 => /lib/tls/libpthread.so.0 libsasl.so.7 => /usr/lib/libsasl.so.7 libssl.so.4 => /lib/libssl.so.4 libcrypto.so.4 => /lib/libcrypto.so.4 liblber.so.2 => /usr/lib/liblber.so.2 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 libdl.so.2 => /lib/libdl.so.2 libcrypt.so.1 => /lib/libcrypt.so.1 libpam.so.0 => /lib/libpam.so.0 libresolv.so.2 => /lib/libresolv.so.2 libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 libz.so.1 => /usr/lib/libz.so.1 ldd /home/apache/lib/libaprutil-0.so.0.9.4 libdb-4.0.so => /lib/libdb-4.0.so libgdbm.so.2 => /usr/lib/libgdbm.so.2 libldap.so.2 => /usr/lib/libldap.so.2 libexpat.so.0 => /usr/lib/libexpat.so.0 libc.so.6 => /lib/tls/libc.so.6 libpthread.so.0 => /lib/tls/libpthread.so.0 libsasl.so.7 => /usr/lib/libsasl.so.7 libssl.so.4 => /lib/libssl.so.4 libcrypto.so.4 => /lib/libcrypto.so.4 liblber.so.2 => /usr/lib/liblber.so.2 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 libdl.so.2 => /lib/libdl.so.2 libcrypt.so.1 => /lib/libcrypt.so.1 libpam.so.0 => /lib/libpam.so.0 libresolv.so.2 => /lib/libresolv.so.2 libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 libz.so.1 => /usr/lib/libz.so.1 So I guess strictly speaking if you build libapr and libaprutil with the appropriate LDFLAGS, you should not need them to build mod_jk2.so and jkjni.so. I found if you don't use --with-os-type=include/linux in your configure command, UNIX sockets (jkjni.so) will fail with the following error: INFO: APR not loaded, disabling jni components: java.io.IOException: initialize Exception during startup processing . . . . . Caused by: java.lang.UnsatisfiedLinkError: getJkEnv at org.apache.jk.apr.AprImpl.getJkEnv(Native Method) About the environment variables . . . I think that if you get libapr and libaprutil built with the listed environment variables you should not need them when building mod_jk2.so and jkjni.so. Messier details are probably better discussed by the developers who know the internals of this code. I'm just beginning to look at it for the following reasons: 1. Submit a patch for autoconf to get the right configure script built. 2. Look at a new MPM module in Apache for Linux and the new thread model that will support in-process communication. When I get to it I don't know since most of my time is spent looking for employment. HTH /mde/ just my two cents . . . . __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
