LiteRTの「Windows向けwheelビルドエラー」を直す：GitHub ActionsがCancelledになる理由から、再現・修正・再発防止まで

LiteRT（TensorFlow Liteの後継として位置づけられるオンデバイス向けランタイム）の開発では、Python配布用の「wheel」を各OSで安定して作ることが重要です。ところがWindowsだけがコケる、もしくはCIが途中で止まってログが見えない――そんな場面は珍しくありません。実際に「Fix the build error in Windows wheel」というGitHub Actions実行（#9687）が走り、ステータスがCancelledになったケースも確認できます。 GitHub

本記事では、ノイズを排しつつ「なぜCancelledになるのか」「Windows wheelが壊れやすい典型原因」「LiteRTで起きがちな落とし穴（例：dlfcn.h問題）」「直し方の実務チェックリスト」を、手元のリポジトリですぐ使える形でまとめます。

• LiteRTの「Windows向けwheelビルドエラー」を直す：GitHub ActionsがCancelledになる理由から、再現・修正・再発防止まで
  • まず状況整理：Actionsが「Cancelled」になるのは“失敗”とは限らない
    • 実務的な見極め
  • Windows wheelが壊れやすい典型原因
    • 1) Windowsに存在しないヘッダ／APIを前提にしている
    • 2) wheel作成手順がOS差分に追随していない
    • 3) 「wheelが無い」→ソースからビルド→失敗、の連鎖
  • 「Fix the build error in Windows wheel」を本当に直すためのチェックリスト
    • A. まず再現性を作る（ローカル再現 or CI最小化）
    • B. Windows特有のコンパイル失敗を潰す
    • C. パッケージング（wheelタグと同梱ファイル）を固める
    • D. Cancelledでログが見えない問題への対処
  • まとめ：Windows wheelは「コードの移植性」と「配布の設計」を同時に整えると安定する

まず状況整理：Actionsが「Cancelled」になるのは“失敗”とは限らない

提示テキストの本質はここです。

• ワークフロー名：Fix the build error in Windows wheel. #9687

• トリガー：pull request

• 実行：copybara-service[bot] がPRをオープン

• ステータス：Cancelled

• 補足：**「より優先度の高い待機リクエストがあるためキャンセル」**という注釈

このパターンは、ビルドが壊れて落ちたというより「同じ種類のジョブが並んだので古い方を打ち切った」可能性が高いです。GitHub Actionsでは、同一ブランチや同一PRで更新が連続すると、後続の実行を優先して先行分をキャンセルする運用（concurrency相当）にしていることがよくあります。ログ閲覧がサインイン必須だと、外部からは“原因不明のキャンセル”に見えがちです。 GitHub

実務的な見極め

• Cancelledでも、直前のコミットで同じワークフローが成功していれば問題なし

• Cancelledが頻発し、常にWindowsだけが成果物（wheel）まで到達しないなら要調査

• まずはワークフロー側に「同一グループをキャンセルする」設定が入っていないか（あるいは意図通りか）を確認します

Windows wheelが壊れやすい典型原因

Windowsでwheelが落ちる理由は、大きく分けて「C/C++ビルド」「Pythonパッケージング」「依存解決」の3系統です。

1) Windowsに存在しないヘッダ／APIを前提にしている

LiteRT関連でも、dlfcn.h がWindowsに無いことが原因でビルドできない、という報告が実際にあります。 GitHub
Linux/macOSの「dlopen/dlsym」前提コードが混じっていると、Windowsではロード周りを LoadLibrary/GetProcAddress に分岐させる必要があります。

対策の方向性

• #ifdef _WIN32 で動的ロード実装を差し替える

• 可能なら「動的ロードを使わず静的リンク」へ寄せる（配布と検証が楽になるケースも）

2) wheel作成手順がOS差分に追随していない

LiteRTには「Python Wheel Packageをビルドする」公式ドキュメントがあり、CMake経由でwheelを作る流れが整理されています。 Google AI for Developers
ただし、この種の手順は“WindowsのMSVC・SDK・Python ABIタグ”の組み合わせが増えるほど崩れやすいです。

対策の方向性

• Windowsは MSVC（cl） を前提に統一し、clang等を混ぜない

• Pythonの対象バージョン（例：3.10/3.11/3.12）とアーキ（x64/arm64）をCIで明示し、成功組み合わせを固定する

3) 「wheelが無い」→ソースからビルド→失敗、の連鎖

pipは該当wheelが見つからないと、ソース配布からwheel生成を試みます。ここでビルド要件が揃っていないと失敗します。 Stack Overflow
依存側にWindows wheelが存在しない、あるいはPython最新に追随していないと、LiteRT本体以前に詰みます。

対策の方向性

• 依存のwheel提供状況（Windows対応・Python対応）を固定し、要件をピン留めする

• “Windowsではこの依存をオプション扱いにする”など、extras分離も検討する

「Fix the build error in Windows wheel」を本当に直すためのチェックリスト

ここからは、PRのタイトルが示すゴール（Windows wheelのビルド修正）に直結する実務項目です。

A. まず再現性を作る（ローカル再現 or CI最小化）

• CIのWindowsジョブだけを切り出した最小ワークフローを用意

• pip wheel . ではなく、プロジェクトが推奨するCMake/スクリプト経由に統一（LiteRTはwheel構築手順が整理されています） Google AI for Developers

B. Windows特有のコンパイル失敗を潰す

• dlfcn.h / unistd.h / pthread など、POSIX前提の混入を点検
  特にLiteRTで話題になった dlfcn.h は要注意です GitHub

• 文字コード・パス（長すぎるパス、スペース含む）で落ちる箇所がないか確認

• 生成物（.pyd/.dll）がどこに出て、wheelに同梱されているかを検証

C. パッケージング（wheelタグと同梱ファイル）を固める

• wheelのタグ（cp311-win_amd64 等）が意図通りか

• 依存DLLがwheelに入っていない、または余計なDLLが入っている、をチェック

• 成果物が無いときは「ビルド成功でもパッケージングで失敗」している可能性が高い

D. Cancelledでログが見えない問題への対処

今回のようにActions実行がCancelledになった場合、原因調査が進みません。 GitHub
運用面の対策としては次が効きます。

• concurrencyでキャンセルする運用なら、Windowsだけはキャンセルしない（優先度の調整）

• どうしてもキャンセルが起きるなら、ビルド途中でもログや中間成果物を出す（例えば「失敗時に必ず出る診断ログ」「依存解決結果の出力」など）

• Bot起票（copybara等）でPR更新が連発する場合は、ワークフロー起動条件（paths/labels）を絞って無駄打ちを減らす

まとめ：Windows wheelは「コードの移植性」と「配布の設計」を同時に整えると安定する

今回のテキストが示しているのは、Windows wheel修正の取り組みがCIで走りつつ、優先度制御によりCancelledになり得る、という現実です。 GitHub
本当に解決するには、(1) Windowsに無いAPI前提（例：dlfcn.h）を潰す GitHub、(2) LiteRTの推奨ビルド手順に寄せてwheel作成を固定する Google AI for Developers、(3) 依存のwheel事情まで含めて「ビルドできる世界線」を管理する Stack Overflow――この3点をセットで進めるのが近道です。

この順で整えると、Windowsだけが落ちる状態から「CIで毎回同じ手順で再現・修正できる」状態に移り、wheel配布の品質が一段上がります。