Dynamic linking fails with libssl3.so systems
adarcanum opened this issue · 7 comments
Hi, I created following project - https://github.com/adarcanum/openssl4j-example/tree/master
When running the main method it throws:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /tmp/native5689319720219818901/libopenssl4j-Linux-amd64.so: libssl.so.1.1: cannot open shared object file: No such file or directory
at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2389)
at java.base/java.lang.Runtime.load0(Runtime.java:755)
at java.base/java.lang.System.load(System.java:1953)
at de.sfuhrm.openssl4j.NativeLoader.load(NativeLoader.java:48)
at de.sfuhrm.openssl4j.NativeLoader.loadAll(NativeLoader.java:39)
at de.sfuhrm.openssl4j.OpenSSL4JProvider.<init>(OpenSSL4JProvider.java:34)
at com.example.MainKt.main(Main.kt:8)
at com.example.MainKt.main(Main.kt)
Not sure what I might be missing here. Help would be appriciated.
EDIT: just for some context I tried doing some debugging, I can see the temp file created and libopenssl4j-Linux-amd64.so
is inside, so I am not sure why it may be failing like this.
Thanks for your issue!
Can you give me more context, i.e. on what operating system + version you are running that?
It looks like the so-file is wanting to load a library (libssl.so.1.1) that is not part of your system. Can you check your libssl versions installed and paste them here please ()?
Mine reads like this:
~# LANG=c ldconfig -v|grep libssl
...
libssl.so.3 -> libssl.so.3
libssl.so.1.0.2 -> libssl.so.1.0.2
libssl.so.1.1 -> libssl.so.1.1
libssl3.so -> libssl3.so
...
which is a Debian 12, but not having the library so-file anymore in any package:
# apt-file search libssl.so
android-libboringssl: /usr/lib/x86_64-linux-gnu/android/libssl.so.0
android-libboringssl-dev: /usr/lib/x86_64-linux-gnu/android/libssl.so
libssl-dev: /usr/lib/x86_64-linux-gnu/libssl.so
libssl3: /usr/lib/x86_64-linux-gnu/libssl.so.3
EDIT: just for some context I tried doing some debugging, I can see the temp file created and libopenssl4j-Linux-amd64.so is inside, so I am not sure why it may be failing like this.
Yes, the so-file in the temp filesystem is actually built on another system (Debian 11!). Probably we'll need also different so-files per target OS version.
Hi,
output of cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
output of LANG=c ldconfig -v|grep libssl
libssl.so.3 -> libssl.so.3
libssl3.so -> libssl3.so
libssl.so.3 -> libssl.so.3
output of apt-file search libssl.so
android-libboringssl: /usr/lib/x86_64-linux-gnu/android/libssl.so.0
android-libboringssl-dev: /usr/lib/x86_64-linux-gnu/android/libssl.so
libssl-dev: /usr/lib/x86_64-linux-gnu/libssl.so
libssl3: /usr/lib/x86_64-linux-gnu/libssl.so.3
Thanks for your feedback! This means that the dynamically linked library to the system does not exist in the needed version and there needs to be a solution for that.
possible approaches:
- statically link libssl to have a robustness over multiple systems and less requirements
- package multiple versions of openssl4j that has bindings to libssl1.1 and libssl3
I personally favor the static linking.
I'll update the ticket to reflect more the source of the problem.
Do you want to provide a PR?
In the branch https://github.com/sfuhrm/openssl4j/tree/STATIC_SSL I have already a possibly working solution. I'll keep you informed.
@adarcanum I have finished including the fix in the main branch and releasing it.
libssl is now statically linked to overcome problems with the system not having libssl.
Would be cool if your could check your use-case with the new openssl4j 0.5.0 and give feedback.
Solved to the current knowledge.