1

I have compiled a Java application (JAR) that runs fine on my Mac OS machine. It uses JNI to call a compiled C-Shared library and uses jnr-ffi to load that native code.

I am getting a bunch of errors that stem from jnr-ffi trying to initialise. It looks like there should be some jni files that should exist on the system as part of the Java installation but they don't exist.

I can't copy the stacktrace verbatim but here are some of the errors which should be helpful:

    Exception in thread "main" j.l.UnsatisfiedLinkError: could not load FFI provider jnr.ffi.provider.jffi.provider


Another unsatisfied link error below: /tmp/...gibberish..so cannot open shared object file: no such file or directory.

Another unsatisfied link error: Can't load library: /usr/lib/libjffi-1.2so

Basically a bunch of errors relating loading native code.

It is also worth nothing that I have extracted the JAR that I am trying to run and it contains a bunch of folders such as arm-Linux, Darwin, i386-Linux, and the file libjffi-1.2.so So it looks like the files exist in the JAR but at runtime, jave is having trouble finding them.

I can't figure out how to fix this and it worked on my other machine. How to fix?

I have tried running with sudo.

jim
  • 8,670
  • 15
  • 78
  • 149

1 Answers1

1

When you run the JVM it will look for the native library and will try to load it. Unfortunately, native libraries are not portable when compiled, and that's why the software you are trying to run, provide the same library compiled for different architectures.

The one you need for the raspberry pi is the arm-Linux one.

You just have to figure out what is the path the the JVM uses to load the library and eighter configure the software to load the proper one, via command line, or replace the one you use in the mac with the one compiled for ARM.

snovelli
  • 5,804
  • 2
  • 37
  • 50
  • Thanks, i'll try that. But, whats with the /tmp directory being searched with a random filename.so ? – jim Apr 05 '16 at 15:12
  • One of the search paths in the exception, is a valid path.. Why is that? – jim Apr 05 '16 at 15:13
  • Java has concept of temporary folder. In the java source code, the programmer may be trying to resolve the library onto that. It's possible that it tries to decompress some archive containing the library in the tmp folder, but since the archive doesn't exist, the extracted file will not exist. (just huessing here) – snovelli Apr 05 '16 at 15:14
  • I think figured out why the temp folder. When you try to load a native library from a jar (your library is probably included inside the jar) you first have to copy it in a temporary folder and then use it. see: http://stackoverflow.com/questions/4691095/java-loading-dlls-by-a-relative-path-and-hide-them-inside-a-jar – snovelli Apr 06 '16 at 14:28
  • Thanks, but the library I am using (not mine) is already doing that stuff with the tmp folder. – jim Apr 06 '16 at 14:55