I have installed foundation db 6.2.10 (both client and server) on macOS 10.15.2. But whenever I am trying to use fdb-java in a java program I am getting the below error
java.lang.UnsatisfiedLinkError: /private/var/folders/m3/dhywtct96_q596wpwhjjlmfh0000gq/T/fdbjni3136449478736359170.library: dlopen(/private/var/folders/m3/dhywtct96_q596wpwhjjlmfh0000gq/T/fdbjni3136449478736359170.library, 1): Library not loaded: libfdb_c.dylib
Referenced from: /private/var/folders/m3/dhywtct96_q596wpwhjjlmfh0000gq/T/fdbjni3136449478736359170.library
Reason: image not found
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1934)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817)
at java.lang.Runtime.load0(Runtime.java:810)
at java.lang.System.load(System.java:1086)
at com.apple.foundationdb.JNIUtil.loadLibrary(JNIUtil.java:106)
at com.apple.foundationdb.FDB.<clinit>(FDB.java:97)
at com.vnera.storage.config.fdb.common.FDB.<init>(FDB.java:135)
at com.vnera.storage.config.fdb.common.FDB.get(FDB.java:242)
at com.vnera.storage.config.fdb.FdbTestStorageUtils.setUp(FdbTestStorageUtils.java:61)
at com.vnera.storage.config.fdb.FdbTestStorageUtils.setUp(FdbTestStorageUtils.java:33)
at com.vnera.tools.FdbEventMigrationTest.setupTest(FdbEventMigrationTest.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:748)
libfdb_c.dylib is also present in /usr/local/lib/
dmanna-a01:tools-module dmanna$ ls -lrt /usr/local/lib/libfdb_c.dylib
-rwxr-xr-x 1 root wheel 8261760 Nov 15 01:25 /usr/local/lib/libfdb_c.dylib
I tried to debug-trace through the calling code and found that com.apple.foundationdb.JNIUtil#loadLibrary is copying the bundled libfdb_java.jnilib file in a temp location and eventually calling System.load(filename); but the System.load() is failing with above exception.
Well, I’m not sure if this is going to be particularly helpful, but macOS Catalina includes some security related changes that now makes the process of loading and running code that hasn’t been signed and/or notarized somewhat more laborious. If that’s it, I think there are ways to whitelist specific applications (but I’m also not sure if that’s it).
I am not surprised, @tuk, that fdbcli is still working as that actually doesn’t use the separate C library (so one can be broken without affecting t’other).
I personally haven’t experienced this problem, so I’m not sure how helpful I can be. If the exact same setup works on macOS Mojave, then it could very well be one of the changes in Catalina.
I determined the cause of this error to be some osx bug with open jdk version we were using. I had changed the jdks on my local setup recently. Switching back to Oracle JDK 8 resolved the issue.
We were seeing the problem with the below jdk version
dmanna-a01:~ dmanna$ java -version
openjdk version "1.8.0_242"
OpenJDK Runtime Environment (Zulu 8.44.0.10-SA-macosx) (build 1.8.0_242-b20)
OpenJDK 64-Bit Server VM (Zulu 8.44.0.10-SA-macosx) (build 25.242-b20, mixed mode)
The main problem seems to be that the fdb binaries are not notarized / signed as per Apple’s requirements.
Azul JDK notarizes the distribution with a more recent secure certificate, however, AdoptOpenJDK and Oracle use older certificates. Thus the Zulu distributions are stricter and does not allow unsigned JNI applications to load libraries from unsecured locations on Catalina.
It seems the pass given to Oracle and AdoptOpenJDK will stop soon, will be forced to update the certificates and will behave similar to Zulu. See this.
Azul has published the following tech doc for this
Hi Guys,
Running onto the same issue. It has become a nightmare now.
Caused by: java.lang.UnsatisfiedLinkError: /private/var/folders/0g/45y2_pyn5994wjtlmjdlkq900000gn/T/fdbjni4682893172993221093.library: dlopen(/private/var/folders/0g/45y2_pyn5994wjtlmjdlkq900000gn/T/fdbjni4682893172993221093.library, 1): Library not loaded: libfdb_c.dylib
Referenced from: /private/var/folders/0g/45y2_pyn5994wjtlmjdlkq900000gn/T/fdbjni4682893172993221093.library
Reason: image not found
Caused by: java.lang.IllegalArgumentException: Could not instantiate implementation: com.experoinc.janusgraph.diskstorage.foundationdb.FoundationDBStoreManager
at org.janusgraph.util.system.ConfigurationUtil.instantiate(ConfigurationUtil.java:64)
at org.janusgraph.diskstorage.Backend.getImplementationClass(Backend.java:440)
at org.janusgraph.diskstorage.Backend.getStorageManager(Backend.java:411)
at org.janusgraph.graphdb.configuration.builder.GraphDatabaseConfigurationBuilder.build(GraphDatabaseConfigurationBuilder.java:50)
at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:161)
at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:132)
at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:112)
... 18 more
For me, Even store manager is not getting loaded FoundationDBStoreManager
Please, If some has fixed this. Let us know how have you fixed it.
These are my stacks:
FoundationDB.pkg (v6.2.20)
Janusgraph-foundationdb-adapter (v0.1.0)
Janusgraph (v0.3.2)
macOS Catalina (v10.15.6)
I suspect that its the same issue - to do with notarization of openjdk requiring dynamic libraries to be loaded from a much more limited set of locations.
The workarounds for nodejs will probably work with java too. Try either
Adding DYLD_LIBRARY_PATH=/usr/local/lib to the environment variables when your process is run.
Copying /usr/local/lib/libfdb_c.dylib to the working directory of the java process
I’ve been recently struggling with this myself with Catalina and FDB 6.2.22 when running tests via the FailSafe maven plugin. I’ve attempted a few different configurations with DYLD_LIBRARY_PATH and java.library.path pointed at /usr/local/lib but havent come up with a solution
I’ve been using Mac OS 10.14 on my main development machine, but even there I got bitten by a similar problem and discovered that I can’t use FDB with OpenJDK11. It does work with Oracle JDK 8.
The choices of a development platform are narrowing quickly, and I’ve been wondering: what do people at Apple use? Surely you guys must use Macs with recent OSs and recent JDKs?
I was facing the same issue, but I could resolve it by copying /usr/local/lib/libfdb_c.dylib to the working directory and setting the environment variable DYLD_LIBRARY_PATH=/usr/local/lib
I am stuck on the same issue using an M1 Pro Macbook Pro (2021).
The main version we use at the moment is 6.3.24 for both the .pkg and the fdb-java jar. I tried copying /usr/local/lib/libfdb_c.dylib and setting the environment variable DYLD_LIBRARY_PATH=/usr/local/lib as mentioned in the previous comment with many different permutations (as well with different FDB client/server versions installed locally and different fdb-java versions as well) to no avail.
I really would not like to disable SIP to make this work (this is the only thing I haven’t tested yet).