Way to load multiple copies of a library with the same name

[hjohn]

I have the following situation:

1. Some classes in my project use opencv stuff, which loads ffmpeg libraries. These have additional dependent libs that all get loaded from a platform specific jar.

2. I use libmpv, which also loads a few dependent libraries, but these are loaded from the system (from /usr/lib). Some of the libraries are the same as opencv pulls in (but different versions).

Each of these works fine in isolation, however when used together in the same JVM it causes failures in one or the other because some of the dependent libraries used are slightly different versions. I get an error like:

    Suppressed: java.lang.UnsatisfiedLinkError: /lib/x86_64-linux-gnu/libavfilter.so.7: undefined symbol: av_sscanf, version LIBAVUTIL_56
        at com.sun.jna.Native.open(Native Method)
        at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:235)
        ... 70 more

The av_sscanf function is indeed only present in the /usr/lib version of libavfilter, but is not present in the platform specific jar's libavfilter that opencv pulls in.

What seems to be happening is that only one copy of libavfilter is loaded, and used for both opencv and libmpv. Which version gets loaded depends on which of these two is used first.

I looked into dlopen but I didn't see any options I could pass in there (via the Library.OPTION_OPEN_FLAGS that would solve my problem). Nevertheless I tried all possible combinations, but none worked. dlmopen seems to have namespace options, but I'm not sure that would solve this issue.

Apart from splitting the application over 2 JVM's, are there any other options I might explore to make this work?

[matthiasblaesing]

Please follow the advise from the issue template: Use the mailing list for questions. At somepoint issues here, that don't follow the template will be closed without anyone looking at them, because people fail to read.

To your question: You can load libraries multiple times (not with the normal JVM methods, but with the low level library loading calls). However, that will not help, as by default symbols are resolved globally and thus you will end up with wrong linkage. You can try to wrestle with dlopen and try with RTLD_LOCAL and RTLD_DEEPBIND.

Maybe this helps:
#724 (comment)
#716 (comment)