動的共有オブジェクト (DSO) サポート

Apache HTTP サーバはモジュール化されたプログラムで、 管理者がモジュールを選択することでサーバに組み込む機能を選ぶことができます。 モジュールはサーバがビルドされるときに

バイナリに 静的に組み込むことができます。もしくは、httpd

バイナリとは 別に存在する動的共有オブジェクト (訳注: Dynamic Shared Object) (DSO) としてコンパイルすることも できます。DSO モジュールはサーバがビルドされるときにコンパイルしたり、 Apache 拡張ツール (httpd

この文書は DSO モジュールの使い方と、仕組みについて 説明します。

のような DSO にモジュールがコンパイルされれば、 apache2.conf

Apache モジュール用の (特にサードパーティモジュールの) DSO ファイルの 作成を簡単にするために、

(APache eXtenSion) という新しいサポートプログラムがあります。 Apache のソースツリーのapxs外で DSO モジュールをビルドするために 使うことができます。発想は単純です: Apache のインストール時の

のときに Apache の C ヘッダをインストールし、DSO ビルド用のプラットフォーム依存の コンパイラとリンカのフラグを

プログラムに追加します。 これにより、ユーザが Apache の配布ソースツリーなしで、さらに DSO サポートのためのプラットフォーム依存のコンパイラやリンカの フラグをいじることなく Apache のモジュールのソースをコンパイル できるようになります。apxs

として、それを DSO mod_foo.so

にビルド、インストール: $ ./configure --prefix=/path/to/install --enable-foo=shared

moduletype:/path/to/3rdparty/modfoo.c \

を使って Apache ソースツリーの $ cd /path/to/3rdparty

$ apxs -i -a -n foo mod_foo.la

どの場合においても、共有モジュールをコンパイルした後で、 apache2.conf

ディレクティブを使って Apache がモジュールを使用するように しなければなりません。LoadModule

最近の Unix 系の OS には 動的共有オブジェクト (DSO) の動的リンク/ロードという気のきいた機構が 存在します。これは、実行時にプログラムのアドレス空間に ロードできるような特別な形式でプログラムをビルドすることを 可能にします。

このロードは二つの方法で行なうことができます: 実行プログラムが 起動されたときに ld.so

というシステムプログラム により自動的に行なわれる方法と、実行プログラム中から、システムコール dlopen()/dlsym()

による Unix ローダへの プログラムシステムのインタフェースを使って手動で行なう方法とが あります。

最初の方法では DSO は普通は共有ライブラリや DSO ライブラリ と呼ばれていて、DSO の名前は libfoo.so

や libfoo.so.1.2

のようになっています。 これらはシステムディレクトリ (通常 /usr/lib

をリンカに 指定することで確立されます。これによりライブラリへの参照が実行プログラムの ファイルに書き込まれて、起動時に Unix のローダが /usr/lib

により設定されたパス、の中から libfoo.so

の場所を見つけることができます。それから、 実行プログラム中の (まだ未解決の) シンボルを DSO にあるシンボルで 解決します。

を起動するコードが含まれています)。よく使われる ライブラリの動的ロードの利点は明らかです。ライブラリのコードは システムライブラリに libc.so

二つめの方法では DSO は普通は共有オブジェクトや DSO ファイルと呼ばれていて、任意の拡張子を付けることができます (ただし、標準的な名前は foo.so

です)。 これらのファイルは通常はプログラム専用のディレクトリに置かれ、 これらを使う実行プログラムへのリンクは自動的にはされません。 ですので、実行プログラムは dlopen()

のすべてのシンボル) で自動的に解決します。 こうすることで、DSO は最初から静的にリンクされていたかのように、 実行プログラムのシンボルを知ることができます。

最後に、DSO の API を利点を生かすために、プログラムは 後でディスパッチテーブルなどでシンボルを使うことができるように、 dlsym()

この DSO 機構は簡単なように見えますが、少なくとも一つ難しい点が あります: プログラムを拡張するために DSO を使っているときに、 DSO が実行プログラムからシンボルを解決する点です (二番目の方法)。 これはなぜでしょうか。それは、DSO のシンボルを実行プログラムの シンボルから「逆解決」するというのはライブラリの設計 (ライブラリはそれを使用するプログラムのことは何も 知らない) に反していて、この機能はすべてのプラットフォームに あるわけではなく、標準化もされていないからです。 実際には実行プログラムのグローバルなシンボルは再エクスポートされることは あまりなく、DSO から使うことができません。リンカにグローバルシンボルすべてを エクスポートするようにさせる方法を見つけることが、実行時にプログラムを 拡張するために DSO を使うときの一番の問題です。

共有ライブラリのアプローチが普通の方法です。DSO 機構はそのために 設計されたものですから。したがって、その方法はオペレーティングシステムが 提供するほとんどすべての種類のライブラリで使われています。 一方、プログラムの拡張のために共有オブジェクトを使用する、という方は あまり使われていません。

のオプションを使う代わりに 実行時に apache2.conf

を使うことができますので、サーバパッケージの柔軟性が高まりました。 たとえば、一つの Apache のインストールから 違う構成のサーバ (標準版と SSL 版、最小構成と拡張版 [mod_perl, PHP3] apxs

の組み合わせにより、Apache ソースツリーの 外で作業でき、開発中のモジュールの新しいバージョンを 実行中の Apache サーバに組み込むために apxs -i

) と Apache コアが使っている他のすべての静的なライブラリと動的ライブラリの シンボル、PIC による静的なライブラリ (libfoo.a

) の シンボルのみに制限されます。その他のコードを使う方法は、 Apache コア自身がすでにそのコードへの参照があるようにするか、 dlopen ()

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

Apache HTTP サーバ バージョン 2.4