BTW, what does "ldd" report for the JNA shared library in question?
That should indicate what it's looking for.
The native portion of JNA (libjnidispatch.so, which gets unpacked to
the temporary file you see) is loaded by absolute path. Any
dependencies for that library are resolved in a system-dependent
manner, which in this case is LD_LIBRARY_PATH.
I didn't do the JNA build for sparc myself, but it's entirely
possible it was linked against glibc instead of the solaris libc.
Feel free to do a build (and submit makefile patches) that ensure
the proper linkage; I don't have access to a sparc/sparc9 box.
On Apr 3, 2008, at 2:58 AM, Ivan Soleimanipour wrote:
I tried to "work around" this problem.
As I mentioned, adding /usr/ib to LD_LIBRARY_PATH doesn't help
as if the agent interpreting LD_LIBRARY_PATH considers all entries
but /usr/lib.
I tried making a soft link from /usr/sfw/lib/libc.so.1 to /usr/lib/
libc.so.1
and got the same "No such file or directory" error.
Heck, I _copied_ /usr/lib/libc.so.1 to /usr/sfw/lib and still the
same
thing. I was expecting some symbol linkage errors (solaris libc vs
gnu libc)
but didn't get that far.
This is all very perplexing.
I'm trying to use JNA bundled with netbeans 6.1 and when I use it
on solaris I get:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /var/
tmp/jna43952.tmp: ld.so.1: java: fatal: libc.so.1: open failed:
No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
...
Trussing shows that jna apparently uses $LD_LIBRARY_PATH and
additionally looks in /usr/sfw/lib but not /usr/lib.
/usr/sfw/lib contains miscellaneous open source libraries.
I think on solarises newer than 9 /usr/sfw/lib contains gnu's libc,
but I don't have it on my solaris 9 machine.
So, is jna built against glibc even on solaris or is this a bug?
2 messages in net.java.dev.jna.usersRe: [jna-users] Re: JNA on solaris
