Rainer,
On 5/8/17 5:00 PM, Rainer Jung wrote: > 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. Oddly enough, the openssl build process never creates a directory called "lib/" unless you "make install" it. I never do that because I have nowhere to "install" it to. >> 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"? I can check that, but I think it would be helpful if the configure script could say "Your 1.0.1f version is too old -- you need 1.0.2 or later." It would make it more clear as to what effective version had been detected. >> 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). It's a build directory, which is certainly a part of the problem. Oddly enough, a re-build from scratch seems to have cleared things up. >> 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. Thanks, -chris
signature.asc
Description: OpenPGP digital signature