Hi Chris,

Am 08.05.2017 um 20:23 schrieb Christopher Schultz:
I'm trying to do a complete test of 8.5.15 (candidate) and I can't
seem to build tcnative because of the OpenSSL dependency.

On my system, I've got OpensSSL 1.0.1t installed globally, but I have
openssl 1.0.2f installed locally for the purposes of building
tcnative. This has worked in the past. When I run configure, it's
telling me that I have 1.0.1t available:

checking for OpenSSL library... using openssl from
/usr/${exec_prefix}/lib and /usr/include
checking OpenSSL library version >= 1.0.2...

Found   OPENSSL_VERSION_NUMBER 0x1000114f (OpenSSL 1.0.1t  3 May 2016)
Require OPENSSL_VERSION_NUMBER 0x1000200f or greater (1.0.2)
configure: error: Your version of OpenSSL is not compatible with this
version of tcnative

If I specify --with-ssl, it's giving me roughly the same behavior:

the logic for the test is contained in file build/tcnative.m4.

The macro is named TCN_CHECK_SSL_TOOLKIT and most is just plain shell syntax.

If you tell configure a directory using --with-ssl, then yes, this macro needs an include and a lib or lib64 sub directory.

If you do not give it a specific directory, it will try /usr /usr/local /usr/local/ssl /usr/pkg /usr/sfw.

checking for OpenSSL library... using openssl from
/home/cschultz/projects/apache-tomcat/openssl-1.0.2f/${exec_prefix}/lib
and
/home/cschultz/projects/apache-tomcat/openssl-1.0.2f/include
checking OpenSSL library version >= 1.0.2... configure: error: Your
version of OpenSSL is not compatible with this version of tcnative

Oddly, it doesn't tell me what my current version actually is.

Can you have a look at the contents of config.log? Any line there that contains "OPENSSL_VERSION_NUMBER"?

In the openssl-1.0.2f directory, I have the expected libssl.* files
but there was no "lib" directory, so I created a lib/ directory and
symlinked all of the ../libssl.* files into it.

Running openssl-1.0.2f/apps/openssl version confirms that the
command-line app has the proper OpenSSL version, and it's using the
right version of the shared library (confirmed with ldd). It looks
like I was missing the symlinks for the libcrypto.* objects. Once I
added those symlinks, I was able to call configure.

AFAIK, my openssl-1.0.2f/ local directory is a legitimately-built
OpenSSL, but the tcnative build process is looking for things in odd
places. I realize that 1.0.2f is a bit behind the times (1+ year old)
but has the build process changed that much? Also, what about people
using these older versions?

No it is not a 2f versus 2k problem. When you say "legitimately-built", is the directory you pass to configure the build directory or an install directory? We do assume an install directory, which should automatically have the right layout (sub dirs include and lib or lib64).

I'm building 1.0.2k from source now to see if any post-build
modifications need to made in order for tcnative's build to pick-up
the libraries, headers, etc. from that version.

Regards,

Rainer


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to