OpenJDK 13/14 introduced change fb5b3981eac:
8222720: Provide extended VMWare/vSphere virtualization related info in
the hs_error file on linux/windows x86_64
On SLES 12 (maybe also other Linuxes) the impl loads
/usr/lib64/libguestlib.so.0 already during JVM startup. That library
depends on /usr/lib64/libvmtools.so.0, which in turn depends on a lot of
other libraries:
NEEDED libdnet.so.1
NEEDED libglib-2.0.so.0
NEEDED libicui18n.so.52.1
NEEDED libicuuc.so.52.1
NEEDED libpthread.so.0
NEEDED libdl.so.2
NEEDED libssl.so.1.0.0
NEEDED libcrypto.so.1.0.0
NEEDED libc.so.6
NEEDED ld-linux-x86-64.so.2
NEEDED libgcc_s.so.1
When building tcnative against OpenSSL 1.0.x, the JVM has already loaded
OpenSSL 1.0 system libs via the above dependency and will not load our
tcnative dependency. This lead to a subtle failure in my case:
/usr/local/jdk13/bin/java: symbol lookup error:
/path/to/lib/libtcnative-1.so.0.2.23: undefined symbol:
SSL_COMP_free_compression_methods
Even worse could be using OpenSSL 1.1.x for tcnative. Then the JVM would
load the 1.0.x version, tcnative would load the 1.1.x version but
symbols that exist in both would be resolved by the runtime linker in
the older version, because it was loaded first (default symbol search
order). All of that can be worked around by non-default linking tricks,
but I wanted to point out this new behavior.
I have written to hotspot-runtime-...@openjdk.java.net about these new
dependencies and potential problems.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
