Fdb-java on macOS catalina throwing error Library not loaded: libfdb_c.dylib

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 am using fdb-java 6.1.9

fdb-cli is working fine though.

Can someone let me know what is going wrong?

Getting same error on OSX Catalina.

Details:

FDB package installed: https://www.foundationdb.org/downloads/6.2.11/macOS/installers/FoundationDB-6.2.11.pkg

OS: OSX Catalina : 10.15.2

Java Dependency Version:

<dependency>
    <groupId>org.foundationdb</groupId>
    <artifactId>fdb-java</artifactId>
    <version>6.2.10</version>
</dependency>

@alloc would you know anything about this?

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.

Thanks @alloc.

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.

1 Like

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

@alloc - Any thoughts on this?

We’re running into the same issue with the nodejs bindings now that nodejs has added notarization to the build process.

I started a forum topic on that too without noticing this thread. Looks like the same issue.

This is tracked under the below issue