Hi Konstantin,
Am 17.04.24 um 21:44 schrieb Konstantin Kolinko:
ср, 17 апр. 2024 г. в 17:21, Rainer Jung <rainer.j...@kippdata.de>:
Am 17.04.24 um 15:34 schrieb Michael Osipov:
Rainer, I do not fully understand the problem here. We use libtool to solve
exactly this problem with versioned SONAMEs. It will create symlinks to the
SONAME.
Do you expect anyone even with dlopen() to load libfoo.o.{SOVERSION} unless it
is strictly needed?
E.g.:
lrwxr-xr-x 1 root wheel 26 2024-03-22 10:20 /usr/lib/libcrypto.so@ ->
../../lib/libcrypto.so.111
lrwxr-xr-x 1 root wheel 13 2024-03-22 10:20 /usr/lib/libssl.so@ ->
libssl.so.111
-r--r--r-- 1 root wheel 608008 2024-03-22 10:20 /usr/lib/libssl.so.111
and so on...
Yes, I expect that! anyone is the JVM :(
The problem is, that the Java API does not care about these well thought
native traditions. You can not open libssl.so.3 using
System.loadlibrary(String name), because whatever you give it as "name"
parameter it will always try to open libname.so. It always prepends
"lib" to name and always suffixes it with plain ".so".
Yes, it might exist as the first in your list of symlinks, but on most
linux distributions this link is not installed by default, because it is
only needed when doing compilations. So it is only installed when you
install development packages for libs.
There are two methods,
System.loadLibrary(libname)
System.load(filename)
or the same methods in Runtime.
The second method accepts an absolute path and apparently does no
manipulation on the name.
There is also System.mapLibraryName().
Note that o.a.t.jni.Library constructor uses all those three methods.
A code that was added several years ago uses mapLibraryName() and
load() to load a library from "catalina.home/bin". It then falls back
to the old algorithm that uses loadLibrary().
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html
thanks for your valuable input as always. I am referring to
java/org/apache/tomcat/util/openssl/openssl_h.java, which only contains
which on Mac does
System.loadLibrary("ssl");
SYMBOL_LOOKUP =
SymbolLookup.loaderLookup().or(Linker.nativeLinker().defaultLookup());
and else
SYMBOL_LOOKUP = SymbolLookup.libraryLookup(System.mapLibraryName("ssl"),
LIBRARY_ARENA)
.or(SymbolLookup.loaderLookup())
.or(Linker.nativeLinker().defaultLookup());
I *think* both attempts do not allow to use a versioned SONAME.
I have not experimented with System.load(filename) and how to combine it
with SymbolLookup. o.a.t.jni.Library does not use SymbolLookup. But it
seems SymbolLookup is not restricted to the development library names.
So there's hope we can improve!
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/SymbolLookup.html
Best regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
