java 17 libsvml.so conflict with user app

[Magnus Ihse Bursie]

On 2021-10-26 01:43, Vitaly Davidovich wrote:
> Hi all,
>
> We're testing some of our code on Java 17 (17.0.1)/linux and hit an issue
> related to libsvml.so.  It seems this library is now part of 17 to support
> the (incubating) Vector API.  We have a java library backed (via JNI) by
> NAG, which itself links against libsvml.so.  The issue arises due to
> java.lang.UnsatisfiedLinkError when our java library is trying to call into
> a NAG function which in turn is looking for a certain symbol from libsvml
> (__svml_exp2_ha_mask in particular).
>
> It looks like the JDK is eagerly loading symbols from its packaged libsvml
> (is there a way to disable that for now?).  That version of the library is
> also in conflict with the one we want to load, as witnessed by the missing
> symbol (there're probably others but we stopped testing at this point).
>
> Is this a known issue/compatibility hazard? Happy to hear thoughts/opinions
> on this and provide further info, if needed.
It sounds like there are two completely different libsvml.so around, 
muddying the waters. The libsvml.so shipped with the JDK is a core part 
of the vector functionality in the JDK. This is highly unlikely to be 
installed as a system library (basically, if anyone has ever managed to 
do that, they've worked hard to do the wrong thing).

A quick googling indicates that there is a separate libsvml.so shipped 
by IBM as part of their compiler. My guess is that your JNI library is 
using this.

We've run into similar issues in the past. Unfortunately, there is no 
really good way of resolving this. :(

One long term solution to minimize this kind of problems would be to 
rename our library "libjsvml.so", in the hope that this is less likely 
to clash with another library. This is a similar solution to what we've 
been taking in the past with other name-clashing JDK libraries.

/Magnus