Python 3.12 (apython312)

PowerPC Tiger向けにビルドしたCPython 3.12.11 + pipです。再配置可能（好きな場所に置けます）。 python.org公式ビルドではない個人ビルドです。調べた限り、Python 3.12とTigerの組み合わせに前例は見当たりませんでした（3.10/3.11はMacPorts/Tigerbrewコミュニティ経由でLeopard向けにありますが、 Tiger向けではありません）。

動作要件

• Mac OS X 10.4.x（Tiger）
• PowerPC G4（AltiVec）またはG5 — G3では動きません
• 空き容量 約200 MB

導入

1. apython312.dmgをマウントします。
2. install.commandをダブルクリックし、インストール先を選択します。

または.tar.bz2から: tar xjf apython312-3.12.11-macosx10.4-powerpc.tar.bz2 -C <展開先>

動くもの

pip / HTTPS（ssl） / sqlite3 / ctypes （ビッグエンディアンでの正常動作を確認済み） / lzma / bz2 / zlib / readline、Flask、Django（+ SQLite）。

動かないもの

• _tkinter（GUIライブラリは同梱していません）
• Rustを要するもの（cryptography>=3.4、orjson、ruffなど） — 必要な場合はcryptography<3.4にピン留めしてください。Djangoのコア機能に cryptographyは不要です。

C拡張を含むパッケージについて

純Pythonのパッケージは問題なく入ります。C拡張を含むものは、このマシンにビルド環境（Tigerbrew + GCC 14）が無いとコンパイルに失敗します。純Pythonフォールバックがあるもの（markupsafe等）は入りますが、無いものは入りません。numpy / scipy / Pillow / lxmlは標準では動かない前提でお願いします。

セキュリティ上の注意

Tiger自体はセキュリティ更新が提供されないOSです。同梱のOpenSSLは3.5.7と新しめですが、OSを含めた全体としては脆弱です。インターネットに公開するサーバや、重要な情報を扱う用途には使わないでください。ローカル開発・学習・LAN内での利用に留めてください。

ライセンス / 免責

スクリプトとパッチはMITライセンス、無保証です。同梱の共有ライブラリ（OpenSSL / SQLite / libffi / readline / gdbm / xz / zlib）はTigerbrew由来で、それぞれのライセンスに従います（readlineとgdbmは GPL-3.0）。

チェックサム（SHA-256）

ソース・ビルド手順・詳細な記録はGitHubにあります。 MacRumorsでも話題にしています。

このビルド（内部的にはapython312という名前です）は、4箇所にパッチを当てたCPython 3.12.11を、Tigerbrew由来のGCC 14ツールチェーンで、 Xcode 2.5から復元したTiger自身のヘッダに対してビルドしたものです。こう書くとあっさりしてますが、実際は「そこに辿り着くまで」がほとんどの作業でした。この実機の初期状態が想定以上に壊れていた、というのがこのページの本題です。

クロスコンパイルではなくネイティブビルド

出来上がるインタプリタはどちらにしても本物のPowerPCバイナリです — 「ネイティブ」か「クロス」かは単にコンパイラ自体がどこで動くかの違いでしかありません。CPythonのビルドシステムはネイティブビルド前提で、Darwin/PPCは現役でメンテされてるクロスコンパイルターゲットでもないので、クロスビルドを選ぶとconfigureとずっと戦う羽目になります。ここでは全部iBook本体上で動かしていて、 SSH越しにリモート操作しつつ、実際のコンパイル作業自体はG4本体がやっています。

CPythonにTiger向けに必要な4つのパッチ

4つとも構図は同じで、CPython 3.12は__APPLE__ターゲットなら当然あるはずだと決め打ちで使ってるAPIが、実際にはMac OS X 10.5か10.6になってから追加されたもの、というパターンです。 pthread_threadid_np()（10.6以降）はpthread_mach_thread_np()にフォールバック。<copyfile.h>/fcopyfile()（10.5以降）は、使われてる4箇所を#if 0で無効化。Tigerはデフォルトで__DARWIN_UNIX03が無効なため、 ttyname_rが現代の形式ではなく古いchar *を返す仕様になっていて、 posixmodule.c側はそこだけ素のttyname()を使うようにしています。 _scproxyは、まっさらなTiger環境には無いSystemConfiguration/CoreServices/ CarbonCoreのヘッダを要求してくる（Xcode 2.5のSDKから復元）んですが、単純に無効化することもできません。Darwinではurllib.requestが無条件でこれをimportするので。

そもそもツールチェーンが揃うところで詰みかけた

今回のiBookは、何年か前に部分的なシステム再インストールが行われた形跡があって、 /usr/includeの中身がたった2ファイルしか無く、/usr/libにも crt1.oやlibSystemStubs.aなど、普通のリンクに要るファイルが軒並み欠けていました。素のgccを叩くだけでld: can't locate file for: -lcrt1.o になり、Tigerbrew自身のソースビルドまで巻き添えで全滅してました。おまけに、Tigerbrewの配布済みビルド（bottle）は今どきのcctools/ld64でリンクされていて、Tiger標準の古い install_name_tool（cctools-576）ではそのMach-Oヘッダすら解釈できない（malformed object (unknown load command 11)）という鶏卵問題も抱えていました。新しいcctoolsを入れるには、そのcctools自身のbottleにも同じ問題がある、という状況です。

ビッグエンディアンが本当に動くことの検証

PowerPCはビッグエンディアンで、C拡張のコード（構造体のパッキング、バッファプロトコル、生バイトを直接触るもの）の中には、それを明言せずに暗黙にリトルエンディアン前提で書かれてるものが少なくありません。ビルドの検証には、実際にctypesを往復させるテストを使っています。C側の qsort()から、本物のPythonコールバックで要素を比較させながら [5,3,1,4,2]をソートさせて、結果がちゃんと[1,2,3,4,5]になることを確認する、というものです。これでlibffiのクロージャ（C側からPython側へコールバックする仕組み）が、このバイトオーダーで正しく動くことまで確認できます。単にインタプリタが起動するだけでは分からない部分です。

今後

numpy/scipy/Pillow/lxmlはまだ手を付けていません — それぞれ独自の移植作業が要る、重いC拡張です。上のまとめには載せきれなかった、いくつかの行き止まりも含めた壁ひとつひとつの記録は、GitHubの notes/obstacles.md にあります。

ソースコードはGitHubにあります。