The precompiled `tonclient.so` cannot be linked with GLIBC_2.17
syslogic opened this issue · comments
This might be a preview for a PR (currently it only loads the pre-compiled tonclient.so
or dll
into the Java JVM).
I've managed to load system-wide & also packaged (extracted from JAR) native assembly in a pure Java/Gradle project.
The issue is that it fails to link the library with glibc 2.17
:
> Task :library:compileJava
> Task :library:processResources UP-TO-DATE
> Task :library:classes
> Task :library:compileTestJava UP-TO-DATE
> Task :library:processTestResources NO-SOURCE
> Task :library:testClasses UP-TO-DATE
> Task :library:test FAILED
> assembly extracted: /tmp/tonclient8948088420223915752.so
> UnsatisfiedLinkError: /tmp/tonclient8948088420223915752.so: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /tmp/tonclient8948088420223915752.so)
io.tonlabs.client.Wrapper.getMessage()Ljava/lang/String;
java.lang.UnsatisfiedLinkError: io.tonlabs.client.Wrapper.getMessage()Ljava/lang/String;
at io.tonlabs.client.Wrapper.getMessage(Native Method)
...
The same with ldd
:
$ ldd ../library/src/main/resources/tonclient.so
../library/src/main/resources/tonclient.so: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by ../library/src/main/resources/tonclient.so)
linux-vdso.so.1 => (0x00007ffffcfb5000)
libssl.so.1.1 => not found
libcrypto.so.1.1 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fab5cea2000)
librt.so.1 => /lib64/librt.so.1 (0x00007fab5cc9a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fab5ca7e000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fab5c868000)
libc.so.6 => /lib64/libc.so.6 (0x00007fab5c49a000)
/lib64/ld-linux-x86-64.so.2 (0x00007fab5e148000)
libm.so.6 => /lib64/libm.so.6 (0x00007fab5c198000)
libz.so.1 => /lib64/libz.so.1 (0x00007fab5bf82000)
yum install openssl11-libs
installed libssl.so.1.1
& libcrypto.so.1.1
- but yum info glibc
says it 2.17
.
The only way seems to install CentOS 8 or Debian, which have kernels built with later versions.
I might try the same on Windows 10 later, to see if it links the DLL
.
Might building from source on CentOS 7 with glibc 2.17
work?
When building the Linux library with an alpine
image, muslc
might be an alternative to glibc
.
Yes, of course you can build from sources on your target system.
And then link it to your application.
Our pre-compiled binaries just help you get started quickly with the SDK.
We provide pre-build binaries only the most popular platforms.