Is it possible to use Android JNI in a regular Java application?

Question

Java

There is a library compiled for android as jni for all platforms, in fact so files. I try to connect this library from a regular java application, it seems to connect, but it gives an error "liblog.so: cannot open shared object file: No such file or directory", because this library has such a dependency. Then I installed android-liblog, android-liblog-dev but it did not help, the error is the same.
ldconfig -p | grep liblog doesn't show anything.
The library sources are closed, because. the library has a closed protocol. I would like to use it without android. The library has the following dependencies:
liblog.so
libz.so
libm.so
libstdc++.so
libc.so
libdl.so

How can dependencies be fixed? And is it possible to run this library in a regular Java application?

UPD: Solved the problem by adding the LD_LIBRARY_PATH variable to the launch configuration. But a new problem has emerged. /usr/lib/x86_64-linux-gnu/libm.so: invalid ELF header Which package should be installed? Ubuntu 64

Answer 1

umm and what hinders that to use in normal Java? JNI - java native interface, it is even in java even in anroid

Answer 2

Why did you decide that it's so easy to take native libraries and drag them from one platform to another without rebuilding.
1) It is necessary that the architectures match.
2) It is necessary that the environment matches, i.e. the core of the system (if calls from there are involved), the libraries around (again, their versions and the fact that they have not been changed to suit a particular OS).
3) Complied with external system APIs.
Conditionally, you can slip some of the libraries that are normal (if this is the case and they have not been changed):
liblog.so - I can be wrong, but this is a purely android lib and under normal Linux it is partially used to build native applications for android but not as a library dependency on Linux.
libz.so is zlib
libm.so is part of libc. Again, a lottery, the library is monstrous and we can say this is the second core of the system.
libc.so - see libm.so
libdl.so - see libm.so
libstdc++.so - don't even think about it, you can easily find it, but again, will it work?
Places where they are searched for and under what names you can symlink.
You can imagine that you are trying to transfer the VAZ carburetor to some kind of FIAT.