[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-dev
Subject:    Loading libraries on Linux
From:       patrik.akerfeldt () gmail ! com (=?ISO-8859-1?Q?Patrik_=C5kerfeldt?=)
Date:       2011-03-30 13:13:51
Message-ID: AANLkTi=6G+KjXh=eARiXg5+8gy4ez21mZhNu7u8RtfXK () mail ! gmail ! com
[Download RAW message or body]

I have this java application that uses a closed source third party
java interface. This interface, in turn, loads a shared object from
the system. The package delivering these shared object is installed
separately and I do not want my java application to have knowledge
about where it is installed (i.e. specify my own LD_LIBRARY_PATH).

And so I tried to add the libraries to ld.so.conf.d/ and cache them
with /sbin/ldconfig. We are running RHEL5 btw. The thing is that
caching them with ldconfig has no effect at all. By looking at the
byte code from the closed source java interface I see they load the
libraries using System.loadLibrary(). Someone told me that
System.loadLibrary() uses dlopen underneath (on Linux).

To test this further, I wrote two very simple test tools, one in java
that loads a library using System.loadLibrary() and another one in C
which uses dlopen to load a library or void* dlhandle =
dlopen(argv[1], RTLD_NOW); to be exact. Then I configured ldconfig
with a folder containing libraries under /opt/somefolder/ and run the
two tools. The Java application was unable to load the library whilst
dlopen did the trick. Removing the folder from ldconfig and running
again shows that none of them succeeds as expected. And furthermore,
if I create a symbolic link (or just do a plain copy) of the library
into /usr/lib, both dlopen and the Java application loads the library.
I tried to work my way through the openjdk source to find the dlopen
call but was unsuccessful.

Can someone please tell me if the behavior I'm experiencing is
expected? I'm happy to give further information if needed.

Thanks,
Patrik ?kerfeldt

[prev in list] [next in list] [prev in thread] [next in thread]