Most likely the user is running a 64-bit system, and has set
LD_LIBRARY_PATH or some other dynamic loader variable to point to the
32-bit library directory, which *shouldn't* be done if running a 64-
bit executable.
It's also possible that JNA is using an incorrect load path to find
whatever library is providing sysinfo. Do you provide an absolute
path, or just the library name?
Where does this library reside on an arch linux system (both 32-bit
and 64-bit versions)?
On May 26, 2009, at 5:08 PM, Joel Uckelman wrote:
Thus spake Timothy Wall:
On May 26, 2009, at 4:54 PM, Joel Uckelman wrote:
Thus spake Timothy Wall:
This is most likely an architecture mismatch, either 32-bit code
trying to load 64-bit code or vice versa.
This could happen if running a 64-bit JVM but only having the 32-
bit
system libraries in LD_LIBRARY_PATH (or in this case,
jna.library.path, which is where JNA will look for the library).
Does this mean that the user has his system misconfigured? Or is
there
something I need to be setting in order to account for this
possibility?
Hard to say without knowing what it is that you're setting. If
you're
configuring an Arch linux package, it could be your fault. If you're
just providing a Java application, then it's more likely the user
that
needs to configure the system properly. If you're providing a
wrapper
that sets stuff up for the Java app, then it might be a little of
both.
My Java app is using JNA in order to call sysinfo(2) to find out how
much
RAM is installed in the user's system. Presently, the app is
delivered as a
tarball, not as an Arch Linux package (I couldn't even say what kind
of
packages Arch uses, off the top of my head).
8 messages in net.java.dev.jna.usersRe: [jna-users] UnsatisfiedLinkError ...
