Loading LibC on Fedora picks the 32-bit version for a 64-bit JVM.

[eregon]

Trying a simple hello world in jruby on Fedora produces this:

$ uname -a
Linux localhost.localdomain 3.16.6-200.fc20.x86_64 #1 SMP Wed Oct 15 13:06:51 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ java -version (the system jdk)
java version "1.7.0_71"
OpenJDK Runtime Environment (fedora-2.5.3.0.fc20-x86_64 u71-b14)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
$ bin/jruby -e 'p :hello'
Native.java:69:in `libc': java.lang.NoClassDefFoundError: Could not initialize class jnr.enxio.channels.Native$SingletonHolder
    from Native.java:112:in `write'
    from NativeDeviceChannel.java:86:in `write'
    from PosixShim.java:90:in `write'
    from OpenFile.java:594:in `flushBufferSync'
    from OpenFile.java:585:in `flushBufferSync2'
    from OpenFile.java:578:in `flushBufferAsync2'
    from OpenFile.java:571:in `flushBuffer'
    from OpenFile.java:426:in `io_fflush'
    from RubyIO.java:2154:in `flushRaw'
    from RubyIO.java:2136:in `flush'
    from RubyKernel.java:498:in `p'
    from RubyKernel$INVOKER$s$0$0$p.gen:-1:in `call'
    from JavaMethod.java:679:in `call'
    from DynamicMethod.java:206:in `call'
    from CachingCallSite.java:295:in `cacheAndCall'
    from CachingCallSite.java:157:in `call'
    from -e:-1:in `invokeOther0:p'
    from -e:1:in `__script__'
    from NativeMethodAccessorImpl.java:-2:in `invoke0'
    from NativeMethodAccessorImpl.java:57:in `invoke'
    from DelegatingMethodAccessorImpl.java:43:in `invoke'
    from Method.java:606:in `invoke'
    from Compiler.java:73:in `__file__'
    from Compiler.java:93:in `load'
    from Ruby.java:805:in `runScript'
    from Ruby.java:798:in `runScript'
    from Ruby.java:749:in `runNormally'
    from Ruby.java:559:in `runFromMain'
    from Main.java:405:in `doRunFromMain'
    from Main.java:300:in `internalRun'
    from Main.java:227:in `run'
    from Main.java:199:in `main'

I have both 64-bit and 32-bit libc because some apps still require 32-bit.
The java.library.path is
/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib,
so it should definitely pick /usr/lib64/libc.so and not /usr/lib/libc.so.6.
Notive there is also /lib/libc.so.6 which is 32-bit.

I cannot find any apparent wrong logic in https://github.com/jnr/jnr-ffi/blob/master/src/main/java/jnr/ffi/Platform.java#L424-L473 but it has some hidden complexity so the bug might still be there or around.
In any case, the loader should definitely consider only compatible architectures and not just take the latest version.

How can I test a version of jnr-ffi I modified with jruby?

See jruby/jruby#2016 for more details.

[eregon]

Should be fixed by #28, thanks @gilles-duboscq !
How can I test it?

[mkristian]

@eregon on master the build already picks jnr-ffi-2.0.0-SNAPSHOT.jar
to build the latest code (which is not deployed on oss.sonatype.org/content/repositories/snapshots/) just run $mvn install inside jnr-ffi

[eregon]

@mkristian Thanks, I see now it is even deployed on sonatype.
Seems everything works fine at me now, closing.