Forum: JRuby 32-bit Java on a x86_64 box uses 64-bit JNA_PATH

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Blair Z. (Guest)
on 2008-11-06 23:33
(Received via mailing list)
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.

2) 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
Charles Oliver N. (Guest)
on 2008-11-07 09:39
(Received via mailing list)
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
Charles Oliver N. (Guest)
on 2008-11-07 09:40
(Received via mailing list)
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? :)

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
Wayne M. (Guest)
on 2008-11-07 10:00
(Received via mailing list)
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. <removed_email_address@domain.invalid>:
>> 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
This topic is locked and can not be replied to.