この記事はPHP Advent Calendar 2020の19日目です。18日目は@You-sakuさんのPHPでYoutubeのAPIを利用したいでした。
私は以前、PHPのすべてのバージョンを使う環境として、phpall、phpcgiall、modphpallを紹介してきました。これらは、PHPのすべてのバージョンをそれぞれコマンドライン、CGI、mod_phpの形式で動作させるものです。
現在では、PHPのバージョンを切り替えて動作させる仕組みはphpenv、phpbrew等何種類もありますし、php-buildという、PHPをビルドするというそのものずばりの仕組みも広く使われています。
しかし、短いPHPスクリプトをPHPの全バージョンで試すという私の使用法からは、phpall（およびその派生としてphpcgiall、modphpall）はメリットがあり、私は今もPHPのビルドを続けています。
そう、私は今も、PHPのすべてのバージョンのバイナリをCLI、CGI、Apacheモジュールの形式で持っているのです。そして、元々は目的があって始めたことなのですが、いまや、「PHPのすべてのバージョンをコンプする」こと自体が目的化してしまっています。この感覚、何かに似ているなと思い返したら…そうです。ポケモンを集めるような感覚なのです。いまや、
徳丸にとってPHPはポケモン
と言っても過言ではありません。
PHPがポケモンだという主張は認めていただくとして、PHPにもポケモン同様にレアキャラがあるでしょうか…
あります。ビルドが困難であればあるほど、レアなポケモン（に相当するPHP）と言ってよいでしょう。
経験上、以下の条件を満たすPHPがレアな（ビルドが困難な）ものと言えます。
- 古いバージョンのPHP（PHP4、PHP5.0、5.1、PHP5.2等）
- 新しい環境で動く（Ubuntu 20.04等）
- できるだけ多くの拡張モジュールを備える
- 32ビット版よりも64ビット版
以下、その理由を簡単に説明しましょう。
古いバージョンのPHP
次の項と関連しますが、古いPHPはビルドすること自体が困難です。その一端は@hnwさんの以下の記事で読むことができます。
古いPHPがビルドが困難な理由は以下の通りです。
- Cコンパイラの新バージョンでは文法チェックが厳しくなった結果、コンパイルエラーになりコンパイルできない
- PHPが利用するライブラリの非互換なバージョンアップ
これらの回避策としては以下が考えられます。
- 古いコンパイラ（gcc）を使う
- コンパイルエラーを緩和するオプションを設定する
- 古いライブラリを使う
- PHPにパッチをあてる
最終的にはPHPにパッチをあてざるを得ない場合もありますが、これはできれば避けたいところです。新しいgccでコンパイルエラーになる箇所を見ていると「これ、単にバグじゃないか」と思うものが多い（それ以外ではライブラリの非互換）のですが、他の方法で回避できるのであれば回避したい…ということで、古いgccを試したりしましたが、今は以下のgccのオプションで回避して、最低限PHPソースにパッチをあてています。
-std=gnu89-fgnu89-inline
ライブラリも結構ハマるところでして、以下は複数のバージョンを使っています。
- zlib（1.1.4、1.2.11）
- openssl（0.9.8、1.1.1）
- curl（7.15.0、7.16.0、7.68.0、7.72.0）
- libxml2（2.7.8、2.9.8、2.9.10）
意外にハマるのがcurl（libcurl）でして、非互換なバージョンアップのため、PHPのバージョンによってcurlのバージョンも変える必要がありました。
新しい環境で動く
前項の裏返しになりますが、新しい環境（OS）であるほど、古いPHPをビルドすることが困難になります。特にライブラリの非互換は避けようのないところで、OS（Linuxディストリビューション）にバンドルされているライブラリでうまくビルドできない場合は、古いライブラリを探してきてビルドすることから始めなければなりません。ライブラリ毎にビルド方法に癖があったりして苦労する場合もありますが、そこがまた楽しいのです。
できるだけ多くの拡張モジュールを備える
前項と関連しますが、できるだけ多くの拡張モジュールを指定した方がビルドの難易度が上がります。OSにバンドルされていないライブラリや、バンドルはされているが非互換のため古いライブラリを別途導入しないケースはなおさらです。
32ビット版よりも64ビット版
意外なことを書くと思われるかもしれませんが、古いPHP（4.1、4.2あたり）はAMD64でのビルドが困難です。ビルド自体はできるのですが、正常に動作しません。この時代はまだAMD64の現物がなかった（AMD64の出荷は2003年4月）からと思われます。PHP 4.0はビルドでき動作もするので、調整すればPHP 4.1や4.2も動作すると思うのですが、私はまだ成功していません。
phpallをUbuntu16.04(32ビット)からUbuntu20.04(64ビット)に移行
さて、著者はphpallの環境を当初Ubuntu12.04(32ビット)に構築し、その後Ubuntu16.04(32ビット)に移行していましたが、PHP 8.0α版が出た際にUbuntu20.04(64ビット)に移行しました。
そのきっかけとなったのは、PHP 8.0から導入されたJITを試そうとして時のことです。どうもx86（32ビット）では、JITは使えないようなのです。下図はphpinfoからの該当部分です。
JITのRFCではx86もサポートされていると書かれていましたが、本番投入は見送られたのでしょうか。私は、phpallを64ビット環境に移す決断をしました。以下はUbuntu20.04(64ビット)でのphpinfoで、JITが有効化できていることがわかります。
残る課題
楽しみとしてのPHPビルドについて紹介しましたが、現状課題が残っています。前述のように、64ビット環境でのPHP4.1と4.2のビルドには成功していないからです。ここは私の技術の至らなさではあるのですが、将来の楽しみにとっておこうと思います。やり方をご存知の方がいれば教えていただけるとありがたいです。
0 件のコメント:
コメントを投稿