wasmtime icon indicating copy to clipboard operation
wasmtime copied to clipboard

libwasmtime.so is not available under centos7 aarch64

Open soulbird opened this issue 3 years ago • 8 comments

We use v0.38.1 version of libwasmtime.so built the application under centos7 aarch64. When the program runs I get the following error:

wasmtime-c-api/lib/libwasmtime.so: symbol __cxa_thread_atexit_impl, version GLIBC_2.18 not defined in file libc.so.6 with link time reference

I tried to build libwasmtime.so from source using rust, and finally my program can run successfully.

I want to know what is the reason for this? Looking forward to any help from you

soulbird avatar Sep 02 '22 09:09 soulbird

When you compile a program or library on a system with a certain version of glibc, it will only run on systems that have at least this version of glibc due to symbol versioning. Wasmtime's CI has a newer version of glibc than CentOS 7 and as such anything compiled by Wasmtime's CI will not run on CentOS 7. Making it work would require building Wasmtime using CentOS 7 or another distro with an equal or older version of glibc.

bjorn3 avatar Sep 02 '22 09:09 bjorn3

I checked libc.so.6 on the machine, GLIBC_2.18 exists

[root@arm64-package]# strings /lib64/libc.so.6|grep 2.18

GLIBC_2.18
_mcount@@GLIBC_2.18

soulbird avatar Sep 02 '22 10:09 soulbird

https://github.com/shadowsocks/shadowsocks-rust/issues/609 suggests that the issue could be that you have multiple libc versions installed at the same time. What does ldd wasmtime-c-api/lib/libwasmtime.so show as path for libc.so.6? Is it the /lib64/libc.so.6 for which you checked that it is glibc 2.18, or something else like /lib/x86_64-linux-gnu/libc.so.6?

bjorn3 avatar Sep 02 '22 11:09 bjorn3

Also, you can try: nm -D --with-symbol-versions /lib64/libc.so.6 | grep __cxa_thread_atexit_impl

akirilov-arm avatar Sep 02 '22 11:09 akirilov-arm

This is the container that our binary builds are produced in which is using Ubuntu 16.04. I believe that's somewhat newer than Centos 7 which means our binary builds aren't compatible. Ubuntu 16.04 on arm64 reports glibc 2.23 and Centos 7 reports glibc 2.17.

The best fix for this would be to update the container to use a different toolchain, ideally a Centos 7-based one. I don't think many of us have experience with Centos 7 though so a PR to update the container would be appreciated.

alexcrichton avatar Sep 02 '22 14:09 alexcrichton

Oh also, for learning a glibc version, I use docker run ubuntu:16.04 ldd --version (or centos:7)

alexcrichton avatar Sep 02 '22 14:09 alexcrichton

There's an older fork of wasmtime's binary-compatibly-builds action in https://github.com/fastly/js-compute-runtime/tree/main/.github/actions/binary-compatible-builds, which I made a number of improvements to a while back. It'd be nice if those converged again.

I see that 08b7c877931a3da4cb73bd3c0961fd475c0e8a60 introduced the Ubuntu 16.04 containers for aarch64 and s390x, but we've been using Centos 7 on x86-64. Maybe copying the x86-64 Docker config to aarch64 would just work?

jameysharp avatar Sep 02 '22 19:09 jameysharp

I tried this command

nm -D --with-symbol-versions /lib64/libc.so.6 | grep __cxa_thread_atexit_impl

The result shows that the symbol __cxa_thread_atexit_impl does not exist. In addition, I am not good at glibc and compilation knowledge, so I may not be able to contribute relevant PR to complete the centos toolchain. So, do you currently have any plans to fix this or release a libwasmtime.so specifically for centos 7 aarch64?

soulbird avatar Sep 06 '22 02:09 soulbird