Project Panama & dynamic library loading

[Maurizio Cimadamore]

Something along these lines might well be required yes - although AFAIK 
not even OSGi can protect you from sonames and missing dependencies (as, 
under the hood, it will still delegate to System::loadLibrary). Also, 
while not required, I think OSGi typical use case will be to co-package 
the required native libraries in a given bundle, which I don't think 
it's exactly the case we're discussing here? E.g. I took a look at 
lwjgl-opengl and that seems to load libGL that comes installed in the 
system - outside the bundle, with a call to dlopen (on Linux). So, if 
the system library is not installed correctly (e.g. the system has 
libGL.so.1, but not libGL.so), I think that approach will still run into 
issues - although I agree that having the ability to co-bundle multiple 
platfrom-dependent shared libraries onto the same artifact is nice.

Maurizio

On 16/09/2019 11:51, Mark Raynsford wrote:
> On 2019-09-16T10:53:09 +0100
> Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>
>> I agree with this analysis.
>>
>> One addition - it's not really that jextract cares about sonames - it's
>> just that if you call
>>
>> System::loadLibrary("foo")
>>
>> and you are on Linux, the VM will try to load:
>>
>> libfoo.so
>>
>> on all the paths that are part of the native library path.
>>
>> If you want something different, then there's the more general
>> System::load which takes a full _patth_ (not a libname), which can of
>> course contain sonames and all.
> Just a quick question: Is anyone here familiar with how OSGi handles
> this? In my opinion, this stuff already seems to be a solved problem
> there.
>
> Bundles (jar files in OSGi speak) contain native libraries directly,
> and contain metadata in the MANIFEST.MF file that explain which native
> libraries match each arch/os combination. For example:
>
> Bundle-NativeCode:\
>    lwjgl_opengl32.dll;osname=Win32;processor=x86,\
>    lwjgl_opengl.dll;osname=Win32;processor=x86-64,\
>    liblwjgl_opengl.so;osname=Linux;processor=x86-64,\
>    liblwjgl_opengl.dylib;osname=MacOSX;processor=x86-64
>
> That's an extract from the OSGi bundles from the LWJGL project. The
> Bundle-NativeCode declaration specifies which native libraries are
> included, and which should be loaded in a given situation. You can see
> that it states that the runtime should load lwjgl_opengl32.dll if the
> current platform is Windows on x86. It should load liblwjgl_opengl.so
> if the current platform is Linux on x86-64, etc. It's also possible to
> state that a particular platform/arch doesn't require a native library.
>
> The runtime transparently extracts and arranges paths as necessary so
> that calls to System::loadLibrary("lwjgl_opengl") work correctly.
>
> I believe that JBoss modules work similarly.
>