Forum: JRuby Could not initialize class jnr.unixsocket.Native$LibC

570ee005a5d5af0dcc6a92ccfb7d1be1?d=identicon&s=25 James Le Cuirot (Guest)
on 2013-08-15 15:13
(Received via mailing list)
Hello,

I'm trying to use the dalli gem (1.1.5) with UNIX sockets under JRuby
1.7.4 on Fedora 19. I get the following error.


Java::JavaLang::NoClassDefFoundError (Could not initialize class
jnr.unixsocket.Native$LibC):
  jnr.unixsocket.Native.libsocket(Native.java:60)
  jnr.unixsocket.Native.socket(Native.java:68)
  jnr.unixsocket.UnixSocketChannel.<init>(UnixSocketChannel.java:66)
  jnr.unixsocket.UnixSocketChannel.open(UnixSocketChannel.java:47)
  org.jruby.ext.socket.RubyUNIXSocket.init_unixsock(RubyUNIXSocket.java:257)
  org.jruby.ext.socket.RubyUNIXSocket.initialize(RubyUNIXSocket.java:82)
  org.jruby.ext.socket.RubyUNIXSocket$INVOKER$i$1$0$initialize.call(RubyUNIXSocket$INVOKER$i$1$0$initialize.gen)
  org.jruby.internal.runtime.methods.JavaMethod$JavaMethodOne.call(JavaMethod.java:968)
  org.jruby.internal.runtime.methods.JavaMethod$JavaMethodN.call(JavaMethod.java:674)
  ...


I can see that the relevant classes are already present in the
classpath as part of jruby.jar, including jnr.unixsocket.Native$LibC. I
normally use RVM but I also tried downloading the standard JRuby
tarball and got the same result.

I've tried debugging it with -J-Djruby.native.verbose=true but that
didn't show anything interesting. I've even tried LD_DEBUG=libs to see
whether it was having trouble with the native libraries. I see a bunch
of undefined symbol errors but they relate to all sorts of things and
libjffi-1.2.so does appear to load eventually so these are probably
spurious. Am I missing something here?

Regards,
James
6a22563bd5790a15adc54c8ca772eb22?d=identicon&s=25 Ben Browning (Guest)
on 2013-08-15 15:44
(Received via mailing list)
Does the following work for you?

jruby -e "puts Java::jnr.unixsocket.Native.libsocket"

If not, install strace (yum install strace) and execute the following:

strace jruby -e "puts Java::jnr.unixsocket.Native.libsocket" 2>&1 | tee
strace.out

Look through strace.out, near the bottom, and see if it's not finding
libgcc, libcstdc++, etc.

Ben
570ee005a5d5af0dcc6a92ccfb7d1be1?d=identicon&s=25 James Le Cuirot (Guest)
on 2013-08-15 16:15
(Received via mailing list)
On Thu, 15 Aug 2013 09:43:27 -0400
Ben Browning <bbrowning@redhat.com> wrote:

> Does the following work for you?
>
> jruby -e "puts Java::jnr.unixsocket.Native.libsocket"

Aha! That set me on the right track. It's some kind of multilib issue.


NativeLibrary.java:87:in `loadNativeLibraries':
java.lang.UnsatisfiedLinkError: /usr/lib/libc.so.6: wrong ELF class:
ELFCLASS32
  from NativeLibrary.java:70:in `getNativeLibraries'
  from NativeLibrary.java:49:in `getSymbolAddress'
  from NativeLibrary.java:59:in `findSymbolAddress'
  from AsmLibraryLoader.java:125:in `generateInterfaceImpl'
  from AsmLibraryLoader.java:63:in `loadLibrary'
  from NativeLibraryLoader.java:43:in `loadLibrary'
  from LibraryLoader.java:228:in `load'
  from Library.java:123:in `loadLibrary'
  from Library.java:80:in `loadLibrary'
  from Native.java:40:in `<clinit>'
  from Unsafe.java:-2:in `ensureClassInitialized'
        ...


I then added -J-Djava.library.path=/usr/lib64 to JRUBY_OPTS and my
application started working perfectly. I can't see any obvious reason
why this might be happening though. I try to avoid 32-bit stuff
wherever possible. Any ideas?

Thanks,
James
5993756d2b69ce0bc16df3318c240d54?d=identicon&s=25 Wayne Meissner (Guest)
on 2013-08-16 02:32
(Received via mailing list)
Make sure you don't have any LD_LIBRARY_PATH or similar ld.so settings
in your environment, and check what is in /etc/ld.so.conf (or however
its configured on linux these days).

JNR by default does _not_ search for libraries, it just calls
dlopen("libc.so.6", <flags>), so it _should_ be getting the version
from /usr/lib64 (or whatever env or ld.so.conf says to search).  Maybe
its time to change that on linux...
570ee005a5d5af0dcc6a92ccfb7d1be1?d=identicon&s=25 James Le Cuirot (Guest)
on 2013-08-16 12:17
(Received via mailing list)
On Fri, 16 Aug 2013 10:30:29 +1000
Wayne Meissner <wmeissner@gmail.com> wrote:

> Make sure you don't have any LD_LIBRARY_PATH or similar ld.so settings
> in your environment, and check what is in /etc/ld.so.conf (or however
> its configured on linux these days).
>
> JNR by default does _not_ search for libraries, it just calls
> dlopen("libc.so.6", <flags>), so it _should_ be getting the version
> from /usr/lib64 (or whatever env or ld.so.conf says to search).  Maybe
> its time to change that on linux...

LD_LIBRARY_PATH is definitely not set. Here's the config from /etc.
Other than the BitDefender entry, all these lines come directly from
Fedora.

/etc/ld.so.conf:
include ld.so.conf.d/*.conf
/opt/BitDefender-scanner/var/lib/

/etc/ld.so.conf.d/* (concatenated):
/usr/lib64/atlas
/usr/lib64/dyninst
# Placeholder file, no vDSO hwcap entries used in this kernel.
# Placeholder file, no vDSO hwcap entries used in this kernel.
# Placeholder file, no vDSO hwcap entries used in this kernel.
/usr/lib64/iscsi
/usr/lib/llvm
/usr/lib64/llvm
/usr/lib64/mysql
/usr/lib64/xulrunner

I notice when I run ldconfig with -v, it says this.

ldconfig: Can't stat /libx32: No such file or directory
ldconfig: Path `/usr/lib' given more than once
ldconfig: Path `/usr/lib64' given more than once
ldconfig: Can't stat /usr/libx32: No such file or directory

I'm not sure why it says "given more than once" when I can't see any
reference to these at all. I know that certain "trusted" system
directories like /lib and /usr/lib are searched by default and it looks
as though it's checking /usr/lib first. On my Gentoo system at home,
which I haven't tried this on, these trusted directories are listed
explicitly in the config. In any case, Gentoo has /usr/lib symlinked
to /usr/lib64 with a separate /usr/lib32 directory.

I noticed a command on the system called dltest. I run it and it says
it finds libc.so.6 but only strace reveals which one. In this case,
it's /lib64/libc.so.6. I don't know why JNR gets a different result.

Regards,
James
This topic is locked and can not be replied to.