fix: fix linux so link issue.

[cloudwebrtc]

Since rustc is not compatible with libwebrtc.a compiled from llvm clang, we must use gcc/g++ 14 to compile Rust-compatible static libraries. However, g++ 14 will force the GLIBC_USE_ISOC23 macro to be enabled, which forces linking to isoc23_xxx symbols. This causes some older Docker images (which do not support glibc_2.38) to fail to load ffi.so. This PR is used to fix this issue.

[Be-ing]

This causes some older Docker images (which do not support glibc_2.38) to fail to load ffi.so.

Ultimately, the only way to reliably prevent such issues is to build libwebrtc from source during the Cargo build process. I have made good progress towards that in #730. I also have some work-in-progress locally that I haven't pushed yet to create a source code archive that compresses down to a 101 MB .tar.xz file instead of the ridiculous 9 GB that gclient downloads. I do not think adding more patches to try to make a prebuilt library that works everywhere (which is impossible) is a good direction to go in.

[cloudwebrtc]

hey @Be-ing, It seems that you have made good progress. Can you try to use the libwebrtc.a compiled by chromium-llvm （maybe gnu) to compile liblivekit_ffi.so in x86 and arm64 linux respectively? It would be great if you can link it correctly.

[Be-ing]

I'll give that a try on x86-64. I don't have an ARM machine around to test with.

I do not think adding more patches to try to make a prebuilt library that works everywhere (which is impossible) is a good direction to go in.

To clarify, if this branch fixes a specific, immediate problem, I don't think it's necessarily bad to merge it, but not a good direction to continue on in general.

[cloudwebrtc]

Building entirely from libwebrtc source is suitable for users who use the rust-sdk directly. For users who use the python/node sdk and build AI agents on top of it, they need to be able to deploy by just running npm or pip to install. This requirement relies on pre-compiled binaries that support as many platforms as possible.

[Be-ing]

The prebuilt libwebrtc can stay as an option alongside building libwebrtc from source. I think building from source should be the default for webrtc-sys. Yes, the build time will be longer, but cargo build will work more reliably on a wider variety of systems. We can take care that gn/ninja invoke sccache if the user wants (the cc crate used under the hood by cxx_build already does use sccache or ccache). Also, packaging prebuilt binaries is a nonstarter for distros. It would be quite ugly for a packager to find webrtc-sys buried in an application's dependency tree doing that.

the python/node sdk

Do those call the Rust code in this repo or invoke libwebrtc's C++ APIs?

[cloudwebrtc]

Do those call the Rust code in this repo or invoke libwebrtc's C++ APIs?

The Python Node SDK actually relies on the precompiled liblivekit_ffi.so, which is then repackaged as a Py and Node.js API through ffi calls. These libraries do not directly call libwebrtc, and webrtc-sys is only used as a LiveKit ffi internal function set.

In Python or Node distributions, there are explicit download commands pointing to the corresponding binary links.
Such as this GitHub release link:
https://github.com/livekit/rust-sdks/releases/tag/rust-sdks%2Flivekit-ffi%400.12.35

[ladvoc]

LGTM ✅

[Be-ing]

Can you try to use the libwebrtc.a compiled by chromium-llvm （maybe gnu) to compile liblivekit_ffi.so in x86 and arm64 linux respectively? It would be great if you can link it correctly.

cargo build works fine for the livekit-ffi crate and successfully creates liblivekit_ffi.so. I tested with both the gnu and chromium-llvm toolchains in #730.