From a65bb9609284d273f0aa232dbaf69597c87f5a12 Mon Sep 17 00:00:00 2001 From: nsfisis Date: Sun, 15 Jun 2025 13:12:46 +0900 Subject: feat(blog/nuldoc): merge consecutive text nodes --- .../compile-php-runtime-to-wasm/index.html | 40 +++++++++++----------- 1 file changed, 20 insertions(+), 20 deletions(-) (limited to 'vhosts/blog/public/posts/2023-10-02/compile-php-runtime-to-wasm') diff --git a/vhosts/blog/public/posts/2023-10-02/compile-php-runtime-to-wasm/index.html b/vhosts/blog/public/posts/2023-10-02/compile-php-runtime-to-wasm/index.html index c17bc163..bd286a6d 100644 --- a/vhosts/blog/public/posts/2023-10-02/compile-php-runtime-to-wasm/index.html +++ b/vhosts/blog/public/posts/2023-10-02/compile-php-runtime-to-wasm/index.html @@ -101,7 +101,7 @@

本記事のゴール

- 先にこの記事のゴールを示しておく。これから示す手順のとおりに進めると、次のようなコードが動くようになる。 このコードはこのあと使うので、index.mjs の名前で保存しておくこと。 + 先にこの記事のゴールを示しておく。これから示す手順のとおりに進めると、次のようなコードが動くようになる。このコードはこのあと使うので、index.mjs の名前で保存しておくこと。

@@ -161,10 +161,10 @@ ほとんどはただの PHP の公開 API を使ったコードだが、Emscripten 向けの注意点が 2点ある。

- まずは EMSCRIPTEN_KEEPALIVE について。 これは Emscripten が用意している特殊なマクロである。 このマクロが付与されている関数は、どこからも使用されていなくともコンパイル後の WebAssembly バイナリから削除されない。 もしこれを付け忘れると、未使用の関数とみなされ削除される。 + まずは EMSCRIPTEN_KEEPALIVE について。これは Emscripten が用意している特殊なマクロである。このマクロが付与されている関数は、どこからも使用されていなくともコンパイル後の WebAssembly バイナリから削除されない。もしこれを付け忘れると、未使用の関数とみなされ削除される。

- 次に、コードを評価したあとに呼んでいる標準出力と標準エラー出力に対する改行の出力について。 出力バッファから出力させるためだけなら改行を出力させなくとも fflush() だけで事足りると考えたのだが、ないと動かなかったので追加した。 これにより、PHP コードの出力の後ろに余分な改行が追加されてしまう。 改行を出力せずともバッファを消費させる手段をご存知のかたはご教示願いたい。 + 次に、コードを評価したあとに呼んでいる標準出力と標準エラー出力に対する改行の出力について。出力バッファから出力させるためだけなら改行を出力させなくとも fflush() だけで事足りると考えたのだが、ないと動かなかったので追加した。これにより、PHP コードの出力の後ろに余分な改行が追加されてしまう。改行を出力せずともバッファを消費させる手段をご存知のかたはご教示願いたい。

@@ -172,7 +172,7 @@

- fflush() の前に改行の出力が必要だった理由が判明したので追記する。 これは、index.mjs で標準出力・標準エラー出力へ出力する方法を指定せず、デフォルトの実装に任せているため。 Emscripten のデフォルト実装では、改行コードを出力するまで出力内容がバッファリングされ、fflush() が機能しない。 + fflush() の前に改行の出力が必要だった理由が判明したので追記する。これは、index.mjs で標準出力・標準エラー出力へ出力する方法を指定せず、デフォルトの実装に任せているため。Emscripten のデフォルト実装では、改行コードを出力するまで出力内容がバッファリングされ、fflush() が機能しない。

デフォルトの出力方法は index.mjs の中で PHPWasm() を呼ぶとき、stdout・stderr というオプションを渡せば変更できる。 @@ -209,7 +209,7 @@ 

FROM emscripten/emsdk:3.1.46 AS wasm-builder

- 次に、 php/php-src から PHP 処理系のソースコードを取得し、ビルドに必要な apt パッケージを取ってくる。 有効にする拡張を増やしたいなら、ここでインストールするパッケージも増やすことになるだろう。 + 次に、 php/php-src から PHP 処理系のソースコードを取得し、ビルドに必要な apt パッケージを取ってくる。有効にする拡張を増やしたいなら、ここでインストールするパッケージも増やすことになるだろう。 

RUN git clone --depth=1 --branch=php-8.2.10 https://github.com/php/php-src
@@ -254,22 +254,22 @@
                 ここまでと比べると少し複雑なので、それぞれ詳しく見ていこう。
               

               

-                まず、buildconf は PHP 処理系をビルドするときに (Emscripten とは関係なく) 使うツールである。 このツールの最も重要な仕事は、configure の生成である。
+                まず、buildconf は PHP 処理系をビルドするときに (Emscripten とは関係なく) 使うツールである。このツールの最も重要な仕事は、configure の生成である。
               

               

-                次に configure するわけだが、ここで emconfigure を使う。 これを使うことで、Emscripten が上手く諸々のツールチェインを WebAssembly のビルド向けに調整しながら configure してくれる。
+                次に configure するわけだが、ここで emconfigure を使う。これを使うことで、Emscripten が上手く諸々のツールチェインを WebAssembly のビルド向けに調整しながら configure してくれる。
               

               

-                configure の後ろに指定してあるフラグは、通常の PHP 処理系のビルドで使う configure と同じなので、詳しくはそちらの cofigure --help を参照していただきたい。 ほとんどは、機能の無効化のために指定している (依存するライブラリを減らし、ビルドをより簡単にするため)。
+                configure の後ろに指定してあるフラグは、通常の PHP 処理系のビルドで使う configure と同じなので、詳しくはそちらの cofigure --help を参照していただきたい。ほとんどは、機能の無効化のために指定している (依存するライブラリを減らし、ビルドをより簡単にするため)。
               

               

-                通常の C のビルドなら、configure の次は make するところだが、ここでも emmake を使う。 役割はほとんど emconfigure と同様である。 指定してある EMCC_CFLAGS という環境変数は、Emscripten の C コンパイラへのフラグで、ここでは ERROR_ON_UNDEFINED_SYMBOLS を無効化している。 これにより、コンパイル中に出現した解決できなかったシンボルを無視するようになる (代わりに、そのシンボルを呼ぼうとしたタイミングで実行時エラーになる)。 すべての依存を完全に解決するのは面倒なので、あまり使わない機能については無視してもよいだろう。
+                通常の C のビルドなら、configure の次は make するところだが、ここでも emmake を使う。役割はほとんど emconfigure と同様である。指定してある EMCC_CFLAGS という環境変数は、Emscripten の C コンパイラへのフラグで、ここでは ERROR_ON_UNDEFINED_SYMBOLS を無効化している。これにより、コンパイル中に出現した解決できなかったシンボルを無視するようになる (代わりに、そのシンボルを呼ぼうとしたタイミングで実行時エラーになる)。すべての依存を完全に解決するのは面倒なので、あまり使わない機能については無視してもよいだろう。
               

               

                 ここまでを実行すると libs/libphp.a が生成される。これは後で使うので移動させている。
               

               

-                さて、PHP 処理系をライブラリ化できたので、次に先ほど載せた C のソースコードをビルドしていこう。 Dockerfile と同じ場所に php-wasm.c という名前で保存し、次のようにする。
+                さて、PHP 処理系をライブラリ化できたので、次に先ほど載せた C のソースコードをビルドしていこう。Dockerfile と同じ場所に php-wasm.c という名前で保存し、次のようにする。
               

               

                 
COPY php-wasm.c /src/
@@ -290,10 +290,10 @@
     :

               

               

-                emcc は cc (C コンパイラ/リンカ) の Emscripten 版で、-c は「コンパイル」の意。 -o や -I は普通の C コンパイラと同様、出力ファイルの指定とインクルードパスの指定である。
+                emcc は cc (C コンパイラ/リンカ) の Emscripten 版で、-c は「コンパイル」の意。-o や -I は普通の C コンパイラと同様、出力ファイルの指定とインクルードパスの指定である。
               

               

-                libphp.a と php-wasm.o が手に入ったので、これらをリンクして WebAssembly のバイナリとそのラッパである JavaScript ファイルを生成する。 これにも emcc コマンドを使う。
+                libphp.a と php-wasm.o が手に入ったので、これらをリンクして WebAssembly のバイナリとそのラッパである JavaScript ファイルを生成する。これにも emcc コマンドを使う。
               

               

                 
RUN emcc \
@@ -313,31 +313,31 @@
                 それぞれのフラグについて解説する。
               

               

-                -s ENVIRONMENT=node は、生成する WebAssembly/JavaScript の実行環境を指定する。 今回は node を指定しているので、Node.js 向けのファイルが生成される。
+                -s ENVIRONMENT=node は、生成する WebAssembly/JavaScript の実行環境を指定する。今回は node を指定しているので、Node.js 向けのファイルが生成される。
               

               

                 -s ERROR_ON_UNDEFINED_SYMBOLS=0 についてはすでに述べたので省略する。
               

               

-                -s EXPORTED_RUNTIME_METHODS='["ccall"]' は、生成される JavaScript から公開される API である。 すでに index.mjs で使用しているが、ccall('関数名', '返り値の型', ['仮引数の型', ...], ['実引数', ...]) のように使う。
+                -s EXPORTED_RUNTIME_METHODS='["ccall"]' は、生成される JavaScript から公開される API である。すでに index.mjs で使用しているが、ccall('関数名', '返り値の型', ['仮引数の型', ...], ['実引数', ...]) のように使う。
               

               

-                -s EXPORT_ES6=1 は、JavaScript コードを ECMAScript 6 に準拠した module として生成する。 これを指定することで、require() ではなく import できる JavaScript を生成させられる。
+                -s EXPORT_ES6=1 は、JavaScript コードを ECMAScript 6 に準拠した module として生成する。これを指定することで、require() ではなく import できる JavaScript を生成させられる。
               

               

                 -s INITIAL_MEMORY=16777216 は呼んで字のごとく。用途に合わせて適当に決めてほしい。
               

               

-                -s INVOKE_RUN=0 は、module をロードしたときに勝手に main() を呼ぶかどうか (だと思う)。 今回は php_wasm_run() しか使うつもりがないので切っている。
+                -s INVOKE_RUN=0 は、module をロードしたときに勝手に main() を呼ぶかどうか (だと思う)。今回は php_wasm_run() しか使うつもりがないので切っている。
               

               

-                -s MODULARIZE=1 は、実質的にほぼ必須のオプションであり、1 を指定することで「WebAssembly module をインスタンス化する関数」をエクスポートするような JavaScript ファイルを生成するようになる。 これを指定しないと、生成物の JavaScript ファイルを読み込むと WebAssembly module が即座にインスタンス化されてしまい、起動のタイミングを制御できない。
+                -s MODULARIZE=1 は、実質的にほぼ必須のオプションであり、1 を指定することで「WebAssembly module をインスタンス化する関数」をエクスポートするような JavaScript ファイルを生成するようになる。これを指定しないと、生成物の JavaScript ファイルを読み込むと WebAssembly module が即座にインスタンス化されてしまい、起動のタイミングを制御できない。
               

               

-                ここまで実行すると、php-wasm.js と php-wasm.wasm が作られる。 では、ここからはこれらの実行環境を作っていこう。
+                ここまで実行すると、php-wasm.js と php-wasm.wasm が作られる。では、ここからはこれらの実行環境を作っていこう。
               

               

-                といっても、Node.js はビルトインで WebAssembly をサポートしているので、ほとんどやることはない。 先ほど掲載した JavaScript のコードは、Dockerfile と同じディレクトリに index.mjs で配置すること。
+                といっても、Node.js はビルトインで WebAssembly をサポートしているので、ほとんどやることはない。先ほど掲載した JavaScript のコードは、Dockerfile と同じディレクトリに index.mjs で配置すること。
               

               

                 
FROM node:20.7
@@ -368,7 +368,7 @@
           

             
まとめ

             

-              ここまでをまとめた Git リポジトリ を用意した。 簡単にコンパイルできるので、興味があれば試してみてほしい。
+              ここまでをまとめた Git リポジトリ を用意した。簡単にコンパイルできるので、興味があれば試してみてほしい。
             

           

           

-- 
cgit v1.2.3-70-g09d2