If you are able to run 32-bit Java 1.6 I assume that means you have the 32-bit libs on your system. It seems like this is attempting to open the first library it finds, and that one turns out to be 64-bit.

A few things I need from you:

• run file <whatever> against every libcrypt* on your system and provide me the result and paths. There must be a 32-bit version somewhere.
• Show me LD_LIBRARY_PATH and LD64_LIBRARY_PATH if you have them.
• Run the above with -J-verbose:jni passed to JRuby in both 32-bit and 64-bit Java 7 (fail and success).
• Clone and attempt to mvn test https://github.com/jnr/jnr-posix, which houses our crypt binding. You will need Apache Maven on your system.

This may come down to making the library more willing to keep trying libraries when the first one fails.

How did you get a 32-bit Java on that system if lib/* is 64-bit libraries? It seems like a weird situation.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 6.0.7 (squeeze)
Release: 6.0.7
Codename: squeeze

$ find / -iname libcrypt*so* -exec file {} \; 2>/dev/null
/lib/libcrypt.so.1: symbolic link to `libcrypt-2.11.3.so'
/lib/libcrypt-2.11.3.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
/lib32/libcrypt.so.1: symbolic link to `libcrypt-2.11.3.so'
/lib32/libcrypt-2.11.3.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
/usr/lib/libcrypto.so: symbolic link to `libcrypto.so.0.9.8'
/usr/lib/libcrypto.so.0.9.8: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
/usr/lib/libcrypt.so: symbolic link to `/lib/libcrypt.so.1'
/usr/lib32/i486/libcrypto.so.0.9.8: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
/usr/lib32/i686/cmov/libcrypto.so.0.9.8: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
/usr/lib32/libcrypto.so.0.9.8: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
/usr/lib32/i586/libcrypto.so.0.9.8: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

$ find / -iname libcrypt*so* -exec dpkg -S {} \; 2>/dev/null
libc6: /lib/libcrypt.so.1
libc6: /lib/libcrypt-2.11.3.so
libc6-i386: /lib32/libcrypt.so.1
libc6-i386: /lib32/libcrypt-2.11.3.so
libssl-dev: /usr/lib/libcrypto.so
libssl0.9.8: /usr/lib/libcrypto.so.0.9.8
libc6-dev: /usr/lib/libcrypt.so
ia32-libs: /usr/lib32/i486/libcrypto.so.0.9.8
ia32-libs: /usr/lib32/i686/cmov/libcrypto.so.0.9.8
ia32-libs: /usr/lib32/libcrypto.so.0.9.8
ia32-libs: /usr/lib32/i586/libcrypto.so.0.9.8

$ env | grep LD_
(empty)

$ java -version -d64 2>&1 && jruby -J-verbose:jni -e "puts"

https://gist.github.com/kml/7c8921673c537a2f5eee

$ java -version -d32 2>&1 && jruby -J-verbose:jni -e "puts"

it same as for 64 bit

$ diff j32-jni.log j64-jni.log
3c3
< Java HotSpot(TM) Server VM (build 24.79-b02, mixed mode)
---
> Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)

jnr-posix-mvn-test-j32.log
https://gist.github.com/kml/f4090c1a81bda1e7e361

jnr-posix-mvn-test-j64.log
https://gist.github.com/kml/67af4cee9ce3f0e3eba2

I am using 32 bit Java 1.8 on Arch 64 bit with error "native support failed to load"

[root@arch1 ~] jruby -S gem install rails
NotImplementedError: waitpid unsupported or native support failed to load
flock at org/jruby/RubyFile.java:298
block in read_binary at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems.rb:773
open at org/jruby/RubyIO.java:1126
open at org/jruby/RubyKernel.java:310
read_binary at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems.rb:772
fetch_spec at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems/source.rb:145
spec at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems/resolver/api_specification.rb:76
add_always_install at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems/resolver/installer_set.rb:77
resolve_dependencies at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems/dependency_installer.rb:473
install_gem at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems/commands/install_command.rb:238
block in install_gems at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems/commands/install_command.rb:299
each at org/jruby/RubyArray.java:1560
install_gems at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems/commands/install_command.rb:295
execute at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems/commands/install_command.rb:202
invoke_with_build_args at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems/command.rb:307
process_args at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems/command_manager.rb:168
run at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems/command_manager.rb:138
run at /root/jruby-9.0.1.0/lib/ruby/stdlib/rubygems/gem_runner.rb:54
at /root/jruby-9.0.1.0/bin/jgem:21
load at org/jruby/RubyKernel.java:957
at /root/jruby-9.0.1.0/bin/gem:4

has been originally reported as a JRuby 1.7 issue, which is know EOL.
if anyone lands here please try using latest JRuby (9K) and get back with a new issue report.