Stream: git-wasmtime

Topic: wasmtime / issue #4848 libwasmtime.so is not available un...

Wasmtime GitHub notifications bot (Sep 02 2022 at 09:44):

soulbird opened issue #4848:

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

Wasmtime GitHub notifications bot (Sep 02 2022 at 09:51):

bjorn3 commented on issue #4848:

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.

Wasmtime GitHub notifications bot (Sep 02 2022 at 10:05):

soulbird commented on issue #4848:

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

Wasmtime GitHub notifications bot (Sep 02 2022 at 11:11):

bjorn3 commented on issue #4848:

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?

Wasmtime GitHub notifications bot (Sep 02 2022 at 11:46):

akirilov-arm commented on issue #4848:

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

Wasmtime GitHub notifications bot (Sep 02 2022 at 14:06):

alexcrichton commented on issue #4848:

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.

Wasmtime GitHub notifications bot (Sep 02 2022 at 14:16):

alexcrichton commented on issue #4848:

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

Wasmtime GitHub notifications bot (Sep 02 2022 at 19:28):

jameysharp commented on issue #4848:

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?

Wasmtime GitHub notifications bot (Sep 06 2022 at 02:51):

soulbird commented on issue #4848:

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?

Last updated: Nov 22 2024 at 16:03 UTC