Timothy Wall wrote:
On May 10, 2007, at 1:11 AM, Wayne Meissner wrote:
On my ubuntu install (7.04), /usr/lib/libc.so isn't a symlink, it is a
LD script - and it still fails to find the library. However, telling
it to use libc.so.6 directly works fine.
We could probably tweak Function.findPath() to explicitly fallback to
libfoo.so.* if libfoo.so isn't found. A bit mucky, but better to fix
it in JNA if possible than have it not work for end-users because they
don't have something installed.
I agree that having it work with some mucky details is better than
having it fail.
How does dlopen react to the LD script? Any idea why it's there? I saw
some chatter on an ubuntu list about the dlopen issue, and the developer
stance was to leave it up to dlopen users to accommodate ubuntu.
dlopen() fails when trying to open it. I ended up giving up and adding
a special case for Linux in NativeLibrary.java which maps "c" =>
"libc.so.6" - and if a library name was in the map, just use it instead
of going through the whole mapLibraryName, findPath() chain. Its not
exactly very elegant, nor foolproof, so I haven't checked it in anywhere
yet.
As to why its there? No idea. Maybe its something to do with both
32bit and 64bit libraries on the same system, and some apps having
/usr/lib/libc.so hardcoded in?
9 messages in net.java.dev.jna.usersRe: Pointer.initIDs UnsatisfiedLinkError
