Hi Rainer, Thanks for the detailed explanation, it is quite helpful. I've added the clean up code in my building script, it should never happen again :)
Thanks, Huxing ------------------------------------------------------------------ From:Rainer Jung <rainer.j...@kippdata.de> Time:2016 Oct 9 (Sun) 19:26 To:Tomcat Developers List <dev@tomcat.apache.org> Subject:Re: [VOTE] Release Apache Tomcat Native 1.2.10 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
