Timothy Wall wrote:
From the API perspective, we want to allow the following:
1) simple library "name", e.g. "c", "m", or "X11"
2) full library name, e.g. "libX11.so.6", nominally for requiring a
particular version
3) full path to library file
Ok, I have all 3 of those working on my branch now.
Basically what it does:
1) Tries to locate the library using the System.mapLibraryName() name
for the library.
2) If it cannot locate that filename it will just try to load whatever
library name the user passed in. (e.g. libc.so.6 or /lib/libc.so.6)
3) If that fails, it goes searching through the paths again for
lib<foo>.so.[0-9]+ and tries to load the highest version. so e.g. on
systems with libc.so.5 and libc.so.6, it will prefer the latter.
That seems to handle all 3 cases.
Note: I also changed the order of the search paths. It now goes:
jna.library.path, java.library.path, sun.boot.library.path, /usr/lib, /lib
i.e. from most-specific to JNA, to least specific.
Tangentially related, and linked to refactoring of library/function
instantation, is providing a per-library search path, as a sort of hint
about where to find the library. I'm not sure though if this is more of
a per-library thing or a per-system thing. Currently, jna.library.path
is provided to indicate the places to search for a library, and it's
probably good enough for now.
That sounds a bit complicated. I could probably do something like:
NativeLibrary.addSearchPath(String libraryName, String path)
and use the supplied path as the first one to try when loading the first
instance of the library. It could become mucky if people libraries with
the same name they want to load from different paths though.
9 messages in net.java.dev.jna.usersRe: resolving UnsatisfiedLinkError
