[V3-02] C++20の配布互換性とnative build構成を検証する

[PyYoshi]

親トラッカー: #114

目的・成果物

sanitizerとDebugの分離、build preset、C++20機能と配布互換性の検証、規格採用の設計判断

実装先・順序

• 実装先: 両repository、別PR
• v3実装PRのbase: 対象repositoryのdev。Draft PRで作成する。
• Phase: 1
• 前提となる作業: [V3-01] 開発baseline・CI/Rules・新規ファイルのライセンス方針を確定する #115
• 新規実装のライセンスはV3-01で対象componentごとに決定する。

作業

• 規格更新と安全性refactor、algorithm変更を別PRにする。
• CMakeとCython/setuptoolsの両経路、最低対応OS/runtimeでwheelを検証しsdist要件を記録する。

完了条件

GCC/Clang/MSVCとApple Clang、CMakeとCython経由で検証。最低対応runtimeでwheelを実行しsdist要件も記録。V3-01に依存

• 対象の実装PR・設計判断へのリンクを記録する。
• 再現command、検証結果、必要なartifact hashを記録する。
• 未解決事項・既知の制約と、依存先への影響を明記する。

現在の実績（2026-09-21）

• GCC/Clang/AppleClang/MSVC、Debug/Release/sanitizerのnative build基盤。
• C++20 opt-inの30 wheel build/installed smoke（run 35513146332）。
• glibc 2.24上のx86_64全5 ABI、およびQEMU ARM64全5 ABIの既存wheel smoke。
• sdist tar.gzからの独立C++20再build、uv環境でのinstalled smoke、sdist要件の記録。
• span/concepts/ranges等の独立機能probe。GCC/AppleClang/MSVCと限定旧glibcで検証。
• 最低macOS・Windows runtimeでの実行。
• 新標準library機能を実wheelへ導入する際の配布条件確認・既定規格の採用判断。

ARM64は未確認ではなくQEMUで確認済み。ただしARM実機性能や現在のdev全体の再buildを保証しない。既定規格・最低対応条件は変更していない。

根拠: #130/#131/#134/#135/#137/#138/#147/#148。
C++20配布検証、最低runtime、ARM64検証、sdist。
#169ではnative #43/#44の通常reset比較と3OS shared lifecycle/export修正も統合した。最低runtimeでの実行とは別の検証。

追加検証：既存wheelの静的監査（2026-09-21）

• run 35513146332のmacOS/Windows各10 wheelをLLVMで静的検査。新規Actions・再buildなし。
• macOS: extensionのarchitectureと最低versionが全件wheel tagと一致（x86_64 cp311=10.9、cp312/313=10.13、cp314/314t=10.15、arm64=11.0）。
• Windows: win32/amd64のCOFF architectureとPython ABI別DLL参照を確認。PEのOS/subsystem 6.0を最低対応OSの保証とはしない。
• extensionの直接依存までの確認。最低OS上のimport/実行、同梱DLLの推移依存、最低CRTでの動作は未検証。

取得量5,356,582 bytes、artifactはGit管理外のarchives/v3-corpus/runtime-audit-macos-v1/とruntime-audit-windows-v1/に保存。再現command・artifact ID・詳細は静的監査記録。
次に必要なのは該当macOS/Windows・architecture・Python/CRTの実行環境。静的監査で元の最低runtime実行条件を代替せず、本Issueはopenを維持する。

[PyYoshi]

追加実装: #129（Draft/CI中）。CCHARDET_CXX_STANDARD=20 opt-in、standalone span/RAII probe、設定test10件、日本語の配布gate文書。通常のC++11/MSVC C++14は維持。GCC16でCython/native全62 compile行にC++20指定、独立uv wheel build/install/smoke成功。ローカルELF要求symbolはGLIBC2.14/GLIBCXX3.4.21/CXXABI1.3.9（manylinux互換性の証明ではない）。手動matrix定義はdevのみでdispatch未開通、masterを変更せず保留。他OS/manylinux/3.14tでのC++20配布検証は未完了なのでIssueはopenを維持。

[PyYoshi]

専用C++20 run35513146332が3 OS・計30 wheelsで成功しました。wrapper/nativeの規格引数とinstalled smoke、3.14tのGIL非有効化assertを確認。head87a69e3/merge71508b9を対象とした結果です。manylinux_2_24 tagへの適格性はauditwheelが認めましたが実行は2.28 container、macOS最低tag OSや旧Windows/最低CRTでの実行は未確認です。既定規格を変更せず残gateを日本語文書へ反映中です。

[PyYoshi]

追加進捗: uchardet #21を11 CI成功でdevへ統合しました。独立C++20 probeでspan/bit_cast/ranges/concepts/integer comparison/erase_ifを検証し、GCC13.3/libstdc++、AppleClang15/libc++、MSVC19.44/STL143で成功。既定規格は維持し、最低runtime gateとは区別しています。cChardet統合は #134（CI中）。現在、保存済みC++20 wheelのglibc2.24 smokeを準備しています。

[PyYoshi]

最低runtimeの追加実測: 既存C++20 wheel run35513146332のcp311/x86_64 wheelを、公式manylinux_2_24 image（digest a332ca25073bf71c6be54fe3c18e477418eedc194685f7263624ef4dfac91f9e）でoffline installし、既存wheel_smoke.pyが成功しました。実環境はglibc2.24 / CPython3.11.1。非root・networkなし・read-only containerで実施。初回は/tmp noexecによるmap失敗であり、専用の一時exec領域で再実行して成功。cp312以降/ARM64/最低macOS・Windowsの証拠ではなく、それらのgateは残します。手順とhashをdocs-only follow-upへ保存予定です。

[PyYoshi]

追加検証を #137 でdevへ統合しました。既存C++20 wheel run 35513146332のcp312/cp313/cp314/cp314tも、glibc 2.24 / libstdc++.so.6.0.22上でoffline installと既存smokeが成功しました。3.14tのGIL無効assertも成功。以前のcp311と合わせてx86_64全5 ABIを確認済みです。

公式manylinux2014の固定digestからinterpreterのみを移植し、新しいglibc/libstdc++は持ち込んでいません。SSL依存不足のためこの環境のTLS対応は保証せず、ネットワークなしの既存wheel検証に限定しています。

再現手順・wheel hash・image digest・制約: docs/v3-minimum-runtime.md。ARM64、最低macOS/Windows、追加C++20 library機能をwheelに入れた場合のruntime依存は未確認のため、このIssueはopenを維持します。既定規格変更なし。MarkdownのみでCI省略を確認済みです。

[PyYoshi]

標準機能側も #138 で追加記録しました。既存native tools/cxx20/features.cppを固定manylinux_2_28 image / GCC14.2.1でO0とO2の両方buildし、旧glibc2.24 imageで終了code 0。span/bit_cast/concepts/ranges/integer比較/erase_ifの小さなprobeです。readelfの要求symbolと旧runtime参照を確認しました。

source・image・binary hash、再現command、compile時header情報とruntime版の違いを docs/v3-minimum-runtime.md に記載。独立probeをwheelへ組み込んだわけではなく、新規標準機能を本体へ導入する際の実wheel検証は引き続き必要です。規格の既定化なし。docs-only CI省略を確認してdevへ統合済み。

[PyYoshi]

PR #147をdevへ統合。既存C++20 cp311 ARM64 wheelをQEMU 10.2.2と公式ARM64 glibc 2.24 imageで実行し、元smokeの全assert・CLI JSONが成功しました。旧ARM64 libc/libstdc++ロードも確認。hash、成功したrunner、コマンド、初回import-cache失敗、制約を日本語で公開しました。

これは実機・性能・他4 ABI・現在dev全体の再build検証ではありません。CLI子PythonへQEMUを明示する補助を使用。#116はopenを維持します。

https://github.com/PyYoshi/cChardet/blob/dev/docs/v3-arm64-runtime.md

[PyYoshi]

PR #148統合: ARM64 glibc 2.24 / QEMUでcp312・cp313・cp314・cp314tも元wheel smokeを終了code 0で通過しました。3.14tのGIL無効assertも成功。#147のcp311と合わせて5 ABIを確認。Pythonのみ公式固定imageから取り出し、新しいglibc/libstdc++は持ち込んでいません。

再現条件・wheel hash・警告・取得量は docs/v3-arm64-runtime.md に追記。実機、性能、最低macOS/Windowsの未完了条件は維持します。文書のみでCI追加起動なし。

[PyYoshi]

既存wheelの配布metadata監査（2026-09-21）

第3試作の承認待ちとは独立して、保存済みC++20 run 35513146332のmacOS/Windows各10 wheelをLLVMで静的確認した。新しいActions起動・再build・最低OSでの実行はしていない。

取得: wheels-macOS artifact 10606395031（1,902,703 bytes）、wheels-Windows 10606201134（3,453,879 bytes）、計5,356,582 bytes。Git管理外archives/v3-corpus/runtime-audit-macos-v1/とruntime-audit-windows-v1/へ保存。既存の取得予算内。

macOS

全10 wheelのextensionのMach-O architectureと最低versionはfilename tagと一致:

• x86_64 cp311: 10.9
• x86_64 cp312/313: 10.13
• x86_64 cp314/314t: 10.15
• arm64全5 ABI: 11.0
  SDKは全件26.5。extensionの直接依存libraryはlibSystem.B.dylibとlibc++.1.dylib。
  これは宣言の整合性であり、そのOSで必要symbolが利用可能であること・import成功の証明ではない。

Windows

win32全5件はCOFF-i386、win_amd64全5件はCOFF-x86-64。
extensionのPE OS/subsystem versionは全件6.0。この値だけでWindows 6.0を対応最低OSと解釈しない。Python/CRTの要件は別。
ABIに対応したpython311/312/313/314/314t.dll、VCRUNTIME140、UCRT API set等へ直接依存。amd64はVCRUNTIME140_1と__CxxFrameHandler4、win32は__CxxFrameHandler3を参照する。
msvcp140はrepair後のhash付きDLL名を参照。今回はextensionの直接importの観測であり、同梱DLLの推移依存や最低CRTでの動作確認とはしない。

再現

macOS: unzip -p WHEEL 'cchardet/*.so' | llvm-readobj --file-header --macho-version-min --needed-libs -
Windows: unzip -p WHEEL 'cchardet/*.pyd' | llvm-readobj --file-header --coff-imports -

最低macOS/Windows上の既存wheel実行という元の残条件は未完了。上記をその代わりにしてcloseしない。現行Linux環境での静的確認は進めたが、該当OS/CRT・Python・architectureの実行環境が次に必要。