On May 10, 2007, at 9:59 AM, Wayne Meissner wrote:
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.
Kind of expected that. I wonder if they've tricked out the dynamic
loader to handle it.
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?
Except that some ubuntu systems don't seem to have libc.so at all.
The whole 32/64 bit thing will require some tweaking (you don't want
to have to define the same library twice; the 64-bitness should be
transparent). I was under the (possibly mistaken) impression that
the JDK/JRE is not widely available as full 64-bit.
9 messages in net.java.dev.jna.usersRe: Pointer.initIDs UnsatisfiedLinkError
