fix(linux): give the compositor's build.rs its own freestanding-header fallback

[EtienneLescot]

Summary

cargo check -p openscreen-compositor --manifest-path crates/Cargo.toml fails on a stock Ubuntu box — x86_64 included, this is not an arm64 issue:

/usr/include/stdio.h:34:10: fatal error: 'stddef.h' file not found
thread 'main' panicked at compositor/build.rs:150:10:
bindgen a échoué sur les headers ffmpeg: ClangDiagnostic(...)

Ubuntu ships libclang.so.1 from the runtime package and its builtin header directory from libclang-N-dev. With only the former — the common case — clang has no freestanding headers of its own, and glibc's #include_next finds none.

scripts/build-linux-compositor-addon.mjs already worked around this by exporting BINDGEN_EXTRA_CLANG_ARGS, but that only ever covered the build going through the script; cargo on its own stayed broken. electron/native/pipewire-capture hit the same wall and solved it inside its build.rs precisely so a bare cargo build works too — its doc comment says as much. This ports that fix to the compositor.

Change	Why
crates/compositor/build.rs	Gains freestanding_header_args(). gcc vendor dir derived from CARGO_CFG_TARGET_ARCH, matched on the <arch>- prefix so Debian's x86_64-linux-gnu, arm64's aarch64-linux-gnu and Arch's x86_64-pc-linux-gnu all resolve, while a cross-gcc for the other architecture is refused (wrong type widths). Requires both limits.h and stddef.h. Defers to a non-empty caller-supplied value.
scripts/build-linux-compositor-addon.mjs	bindgenClangArgs() deleted.

Deleting the script's copy is load-bearing, not cleanup. build.rs defers to a non-empty caller-supplied BINDGEN_EXTRA_CLANG_ARGS, so if the script kept setting one, its guess would keep winning — including when it is the worse of the two. Leaving it would have made this fix inert on exactly the machines that need it.

Related issue

No existing issue — found while verifying #293.

Type of change

• Bug fix

Release impact

• Patch
• No release note needed

Build-time only; nothing in the shipped artifact changes.

Desktop impact

• Linux

The new code is gated on target_os == "linux". On macOS the sysroot comes from xcrun, on Windows from MSVC — neither path is touched, and scripts/build-linux-compositor-addon.mjs already exits early when process.platform !== "linux".

Screenshots / video

No visual change.

Testing

Ubuntu, x86_64, libclang-18 runtime only (no libclang-18-dev).

A/B on clean builds (cargo clean -p openscreen-compositor between each), BINDGEN_EXTRA_CLANG_ARGS unset:

build.rs	Result
current main	fatal error: 'stddef.h' file not found → panic
this branch	Finished

Script path — npm run build:native:compositor:linux, with BINDGEN_EXTRA_CLANG_ARGS unset: builds, stages the renamed ffmpeg libraries, copies the addon, and passes its own Verified: no unprefixed ffmpeg imports remain in the addon check.

Suite — npx vitest run → 141 files, 1694 passed, 1 skipped, 0 failed. biome check clean. cargo fmt --check shows no diff in build.rs (the deviations it reports are pre-existing in audio.rs / compositor_linux.rs on main).

Not verified on Windows or macOS locally — only the x86_64-unknown-linux-gnu target is installed here. The target_os == "linux" gate is the argument, and CI's windows-latest / macos build jobs are the check.

Note on #293

Rebased onto main after #293 merged. The expected conflict in scripts/build-linux-compositor-addon.mjs is resolved: bindgenClangArgs() is gone, and #293's MULTIARCH constant stays — resolveLibclangDir() still needs it for the library path, only the gcc-include half went away.

Deleting it also left a dangling doc reference in electron/native/pipewire-capture/build.rs, which pointed readers at bindgenClangArgs(). It now names its actual twin, freestanding_header_args() in crates/compositor/build.rs.

Re-verified after the rebase: clean cargo check with BINDGEN_EXTRA_CLANG_ARGS unset, npm run build:native:compositor:linux green through its unprefixed-symbol check, npx vitest run 142 files / 1698 passed / 0 failed, biome check clean.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@EtienneLescot, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 13 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: d9433d90-1d99-4d5b-882d-6e69df1f63f9

📥 Commits

Reviewing files that changed from the base of the PR and between 7c4827b and 55e19ee.

📒 Files selected for processing (3)

• crates/compositor/build.rs
• electron/native/pipewire-capture/build.rs
• scripts/build-linux-compositor-addon.mjs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}