From c5fedd176f23a79f77bb3a60d4a986fd6a0d0901 Mon Sep 17 00:00:00 2001 From: Josh Knapp Date: Sun, 6 Sep 2026 23:07:04 -0700 Subject: [PATCH] docs: the -A x64 fix is confirmed; Windows now blocked on OBS's own CMake Updates the Windows record written in 551f782, which was accurate when written but has since been overtaken: the run it described as "in progress" (edb0c02, the first commit carrying the -A x64 fix) has now completed. The informative part is that the fix worked and Windows failed further along. obs-deps and Qt6 downloaded, CEF was skipped, the OBS sub-configure ran for 53s and correctly reported "Plugin Support" and "User Interface" disabled -- then failed at generate time: CMake Error at libobs/cmake/os-windows.cmake:46 (target_link_libraries): Target "libobs" links to: OBS::w32-pthreads but the target was not found. Traced at the 30.0.2 tag, and it does not appear to be anything this repo is doing wrong: - libobs/cmake/os-windows.cmake links OBS::w32-pthreads; - that target exists only in deps/w32-pthreads/CMakeLists.txt, reached only via deps/CMakeLists.txt; - deps/ is added only by the LEGACY branch of the top-level CMakeLists. The modern branch that -DOBS_CMAKE_VERSION=3.0.0 selects adds libobs, libobs-d3d11, libobs-winrt, libobs-opengl, plugins, test/test-input and UI -- never deps; - libobs/CMakeLists.txt adds only deps/libcaption and deps/uthash; - plugins/CMakeLists.txt returns immediately under ENABLE_PLUGINS=OFF, and does not add deps/ even when enabled. macOS is unaffected because its libobs does not link w32-pthreads, and at 30.0.2 the modern path was the default only on macOS -- consistent with the Windows side of it being under-exercised upstream. Deliberately NOT "fixed" here by bumping the pin: 30.0.2, 30.1.2, 30.2.3, 31.0.3 and 31.1.1 all still link OBS::w32-pthreads and none of them add deps/w32-pthreads from libobs/CMakeLists.txt, so a bump is not obviously the answer and needs checking rather than assuming. Three options are written up with the evidence behind each, so whoever picks this up starts from a diagnosis instead of from the error message. Everything else 551f782 said stands, including its caution not to treat either fix as confirmed without a green run -- the PowerShell rewrite is still queued and still unproven, and is marked as such. The CI table row and the top-level Status paragraph are updated to match; the licensing/release gate is untouched. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE --- README.md | 100 ++++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 75 insertions(+), 25 deletions(-) diff --git a/README.md b/README.md index dd189ef..3f7b764 100644 --- a/README.md +++ b/README.md @@ -29,13 +29,14 @@ real streamer-tools API shape, and pushes decoded frames into It has **not been run in the OBS GUI on any platform.** macOS builds the real module in CI but its artifact is not yet loadable (see the macOS packaging gap -under CI). Windows CI has **failed on every completed run so far** (7 -consecutive failures on this branch as of this writing); a run against the -commit with the `-A x64` argument fix is in progress but not yet complete, -and the commit with the PowerShell rewrite of the Windows steps is still -queued behind it. Neither fix has a completed, passing run yet. See "Where -the Windows bootstrap got to" under CI below for the exact record, and check -current CI status rather than trusting this paragraph's age. +under CI). Windows CI has **failed on every completed run so far**. The +`-A x64` argument fix is now confirmed working — the run carrying it got as +far as building libobs — but it exposed a deeper blocker: OBS 30.0.2's +opt-in modern CMake path never defines the `OBS::w32-pthreads` target its own +Windows libobs links against. The PowerShell rewrite of the Windows steps is +still queued and unproven. See "Where the Windows bootstrap got to" under CI +below for the trace and the options, and check current CI status rather than +trusting this paragraph's age. See "What is verified, and how" below for exactly what has and has not been checked, and "Testing this by hand" for what a human still needs to do. @@ -228,7 +229,7 @@ runners available to this repo under the `CyberCoveLLC` org. |---|---|---|---| | `linux` | `ubuntu-24.04` | `localhost.localdomain` | **Green.** Builds the real adapter against Ubuntu's libobs-dev 30.0.2, runs all six test suites, uploads `build/package` as an artifact | | `macos` | `macos-latest` | `home-mac` (Global) | **Green.** Builds libobs 30.0.2 from source, then the real adapter; 6/6 tests; artifact uploaded. But see the macOS packaging gap below | -| `windows` | `windows-latest` | `winvm-builder` (org-scoped) | **Failing** — 7/7 completed runs on this branch have failed; see below | +| `windows` | `windows-latest` | `winvm-builder` (org-scoped) | **Failing** — every completed run on this branch has failed. The latest gets as far as building libobs and stops on an OBS-side `OBS::w32-pthreads` target that its own modern CMake path never defines; see below | The Linux job is pinned to `ubuntu-24.04` rather than `ubuntu-latest`: this instance's two Linux runners answer `ubuntu-latest` with different releases, @@ -305,17 +306,63 @@ Windows is by far the slowest job — the `lukka/get-cmake` step alone takes pushes leaves a queue that takes an hour to drain. **The honest record: every completed Windows CI run on this branch has -failed. 7 consecutive failures**, at the 7 branch commits (in order) that had -a completed Windows run as of this writing -- all of them at commits before -the `-A x64` fix below was applied. As of this writing, a Windows run against -the commit with that fix is in progress but has not yet completed, and the -commit with the PowerShell rewrite is still queued behind it (the runner's -serial queue means fixed commits can sit behind older, unfixed ones for a -while). Do not read either fix below as "confirmed" until a Windows run -actually goes green on a commit that includes it; check current CI status -rather than trusting this paragraph's age. +failed.** The first 7 failures were all at commits predating the `-A x64` fix +below. The 8th, at `edb0c02` — the first commit that actually carries that fix +— has since completed, and it is the informative one: **the `-A x64` fix +worked, and Windows failed further along, on something else.** The PowerShell +rewrite is still queued behind it and remains unproven. Do not read either fix +below as "confirmed"; check current CI status rather than trusting this +paragraph's age. -Two bugs of its own were found and (believed, not yet proven) fixed: +What `edb0c02` showed: obs-deps and Qt6 downloaded, CEF skipped, the OBS +sub-configure ran for 53s and correctly reported "Plugin Support" and "User +Interface" disabled — then failed at generate time: + +``` +CMake Error at libobs/cmake/os-windows.cmake:46 (target_link_libraries): + Target "libobs" links to: + OBS::w32-pthreads + but the target was not found. +``` + +**That looks like a genuine hole in OBS 30.0.2's opt-in modern CMake path on +Windows, not something this repo is doing wrong.** Traced at the 30.0.2 tag: + +- `libobs/cmake/os-windows.cmake` links `OBS::w32-pthreads`; +- that target is defined only by `deps/w32-pthreads/CMakeLists.txt`, reached + only through `deps/CMakeLists.txt`; +- `deps/` is added only by the **legacy** branch of the top-level + `CMakeLists.txt`. The modern branch — the one `-DOBS_CMAKE_VERSION=3.0.0` + selects — adds `libobs`, `libobs-d3d11`, `libobs-winrt`, `libobs-opengl`, + `plugins`, `test/test-input` and `UI`, never `deps`; +- `libobs/CMakeLists.txt` adds only `deps/libcaption` and `deps/uthash`; +- `plugins/CMakeLists.txt` returns immediately under `ENABLE_PLUGINS=OFF`, and + does not add `deps/` even when enabled. + +macOS is unaffected because its libobs does not link w32-pthreads. At 30.0.2 +the modern path was the *default* only on macOS +(`if(CMAKE_HOST_SYSTEM_NAME MATCHES "(Darwin)" OR OBS_CMAKE_VERSION ...)`), +which is consistent with the Windows side of it being under-exercised +upstream. + +Deliberately **not** "fixed" by bumping the pin: 30.0.2, 30.1.2, 30.2.3, +31.0.3 and 31.1.1 were all checked, and every one still links +`OBS::w32-pthreads` from `libobs/cmake/os-windows.cmake` while none of them +add `deps/w32-pthreads` from `libobs/CMakeLists.txt`. A version bump is +therefore not obviously the answer and needs checking rather than assuming. +Options, roughly in order of preference: + +1. Work out how obs-plugintemplate's own Windows CI satisfies this target at + its 31.1.1 pin — it builds `obs-frontend-api` rather than `libobs`, which + may pull in a different subdirectory set. If so, building that target (and + accepting the Qt dependency on Windows only) is the smallest change. +2. Have the bootstrap add `add_subdirectory(deps/w32-pthreads)` to the + extracted OBS tree before configuring. Effective, but a patch against a + third-party tree that must be carried across pin bumps. +3. Drop the from-source libobs on Windows and find a prebuilt OBS SDK. + +Two bugs of its own were found; the first is now proven fixed by `edb0c02` +getting past it, the second is still unproven: 1. Upstream passes `-A x64,version=` to the OBS sub-configure, and with a current CMake that `,version=` suffix reappears verbatim in the @@ -328,13 +375,16 @@ Two bugs of its own were found and (believed, not yet proven) fixed: Unable to download .../windows-deps-2023-11-03-x64,version=10.0.26100.0.zip ``` - Plain `-A x64` now. + Plain `-A x64` now. **Confirmed fixed:** the `edb0c02` run got past this + and downloaded `windows-deps-2023-11-03-x64.zip` correctly. 2. The Windows CI steps were originally written in bash (via `shell: bash`), which is a poor fit for a `windows-latest` runner's - default toolchain expectations; they were rewritten in PowerShell. + default toolchain expectations; they were rewritten in PowerShell. **Still + unproven** — no completed run has included it. -Until a Windows run completes green with both fixes in place, Windows should -be treated as unverified beyond "the core library and the WinHTTP backend -compile and their tests pass", which earlier (failing-job) runs did show -before failing later in the job. Expect further iterations there of the same -kind the macOS bootstrap needed. +Until a Windows run completes green, Windows should be treated as unverified +beyond "the core library and the WinHTTP backend compile and their tests +pass", which earlier (failing-job) runs did show before failing later in the +job. The `w32-pthreads` blocker above is the next thing to solve, and it is +upstream's problem to work around rather than a defect in this repo's +bootstrap.