sfuhrm/openssl4j

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.

sfuhrm commented

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
sfuhrm commented

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
sfuhrm commented

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?

sfuhrm commented

In the branch https://github.com/sfuhrm/openssl4j/tree/STATIC_SSL I have already a possibly working solution. I'll keep you informed.

sfuhrm commented

@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.