mirror of
https://github.com/google/brotli.git
synced 2026-07-08 17:56:58 +00:00
java.lang.UnsatisfiedLinkError: org.brotli.wrapper.enc.EncoderJNI.nativeCreate([J)Ljava/nio/ByteBuffer #218
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @vaneri on GitHub (Feb 28, 2018).
Hello,
Here are the steps that I did so far:
supposedly adding all the libraries in the path that can be discovered
As this was not working and I was getting the exception UnsatisfiedLinkError; I tried the following:
Loading individually the libraries:
System.load(new java.io.File("/usr/lib/libbrotlicommon.so").getAbsolutePath());
System.load(new java.io.File("/usr/lib/libbrotlidec.so").getAbsolutePath());
System.load(new java.io.File("/usr/lib/libbrotlienc.so").getAbsolutePath());
This didn't help either.
I try to change the path java.library.path and use the /usr/lib but this didn't help either.
Do you have any clue on what I am doing wrong in the JNI loading?
I am using :
Distributor ID: Ubuntu
Description: Ubuntu 16.04.4 LTS
and
IntelliJ IDEA as IDE
Thanks
@eustas commented on GitHub (Feb 28, 2018):
Hello.
JNI wrappers are currently not supported in CMake build.
You could try using Bazel:
bazel build -c opt java/org/brotli/wrapper/...:all, or pick up prebuilt artifacts from bintray (only for windows)@vaneri commented on GitHub (Feb 28, 2018):
Thanks for the information; could you tell me more about the bazel output; is it only working for windows?
What shall I suppose to do with the output? what jar/file should I use/copy?
Thanks a lot for your help,
Rimbaud
We found out that the library generated is .dll and not really was you would expect in using linux
For the one interested, here is the output that should be used:
bazel-bin/brotli_jni.dll
Would certainly be interesting to have those information in the README instead of a link to bazel that is just useless.
@eustas commented on GitHub (May 7, 2019):
".dll" is the file suffix. Actually when project is built under mac / linux it produces valid shared library (those systems are less picky about filename suffix). Anyways, produced artifact could be renamed...
@eustas commented on GitHub (May 7, 2019):
Although, it is always better to make a custom build and have a single library for all the native deps of the app, if possible.
FWIW, jni library for windows is published on bintray after successful Appveyor builds; perhaps this will be also useful for OSX, but not for linux (due to fragmentation).