Loading 32bit library when 64bit one is available

[chrisseaton]

A colleague of mine has two versions of libcrypt.so.1 on Kubuntu 15.04.

/lib/i386-linux-gnu/libcrypt.so.1
/lib/x86_64-linux-gnu/libcrypt.so.1

JFFI, on behalf of jnr-posix, is loading the 32bit one when it should load the 64bit one. What is the mechanism, either in the OS or JFFI or wherever, that should ensure the correct one is loaded, and what could be going wrong here?

The 32bit library is needed by Skype for Linux, so it is not an obscure package.

[nirvdrum]

I'm pretty sure the problem is in jnr-ffi and has already been fixed by jnr/jnr-ffi@b9fccdd

In the meanwhile, I think your colleague can get things working by changing a system property before JNR loads. The list searched is here:

https://github.com/jnr/jnr-ffi/blob/2.0.3/src/main/java/jnr/ffi/LibraryLoader.java#L338-L342

[jtulach]

I can confirm that running my Ruby program with as
$ ./bin/jruby -J-Djna.library.path=/lib/x86_64-linux-gnu/ -X+T ~/sieve.rb
workarounds the library resolution problem.

[chrisseaton]

Great - I'll close as the fix should also be coming soon.

[jtulach]

OK. In addition to the above, here a way to successfully execute maven build on such dual bit system:
jruby-truffle-head/truffle$ mvn test -DargLine=-Djna.library.path=/lib/x86_64-linux-gnu/

[chrisseaton]

Reopened as this doesn't seem to be fixed yet.

[mkristian]

this should be solved with jnr/jnr-ffi#52

at least it sounds all very familiar to my problem on ubuntu which is solved with the above PR

[headius]

We'll call this fixed with jnr/jnr-ffi#52 until someone says otherwise.