The problem
I’ve been trying to run a unit test on my own Mac. The test runs fine on Linux servers, but fails locally with the following trace:
java.lang.UnsatisfiedLinkError: no fedel_client in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1758)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1045)
....
What I’ve tried
Copy the .so file from the server
I’ve copied fedel_client.so from the server to /workspace/dapper/java/lib/native/macosx on my local machine, and added it to the java.library.path:
-Djava.library.path=/workspace/dapper/java/lib/native/macosx:...
Create a symlink
I’ve created a symlink from fedel_clinet to fedel_clinet.so, in case that Java is looking for the former (without the .so extension).
Add the .so directory to .bashrc
I’ve tried adding .so directory to PATH:
PATH=$PATH:/Users/adamatan/workspaces/trunk/dapper/java/lib/native/macosx
And to LD_LIBRARY_PATH:
export LD_LIBRARY_PATH="/Users/adamatan/workspaces/trunk/dapper/java/lib/native/macosx"
Print the java.library.path
I’ve printed java.library.path, to see if the changes in the Eclipse environment were propagated to the JVM:
System.out.println(System.getProperty("java.library.path"));
And got:
/workspace/dapper/java/lib/native/macosx:....
The exact values I placed in the Eclipse configuration.
Debugging ideas?
I got the exact same error with all the aforementioned solutions. Any idea how to debug this problem? Can I get a more verbose error message from Java? Is the file not found, or not loaded? If it isn’t loaded, why is that?
I may be reading you wrong, but it sounds like you’ve copied the native library (
libfedel_client.so) from the Linux server to your own Mac. If this is the case, this will certainly not work. You cannot use a Linux native library on your Mac, you will need to recompile it on the Mac to produce alibfedel_client.dylib.Depending on the version of the Apple Java runtime you’re using, you may need to use the
.jnilibextension. Early runtimes used the.jnilibextension instead of.dylib, and both extensions are still supported (although.dylibis now the default.)