luben / zstd-jni

JNI binding for Zstd
Other
853 stars 168 forks source link

Allow choosing the path where the native library is extracted using a system property #315

Closed bgK closed 2 months ago

bgK commented 4 months ago

I'm trying to deploy an application using zstd-jni on a system where /tmp is mounted noexec.

zstd-jni initialization fails with the following error:

java.lang.ExceptionInInitializerError: Exception java.lang.UnsatisfiedLinkError: /tmp/libzstd-jni-1.5.5-111543552353015917660.so: /tmp/libzstd-jni-1.5.5-111543552353015917660.so: failed to map segment from shared object

I could override java.io.tmpdir but that affects the rest of the application. The other temporary files are no longer noexec.

I could use the ZstdNativePath system property, but that complexifies the deployment scenario, the proper native library for the architecture needs to be extracted and kept in sync with the java library version.

I could call Native.load(File tempFolder) while initializing the application to override the path. That's weird, because my application has nothing to do with Zstd, I just happen to have zstd-jni on the classpath mostly by accident. It's a transitive runtime dependency of kafka-clients. Netty picks it up and tries to use it.

It would be nice to have a new system property to override the path where zstd-jni extracts the native library. That way, the logic for extracting the native library remains in zstd-jni. Only the deployments where /tmp is mounted as noexec are affected and can set the property to a path where the library can be loaded.

luben commented 2 months ago

now it's released as 1.5.6-4. You can specify the ZstdTempFolder property to tell Zstd where to extract the native library