On 2024/04/17 14:21:06 Rainer Jung wrote:
> 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.
Ah, now I see your problem, but it looks like a downstream problem of your
distro of choice, no? I wonder how you compile then custom software if .so
isn't present and the linker cannot find it with -L? What if you install the
devel package to have .so link?
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
