New library dependencies due to 8222720 (fb5b3981eac)

[Rainer Jung]

Hi David,

Am 30.07.2019 um 01:56 schrieb David Holmes:
> Hi Rainer,
> 
> On 30/07/2019 7:34 am, Rainer Jung wrote:
>> While doing Tomcat tests I noticed, that at least on SLES 12 JDK 13 
>> and 14 EA have a lot of new runtime library dependencies.
>>
>> Change fb5b3981eac with log
>>
>> 8222720: Provide extended VMWare/vSphere virtualization related info 
>> in the hs_error file on linux/windows x86_64
>>
>> 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
>>
>> Some are not so problematic, but for instance Tomcat is able to use 
>> custom build OpenSSL libraries to replace the JSSE crypto engine with 
>> an OpenSSL based one using JNI. Unfortunately the JDK is now loading 
>> libssl and libcrypto early. In case our TC OpenSSL also uses SO 
>> version 1.0.0 it will not get loaded, in case it is another version we 
>> can run into a mix of symbols resolved in the platform OpenSSL libs 
>> now loaded early and the ones provided with TC loaded later.
>>
>> This is an example, why it would be good to not introduce too many 
>> native library dependencies for the JVM or make it optional in the 
>> sense of configurable during runtime. Of the above list, the icu libs, 
>> libglib and libdnet are other libs one would probably try to avoid.
>>
>> Don't know whether this list is appropriate for discussing it. If not 
>> any pointers to a better list are appreciated.
> 
> This is the correct list to discuss this.
> 
> When 8222720 was put in I had no idea it would result in eager loading 
> of libraries beyond the explicit load of libguestlib.
> 
> To be clear you are running under VMWare? This should only happen to 
> enable reporting for the VMWare virtualization info in case of a crash.

Yes, I am running under VMWare. The library /usr/lib64/libguestlib.so.0 
and its dependency /usr/lib64/libvmtools.so.0 both belong to the package 
libvmtools0. Its sources seem to be available at 
https://github.com/vmware/open-vm-tools.

> This may need to be revisited.
> 
> Thanks for the report.

Thanks for looking at this!

Rainer