Michael,
On 4/17/24 16:46, Michael Osipov wrote:
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?
That works, but doesn't seem to be a reasonable requirement if you just
want to install Ubuntu and Tomcat and run a server.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
