windows vcpkg support #25

Sqhh99 · 2025-12-29T15:33:05Z

This PR adjusts the build configuration to handle platform-specific dependency management. #23

Initially, I tried using vcpkg for protobuf and abseil on all platforms. However, I encountered a few issues:

The SDK produces static libraries (livekit.lib and livekit_ffi.lib). When testing on WSL, I found that users need to link the exact protobuf and abseil versions used during build. On Windows, there's an additional complication: the webrtc-sys crate in client-sdk-rust uses pre-built static libraries with /MT runtime (see config.toml: target-feature=+crt-static). If livekit.lib also uses /MT, any application using /MD runtime will encounter linking conflicts. Since most Windows applications and frameworks use /MD by default, I changed livekit_ffi to a DLL to isolate the /MT dependency, allowing livekit.lib to use /MD safely.

Linux and macOS don't have the /MT vs /MD distinction. Also, vcpkg's library versions don't match what system package managers provide, making it impractical to bundle everything. It's much simpler for users to just install protobuf and abseil via apt or brew.

The current approach:

Platform	Dependencies	Distribution
Windows	vcpkg	Bundled DLLs
Linux	apt	Static lib only
macOS	Homebrew	Static lib only

Using the SDK:

Windows: Link livekit.lib and livekit_ffi.dll.lib, copy the DLLs to your executable directory
Linux: Install libprotobuf-dev and libabsl-dev via apt, then link liblivekit.a and liblivekit_ffi.a
macOS: Install protobuf and abseil via brew, then link liblivekit.a and liblivekit_ffi.a

I'm not sure if this is the best solution, but Windows lacks a system package manager, so bundling dependencies seems necessary for a usable distribution.

Windows output structure:

build/
├── include/livekit/          # Headers
├── lib/windows-x64/release/
│   ├── livekit.lib           # Main library
│   ├── livekit_ffi.dll       # FFI runtime
│   ├── libprotobuf.dll       # Protobuf runtime
│   └── abseil_dll.dll        # Abseil runtime
└── bin/release/              # Examples

The CI now builds and runs examples on all platforms to verify the libraries work correctly.

livekit.vcxproj -> D:\workspace\lib-workspace\client-sdk-cpp\build\Release\livekit.lib SimpleDataStream.vcxproj -> D:\workspace\lib-workspace\client-sdk-cpp\build\examples\Release\SimpleDataStream.exe SimpleRoom.vcxproj -> D:\workspace\lib-workspace\client-sdk-cpp\build\examples\Release\SimpleRoom.exe SimpleRpc.vcxproj -> D:\workspace\lib-workspace\client-sdk-cpp\build\examples\Release\SimpleRpc.exe Build Succeeded.

- Fix "file path too long" errors by switching from CMAKE_SOURCE_DIR to CMAKE_CURRENT_SOURCE_DIR for relative path resolution. - Refactor CMakeLists.txt to support nested project usage via LIVEKIT_IS_TOPLEVEL check. - Align MSVC runtime library with Rust static CRT (MultiThreaded) to prevent link-time conflicts. - Implement unified binary output directory (bin/lib/include) with config-specific subfolders. - Add robust cargo build integration using run_cargo.cmake script. - Introduce install logic and full clean targets (clean_all).

- Added CMakePresets.json for unified cross-platform build configurations. - Optimized Rust FFI build logic to prevent unnecessary recompilation when C++ code changes. - Fixed MSVC runtime library (MT/MD) mismatch on Windows. - Added automatic header aggregation to build/include directory. - Refactored CMakeLists.txt to support both top-level and subdirectory integration.

…cies - Add GitHub Actions workflow for Windows, Linux, and macOS - Integrate vcpkg manifest mode with CMake Presets - Fix missing Linux dependencies (libva, alsa, libclang, etc.) - Add CXXFLAGS to ignore deprecated warnings from WebRTC on newer GCC - Synchronize git submodules and fix protocol file paths - Configure build.h template for build metadata injection

- Remove livekit_ffi.h inclusion from public participant.h - Add livekit_ffi.h to room.cpp for internal access to INVALID_HANDLE - Improve header encapsulation by hiding internal FFI definitions from SDK users

…T conflicts Motivation: The prebuilt libwebrtc library is strictly compiled with the /MT runtime, causing severe symbol redefinition and runtime mismatch errors (LNK2038) when linked against /MD-based Qt applications. Changes: 1. Architecture Redesign: Refactored livekit-ffi to build as a shared library (cdylib/DLL) instead of a static library on Windows. 2. Binary Isolation: Leveraged the DLL boundary to encapsulate /MT dependencies, allowing the consumer layer (livekit.lib) to safely use /MD. 3. CMake Infrastructure Enhancements: - Explicitly set CMAKE_MSVC_RUNTIME_LIBRARY to MultiThreadedDLL for MSVC targets. - Automated the Rust build pipeline with PROTOC environment variable injection for protobuf generation. - Added POST_BUILD commands to automatically deploy livekit_ffi.dll and third-party dependencies (protobuf, abseil) to the output directory. 4. Platform Consistency: Maintained the original static linking logic for Linux and macOS to preserve performance and simplicity. Verification: Validated the generated livekit.lib using `dumpbin /DIRECTIVES`, confirming the RuntimeLibrary is correctly set to MD_DynamicRelease.

- Automatically copy libprotobuf.lib and abseil_dll.lib to SDK lib

- Replace protobuf_generate with custom add_custom_command - Use --proto_path to ensure correct symbol naming - Linux/macOS use system protobuf (apt/brew) - Windows uses vcpkg - Update documentation for platform-specific dependencies

- Add include paths for all examples (src/, generated/, protobuf) - Copy DLLs to examples output on Windows - Use FetchContent for SDL3 on all platforms - Remove sdl3 from vcpkg.json (not in baseline)

- Add debug-examples and release-examples commands - Update usage help text

xianshijing-lk · 2025-12-30T05:41:55Z

Great work. I was also hit by the MT / MD issues, the problem seems to be some pre-built libs are using MT and it will cause symbol conflicts, I suspect it was libwebrtc but didn't get time to verify it.

I like your approach of workaround the problem:

I changed livekit_ffi to a DLL to isolate the /MT dependency, allowing livekit.lib to use /MD safely.

xianshijing-lk

from a quick look. Thanks, they are solid code.

xianshijing-lk · 2025-12-30T05:53:01Z

.github/workflows/builds.yml

        run: |
-          [[ -x build.sh ]] && ./build.sh clean-all || true
+          if [[ "$RUNNER_OS" == "Windows" ]]; then
+            rm -rf build || true


I am not sure if it is enough to remove the build folder ? I think "./build.sh clean" also does the "cd client-sdk-rust; cargo clean;"

xianshijing-lk · 2025-12-30T06:03:33Z

.github/workflows/builds.yml

-        run: |
-          ./build.sh release
+      - name: Configure CMake
+        run: cmake --preset ${{ matrix.preset }}


I really like adding the preset.

But I wonder if we should do build.sh on Unix and build.cmd on windows ? so that the CIs and developers are using the same development cmds. What do you think?

xianshijing-lk · 2025-12-30T06:04:47Z

CMakeLists.txt

+cmake_minimum_required(VERSION 3.20)
+
+if(NOT DEFINED LIVEKIT_VERSION OR LIVEKIT_VERSION STREQUAL "")
+  set(LIVEKIT_VERSION "0.1.0")


nit, just use 0.0.0 as default. once your PR is landed, I would like to make the first release.

xianshijing-lk · 2025-12-30T06:11:17Z

CMakeLists.txt

-  TARGET livekit_proto
-  PROTOC_OUT_DIR ${PROTO_BINARY_DIR}
-  IMPORT_DIRS ${FFI_PROTO_DIR}
+# Manually generate protobuf files to avoid path prefix issues


Interesting. I am curious what path prefix issues you met. The protobuf worked out of box for me after I installed the protobuf via vcpkg, but likely my workspace wasn't cleaned at all.

xianshijing-lk · 2025-12-30T06:13:24Z

CMakeLists.txt

+  add_custom_command(
+    TARGET build_rust_ffi
+    POST_BUILD
+    COMMAND ${CMAKE_AR} -dv "${RUST_LIB_RELEASE}" protozero_plugin.o


you will need to rebase my latest change in #21, otherwise the debug build will fail on Linux as it is looking for ${RUST_LIB_RELEASE}

xianshijing-lk · 2025-12-30T06:25:40Z

CMakePresets.json

+      "displayName": "Windows x64 Debug",
+      "description": "Build for Windows x64 Debug (vcpkg)",
+      "inherits": "windows-base",
+      "binaryDir": "${sourceDir}/build"


should release and debug have different binaryDir ?
like ${sourceDir}/build-release
${sourceDir}/build-debug ?

xianshijing-lk · 2025-12-30T06:26:06Z

CMakePresets.json

+      "displayName": "Linux Release",
+      "description": "Build for Linux Release (system packages)",
+      "inherits": "linux-base",
+      "binaryDir": "${sourceDir}/build",


same for Linux and Mac

xianshijing-lk · 2025-12-30T06:28:07Z

CMakePresets.json

+      }
+    },
+    {
+      "name": "windows-release",


is it intentional to have windows-release and windows-debug to be the same ?

if they should be the same, should we just use one windows rather than 2 ?

xianshijing-lk · 2025-12-30T06:33:34Z

build.cmd

+
+:build_only
+echo ==^> Building (%BUILD_TYPE%)...
+cmake --build "%BUILD_DIR%" --config %BUILD_TYPE% -j %VERBOSE%


do we need the -j on windows ?

if VERBOSE is empty, will it work ? I am not sure, but doubt if "cmake --build ... -j" is valid

xianshijing-lk · 2025-12-30T06:34:27Z

build.cmd

+
+if "%1"=="debug-examples" (
+    set "BUILD_TYPE=Debug"
+    set "PRESET=windows-debug-examples"


I only see windows-release-examples, do we need windows-debug-examples here ?

Sqhh99 added 20 commits December 23, 2025 06:11

Build Success - Stable Version

3d13932

Merge remote-tracking branch 'upstream/main'

5f5b0e7

refactor: decouple ffi headers from public headers

daa0a7c

- Remove livekit_ffi.h inclusion from public participant.h - Add livekit_ffi.h to room.cpp for internal access to INVALID_HANDLE - Improve header encapsulation by hiding internal FFI definitions from SDK users

Automatically copy dependency libraries to the lib directory

2bd6aac

feat: add build.cmd with auto libclang detection for Windows

7f998e7

chore: cleanup unnecessary files and update .gitignore

4a68e47

feat: copy essential .lib files for developer distribution

0d324e4

- Automatically copy libprotobuf.lib and abseil_dll.lib to SDK lib

feat: use vcpkg only on Windows, system packages on Linux/macOS

a6ee159

fix: explicitly find protoc for macOS compatibility

d8a16f5

ci: add examples building and testing to all platforms

fc6490c

fix: complete cross-platform examples build support

f03e3a0

- Add include paths for all examples (src/, generated/, protobuf) - Copy DLLs to examples output on Windows - Use FetchContent for SDL3 on all platforms - Remove sdl3 from vcpkg.json (not in baseline)

feat: add examples building support to build scripts

ff6458e

- Add debug-examples and release-examples commands - Update usage help text

fix: improve smoke tests to detect startup failures on all platforms

577f22c

fix: use System.Diagnostics.Process for Windows smoke test

2fe6e8b

Sqhh99 changed the title ~~Sqhh99/windows vcpkg support~~ windows vcpkg support Dec 29, 2025

xianshijing-lk reviewed Dec 30, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

windows vcpkg support #25

windows vcpkg support #25

Sqhh99 commented Dec 29, 2025 •

edited

Loading

Uh oh!

xianshijing-lk commented Dec 30, 2025

Uh oh!

xianshijing-lk left a comment

Uh oh!

xianshijing-lk Dec 30, 2025

Uh oh!

xianshijing-lk Dec 30, 2025

Uh oh!

xianshijing-lk Dec 30, 2025

Uh oh!

xianshijing-lk Dec 30, 2025

Uh oh!

xianshijing-lk Dec 30, 2025

Uh oh!

xianshijing-lk Dec 30, 2025

Uh oh!

xianshijing-lk Dec 30, 2025

Uh oh!

xianshijing-lk Dec 30, 2025

Uh oh!

xianshijing-lk Dec 30, 2025

Uh oh!

xianshijing-lk Dec 30, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

windows vcpkg support #25

Are you sure you want to change the base?

windows vcpkg support #25

Conversation

Sqhh99 commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xianshijing-lk commented Dec 30, 2025

Uh oh!

xianshijing-lk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Sqhh99 commented Dec 29, 2025 •

edited

Loading