https://livekit.io logo
Join Slack
Powered by
hitting an ARM-only issue with <vscode-file://vsco...
# ask-ai
d
hitting an ARM-only issue with livekit-agents==1.5.1 / livekit==1.1.3 on a Debian Bookworm 
aarch64
container. The original worker error was 
ImportError: failed to load liblivekit_ffi.so: undefined symbol: __arm_tpidr2_save
, and reproduced it directly by calling 
rtc.AudioProcessingModule(...)
inside the container. 
ldd
is clean, but the shipped 
liblivekit_ffi.so
references 
__arm_tpidr2_save
and no system library provides it. Has anyone seen this on the 
manylinux_2_28_aarch64
wheel or know a compatible version/fix? This is happening after upgrading to 1.5.1 from 1.4.3
✅ 1
t
Thanks for reaching out, akshat. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’m sorry you’re hitting that ARM-only ImportError after upgrading. I’m responding to the part about the missing symbol 
__arm_tpidr2_save
from the bundled 
liblivekit_ffi.so
in the manylinux_aarch64 wheel and will help narrow whether this is a packaging/ABI mismatch or something in the container/toolchain. I don’t have details yet to confirm root cause, so please run the following diagnostics from inside the same Debian Bookworm aarch64 container where the error reproduces and share the outputs. These will tell us whether the wheel was built against an incompatible runtime or if the symbol is actually referenced incorrectly. 1. Exact wheel filename you installed (including platform tag) ◦ Example: 
ls -l /path/to/venv/lib/pythonX/site-packages | grep livekit_agents
◦ Or the pip install output that shows the filename. 1. Kernel / OS info ◦ uname -a 1. glibc / ldd version ◦ ldd --version 1. Python version/build ◦ python -c "import sys,platform; print(sys.version); print(platform.python_implementation(), platform.platform())" 1. Path to the installed package and the native library ◦ python -c "import livekit_agents, inspect; print(livekit_agents.file)" ◦ Then locate 
liblivekit_ffi.so
(likely under the package folder or 
.libs
) 1. Full ImportError traceback you see when calling 
rtc.AudioProcessingModule(...)
◦ Paste the full traceback (helps identify loader path). 1. Shared object inspection (run against the actual 
liblivekit_ffi.so
found above) ◦ readelf -sW /path/to/liblivekit_ffi.so | grep __arm_tpidr2_save ◦ nm -D /path/to/liblivekit_ffi.so | grep tpidr ◦ ldd -v /path/to/liblivekit_ffi.so 1. Container base image and any custom toolchain flags ◦ Which base image (e.g., 
debian:bookworm-slim
), and whether you used a custom build toolchain (custom GCC/clang, custom linker flags, cross-compile steps, or patched musl/glibc). 1. If you have the wheel file available, please provide the exact filename or a link to it (if you can share). If you prefer not to post the wheel publicly, say so and include just the filename and outputs above. What I’ll do once you send these: • Check whether the 
.so
actually references 
__arm_tpidr2_save
. • Confirm whether that symbol is expected for a particular compiler/toolchain (it’s often related to thread pointer access on some ARM toolchains). • Suggest immediate workarounds (e.g., downgrade to 1.4.3 which you said worked) and potential rebuild/packaging fixes depending on results. • If the outputs point to a packaging ABI mismatch, I will outline the exact fix steps or what we need to change in the wheel build. If any of those commands are difficult to run in your environment, tell me which ones you can run and I’ll adjust. Sources: Rust SDKs | livekit/livekit_composite | DeepWiki, with interactive elements
d
uname -a -> aarch64 GNU/Linux ldd --version ldd (Debian GLIBC 2.36-9+deb12u13) 2.36 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. python -c "import sys,platform; print(sys.version); print(platform.python_implementation(), platform.platform())" 3.13.11 (main, Feb 3 2026, 031420) [GCC 12.2.0] CPython Linux-6.17.0-1007-aws-aarch64-with-glibc2.36
t
Thanks — I see your container is aarch64 with glibc 2.36 and Python 3.13, and that you reproduce the error after upgrading to livekit-agents 1.5.1. I’m responding to the missing symbol 
__arm_tpidr2_save
from the bundled 
liblivekit_ffi.so
and will help narrow whether this is a packaging/ABI mismatch or something toolchain-related. To proceed I still need a couple more quick checks from inside the same container so I can confirm whether the wheel’s native library actually references that symbol and whether the runtime provides it. Please run and paste the outputs of these (short) commands: 1. Exact wheel / installed package info: ◦ python -c "import livekit_agents, os; print(livekit_agents.file); print(os.listdir(os.path.dirname(livekit_agents.file)))" 1. Locate the native .so and show its filename: ◦ find $(python -c "import livekit_agents, os; print(os.path.dirname(livekit_agents.file))") -type f -name "liblivekit_ffi.so" -print 1. Confirm the ImportError full traceback you get when you call 
rtc.AudioProcessingModule(...)
(copy-paste the whole traceback). 2. Inspect the .so for that symbol and its dynamic dependencies: ◦ readelf -sW /path/to/liblivekit_ffi.so | grep __arm_tpidr2_save || true ◦ nm -D /path/to/liblivekit_ffi.so | grep tpidr || true ◦ ldd -v /path/to/liblivekit_ffi.so (Replace /path/to/liblivekit_ffi.so with the path from step 2.) What I’ll look for in those outputs: • Whether 
liblivekit_ffi.so
actually exports/undefined-references 
__arm_tpidr2_save
. • Whether any linked library is expected to provide it (and whether that library is missing or incompatible). • Evidence of an ABI mismatch (wheel built against a different toolchain that emits that symbol). Immediate workarounds while we investigate: • Downgrade back to 1.4.3 (you mentioned it worked) to restore functionality. • If you can’t downgrade, running the same wheel on a different aarch64 image (for example older glibc or different distro) may help confirm a build vs runtime mismatch. If you’d prefer, paste the path to the .so and the traceback and I’ll analyze the outputs you provided and recommend next steps (build/packaging changes or a short-term workaround). , with interactive elements
d
Is there a compatibility issue with 1.5.1 version and ARM based machines?
t
Thanks — I’m responding to your direct question about whether livekit-agents 1.5.1 is incompatible with ARM machines (the ImportError for 
__arm_tpidr2_save
in 
liblivekit_ffi.so
). I do not have a confirmed, documented compatibility flag that says 1.5.1 is incompatible with aarch64. However, the error you described — an undefined symbol 
__arm_tpidr2_save
in the bundled 
liblivekit_ffi.so
— is consistent with an ABI/toolchain mismatch between how the wheel was built and the runtime in your container (toolchain emitted a reference the runtime’s C library doesn’t provide). What we can do next to confirm and resolve: 1. If you haven’t already, please provide the outputs I asked for earlier so I can verify the library references directly: ◦ Exact installed package path and files: ▪︎ python -c "import livekit_agents, os; print(livekit_agents.file); print(os.listdir(os.path.dirname(livekit_agents.file)))" ◦ Path to 
liblivekit_ffi.so
(use find as shown previously). ◦ Full ImportError traceback when calling 
rtc.AudioProcessingModule(...)
. ◦ Inspection of the shared object: ▪︎ readelf -sW /path/to/liblivekit_ffi.so | grep __arm_tpidr2_save || true ▪︎ nm -D /path/to/liblivekit_ffi.so | grep tpidr || true ▪︎ ldd -v /path/to/liblivekit_ffi.so 1. Short-term workaround: ◦ Downgrade to 1.4.3 (which you said worked) to restore functionality while we diagnose the root cause. 1. Likely causes and next steps if inspection shows the symbol is referenced: ◦ The wheel may have been built with a compiler/runtime that emits 
__arm_tpidr2_save
for thread-pointer access. That symbol may not exist in your glibc/toolchain combo. ◦ If the .so actually references that symbol, the fix will be either to rebuild the native extension with a toolchain compatible with manylinux_2_28_aarch64 expectations or to provide a build variant compatible with your runtime. ◦ After you send the requested outputs I’ll confirm whether the .so references the symbol and which linked library (if any) should supply it, then outline precise build/package changes or a recommended wheel to use. If you paste the path to the .so plus the readelf/nm/ldd outputs and the ImportError traceback here, I’ll analyze them and give a concrete recommendation (rebuild flags, packaging change, or a specific workaround). , with interactive elements
2 Views
Open in Slack
PreviousNext
Powered by