On May 10, 2007, at 10:46 AM, Wayne Meissner wrote:
Except that some ubuntu systems don't seem to have libc.so at
all. The
So there are 3 cases here:
1) libc.so exists and is a real library or a symlink to one
2) libc.so exists, but is a LD script
3) libc.so doesn't exist at all.
#1 works out of the box, I've done the hardcoded mapping of
'c'=>'libc.so.6' for case #2, and had code that searched the
library paths for libc.so.[0-9]+ - but dumped it when it wouldn't
work on my machine, since it only searched if libfoo.so didn't
exist - and the LD script meant it did ...
I might re-do the library searching, but do it after the load of
the normal library fails.
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
The latter two are provided in case you can't make #1 work, but are
really last-ditch efforts. #2 doesn't account for *newer* versions,
and #3 is not likely to be portable across linux distros.
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.
9 messages in net.java.dev.jna.usersRe: resolving UnsatisfiedLinkError
