前回、密封ビルドについて書いたところ、仮想マシンを使ってビルド環境を密封するのがよいとコメントで教えてもらった。確かにこれは強力なやり方だ。
では、密封ビルドは完成したとして、実行プログラムを密封するにはどうしたらいいだろうか？実行環境に何かを別途インストールするのは面倒くさいし、実行環境の差異によってプログラムの挙動に問題が生じるのは避けたい。実行プログラムを密封して （self-contained にして）、こういう問題をなくすにはどうすればいいか、Linuxを前提に考えてみたい。
まず最初に取り除きたいのは共有ライブラリだ。共有ライブラリのインストールは面倒だし、バージョンの違いによる相性の問題は発生しがちだ。ソフトウェアップデートでバージョンが勝手に上がってしまうこともある。
これらの影響を遮断するには、必要なものをすべて静的にリンクすればいいはずだ（セキュリティ上の理由で静的リンクはよくないという考え方もあるけど、ここではその話は置いておく）。が、これが案外むずかしい。Linux の libc はいくつかの .so ファイルを動的にロードしたりするので、完全な静的リンクはできないのだ。
じゃあどうするかというと、/my_world のようなディレクトリに特定のバージョンの libc.so などを入れて、そっちを使うようにすれば、システムの libc を使わずにすむはずだ。あるいはchrootを作って必要なものを全部そこに入れてしまうという手もある。libcくらいは信用してもいいような気もするけど。
外部コマンドへの依存も取り除きたい。実行環境に入っているとは限らないし、入っていても変なバージョンかもしれない。
設定ファイルやらなんやらの外部ファイルへの依存も取り除きたい。実行ファイルに必要な情報がすべて入っていて、どこにでも好きにコピーできるというのは便利なものだ。
環境変数に依存するのも避けたい。とりわけ、ロカールの違いで isalpha() などの挙動が意図せず変わってしまうのは困る。だいたい、こういったことはロカールに任せるより、ICU[1] などを使って意図的にやったほうがうまくいくものだ。
これでぼちぼち密封度が高まった。完全に密封するためには、まだカーネルというものが残っているが、これは仮想マシンでも使わない限り無理そうだ。
プログラムの密封というアイディアはスクリプト言語でも有効だ。以前に MovableType [2] というブログシステムをインストールしたときに、サードパーティのものを含めて必要なライブラリがすべて同梱されていて、これはいいと思った。
ユーザとしては他のライブラリを別個に入れる必要がないのは楽だし、開発元としては、バージョンの相性問題に悩まされなくてすむのはいいんじゃないかと思う。
外部への依存性がやたら多いプログラムよりも、こうやって何でも入っているプログラムの方が、はまりポイントが少なくて安心して使えるものだ。さすがに Perl のバイナリは同梱されていなかったけど。
[1] http://site.icu-project.org/
[2] http://www.movabletype.org/