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.