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: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)