чт, 18 апр. 2024 г. в 00:46, Rainer Jung <rainer.j...@kippdata.de>:
>
> 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
Thank you for the references.
Those lines of code are not generated, but are written by Remy.
A comment referencing "https://github.com/sergot/openssl/issues/81"; was a clue.
See the changes in February 2024 (starting with 2024-02-08).
SymbolLookup has two methods, just like the pair of methods in System/Runtime:
libraryLookup(String, Arena)
libraryLookup(Path, Arena).
The second method accepts a full path to a library file.
Interesting is that this new API allows unloading the library - that
is what the Arena argument is for.
As we do not plan to unload the library, I think it makes sense to use
the "good old" System.load() / loadLibrary() methods to load the
library, and use the SymbolLookup loaderLookup() factory method.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
