Am 09.10.2016 um 12:04 schrieb Huxing Zhang:
Hi Rainer,
Thanks for your hint, I think I've found out the root cause.
When I first compile openssl 1.1.0, the binaries have been installed to
/usr/local/openssl, the libcrypto.so.1.1 has been installed to
/usr/local/openssl/lib/.
After I re-installed openssl 1.0.2j, the files in /usr/local/openssl has been
replaced, however the libcrypto.so.1.1 is still there, because openssl 1.0.x
did not produce that file.
So when I recompile tc-native 1.2.10, with --with-ssl=/usr/local/openssl
(1.0.2j), the libcrypto.so.1.1 is referenced, where get_rfc3526_prime_8192 is
not exist.
Following is the output:
$objdump -p
/home/admin/tomcat/tcnative/tomcat-native-1.2.10-src/native/.libs/libtcnative-1.so.0.2.10
/home/admin/tomcat/tcnative/tomcat-native-1.2.10-src/native/.libs/libtcnative-1.so.0.2.10:
file format elf64-x86-64
Program Header:
LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr
0x0000000000000000 align 2**21
filesz 0x0000000000028244 memsz 0x0000000000028244 flags r-x
LOAD off 0x0000000000028248 vaddr 0x0000000000228248 paddr
0x0000000000228248 align 2**21
filesz 0x0000000000001450 memsz 0x0000000000001b50 flags rw-
DYNAMIC off 0x00000000000282c8 vaddr 0x00000000002282c8 paddr
0x00000000002282c8 align 2**3
filesz 0x0000000000000200 memsz 0x0000000000000200 flags rw-
NOTE off 0x0000000000000190 vaddr 0x0000000000000190 paddr
0x0000000000000190 align 2**2
filesz 0x0000000000000024 memsz 0x0000000000000024 flags r--
EH_FRAME off 0x0000000000023594 vaddr 0x0000000000023594 paddr
0x0000000000023594 align 2**2
filesz 0x0000000000000dbc memsz 0x0000000000000dbc flags r--
STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr
0x0000000000000000 align 2**3
filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-
Dynamic Section:
NEEDED libssl.so.1.1
NEEDED libcrypto.so.1.1
NEEDED libapr-1.so.0
NEEDED librt.so.1
NEEDED libcrypt.so.1
NEEDED libpthread.so.0
NEEDED libc.so.6
SONAME libtcnative-1.so.0
RPATH /usr/local/apr/lib:/usr/local/openssl/lib
INIT 0x000000000000f2e0
FINI 0x00000000000225a8
GNU_HASH 0x00000000000001b8
STRTAB 0x0000000000005cf0
SYMTAB 0x0000000000000de8
STRSZ 0x0000000000005b7e
SYMENT 0x0000000000000018
PLTGOT 0x0000000000228588
PLTRELSZ 0x0000000000002c58
PLTREL 0x0000000000000007
JMPREL 0x000000000000c688
RELA 0x000000000000bf98
RELASZ 0x00000000000006f0
RELAENT 0x0000000000000018
VERNEED 0x000000000000bf08
VERNEEDNUM 0x0000000000000004
VERSYM 0x000000000000b86e
RELACOUNT 0x0000000000000024
Version References:
required from libpthread.so.0:
0x09691a75 0x00 05 GLIBC_2.2.5
required from libc.so.6:
0x0d696913 0x00 06 GLIBC_2.3
0x09691a75 0x00 04 GLIBC_2.2.5
required from libssl.so.1.1:
0x066d1f10 0x00 03 OPENSSL_1_1_0
required from libcrypto.so.1.1:
0x066d1f10 0x00 02 OPENSSL_1_1_0
$nm /usr/local/openssl/lib/libcrypto.so.1.1 | grep get_rfc3526_prime_8192
00000000000a4830 T BN_get_rfc3526_prime_8192
The solution will be cleaning up the /usr/local/openssl and re-compile
tc-native, and everything works fine.
Yes, that looks plausible. Glad that you fixed it.
Just one more explanation, how it comes your build rerefrences the *.1.1
OpenSSL libraries:
When the link step runs during the build, it does not yet know about the
version. Al it gets is the -lssl and -lcrypto flags. That means it will
look for files libssl.so and libcrypto.so in the linker search path,
including LD_LIBRARY_PATH at the time of linking and including any path
given with "-L" flag.
These files libssl.so and libcrypto.so internally contain their
so-called SONAME. This SONAME is also part of the "objdump -p" output.
For example for libtcnytive.so is it the line
SONAME libtcnative-1.so.0
For OpenSSL libcrypto.so and libssl.so coming from OpenSSL 1.0.x (for x
in 0, 1, 2) it will be
SONAME libcrypto.so.1.0.0
SONAME libssl.so.1.0.0
and for OpenSSL 1.1.0 it will be:
SONAME libcrypto.so.1.1
SONAME libssl.so.1.1
The linker checks, that it could resolves needed symbols in the .so
files and then records the SONAME in the list of dependencies of the
linked file.
During runtime, the runtime linker reads the neded SONAMES from e.g.
libtcnative.so and looks for files that have those names. That means now
it will search for e.g. libcrypto.so.1.0.0 and libssl.so.1.0.0 if those
were the SONAMES during the link phase.
SONAMEs are typically used to express version compatibilities. So e.g.
OpenSSL 1.0.x using always an SONAME that ends with 1.0.0 expresses a
compatibility between those versions.
The observation that you libtcnative had a dependency against the .1.1
versions means, that during link your libssl.so and libcrypto.so files
where still from the 1.1 OpenSSL version, but likely your header files
where from the 1.0.2 version.
Anyways, cleaning up when switching is exactly the right thing to do (or
using versioned directories).
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
