Skip to content

feat: support cross-compilation (tested for 32-bit ARM Linux)#194

Closed
ibrahim-mubarak wants to merge 1 commit into
livekit:mainfrom
ibrahim-mubarak:feat/cross-compile-support
Closed

feat: support cross-compilation (tested for 32-bit ARM Linux)#194
ibrahim-mubarak wants to merge 1 commit into
livekit:mainfrom
ibrahim-mubarak:feat/cross-compile-support

Conversation

@ibrahim-mubarak

Copy link
Copy Markdown

What

Makes the C++ SDK buildable with a CMake cross toolchain file. Verified end-to-end for 32-bit ARM Linux (armv7-unknown-linux-gnueabihf) targeting an embedded armv8 AArch32 (Cortex-A32, glibc 2.39) sysroot: liblivekit.so + liblivekit_ffi.so build, and livekit::initialize()/shutdown() round-trips through the FFI under qemu-arm.

Companion PR (Rust side / libwebrtc arm build): livekit/rust-sdks#1218

Changes

  • Honor a pre-set RUST_TARGET_TRIPLE: a cross toolchain file can now set it (cache var), and the cargo build gets --target plus the imported liblivekit_ffi.so path follows target/<triple>/. Previously the triple was only derived on macOS.
  • Scope cargo to -p livekit-ffi: the workspace has no default-members, so plain cargo build also compiled all examples (including wgpu-based ones) — wasted work natively, build failures when cross-compiling.
  • Cross-aware protoc: cmake/protobuf.cmake force-enabled protobuf_BUILD_PROTOC_BINARIES, producing a target-arch protoc that cannot run on the build host ("Exec format error" at codegen). When CMAKE_CROSSCOMPILING, protoc binaries are now skipped and a host protoc matching the vendored protobuf version must be passed via -DProtobuf_PROTOC_EXECUTABLE (official release binaries work). It is forwarded to the Rust build via ENV{PROTOC} as before.

Usage example

# toolchain-arm.cmake
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_SYSROOT /path/to/target-sysroot)
set(CMAKE_C_COMPILER   arm-...-gcc)
set(CMAKE_CXX_COMPILER arm-...-g++)
set(RUST_TARGET_TRIPLE armv7-unknown-linux-gnueabihf CACHE STRING "" FORCE)
cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_TOOLCHAIN_FILE=toolchain-arm.cmake \
  -DProtobuf_PROTOC_EXECUTABLE=/path/to/host/protoc   # v25.3
cmake --build build

(plus the usual cargo cross setup: rustup target add, linker in .cargo/config.toml, and LK_CUSTOM_WEBRTC pointing at a libwebrtc built with build_linux.sh --arch arm from the rust-sdks PR.)

No behavior change for native builds.

🤖 Generated with Claude Code

https://claude.ai/code/session_01L4fDRyTiTphQnidL2Myptq

Three changes needed to build the SDK with a CMake toolchain file for
a foreign target (verified with armv7-unknown-linux-gnueabihf against
an embedded armv8 AArch32 / Cortex-A32 sysroot):

- CMakeLists.txt: honor a RUST_TARGET_TRIPLE already set in the cache
  (e.g. by a cross toolchain file) instead of deriving it only for
  macOS; cargo then builds livekit-ffi with --target and the imported
  liblivekit_ffi.so location follows target/<triple>/.
- CMakeLists.txt: scope the cargo invocation to -p livekit-ffi. The
  workspace has no default-members, so a bare 'cargo build' also
  builds every example (including GPU-dependent ones) which is wasted
  work natively and fails when cross-compiling.
- cmake/protobuf.cmake: when CMAKE_CROSSCOMPILING, don't force
  protobuf_BUILD_PROTOC_BINARIES=ON — a cross-compiled protoc cannot
  run on the build host. Require a host protoc (matching the vendored
  protobuf version) via -DProtobuf_PROTOC_EXECUTABLE instead; it is
  also forwarded to the Rust build through ENV{PROTOC}.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L4fDRyTiTphQnidL2Myptq
@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@ibrahim-mubarak

Copy link
Copy Markdown
Author

Closing for now — will resubmit once ready.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants