New library dependencies due to 8222720 (fb5b3981eac)

[David Holmes]

Hi Rainer,

I have filed:

https://bugs.openjdk.java.net/browse/JDK-8228764

Matthias: I think we may have to backout JDK-8222720 from JDK 13, 
re-examine this and re-do for 14.

Thanks,
David
-----

On 30/07/2019 5:34 pm, Rainer Jung wrote:
> 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
>