libwebrtc_sys contains internally inconsistent MSVC CRT flags (/MT + /MD), causing LNK2038 on Windows

[AusAgentSmith]

When building a project that depends on libwebrtc_sys (via livekit_client) on Windows with MSVC, the linker fails with:

error: linking with `link.exe` failed: exit code: 1169
libwebrtc_sys-*.rlib(video_frame.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary':
  value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease'
  in libwebrtc_sys-*.rlib(c89f54398a9ca59a-apm.rs.o)

Root cause

The .rlib contains two categories of objects with conflicting CRT settings:

• C++ objects (e.g. video_frame.obj, candidate.obj, push_resampler.obj) — compiled with /MT (static CRT)
• Rust wrapper objects (e.g. apm.rs.o) — compiled with /MD (dynamic CRT)

MSVC's linker rejects mixed /MT+/MD within the same translation unit set. This is not a project configuration error — the mismatch is baked into the prebuilt library itself.

Affected revision

livekit-rust-sdks at 147fbca3d4b592d96d33f5e6a84b59fc0b5d9bf1 (as pinned by Zed industries in their fork).

Environment

Tested on:

• VS Build Tools 2022 (MSVC 14.44.35207) — Windows 10 26H2
• VS Build Tools 2026 (MSVC 14.50.35717) — Windows 10 26H2
• Rust 1.95.0 stable, x86_64-pc-windows-msvc
• Clean builds with no cached artifacts
• With and without -C target-feature=+crt-static (the flag Zed's .cargo/config.toml uses with the comment "This fixes the linking issue when compiling livekit on Windows" — it does not fix the issue at this revision)
• With and without a proper VS Developer environment (vcvarsall.bat amd64)

Workaround

Feature-gate livekit_client so it is excluded from builds that don't need LiveKit/WebRTC. The linker error is avoided entirely when libwebrtc_sys is not linked into the final binary.

Expected behaviour

The prebuilt WebRTC library objects should all use the same CRT linkage — either all /MT or all /MD, not a mix of both within the same .rlib.

[AusAgentSmith]

Update after investigation:

The WEBRTC_TAG (prebuilt binary) has changed between the affected revision and HEAD:

Commit	WEBRTC_TAG	GitHub Release
147fbca3 (Zed's pinned rev, broken)	webrtc-0001d84-4	Not found (404 — no GitHub release)
Current HEAD	webrtc-7af9351	Released 2026-03-31 with webrtc-win-x64-release.zip

The prebuilt used by the broken revision (webrtc-0001d84-4) doesn't appear to have a proper GitHub release, suggesting it was a development/test build that may not have been compiled with consistent CRT flags.

The new prebuilt (webrtc-7af9351, released 2026-03-31) has proper Windows assets. It's possible the CRT mismatch is already fixed in this revision — we'll test and report back. If confirmed fixed, this issue can be closed as resolved in webrtc-7af9351.

[AusAgentSmith]

Full version/prebuilt matrix:

livekit version	WEBRTC_TAG	CRT status
0.7.32	webrtc-0001d84-2	Broken (LNK2038)
0.7.33	webrtc-0001d84-2	Likely broken (same prebuilt)
0.7.35	webrtc-24f6822-3	Unknown — new prebuilt
0.7.37 (HEAD)	webrtc-7af9351	Likely fixed (properly released Windows assets)

The CRT mismatch is introduced by the webrtc-0001d84-2 prebuilt and appears fixed starting with webrtc-24f6822-3 (0.7.35+). The zed-industries fork (which Zed pins) is still on 0.7.32 / webrtc-0001d84-2.

Conclusion: Upgrading to webrtc-sys >= 0.7.35 should resolve the LNK2038 error. The webrtc-0001d84-2 prebuilt should be considered broken for MSVC builds.