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
