32-bit Java on a x86_64 box uses 64-bit JNA_PATH

Ruby JRuby
1

Hello,

I just upgraded to 1.1.5 and saw this snippet in the jruby shell script.

Figure out the OS and cpu the same as JNA would, so the library path

can be set

case “uname -m” in
i[34567]86) JNA_CPU=“i386”;;
i86pc) JNA_CPU=“x86”;;
amd64|x86_64) JNA_CPU=amd64;;
esac
JNA_OS="uname -s | tr '[A-Z]' '[a-z]'"
case “$JNA_OS” in
darwin) JNA_PATH=“darwin”;;
*) JNA_PATH="${OS}-${JNA_CPU}";;
esac

Two things, one easy, one harder.

  1. The OS variable is referenced here

    *) JNA_PATH="${OS}-${JNA_CPU}";;

but it’s JNA_OS that is set, so JNA_PATH is incorrectly set.

  1. The script assumes that one is running a 64-bit Java process on a
    64-bit box,
    which isn’t always the case. Is there an easy way for the script to see
    if the
    Java process is a 32- or a 64-bit one and then set the JNA_PATH
    correctly?

Using java -showversion one can see if it’s a 64-bit Java, but that
sounds
painful and messy matching all the different outputs one could run into.

Reading dlopen()'s manual page, it sounds like we could set
LD_LIBRARY_PATH to

$JRUBY_HOME/lib/native/linux-amd64:$JRUBY_HOME/lib/native/linux-i386

and the process will find the correct 32- or 64-bit .so at runtime.

    The  function  dlopen()  loads  the  dynamic library file named

by the
null-terminated string filename and returns an opaque “handle”
for the
dynamic library. If filename is NULL, then the returned handle
is for
the main program. If filename contains a slash ("/"), then
it is
interpreted as a (relative or absolute) pathname.
Otherwise, the
dynamic linker searches for the library as follows (see
ld.so(8) for
further details):

    o      If  the environment variable LD_LIBRARY_PATH is defined

to con-
tain a colon-separated list of directories, then
these are
searched. (As a security measure this variable is
ignored for
set-UID and set-GID programs.)

Regards,
Blair

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
2

Very good find…seems like this is more of a JNA bug though. What do
you think Wayne?

Blair Z. wrote:

amd64|x86_64) JNA_CPU=amd64;;

sounds painful and messy matching all the different outputs one could
by the
further details):
Blair

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
3

Actually, disregard my other mail. LD_LIBRARY_PATH sounds right, but it
would have to be DYLD_LIBRARY_PATH under OS X I think? Wayne? :slight_smile:

Blair Z. wrote:

amd64|x86_64) JNA_CPU=amd64;;

sounds painful and messy matching all the different outputs one could
by the
further details):
Blair

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
4

LD_LIBRARY_PATH/DYLD_LIBRARY_PATH don’t work when jna.jar is in the
bootclasspath, which is why I added the -Djna.boot.library.path option
to jna…

The only problem is in the bin/jruby script, where it was assuming
that 64bit machine == 64bit jvm. In theory, JNA will try to load the
library from each of the paths in jna.boot.library.path until one
succeeds, else it will fallback to loading via the system library
paths, and finally back to extracting-from-the-jar.

i.e. JNA_PATH just needs to be fixed up, and it should all work.
(its probably only broken on SElinux, otherwise someone would have
noticed before now)

2008/11/7 Charles Oliver N. [email protected]:

be set
esac
64-bit box, which isn’t always the case. Is there an easy way for the

  interpreted  as  a  (relative  or  absolute) pathname.  Otherwise,

for

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email