Rainer, On 11/3/15 12:36 PM, Rainer Jung wrote: > Am 03.11.2015 um 17:18 schrieb Christopher Schultz: >> Mark, >> >> On 11/2/15 4:04 PM, Mark Thomas wrote: >>> Version 1.2.1 includes the following changes: >>> - Fix to enable 1.2.x to work with Tomcat releases that do not have >>> the SNI callback implemented on the Java side >>> >>> The proposed release artefacts can be found at [1], >>> and the build was done using tag [2]. >>> >>> The Apache Tomcat Native 1.2.1 is >>> [ ] Stable, go ahead and release >>> [ ] Broken because of ... >>> >>> >>> [1] >>> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.2.1/ >>> >>> [2] >>> https://svn.apache.org/repos/asf/tomcat/native/tags/TOMCAT_NATIVE_1_2_1 >> >> I don't have OpenSSL 1.0.2 on one of my Linux servers, and I get this >> result: >> >> $ ./configure --with-apr=../../apr-1.4.6 --with-ssl >> checking build system type... x86_64-unknown-linux-gnu >> checking host system type... x86_64-unknown-linux-gnu >> checking target system type... x86_64-unknown-linux-gnu >> checking for a BSD-compatible install... /usr/bin/install -c >> checking for working mkdir -p... yes >> Tomcat Native Version: 1.2.1 >> checking for chosen layout... tcnative >> checking for APR... yes >> configure: APR 1.4.6 detected. >> ./configure: line 2689: cd: /home/cschultz/projects/apr-1.4.6/build: No > > We need to determine, where APR installed some build support files. > configure does in line 2687 > > APR_BUILD_DIR="`$apr_config --installbuilddir`" > > then cd to APR_BUILD_DIR and then pwd to get the dir path. > > You might want to insert directly before line > > 2687 APR_BUILD_DIR="`$apr_config --installbuilddir`" > > an > > echo $apr_config > > to check, which apr_config was actually used, whether the one from the > APR you wanted to use, or another one. Then you can run > > apr_config --installbuilddir > > by yourself using the same apr_config, that your echo gave and look into > the directory, that is returned by that command. That directory must > exist and there needs to be an apr_rules.mk file in that directory.
It looks like my apr directory didn't have all it needed. Using --with-apr=`which apr-config` did the trick on my Debian Linux system. I had been playing around with different APR versions a while back and it looks like I selected the wrong one for the build. Fixing the APR path allows tcnative to build without warnings or errors. It even links against libssl, even though the configure script really wants to have OpenSSL 1.0.2 and I only have 1.0.1. I'm curious to see what happens when I run it. >> such file or directory >> setting CC to "gcc" >> setting CPP to "gcc -E" >> adding "-I/usr/local/java-8/include" to TCNATIVE_PRIV_INCLUDES >> checking for JDK os include directory... linux >> adding "-I/usr/local/java-8/include/linux" to TCNATIVE_PRIV_INCLUDES >> checking for gcc... gcc >> checking whether the C compiler works... yes >> checking for C compiler default output file name... a.out >> checking for suffix of executables... >> checking whether we are cross compiling... no >> checking for suffix of object files... o >> checking whether we are using the GNU C compiler... yes >> checking whether gcc accepts -g... yes >> checking for gcc option to accept ISO C89... none needed >> checking for OpenSSL library... using openssl from /usr/lib and >> /usr/include >> checking OpenSSL library version >= 1.0.2... >> >> Found OPENSSL_VERSION_NUMBER 0x1000105f (OpenSSL 1.0.1e 11 Feb 2013) >> Require OPENSSL_VERSION_NUMBER 0x1000200f or greater (1.0.2) >> >> not compatible >> checking for OpenSSL DSA support... yes >> setting TCNATIVE_LDFLAGS to "-lssl -lcrypto" >> adding "-DHAVE_OPENSSL" to CFLAGS >> setting TCNATIVE_LIBS to "" >> setting TCNATIVE_LIBS to " >> /home/cschultz/projects/apr-1.4.6/libapr-1.la -luuid -lrt -lcrypt >> -lpthread -ldl" >> checking for apr_pollset_wakeup in -lapr-1... yes >> adding "-DHAVE_POLLSET_WAKEUP" to CFLAGS >> cp: cannot stat `/apr_rules.mk': No such file or directory > > Same root cause as above. > >> configure: creating ./config.status >> config.status: creating tcnative.pc >> config.status: creating Makefile >> config.status: executing default commands >> $ make >> Makefile:47: >> /home/cschultz/projects/apache/tomcat-native-1.2.1-src/native/build/rules.mk: >> >> No such file or directory >> make: *** No rule to make target >> `/home/cschultz/projects/apache/tomcat-native-1.2.1-src/native/build/rules.mk'. >> >> Stop. >> >> >> Presumably, this is due to the OpenSSL version problem, but configure >> doesn't /appear/ to fail, and then make certainly does. >> >> On my OS X system (once I babied the CLI built-tools back into working >> order -- SO frustrating every time Apple updates something and breaks it >> all), the build was clean -- not even a compiler warning. >> >> I haven't tested it at all. Just the build on both systems. > > The problem is due to some APR mismatch. See above. Fixed. Thanks for the review. I now have two built modules (one Linux .so, one Mac OS X .dylib). I'll try to get some testing done with them as well. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
