Library path on Linux

[Rick Fincher]

Hi All,

I'm trying to run a program with a shared library on a Linux system (Debian on Raspberry Pi, or "Raspbian").  I get the dreaded "UnsatisfiedLinkError".  I set the LD_LIBRARY_PATH environment variable as well as -Djna.library.path and -Djava.library.path.

The library is the file /usr/lib/libpi_i2c.so

On the Java side I load with:
CLibrary INSTANCE = (CLibrary)  Native.loadLibrary(("pi_i2c"), CLibrary.class);

Here is the command line on the Linux side and the resultant Exception:

$ java -Djna.library.path=/usr/lib -jar I2CTest.jar debug

Exception in thread "main" java.lang.UnsatisfiedLinkError: /tmp/jna-pi/jna8845416459597401346.tmp: /tmp/jna-pi/jna8845416459597401346.tmp: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1750)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1646)
        at java.lang.Runtime.load0(Runtime.java:787)
        at java.lang.System.load(System.java:1022)
        at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:771)
        at com.sun.jna.Native.loadNativeLibrary(Native.java:697)
        at com.sun.jna.Native.<clinit>(Native.java:127)
        at i2c.I2C_0$CLibrary.<clinit>(I2C_0.java:53)
        at i2c.I2C_0.init(I2C_0.java:47)
        at i2c.I2C_0.<init>(I2C_0.java:43)
        at i2ctest.I2CTest.<init>(I2CTest.java:28)
        at i2ctest.I2CTest.main(I2CTest.java:78)

Any idea what I'm doing wrong?

Thanks,

Rick

[Timothy Wall]

JNA is not finding libjnidispatch.so on LD_LIBRARY_PATH (java.library.path by the time java sees it).

It tries to unpack it from the jar file to /tmp/jna-$USER/jnaNNNN.tmp, but if libjnidispatch.so doesn't exist in the jar file, that will fail. Put "build/native" into LD_LIBRARY_PATH until you tweak build.xml to put libjnidispatch.so into jna.jar in the appropriate spot.

[Rick Fincher]

Thanks for the reply.  

The copy of jna.jar (version 3.4.2) that I'm using has libjnidispatch.so in com/sun/jna/linux-arm which is, I assume, the proper directory for the Raspberry Pi, since it uses an arm processor.


I pulled a copy out and tried putting it in /usr/lib.  I set LD_LIBRARY_PATH to:

$ echo $LD_LIBRARY_PATH
build/native:/usr/lib

Still no luck.

Where should libjnidispatch.so go for the Raspberry Pi?  Should I recompile it on the Pi and put it into a shared library and install that on the Pi separately?


Thanks!

On 9/19/2012 6:49 AM, Timothy Wall wrote:

JNA is not finding libjnidispatch.so on LD_LIBRARY_PATH (java.library.path by the time java sees it).

It tries to unpack it from the jar file to /tmp/jna-$USER/jnaNNNN.tmp, but if libjnidispatch.so doesn't exist in the jar file, that will fail.  Put "build/native" into LD_LIBRARY_PATH until you tweak build.xml to put libjnidispatch.so into jna.jar in the appropriate spot.

-------------------------

[Timothy Wall]

It looks like JNA is finding the library within the jar and unpacking it, but then the system is reporting "file not found" when actually trying to load it. Run ldd on it to make sure any libraries on which it depends are present. Seems odd that it's referring to a "shared object file", but that may be nothing.

As for why it's not found when you explicitly put it in a directory pointed at by LD_LIBRARY_PATH, I don't know.

Run "file" on libjnidispatch.so to verify it's reported as the appropriate format and architecture.

You can rebuild locally and compare the newly generated file with the one within JNA (format/arch).

[Rick Fincher]

Here's the output from file and ldd:

 $ ldd libjnidispatch.so
        not a dynamic executable


 $ file libjnidispatch.so
libjnidispatch.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xb2fe121fc0b27c6562e0a73bda21e2bc23193938, not stripped

Thanks,

Rick

[Timothy Wall]

how does that compare with a libXXX.so that you know to be kosher?

[Rick Fincher]

Here's the 'file' and 'ldd' output for libc:

pi@raspberrypi /lib/arm-linux-gnueabihf $ file libc-2.13.so
 libc-2.13.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=0x3570fca320483687fcd8d5e743c228f452f81a9c, for GNU/Linux 2.6.26, stripped


pi@raspberrypi /lib/arm-linux-gnueabihf $ ldd libc-2.13.so
        /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0x40265000)
        /lib/ld-linux-armhf.so.3 (0x400ec000)

Looks like I need to recompile libjnidispatch.so on the Raspberry Pi and replace it in the jar?


Rick

[Timothy Wall]

On Sep 20, 2012, at 9:23 AM, Rick Fincher wrote:

> Here's the 'file' and 'ldd' output for libc:
>
> pi@raspberrypi /lib/arm-linux-gnueabihf $ file libc-2.13.so
> libc-2.13.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=0x3570fca320483687fcd8d5e743c228f452f81a9c, for GNU/Linux 2.6.26, stripped
>
>
> pi@raspberrypi /lib/arm-linux-gnueabihf $ ldd libc-2.13.so
> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0x40265000)
> /lib/ld-linux-armhf.so.3 (0x400ec000)
>
> Looks like I need to recompile libjnidispatch.so on the Raspberry Pi and replace it in the jar?
>
>

Well, the one in there obviously doesn't work for you; you can certainly recompile libjnidispatch.so, and that will probably work in your situation.

What I'd like to determine is whether the existing file is just totally bogus (I may have built it on a donated linux-arm system or someone may have contributed it, I don't recall), or whether linux-arm needs something distinctly different from your Pi system.

[Neil C Smith]

Sorry if this is adding to the noise, but could this be caused by the
difference between the hard-float and soft-float ABI's? Does JNA work
with the Oracle JVM on the standard Debian rather than Raspbian? See
here - http://www.raspberrypi.org/downloads Was looking into this a
little recently, though still don't have a Pi to play with.

Neil

--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net

Praxis LIVE - Open-source, graphical environment for rapid development
of intermedia performance tools, projections and interactive spaces -
http://code.google.com/p/praxis

OpenEye - specialist web solutions for the cultural, education,
charitable and local government sectors - http://openeye.info

[Rick Fincher]

That's an interesting suggestion.  From what I understand, it isn't a problem.  The Oravle JVM uses software floating point and Raspbian uses the hardware floating point libraries.  Oracle is working on a version of the JVM that uses the hardware floating point, but the only difference really is speed.

There is now a version of Raspbian on the raspberrypi.org/downloads web page compiled with the software floating point libraries for people that must use the Oracle JVM.

The Oracle JVM is so much faster than Open JDK that if you are running a lot of Java apps, you may not mind the slow down in other stuff from using the software floating point.

Floating point works fine with the Open JDK 6 because the Raspbian version is compiled with the hardware libraries.

The only incompatibility I am aware of is in the Oracle JVM.  The problem has to do with the low level nature of the JVM code, as I understand it.

That said, recompiling the  libjnidispatch.so library on the Pi, or even the entire JNA library, would be worth a try.  That should take care of the problem.

Rick

[Rick Fincher]

I can't say for certain, but from what I've seen of the Raspberry Pi so far, stuff written for Linux/Arm seems to work fine in most cases.

Of course, most of that is source code that was pulled over and recompiled on the Pi.

When I get some time (under the gun on a project right now, so I switched back to JNI) I'll try to compile that and see if it helps.

I'd much rather use JNA for this stuff.

Rick

[Domingo Berron]

Hi Rick,

Do you get finally JNA working on Raspberry?

I'm trying but I have now the same problem that you had.