Works for me. I build with ant - didn't try the other build.

Make sure libapr.so is in LD_LIBRARY_PATH and 
 ldd libjkjni.so 
lists apr.so as a dependency.

I have the same problem. I want to use channelUnix but not the inprocess jni.
I have RH8 httpd and http-devel (2.0.40) from rpms
and the 4.1.24 tomcat binaries installed. I compiled the 4.1.24 connectors
from the source tgz (worked after ln -s /usr/lib/libapr.so /usr/lib/libapr-0.so)
Now it's not loading with the same error message as above. The symbol
is from mod_jk2 and LD_PRELOAD=/usr/lib/httpd/modules/mod_jk2.so does not
help since lot of stuff from apache isn't resolvable in mod_jk2.so.

A short glance at the ChannelUn code tells me I need jni for channelUnix.
Is that correct ?

I'm having the exact same problem.  nm shows apr_md5_final() to be in 
libaprutil, not libapr.  But, ldd jkjni.so does not show libaprutil to be a 
dependency.

I am also having this problem.  My environment is:

Redhat Linux 9 (kernel 2.4.20-9)
j2sdk 1.4.1_03
Tomcat 4.1.24 binary
Apache 2.0.46 built from source with:
     ./configure --enable-modules=all --enable-shared=most --enable-ssl=shared
     CPPFLAGS=-I/usr/kerberos/include

mod_jk2.so built from jakarta-tomcat-connectors-jk2-2.0.2-src
change to jk/native2 and run configure with:
      ./configure --with-apxs2=/home/apache/bin/apxs \
                  --with-tomcat41=/home/tomcat

ld.so.conf has /home/apache/lib entered.  A partial listing of /sbin/ldconfig -v
is shown below.

/home/apache/lib:
        jkjni.so -> libjkjni.so
        libaprutil-0.so.0 -> libaprutil-0.so.0.9.3
        libapr-0.so.0 -> libapr-0.so.0.9.3

An ldd for jkjni.so is shown below.

ldd /home/apache/lib/jkjni.so
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40039000)
        libapr-0.so.0 => /home/apache/lib/libapr-0.so.0 (0x40066000)
        libpcre.so.0 => /lib/libpcre.so.0 (0x40083000)
        libpcreposix.so.0 => /usr/lib/libpcreposix.so.0 (0x4008e000)
        libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

An nm for libapr-0.so.0 run through grep apr_md5_final shows no match.  However
an nm for libaprutil-0.so.0 run through grep apr_md5_final shows:

00009248 T apr_md5_final

After exploring the dependencies a bit, I came up with the following:

To build apr and aprutil with the proper dependencies, LDFLAGS was set to the
following:

export LDFLAGS="-lgdbm -lldap -lexpat -ldb"

Apache 2.0.46 was then built to create apr and aprutil.  ldd on the two
libraries is shown below.

ldd /home/apache/lib/libapr-0.so.0.9.4
        libdb-4.0.so => /lib/libdb-4.0.so (0x40036000)
        libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x400de000)
        libldap.so.2 => /usr/lib/libldap.so.2 (0x400e5000)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40111000)
        libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40131000)
        libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4013f000)
        libssl.so.4 => /lib/libssl.so.4 (0x4014a000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0x4017f000)
        liblber.so.2 => /usr/lib/liblber.so.2 (0x40271000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
        libdl.so.2 => /lib/libdl.so.2 (0x4027c000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40280000)
        libpam.so.0 => /lib/libpam.so.0 (0x402ad000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x402b5000)
        libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2(0x402c7000)
        libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x402db000)
        libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x40339000)
        libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x40349000)
        libz.so.1 => /usr/lib/libz.so.1 (0x4034b000)

ldd /home/apache/lib/libaprutil-0.so.0.9.4
        libdb-4.0.so => /lib/libdb-4.0.so (0x4002d000)
        libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x400d5000)
        libldap.so.2 => /usr/lib/libldap.so.2 (0x400dc000)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40108000)
        libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40128000)
        libsasl.so.7 => /usr/lib/libsasl.so.7 (0x40136000)
        libssl.so.4 => /lib/libssl.so.4 (0x40141000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0x40176000)
        liblber.so.2 => /usr/lib/liblber.so.2 (0x40268000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
        libdl.so.2 => /lib/libdl.so.2 (0x40273000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40277000)
        libpam.so.0 => /lib/libpam.so.0 (0x402a4000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x402ac000)
        libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2(0x402be000)
        libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x402d2000)
        libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x40330000)
        libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x40340000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40342000)

The Makefile in:

jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2

was modified so that the JK_LDFLAGS reads as follows:

JK_LDFLAGS=-L${APACHE2_LIBDIR} -lcrypt -lapr-0 -laprutil-0 -lpcre -lpcreposix

Creation and installation of mod_jk2.so and jkjni.so proceeded as expected.  The
socket connection works as expected.

When an out-of-process UNIX socket was attempted, the following error occured
while starting up Tomcat.

INFO: Starting Coyote HTTP/1.1 on port 8080
Jun 19, 2003 2:19:05 PM org.apache.jk.server.JkMain start
INFO: APR not loaded, disabling jni components: java.io.IOException: initialize
Exception during startup processing
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
Caused by: java.lang.UnsatisfiedLinkError: getJkEnv
at org.apache.jk.apr.AprImpl.getJkEnv(Native Method)
at org.apache.jk.common.JniHandler.initNative(JniHandler.java:132)
at org.apache.jk.common.ChannelUn.init(ChannelUn.java:114)
at org.apache.jk.server.JkMain.start(JkMain.java:351)
at org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.java:169)
at org.apache.coyote.tomcat4.CoyoteConnector.start(CoyoteConnector.java:1141)
at org.apache.catalina.core.StandardService.start(StandardService.java:506)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:2190)
at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
... 5 more

And Tomcat dies.

I guess the next thing to do is find where getJkEnv is and why it's not linked
in appropriately.

This appears to be more and more like a build configuration issue coupled with
Redhat 9 Linux rpm locations.

when I modify the mkefile like described here I gt another error:

libjkjni.so: undefined symbol: gdbm_errno

For Info:
tomcat 4.1.29
j2sdk1.4.1_02
jk2_2.0.2
kernel 2.4.5 (I know it´s rather old, but I cant get the admins to upgrade it)

After a long time of not working with this, I decided to tackle the issue again.

I'm now on Fedora Core 1, j2sdk 1.4.2_02, Tomcat 5.0.16, and Apache 2.0.48.

I used the following flags before compiling Apache 2.0.48

export LDFLAGS="-lgdbm -lldap -lexpat -ldb -L/usr"
export CPPFLAGS="-I/usr/kerberos/include -I/usr/openssl/include"

I used the following to configure Apache 2.0.48

./configure --enable-ssl=shared --enable-modules=all --enable-mods-shared=most

I then moved over to the connectors - source from:

jakarta-tomcat-connectors-jk2-2.0.2-src.tar.gz

I ran the following configure command in
jakarta-tomcat-connectors-jk2-2.0.2-src/native/jk2:

./configure --with-apxs2=/home/apache/bin/apxs \
            --with-tomcat41=/home/tomcat \
            --with-os-type=/usr/java/jre/lib/i386 \
            --with-jni \
            --with-pcre

The third line is new.

Once the configuration is run, the Makefile in 
jakarta-tomcat-connectors-jk2-2.0.2-src/native/jk2/server/apache2 was altered.

JK_LDFLAGS=-L${APACHE2_LIBDIR} -lcrypt -lapr-0 -lpcre -lpcreposix -laprutil-0

In particular, -laprutil-0 was added.

After building and installing mod_jk2.so and jkjni.so, I was able to get the
following Apache 2.048 - Tomcat 5.0.16 

httpd - tomcat via IP sockets    works
httpd - tomcat via UNIX sockets  works
httpd - tomcat via in-process    loops with unable to find child nnnn in 
                                 httpd error_log

This has been mentioned on the Tomcat mailing lists, so I will search to see if
there is a solution.

I think people should just avoid JNI for now. It doesn't give any performance
boost anyway.

I tested SSI with Apache 2 very recently, and it mostly works (some warnings on
startup, but otherwise it works ok). See the configuration and tips in this
other bug report. JNI will work only with multi threaded MPMs, never with multi
process.

*** This bug has been marked as a duplicate of 27167 ***

(In reply to comment #8)
> I think people should just avoid JNI for now. It doesn't give any performance
> boost anyway.

Huhh?!? Sorry, I just have to comment..

Please compare the performance (should I say penalty) of *not* using JNI... The
last time I tested (and also just now), shoveling long byte streams through
ServletResponse.getOutputStream() __completely___ brings the native apache
server to a grinding hault (full CPU usage, e.g. D-O-S). My test on a 2GHZ box
of a file download via FileInputStream -> getOutputStream() (4096 buffer)
*pinned* the CPU (the Apache process, specifically), yet could only sustain a
mere 1-2 MBytes/second.

When I compared jni performance a year or two ago (when I could get it to work),
this performance hit was marginal or negligible as I recall. And other JNI based
servers (right now) also have no such performace hit.

I concede that this isn't neccsarily the socket channels architecture's fault
(perhaps it just need to be buffered/optimized on the mod_jk side?), but still...