Tomcat doesn't find my APR libraries

Guys, I downloaded apr-1.4.6.tar.gz and did the following

$ ./configure --prefix=/usr
$ make
$ make test
$ make install

The tests passed and the new libraries got installed in /usr/lib
[root@myinstance lib]# ls *apr*
apr.exp libapr-1.a libapr-1.la libapr-1.so libapr-1.so.0 libapr-1.so.0.4.6 pkgconfig

Still tomcat doesn't find these libraries and i am getting

Apr 8, 2012 7:17:53 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-1.6.0-sun-1.6.0.22.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.22.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.22.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
Apr 8, 2012 7:17:53 PM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080

What to do next

Ok got it

Need to do these too

cd /opt/ARA/apache-tomcat/bin/tomcat-native-1.1.20-src/jni/native/
/configure --with-apr=/usr/local/apr --with-java-home=/usr/java/latest
make
make install
export JAVA_OPTS="$JAVA_OPTS -Djava.library.path=/usr/local/apr/lib"

Guys, if you know any vital info that you need to share please post. I also found that all these steps can be automated to make a rpm out of this. If you know that or any other useful information , please generously share

thanks

I think you're asking how to make an RPM for this.

Actually, you'd make 2 RPMs. A Source RPM (SRPM) and a distribution RPM.

The RPM process is based on the idea that a general solution is going to be adapted to a specific platform, so the original source code is bundled up with patches that customize the product, build it with the patches applied, then produce the distribution RPM that actually gets installed on the target system(s). That way you don't end up with a massive heap of customized source code that branches from the original product and is harder to keep maintained. As part of the SRPM process, you get an RPM that can be passed around and installed on development systems.

You can generate a distribution RPM without going through the SRPM process (I do it all the time for WAR builds, which use original source and no patches), but it sounds like you'd be better off going the SRPM route anyway. Even if you don't pass around copies of the patched source, the mere fact that you build using patches makes working through SRPM worthwhile.

For best results on RPM building questions, ask them in the Linux/Unix forum, since you'll find more experts on that particular topic over there.