On 18/07/16 14:56, Grzegorz Krajewski wrote: > Helo there! > > After installing from source openssl-1.0.1t which I downloaded > from openssl.org <http://openssl.org/>, I'm getting "runtime error": > * /lib64/libcrypto.so.10: no version information available (required by > executedTool)* > Before installation I had openssl-1.0.1e > > Flow how I build it: > tar zxf openssl-1.0.1t.tar (acronym to full name of 1.0.1t) > cd openssl-1.0.1t/ > ./config shared > make > make install > , it's installing in /usr/local/ssl/ that is why I copy to proper path > /lib64/ or /usr/lib64/ (dependently from OS: redhat, suse, fedora) and > overwrite old .so files. > * > * > *[x at x ~]# ./RemoteAgentLinux64 -verbose* > *./RemoteAgentLinux64: /lib64/libcrypto.so.10: no version information > available (required by ./RemoteAgentLinux64)* > *./RemoteAgentLinux64: /lib64/libcrypto.so.10: no version information > available (required by ./RemoteAgentLinux64)* > *./RemoteAgentLinux64: /lib64/libssl.so.10: no version information > available (required by ./RemoteAgentLinux64) > > * > *[x at x ~]# openssl version -a* > *OpenSSL 1.0.1t 3 May 2016* > *built on: Wed Jul 13 07:31:08 2016* > *platform: linux-x86_64* > *options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) > blowfish(idx)* > *compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC > -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H > -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM > -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM* > *OPENSSLDIR: "/usr/local/ssl"* > > I found some information that I'm gonna have this warning when I build > tool which I'm executing with older version of openssl ( < 1.0.1t ) then > the one which I wanna use finally ( 1.0.1t ). Is this possible? This warning occurs because OpenSSL 1.0.1 and OpenSSL 1.0.2 do not provide symbol version information (the forthcoming OpenSSL 1.1.0 does do this BTW) but the application you are running is expecting those symbol versions to be present. Most distros do not provide out-of-the-box OpenSSL. Instead they normally add some of their own patches on top. At least Debian adds a patch to include symbol version info and, from your description, it sounds like other distros do this too. Applications linked against a version of the library which includes symbol versions will complain if you try to run them with a version that doesn't have that information. The distros will typically update the OS patched version of OpenSSL with security updates from upstream OpenSSL, so normally there is no reason to upgrade the "letter" version of an OS supplied OpenSSL with an upstream version unless: 1) there are specific bug fixes you wish to obtain that have not been incorporated in the OS supplied version or 2) you wish to use specific compilation options different to that used in the OS version or 3) you wish to do a "number" upgrade such as 1.0.1 to 1.0.2 If you decide to install from upstream then it is usually preferable to install it in some other location to that used by the OS (e.g. keep it in /usr/local/ssl). That way apps that need to use the upstream version can use that version, but all the other system supplied apps can use the OS version. Otherwise you run into problems where some apps are expecting symbol version info (e.g. system supplied apps) whereas others are not. If your app is linked against the OS supplied version, and you now wish to use the upstream version then you will need to relink your app against the new library so that it no longer uses the symbol versioning information. Matt
