## Program Library HOWTO

David A.
Wheeler

          dwheeler(a)dwheeler.com

日本語訳：2004 年 9 月 17 日 (原文：2003 年 4 月 28 日、バージョン 1.20)
川崎 貴彦
日本語訳

          takahiko(a)hakubi.co.jp

この HOWTO はプログラマ向けであり、Linux におけるプログラムライブラリの作成方法と使用方法を説明するものです。 「静的ライブラリ (static library)」、「共有ライブラリ (shared library)」、「動的ライブラリ (dynamically loaded library)」を対象とします。 (訳注：この訳文では、「dynamically loaded library」のことを「動的ライブラリ」と呼ぶことにします。 世の中では、shared library のことを指して動的ライブラリと表現する例もありますが、それとは異なりますので注意してください。)

## はじめに

この HOWTO はプログラマ向けであり、GNU ツールセットを利用して、Linux 上でプログラムライブラリを作成する方法、およびその使用方法を説明するものです。 「プログラムライブラリ」とは、のちのちプログラムに組み込むためのコンパイル済みコード (およびデータ) を含む、単なるファイルのことです。プログラムライブラリは、プログラムを、よりモジュール化され、より速く再コンパイルでき、より簡単に更新できるものにします。 プログラムライブラリは三つのタイプ、すなわち、静的ライブラリ (static library)、共有ライブラリ (shared library)、動的ライブラリ (dynamically loaded library)、に分類することができます。

この文書は、最初に、静的ライブラリ (プログラムが実行される前にその実行可能プログラムに組み込まれるライブラリ) について説明します。それから、共有ライブラリ (プログラム実行時にロードされ、かつ複数のプログラム間で共有されるライブラリ) について説明します。最後に、動的ライブラリ (プログラム実行中の任意の時点でロードして使用することが可能なライブラリ) について説明します。 動的ライブラリのライブラリフォーマットは、実際には別の種類というわけではありません (静的ライブラリも共有ライブラリも動的ライブラリとして使用することが可能です)。 その代わりに、プログラマが動的ライブラリを使用する方法に違いがあります。 この HOWTO は、例を挙げている章と、その他の情報源への参照を挙げている章で締めくくります。

ライブラリを開発しているほとんどの開発者は、共有ライブラリを作成すべきです。 というのは、ユーザが、そのライブラリを使用するアプリケーションとは別々にライブラリを更新できるようになるからです。 動的ライブラリは便利ですが、使用するには少し手間がかかります。 また、多くのプログラムでは、動的ライブラリが提供する柔軟性を必要とはしません。 これとは逆に、静的ライブラリの場合、ライブラリを更新するのは非常に厄介です。 そのため、日常的に利用しようとしているならば、静的ライブラリはお勧めしません。 ただし、各ライブラリにはそれぞれの利点があります。 利点については、各ライブラリごとの章でそれぞれ説明します。 C++ と動的ライブラリを使用する開発者は、「C++ dlopen mini HOWTO」も参照してください。

共有ライブラリを指して dynamically linked library (DLL) という用語を使う人がいること、その DLL という用語を動的ライブラリとして使用される任意のライブラリを指すために使う人がいること、また、どちらかの条件を満たすライブラリを指すために DLL という用語を使う人がいること、には注意したほうがよいです。 いずれを指すにしても、この HOWTO では Linux における DLL を扱います。

この HOWTO では、実行可能ファイルおよびライブラリ用の Executable and Linking Format (ELF) フォーマット (昨今のほとんど全ての Linux ディストリビューションで使用されているフォーマット) についてのみ扱います。 GNU gcc ツールセットは、実際には ELF 以外のライブラリフォーマットを扱うことができます。特に、ほとんどの Linux ディストリビューションでは、旧式の a.out フォーマットを今なお使用することが可能です。 しかしながら、これらのフォーマットはこの文書の対象外とします。

多くのシステムへと移植する必要のあるアプリケーションを作成しているならば、ライブラリを構築してインストールするとき、Linux ツールを直接使用する代わりに、GNU libtool を使用することを考慮したほうがよいかもしれません。 GNU libtool は、共有ライブラリ使用時の複雑さ (例えば、共有ライブラリの作成やインストール等) を一貫性のある移植性の高いインターフェースで隠蔽する、汎用的なライブラリサポートスクリプトです。 Linux 上では、GNU libtool は、この HOWTO で説明されているツール群と約束ごとの上に構築されています。 動的ライブラリに対する移植性の高いインターフェースとして、様々なポータビリティラッパーを使用することができます。 GNU libtool には「libltdl」と呼ばれるラッパーが含まれています。 他の選択肢としては、移植性のある方法でモジュールの動的ローディングをサポートする glib ライブラリ (glibc と混同しないでください) を使用することもできます。 glib の詳細については http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html で学習することができます。再度述べますが、Linux 上では、この機能は、この HOWTO 内で説明されている構成物を利用することによって実装されています。もしもあなたが実際に Linux 上でコードの開発またはデバッグをされているなら、おそらく、この HOWTO 内の情報をこれから先必要とされることでしょう。

この HOWTO の一次配布場所は http://www.dwheeler.com/program-library/ であり (訳注：日本語訳は http://www.linux.or.jp/JF/JFdocs/Program-Library-HOWTO/ にあります)、Linux Documentation Project (http://www.linuxdoc.org/) に寄贈されています。著作権は David A. Wheeler にあり (Copyright (C) 2000)、General Public License (GPL) でライセンスされています。詳細な情報については最後の章を読んでください。

## 静的ライブラリ

静的ライブラリは、通常のオブジェクトファイルの単なる集合体です。 慣習として、静的ライブラリは「.a」という拡張子を持ちます。 この集合体は、ar (archiver) プログラムを使用して作成されます。 静的ライブラリは以前ほどには使われなくなっていますが、これは、共有ライブラリのほうが優れているためです (あとで説明します)。それでもまだ、静的ライブラリは折に触れて作成され (はじめは歴史的な理由で存在していました)、また、説明するのも簡単です。

ユーザは、コードを再コンパイルする必要なく静的ライブラリをプログラムにリンクすることができるので、再コンパイルにかかる時間を節約できます。 ただ、昨今の高速なコンパイラのことを考えると、再コンパイル時間は重要ではなくなってきているので、この理由付けは以前ほど有力ではありません。 静的ライブラリは、その開発者が、ライブラリをリンクすることをプログラマに許可はしたいがライブラリのソースコードは渡したくはない、という場合にしばしば役に立ちます (これはライブラリベンダにとっては好都合ですが、そのライブラリを使おうとしているプログラマにとっては、どう考えても好都合とは言えません)。 論理的には、実行可能ファイルにリンクされる静的 ELF ライブラリ内のコードは若干速く (1 〜 5%) 動作するはずですが、実際には、他のごちゃごちゃした要因のため、その通りになることは稀のようです。

静的ライブラリを作成する、もしくは既に存在する静的ライブラリにさらにオブジェクトファイルを追加するためには、次のようなコマンドを使用してください。

      ar rcs my_library.a file1.o file2.o

このコマンド例では、静的ライブラリ my_library.a にオブジェクトファイル file1.o と file2.o を追加しています。まだ my_library.a が存在していなければ、作成します。 静的ライブラリ作成に関する詳細な情報については ar(1) を参照してください。

静的ライブラリを作成したら、それを使いたくなることでしょう。 実行可能プログラムを作成するときにコンパイルとリンク処理の一部として取り込むことで、静的ライブラリを使用できます。 実行可能ファイルを作成するときに gcc(1) を使っているならば、ライブラリを指定するのに -l オプションを使用できます。 より詳しい情報については info:gcc を参照してください。

gcc を使うときにはパラメータの順番に気をつけてください。-l オプションはリンカオプションなので、コンパイルするファイル名の「後に」置く必要があります。 これは、通常のオプション構文とはだいぶ異なります。-l オプションをファイル名の前に置いた場合、リンクは完全に失敗し、不可解なエラーになってしまうでしょう。

-l と -L オプションを使ってリンカ ld(1) を直接使用することもできます。 しかしながら、ld(1) のインターフェースは gcc(1) よりも変更されやすいので、ほとんどの場合は gcc(1) を使うほうがよいです。

## 共有ライブラリ

共有ライブラリは、プログラム起動時にロードされるライブラリです。 共有ライブラリが適切にインストールされると、その後に起動される全てのプログラムは、自動的にその新しい共有ライブラリを使うことになります。 実際には、これよりもはるかに柔軟で洗練されています。なぜなら、Linux における共有ライブラリの実現方法のおかげで、次のことが可能となるからです。

- ライブラリを更新しながらも、そのライブラリの古くて後方互換性のないバージョンを使いたいというプログラムを、引き続きサポートすることができる

- 特定のプログラムを実行するとき、特定のライブラリ、もしくはライブラリ内の特定の関数でさえもオーバーライドすることができる

- 既存のライブラリを使用してプログラムが動いている間にも、これら全てをおこなうことができる

### 約束ごと

これらの望ましい特性すべてを共有ライブラリがサポートするためには、多くの慣習と指針に従わなければなりません。 ライブラリの名前、特に「soname」と「real name」の違いについて (及びそれらがどのように相互作用するかについて) 学ばなければなりません。 また、それらがファイルシステム内のどの場所に置かれるべきであるかについても、知っておかなければなりません。

#### 共有ライブラリ名

全ての共有ライブラリは「soname」と呼ばれる特別な名前を持っています。 soname は、「lib」というプレフィックス、ライブラリの名前、「.so」という語句で構成され、さらに後ろに、ピリオドと、インターフェース変更時に必ず増加するバージョン番号、が続きます (特別な例外として、最下層の C ライブラリは「lib」では始まりません)。 完全記述の soname は、そのライブラリ自身が含まれるディレクトリをプレフィックスとして含んでいます。 実際のシステムでは、完全記述の soname は、共有ライブラリの「real name」への単なるシンボリックリンクになっています。

全ての共有ライブラリには「real name」(実際のライブラリコードを含むファイルの名前) があります。real name は、soname に、ピリオド、マイナー番号、もう一つのピリオド、リリース番号、を加えたものです。 最後のピリオドとリリース番号は任意です。 マイナー番号とリリース番号は、ライブラリのどのバージョンがインストールされているかを正確に示すもので、設定管理に役立ちます。 これらの番号は (同じにしてくれれば話が分かりやすくなるのですが) 文書中でライブラリを説明する際に用いられている番号と同じではないかもしれない、という点に注意してください。

加えて、ライブラリ要求時にコンパイラが使用する名前というものもあります (「linker name」と呼ぼうと思います)。 この名前は、単純に一切のバージョン番号を取り除いた soname です。

共有ライブラリを管理する鍵となるのは、これらの名前の使い分けです。 必要とする共有ライブラリの一覧表を内部に持つときには、プログラムは、必要とする soname のみをリストアップするようにします。 逆に、共有ライブラリを作成するときには、(より詳細なバージョン情報を持つ) 特定のファイル名を持つライブラリのみを作成するようにします。 新しいバージョンのライブラリをインストールするときには、二、三の特別なディレクトリのうちの一つにそれをインストールし、それから ldconfig(8) プログラムを実行します。 ldconfig は、既に存在するファイルを調べ、real name へのシンボリックリンクとして soname 群を作成します。 同様にして、キャッシュファイル `/etc/ld.so.cache` も作成します (すぐに説明します)。

ldconfig は linker name を作成しません。 通常、この作成作業はライブラリインストール時におこない、単純に、「最新の」soname もしくは最新の real name へのシンボリックリンクとして linker name を作成します。 ほとんどの場合において、ライブラリを更新したら、リンク時にそれを自動的に利用したいと思うでしょうから、soname へのシンボリックリンクとして linker name を作っておくことをお勧めします。 なぜ ldconfig が自動的に linker name を作成しないのかを、私は H. J. Lu に尋ねました。 彼の説明は、基本的には、「ライブラリの最新バージョンを使ってコードを実行したいと思われるかも知れませんが、そうではなく、(おそらく互換性のない) 古いライブラリをリンクしながらの開発作業を希望されることもありうるでしょう」、というものでした。 そのため、ldconfig は、プログラムをどのライブラリにリンクさせたいのかということについては、何の仮定もおこなわないのです。 ですから、ライブラリとしてリンカに使わせるものを実際に更新するためには、インストーラがシンボリックリンクを個別に変更しなければならないのです。

例えば、`/usr/lib/libreadline.so.3` は完全記述の soname であり、これは ldconfig が `/usr/lib/libreadline.so.3.0` というような何らかの real name に対するシンボリックリンクとして作成するものです。 `/usr/lib/libreadline.so` という linker name も作成するべきであり、それは、`/usr/lib/libreadline.so.3` を参照するシンボリックリンクとなるでしょう。

#### ファイルシステム配置

共有ライブラリはファイルシステム内のどこかに配置しなければなりません。 ほとんどのオープンソースソフトウェアは、GNU 規約に従う傾向があります。 詳細は info:standards#Directory_Variables にある info ファイルドキュメントを参照してください。 GNU 規約は、ソースコードを配布するとき、デフォルト設定時にはライブラリを全て `/usr/local/lib` にインストールするよう推奨しています (コマンドを全て `/usr/local/bin` に配置するようにとも推奨しています)。 また、これらのデフォルト設定をオーバーライドしたり、インストールルーチンを呼び出したりする際の約束ごとも定義しています。

ファイルシステム階層規約 (Filesystem Hierarchy Standard; FHS) は、ディストリビューションにおいて何をどこにインストールすべきかを説明しています (http://www.pathname.com/fhs/ を参照してください)。FHS によると、ほとんどのライブラリは `/usr/lib` にインストールし、起動時に必要とされるライブラリは `/lib` に、システムの一部ではないライブラリは `/usr/local/lib` にインストールするのが良い、ということになります。

実際には、これら二つの規約間に矛盾はありません。 GNU 規約は、ソースコード開発者のためのデフォルト設定を推奨しているのであり、一方で FHS は、ディストリビュータ (通常、システムパッケージ管理システムによりソースコードのデフォルト設定を選択的にオーバーライドする人々) のためのデフォルト設定を推奨しているのです。 実際にこれはうまく機能しています。あなたがダウンロードした「最新の」(おそらくバグだらけの！) ソースコードは、自動的に自分自身を「ローカルな」ディレクトリ (`/usr/local`) にインストールします。 そしてコードが成熟してきたら、ディストリビューション用の標準的な位置にコードを配置するため、パッケージ管理ツールでデフォルト設定を簡単にオーバーライドできます。 あなたのライブラリが、ライブラリ経由でしか呼び出されることのないプログラムを呼び出しているのならば、それらのプログラムを `/usr/local/libexec` (あるディストリビューションでは `/usr/libexec` になります) に配置するべきです。 厄介なのは、Red Hat から派生したシステムがデフォルト設定では `/usr/local/lib` をライブラリ検索対象に含めていないということです。 `/etc/ld.so.conf` に関する下記の議論を参照してください。 他の標準的なライブラリ配置場所としては、X Window System 用の `/usr/X11R6/lib` があります。`/lib/security` は PAM モジュール用に使われますが、通常、PAM モジュール群は動的ライブラリ (これもあとで説明します) としてロードされるので注意してください。

### ライブラリはどのように使われるか

GNU glibc ベースのシステム (全ての Linux システムが含まれます) では、ELF バイナリ実行ファイルを起動すると、自動的にプログラムローダがロードされ、実行されます。 Linux システムでは、このローダは `/lib/ld-linux.so.X` (X にはバージョン番号が入ります) という名前です。 このローダは、プログラムによって使用されるその他の全ての共有ライブラリを順次探し出し、ロードします。

検索対象となるディレクトリのリストは、`/etc/ld.so.conf` ファイル内に記述されています。 Red Hat から派生しているディストリビューションの多くは、通常 `/etc/ld.so.conf` ファイル内に `/usr/local/lib` を含めていません。私はこれをバグだと考えており、また、`/usr/local/lib` を `/etc/ld.so.conf` に追加することは、Red Hat から派生しているシステム上で多くのプログラムを走らせるのに必要な、共通の「修正」だと思っています。

ライブラリ内の幾つかの関数をオーバーライドしたいだけで、残りはそのままにしておきたいならば、オーバーライドするライブラリ (.o ファイル) の名前を `/etc/ld.so.preload` に入れることができます。 これらの「先行ロード」ライブラリは、標準集合よりも先行します。 この先行ロードファイルは、典型的には緊急用のパッチとして使われます。 通常、ディストリビューションが配布される際、このようなファイルは含まれないでしょう。

プログラム起動時にこれら全てのディレクトリを検索するのは、とても非効率的なので、実際にはキャッシュ処理がおこなわれます。 ldconfig(8) プログラムはデフォルトで `/etc/ld.so.conf` ファイルを読み込み、適切なシンボリックリンクを動的リンクディレクトリ内に作成します (これにより、標準的な慣習に沿うことになります)。 それから、あとで他のプログラムから利用されることになるキャッシュを `/etc/ld.so.cache` に書き込みます。 これにより、ライブラリへのアクセスが非常に速くなります。 結果として言えることは、DLL を追加したとき、または、DLL を削除したり、DLL ディレクトリのセットを変更したりしたときには必ず、ldconfig を実行しなければならない、ということです。 ldconfig の実行は、ライブラリインストール時にパッケージ管理ツールによっておこなわれるステップの一つであることが多いです。 ldconfig 以降、動的ローダは起動時、実際には `/etc/ld.so.cache` ファイルを使い、必要とするライブラリをロードすることになります。

話は変わりますが、FreeBSD は、このキャッシュ用のファイル名が少し異なります。 FreeBSD では、ELF キャッシュは `/var/run/ld-elf.so.hints` で、a.out キャッシュは `/var/run/ld.so.hints` になります。 これらのファイルもまた ldconfig(8) により更新されるので、場所の違いが問題となるのは、幾つかの特別な状況においてのみでしょう。

### 環境変数

様々な環境変数により、共有ライブラリのロード処理を制御できます。 ロード処理をオーバーライドするための環境変数が存在するのです。

#### LD_LIBRARY_PATH

特定のプログラムを実行する際、一時的に別のライブラリを代替的に使用することができます。Linux では、環境変数 LD_LIBRARY_PATH に、標準的なディレクトリ群に先立ってライブラリ検索対象とすべきディレクトリ群を、コロンで区切って並べます。 これは、新しいライブラリをデバッグするときや、特殊な目的のために非標準的なライブラリを使用するときなどに便利です。 環境変数 LD_PRELOAD には、ちょうど `/etc/ld.so.preload` でやっているのと同じように、共有ライブラリ群を、標準集合をオーバーライドする関数群と共に列挙します。 これらの機能は、ローダ `/lib/ld-linux.so` により実装されています。 LD_LIBRARY_PATH は多くの Unix 系システムで機能しますが、全てのシステムにおいて機能するわけではないので注意しましょう。 例えば、HP-UX でも同じ機能を利用できますが、それは SHLIB_PATH ですし、AIX では LIBPATH となります (構文は同じで、コロン区切りのリストです)。

LD_LIBRARY_PATH は開発やテストには便利ですが、一般ユーザに日常的に使用させようとして、インストール処理で変更すべきではありません。 この理由については、http://www.visi.com/~barr/ldpath.html の「Why LD_LIBRARY_PATH is bad」(なぜ LD_LIBRARY_PATH はいけないのか) を参照してください。 とは言うものの、LD_LIBRARY_PATH は、開発やテスト、そして、他の方法では回避できない問題に対処するためには、やはり便利です。 LD_LIBRARY_PATH 環境変数を設定したくない場合、Linux では、プログラムローダを直接起動して引数を与えることもできます。 例えば、次のようにすると、指定の実行ファイルが、環境変数 LD_LIBRARY_PATH の内容ではなく、与えられた PATH を使用して実行されます。

      /lib/ld-linux.so.2 --library-path PATH EXECUTABLE

引数を与えずに ld-linux.so を実行すると、使い方についてのヘルプが表示されます。 しかし、もう一度言いますが、普段はこれを使わないようにしてください。 これらの機能は全てデバッグのためにあるのです。

#### LD_DEBUG

GNU C ローダのもう一つの便利な環境変数は LD_DEBUG です。 これにより、dl*() 関数群が、実行中の処理に関する情報を大量に出力するようになります。 例えば、次のコマンド

      export LD_DEBUG=files
      command_to_run

は、ライブラリを扱うときに処理するファイル群とライブラリ群を表示し、検出された依存関係、および、どの so ファイルがどの順番でロードされたか、を教えてくれます。LD_DEBUG を「bindings」にセットすると、シンボルのバインディングに関する情報を表示します。 「libs」にセットすると、ライブラリ検索パスを表示します。 「versions」にセットすると、バージョン依存関係を表示します。

LD_DEBUG を「help」に設定し、プログラムの実行を試みると、指定可能なオプションがリストアップされます。 再度申しますが、LD_DEBUG は日常的に使用するためのものではなく、デバッグ時やテスト時に役立つものです。

#### その他の環境変数

実際には、ロード処理を制御する環境変数は他にもたくさん存在します。それらの名前は LD_ や RTLD_ ではじまり、そのほとんどが、ローダ処理の低レベルなデバッグや特殊な機能を実装するためのものです。 ほとんどのものにはまだ文書がありません。 これらについて調べたいなら、(gcc の一部である) ローダのソースコードを読むのが一番です。

特別な対応をおこなっていない場合、動的にリンクされるライブラリに対する制御をユーザに許可してしまうと、setuid/setgid プログラムは悲惨なことになるでしょう。そのため、(プログラム起動時にプログラムの残りの部分をロードする) GNU ローダは、これらの環境変数 (及び類似の環境変数) を無視するか、もしくは、これらの環境変数の効果を大幅に制限します。 ローダは、プログラムの信任証 (credential) を調べることによって、そのプログラムが setuid もしくは setgid されているかどうかを確認します。もしも uid (実ユーザ ID) と euid (実効ユーザ ID) が異なるか、もしくは gid (実グループ ID) と egid (実効グループ ID) が異なるなら、ローダはそのプログラムが setuid/setgid されている (もしくはそのようなプログラムから起動された) と推定し、リンク処理を制御する能力を大幅に制限します。 GNU glibc ライブラリのソースコードを読めば、このことを確認することができるでしょう。 特に、elf/rtld.c ファイルと sysdeps/generic/dl-sysdep.c ファイルを参照してください。 これらのことから、「uid と gid を euid と egid に等しくしてからプログラムを呼べば、これらの環境変数が完全に機能する」、ということが分かります。 他の Unix 系システムでは、別の方法でこの問題に対処しますが、「setuid/setgid プログラムは、設定されている環境変数群によって過度に影響を受けるべきではない」、という考え方は同じです。

### 共有ライブラリの作成

共有ライブラリの作成は簡単です。 まずはじめに、共有ライブラリに組み込むオブジェクトファイルを、gcc の -fPIC または -fpic フラグを使って作成します。 -fPIC と -fpic オプションにより、共有ライブラリに対する要求事項である「位置独立コード (position independent code)」を生成することができます。 二つのオプションの違いについては、後の説明を参照してください。 soname は、gcc の -Wl オプションを使って指定します。 -Wl オプションは、オプション群 (今回の例では -soname リンカオプション) をリンカに渡すためのものです。-Wl の後ろのカンマはタイプミスではありません。 -Wl オプションには、エスケープされていないスペースを含めてはならないのです (訳注：-Wl の直後に続く「,-soname,your_soname」という文字列は、カンマの部分で分割されてからリンカに渡されます。 つまり、リンカには「-soname your_soname」というオプションが渡されます)。 次の書式を用いて共有ライブラリを作成してください。

      gcc -shared -Wl,-soname,your_soname \
          -o library_name file_list library_list

二つのオブジェクトファイル (a.o と b.o) を作成し、これら両方のオブジェクトファイルを含む共有ライブラリを作成する例を挙げます。 下記のコンパイル処理では、オブジェクトファイルにデバッグ情報 (-g) が含まれることになり、また、警告メッセージ (-Wall) も表示されます。これらのオプションは、共有ライブラリ作成に必須ではありませんが、お勧めします。 このコンパイル処理で、(-c オプションにより) オブジェクトファイルが生成されます。 なお、-fPIC オプションの指定は必須です。

      gcc -fPIC -g -c -Wall a.c
      gcc -fPIC -g -c -Wall b.c
      gcc -shared -Wl,-soname,libmystuff.so.1 \
          -o libmystuff.so.1.0.1 a.o b.o -lc

注意すべきことが幾つかあります。

- 生成されたライブラリを strip しないでください。 また、本当に必要でない限り、コンパイラオプション -fomit-frame-pointer を使わないでください。 これらをおこなっても生成されたライブラリは機能しますが、デバッガがほとんど使い物にならなくなってしまいます。

- コードの生成には -fPIC または -fpic を使用してください。 コードの生成に -fPIC と -fpic のどちらを使うかは、ターゲットに依存します。 -fPIC を選んでおけば常に動きますが、-fpic よりも大きなコードを生成する可能性があります (これを覚えておく方法は、「PIC は大文字だから大きなコードを生成する可能性がある」、です)。 -fpic オプションを使うと、通常は小さくて速いコードが生成されますが、グローバルで可視にできるシンボルの数やコードのサイズといった、プラットフォームに依存する制限があります。 共有ライブラリを作成するとき、うまくいくかどうかをリンカが教えてくれます。 疑わしいとき、私は -fPIC の方を選択します。なぜなら、-fPIC は常に機能するからです。

- 場合によっては、gcc を呼び出してオブジェクトファイルを生成するとき、「-Wl,-export-dynamic」オプションを含めなければならないこともあります。 通常、動的シンボルテーブルには、動的オブジェクトが使用するシンボルのみが含まれています。 このオプションは、(ELF ファイルを生成する場合) 全てのシンボルを動的シンボルテーブルに追加します (詳細については ld(1) を参照してください)。 「逆依存関係」が存在するとき、つまり、ライブラリをロードしようとしているプログラムの内部で (慣習により) 宣言しておかなければならないシンボルが、動的ライブラリにおいて未解決のとき、このオプションを使う必要があります。 「逆依存関係」を機能させるには、主プログラムが、シンボル群を動的に利用可能にする必要があります。 Linux システムだけで作業するのであれば、「-Wl,-export-dynamic」のかわりに「-rdynamic」でもよいです。 しかし、ELF 文書によると、Linux 以外のシステムにおける gcc では、「-rdynamic」フラグは常に機能するわけではありません。

開発中は、「他の多くのプログラムからも利用されているライブラリを修正してしまうかもしれない」という潜在的な問題があります。 開発段階のライブラリを対象にしてテストをおこなっている特定のアプリケーション以外には、その開発段階のライブラリを使わせたくないでしょう。 使用することになると思われるリンクオプションは、ld の「-rpath」です。 これは、コンパイルする個々のプログラムの、実行時のライブラリ検索パスを指定するものです。 gcc からは、次のように指定することで、-rpath オプションを渡すことができます。

      -Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)

ライブラリのクライアントプログラムをビルドするときにこのオプションを使えば、そのプログラムが当該ライブラリを隠蔽してしまうような他の技術と競合していないこと、または、そのような技術を使用していないこと、を確認する必要があることを除いて、LD_LIBRARY_PATH (次で説明します) について悩む必要がなくなります。

### 共有ライブラリのインストールと使用

共有ライブラリを作成したら、それをインストールしたくなることでしょう。 簡単な方法は、標準的なディレクトリ (例えば /usr/lib など) の一つに、そのライブラリをコピーし、ldconfig(8) を実行することです。

まず、共有ライブラリをどこかに作成する必要があるでしょう。 それから、必要なシンボリックリンク、特に soname から real name へのリンクを作成する必要もあるでしょう (同様に、バージョン番号を全く指定しないユーザのため、バージョン番号の無い soname, つまり「.so」で終わる soname からのリンクも必要です)。 最も簡単な方法は、次のとおり実行することです。

      ldconfig -n directory_with_shared_libraries

最後に、プログラムをコンパイルするときに、使おうとしている全ての静的ライブラリと共有ライブラリについて、リンカに教えてやる必要があります。 これは、-l オプションと -L オプションを使っておこないます。

標準的な場所にライブラリをインストールできない、もしくはインストールしたくないなら (例えばあなたが /usr/lib を変更する権限を持っていないなど)、別の手順を踏まなければなりません。 このような場合、ライブラリをどこかにインストールしておき、そのライブラリを見つけるために十分な量の情報をプログラムに与えなければなりません。 これをおこなうには、幾つか方法があります。 単純な場合では、gcc の -L フラグを使用できます。 また、特に、ある特定のプログラム以外は非標準的な場所に置いてあるライブラリを利用しないというのであれば、(上で説明した)「-rpath」を使うこともできます。 環境変数を使っていろいろ制御することもできます。 特に、LD_LIBRARY_PATH を設定することができます。 LD_LIBRARY_PATH には、共有ライブラリを検索するときに通常の場所に先立って検索対象とするディレクトリ群を、コロンで区切って列挙します。 bash をお使いでしたら、次の方法で my_program を実行できます。

      LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH my_program

幾つかの関数を選択的にオーバーライドしたいだけならば、オーバーライドするオブジェクトファイルを作成して LD_PRELOAD を設定するだけで実現できます。 このオブジェクトファイル内の関数により、対象となっている関数だけがオーバーライドされます (他の関数は元のままです)。

通常、ライブラリの更新は、何も気にせずにおこなうことができます。 もしも API に変更があるならば、ライブラリ作成者により soname も変更されていることでしょう。 そういうわけで、一つのシステム上に複数のライブラリが存在でき、各プログラムに対するライブラリが正しく選択されるのです。 しかし、もしも、ライブラリの更新で soname は変更されなかったのにプログラムがうまく動かなくなってしまった、ということがあるのならば、古いライブラリをどこかにコピーし、そのプログラムの名称を変更する (古い名前に「.orig」を付け足すなど) ことによって、そのプログラムが古いバージョンのほうのライブラリを使うように強制することができます。 これらの作業をおこなったあと、利用するライブラリを再設定して実際の (名称変更された) プログラムを呼び出す、小さな「ラッパー」スクリプトを作成してください。 番号付けの約束ごとのおかげで、同一ディレクトリ内に複数のバージョンのライブラリを置くこともできますが、お望みなら、古いライブラリをそれ独自の特別な場所に置くこともできます。 ラッパースクリプトは、次のようなものになるでしょう。

      #!/bin/sh
      export LD_LIBRARY_PATH=/usr/local/my_lib:$LD_LIBRARY_PATH
      exec /usr/bin/my_program.orig "$@"

自分でプログラムを書くときには、この方法に依存しないようにしてください。 ライブラリの後方互換性を持たせるか、もしくは、互換性の無い変更をおこなうときは必ず soname のバージョン番号を増やすよう、気を払ってください。 この方法は、最悪の場合の問題を扱うための「緊急時」対応なのです。

ldd(1) を使えば、プログラムによって使用されている共有ライブラリのリストを見ることができます。 例えば、次のようにタイプすれば、ls によって使用される共有ライブラリを確認できます。

      ldd /bin/ls

通常、プログラムが依存する各 soname について、それぞれどのディレクトリに存在するかが特定され、 その特定されたディレクトリ名とともに、当該 soname 群のリストが表示されます。 実質的に全ての状況において、少なくとも二つの依存情報が表示されるでしょう。

- /lib/ld-linux.so.N (N は 1 以上。通常は少なくとも 2). これは、他の全てのライブラリをロードするためのライブラリです。

- libc.so.N (N は 6 以上). これは C ライブラリです。C 言語以外の言語でさえ、C ライブラリを使用する傾向があります (少なくともそれら自身のライブラリを実装するため)。 そのため、ほとんどのプログラムは、少なくともこのライブラリを含んでいます。

注意：信頼できないプログラムに対して ldd を実行してはいけません。 ldd(1) のマニュアルで明確に述べられているとおり、ldd は、(幾つかの状況においては) 特別な環境変数 (ELF オブジェクトの場合は LD_TRACE_LOADED_OBJECTS) を設定してプログラムを実行することにより、動作しています。 信頼できないプログラムが、(ldd 情報を単に表示するかわりに) 任意のコードを ldd ユーザに強制実行させてしまうことも可能かもしれません。

### 互換性のないライブラリ

新しいバージョンのライブラリが古いものとのバイナリ互換性を持たないときには、soname を変更する必要があります。 C 言語では、ライブラリがバイナリ互換ではなくなってしまう四つの基本的な原因があります。

1. 関数の挙動が変更され、元々の仕様に適合しなくなる

2. エクスポートされているデータが変更される (例外：構造体がライブラリ内でのみアロケートされる場合に限り、構造体の末尾に任意のメンバーを追加することには問題がない)

3. エクスポートされている関数が削除される

4. エクスポートされている関数のインターフェースが変更される

これらの原因を回避できれば、ライブラリをバイナリ互換に保つことができます。 別の言い方をすると、これらの変更を避ければ、Application Binary Interface (ABI) 互換を保つことができる、ということです。 例えば、古い関数を削除せずに新しい関数を追加したい、というのは問題ないでしょう。 構造体の末尾にのみメンバーを追加し、その構造体をアロケートするのはライブラリ内だけとし (アプリケーションにはアロケートさせない)、追加のメンバーをオプション扱いにする (ライブラリがそのメンバーを設定する)、などの操作をおこなって生じる変更が、古いプログラムに対して影響を与えないことが確かな場合にのみ、メンバーを追加することができます。 もしもユーザが構造体を配列で使っているならば、その構造体を拡張することはほとんどできないので十分注意してください。

C++ (および、テンプレートやディスパッチされるメソッドをコンパイル時に組み込むという方法でサポートするその他の言語) では、状況はより複雑になります。 上記に述べたことが全て当てはまる上、さらに多くの注意点があります。 幾つかの情報が、コンパイルされるコード内に「隠蔽された状態で」組み込まれるという点にその原因があるのですが、このために、C++ が通常どのように実装されているかを知らない人には理解しにくい依存問題が、引き起こされてしまうのです。 正確に言えば、これは「新しい」問題ではありません。単に、コンパイル済みの C++ コードが、人によっては驚くかもしれない動作をして問題を引き起こす、というだけの話です。 次のリストは、バイナリ互換を維持するために C++ 内でやってはいけない項目のリスト (おそらく完全ではありませんが) であり、Troll Tech 社テクニカル FAQ で公開されているものです。

1. 仮想関数の再実装を追加する (古いバイナリが元の実装を呼び出すのが安全ではない場合)。 コンパイラは SuperClass::virtualFunction() 呼出しをコンパイル時に評価するため (リンク時ではない)。

2. 仮想メンバ関数を追加または削除する。 これにより全サブクラスの仮想関数テーブルのサイズとレイアウトが変更されてしまうため。

3. インラインメンバ関数経由でアクセス可能なデータメンバを移動させたり、データメンバの型を変更する。

4. クラス階層を変更する。ただし、リーフ (訳注：下位クラスを持たないクラス) の新規追加を除く。

5. プライベートデータを追加、または削除する。 これにより全サブクラスのサイズとレイアウトが変更されてしまうため。

6. public もしくは protected メンバ関数がインライン関数でない場合に、それらを削除する。

7. public もしくは protected メンバ関数をインライン化する。

8. インライン関数の挙動を変更する。ただし、古いバージョンが機能し続ける場合を除く。

9. 可搬性を持たせたいプログラム内のメンバ関数のアクセス権 (すなわち、public, protected または private) を変更する。 アクセス権情報を関数名に組み入れるコンパイラもあるため。

この長いリストのことを考えると (訳注：＝こんな長いリストの全項目を守り続けることは無理だろうから)、特に C++ ライブラリの開発者は、バイナリ互換性を維持できない更新を頻繁に実施することを計画しておく必要があります。 幸いにして、Unix 系システム (Linux を含みます) では、一つのライブラリの複数のバージョンを同時にロードすることができるので、ディスクスペースを消費することにはなりますが、古いライブラリを必要とする「古い」プログラムを引き続き実行することが可能です。

## 動的ライブラリ

動的ライブラリは、プログラムの起動時以外のときにロードされるライブラリです。 動的ライブラリは、プラグインやモジュールを実装するときに特に便利です。 というのは、必要になるまで、プラグインのロードを待機させることができるからです。 例えば、Pluggable Authentication Modules (PAM) システムでは、管理者が認証の設定／再設定をおこなえるよう、動的ライブラリを使用しています。 また、効率を上げるために途中で休止せずにその時々でコードをマシンコードにコンパイルし、そのコンパイルされたものを使用するというインタプリタを実装するのにも役に立ちます。 この方法は、例えばジャストインタイム・コンパイラや、マルチユーザ・ダンジョン (MUD) を実装するときに使えます。

Linux では、実際のところ、フォーマットという視点から見ると、動的ライブラリは特別なものではありません。 今まで述べてきたものと同じで、標準的なオブジェクトファイルや共有ライブラリとしてビルドされています。 主な違いは、動的ライブラリは、プログラムのリンク時や起動時に自動的にはロードされない、という点です。 そのかわりに、ライブラリをオープンし、シンボルを検索し、エラーを処理し、ライブラリを閉じる、という API が存在します。 この API を使用するためには、C プログラマはヘッダファイル <dlfcn.h> をインクルードする必要があります。

Linux で使用されるインターフェースは、基本的に Solaris のものと同じです。 これを「dlopen()」API と呼ぼうと思います。 しかし、このインターフェースは全てのプラットフォームでサポートされているわけではありません。 HP-UX では shl_load() という別の仕組みが使用され、Windows プラットフォームでは全く異なるインターフェースである DLL が使用されます。 広範な移植性を最終目標とするならば、おそらく、プラットフォーム間の差違を隠蔽するラッパーライブラリの使用を検討したほうがよいでしょう。 方法の一つとして、モジュールの動的ローディングをサポートする glib ライブラリがあります。 glib ライブラリは、プラットフォーム固有の動的ローディング・ルーチン群を内部で使用し、動的ローディング用の移植性の高いインターフェースを実装しています。 glib については、http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html を参照してください。 glib のインターフェースについては、glib のドキュメントで十分に説明されているので、ここではこれ以上言及しません。 もう一つの方法は、libltdl を使う方法です。 libltdl は、GNU libtool の一部です。 もっと多くの機能が必要ならば、CORBA Object Request Broker (ORB) を調べてみるのもよいでしょう。 Linux と Solaris でサポートされるインターフェースを直接使用することにまだ興味をお持ちならば、読み進んでください。

C++ と動的ライブラリを使用する開発者の方は、「C++ dlopen mini HOWTO」も参照してください。

### dlopen()

dlopen(3) 関数は、ライブラリをオープンし、使用前の準備をおこないます。 C のプロトタイプは次のようになります。

      void * dlopen(const char *filename, int flag);

ファイル名が「/」で始まるならば (つまり絶対パスならば)、dlopen() は単にそのファイル名を使おうとします (ライブラリを検索しようとはしません)。 それ以外ならば、dlopen() は次の順番でライブラリを検索します。

1. ユーザの LD_LIBRARY_PATH 環境変数内のコロンで区切られたディレクトリリスト

2. /etc/ld.so.cache 内に指定されたライブラリリスト (/etc/ld.so.cache は /etc/ld.so.conf をもとに生成されます)

3. /lib, 次に /usr/lib. この順番に注意してください。この順番は、古い a.out ローダで使われていた順番とは逆です。 古い a.out ローダは、プログラムをロードするとき、最初に /usr/lib を検索し、そのあとで /lib を検索していました (man ページ ld.so(8) を参照してください)。 このことは、通常は問題にならないはずです。 なぜなら、ライブラリはどちらか一方のディレクトリのみに置いてあるはずだからです。 異なるライブラリに同じ名前を付けると、混乱を招きます。

dlopen() では、flag の値は RTLD_LAZY か RTLD_NOW のどちらかでなければなりません。 RTLD_LAZY は、「動的ライブラリのコードが実行されるときに未定義シンボルを解決せよ」という意味で、RTLD_NOW は、「dlopen() がリターンする前に全ての未定義シンボルを解決せよ、それができないようならば失敗せよ」という意味です。 RTLD_GLOBAL は、flag のどちらかの値と任意で論理和結合させることができます。 RTLD_GLOBAL フラグを付けてロードされたライブラリ内で定義されている外部シンボルは、後からロードされるライブラリからでも使用できるようになります。 デバッグ中は、おそらく RTLD_NOW を使いたくなるでしょう。 RTLD_LAZY を使うと、未解決の参照があったときに不可解なエラーが生成されます。 RTLD_NOW を使うと、ライブラリのオープンには若干時間がかかるようになります (しかし、のちのちの検索速度は速くなります)。 このことがユーザインターフェース上問題になるようでしたら、あとで RTLD_LAZY に切り替えることができます。

ライブラリが他のライブラリに依存しているなら (例えば、X が Y に依存している)、依存されているほうを先にロードしてください (この例で言えば、Y を先にロードし、それから X をロードします)。

dlopen() の戻り値は、他の動的ライブラリ・ルーチンによって使用される「ハンドル」です (このハンドルの実体は隠蔽されているものとして扱ってください)。 ロードが失敗した場合、dlopen() は NULL を返しますので、戻り値をチェックする必要があります。 同じライブラリが dlopen() で二回以上ロードされると、同じファイルハンドルが返されます。

古いシステムでは、ライブラリが _init という名前のルーチンをエクスポートしている場合、dlopen() から戻る前にそのコードが実行されます。 この仕組みを使って、ライブラリの初期化ルーチンを実装することができます。 しかし、ライブラリは、_init や _fini といった名前のルーチンをエクスポートすべきではありません。 これらの仕組みは古くなっており、望んでいない動作をする可能性があります。 かわりに、ライブラリでは、__attribute__((constructor)) 関数属性と __attribute__((destructor)) 関数属性を使用してルーチンをエクスポートしてください (gcc を使用しているものと仮定しています)。 詳細については を参照してください。

### dlerror()

dlerror() によりエラーを報告できます。 dlerror() は、最後の dlopen(), dlsym(), または dlclose() 呼出しのエラーについて説明する文字列を返します。 一つ変わっているのは、dlerror() を呼び出すと、以降の dlerror() の呼出しは他のエラーが発生するまで NULL を返すという点です。

### dlsym()

動的ライブラリをロードしても、それを使えなければ意味がありません。 動的ライブラリを使用する上で中心となるルーチンは dlsym(3) です。 dlsym() は、与えられた (オープン済みの) ライブラリ内にあるシンボルの値を検索します。 この関数は次のように定義されています。

      void * dlsym(void *handle, char *symbol);

handle は dlopen() から返される値で、symbol はヌル文字で終端された文字列です。 dlsym() の結果を void * ポインタに格納することは、できるだけ避けてください。 なぜなら、そのポインタを使用するたびにキャストしなければならなくなるからです (そのプログラムをメンテナンスしようとする他の方々が受け取れる情報量も減ってしまいます)。

dlsym() は、シンボルが見つからなければ NULL を返します。 シンボルが NULL もしくはゼロという値をとることはありえないと分かっていれば、問題ありません。 しかし、そうでない場合は潜在的に曖昧さが残ります。もしも NULL を受け取った場合、それは、「そんなシンボルは存在しない」ということを意味するのでしょうか、それとも「そのシンボルの値は NULL である」ということを意味するのでしょうか？ 標準的な方法は、(存在している可能性のあるエラー条件をクリアするために) まず最初に dlerror() を呼び、次に、シンボルを要求するために dlsym() を呼び、最後に、エラーが発生しているかどうかを調べるために再度 dlerror() を呼び出す、というものです。 コードは次のようになるでしょう。

      dlerror(); /* エラーコードをクリアする。*/
      s = (actual_type) dlsym(handle, symbol_being_searched_for);
      if ((err = dlerror()) != NULL) {
          /* ハンドルエラー。シンボルは見つからなかった。*/
      } else {
          /* シンボルが見つかった。値は s に格納されている。*/
      }

### dlclose()

dlopen() の逆が dlclose() です。dlclose() で動的ライブラリをクローズします。 dl ライブラリは動的なファイルハンドルへのリンク数を管理しているので、同一の動的ライブラリに対して、dlopen() が成功した回数と同じ数の dlclose() が呼ばれない限り、当該ライブラリは実際にはメモリ上から削除されません。 ですので、同じプログラムが同じライブラリを何回ロードしても、問題にはなりません。 ライブラリの割当てが解除されるとき、古いライブラリでは、(もしも存在するならば) _fini 関数が呼ばれます。 しかし、_fini は古い仕組みなので、これに依存してはいけません。 かわりに、ライブラリでは、__attribute__((constructor)) 関数属性と __attribute__((destructor)) 関数属性を使用してルーチンをエクスポートしてください。 詳細については を参照してください。 注意：dlclose() は、成功ならば 0 を、エラーならば非ゼロを返します。 この返り値について言及していない Linux man ページもあります。

### 動的ライブラリの例

dlopen(3) の man ページ内の例をここに掲載します。 この例では、数学ライブラリをロードし、2.0 のコサインを出力しています。 また、全てのステップでエラーをチェックしています (推奨)。

      #include <stdlib.h>
      #include <stdio.h>
      #include <dlfcn.h>

      int main(int argc, char **argv) {
          void *handle;
          double (*cosine)(double);
          char *error;

          handle = dlopen ("/lib/libm.so.6", RTLD_LAZY);
          if (!handle) {
              fputs (dlerror(), stderr);
              exit(1);
          }

          cosine = dlsym(handle, "cos");
          if ((error = dlerror()) != NULL)  {
              fputs(error, stderr);
              exit(1);
          }

          printf ("%f\n", (*cosine)(2.0));
          dlclose(handle);
      }

このプログラムが "foo.c" という名前のファイルだとすると、次のコマンドでプログラムを作成することができます。

      gcc -o foo foo.c -ldl

## 雑録

### nm コマンド

nm(1) コマンドは、指定されたライブラリ内に存在するシンボルのリストを表示します。 静的ライブラリ、共有ライブラリのどちらに対しても機能します。 指定されたライブラリについて、nm(1) は、定義されているシンボルの名前、それぞれのシンボルの値、シンボルのタイプ、を表示できます。 また、そのライブラリ内に情報が存在するならば (-l オプションを参照してください)、シンボルがソースコード内のどこで (ファイル名と行番号) 定義されているかということも特定できます。

シンボルタイプについては、もう少し説明が必要です。 小文字はそのシンボルがローカルであることを意味し、大文字はそのシンボルがグローバル (外部定義) であることを意味します。 典型的なシンボルタイプは次のとおりです。

- T (コードセクション内の普通の定義)

- D (初期化されたデータセクション)

- B (初期化されないデータセクション)

- U (未定義。シンボルはライブラリによって使われているが、ライブラリ内では定義されていない)

- W (weak. もしも他のライブラリも同じシンボルを定義している場合、その定義によりオーバーライドされる)

関数の名前は覚えているけれども、それがどのライブラリで定義されているか正確には思い出せない場合、nm の「-o」オプションを使い (コマンドラインではファイル名より前に置きます)、出力を grep することによって、ライブラリ名を見つけ出すことができます。 Bourne シェルであれば、/lib, /usr/lib, /usr/lib 直下のサブディレクトリ、および /usr/local/lib 内の全ライブラリを対象にして「cos」を検索するには、次のようにします。

      nm -o /lib/* /usr/lib/* /usr/lib/*/* \
            /usr/local/lib/* 2> /dev/null | grep 'cos$'

nm に関する詳細な情報は、お手元のマシンにインストールされている nm の「info」文書 (info:binutils#nm) 内にあります。

### ライブラリのコンストラクタ関数およびデストラクタ関数

ライブラリの初期化ルーチンと終了処理ルーチンは、gcc の __attribute__((constructor)) 関数属性と __attribute__((destructor)) 関数属性を使用してエクスポートします。 これらの関数属性に関する情報は gcc の info ページを参照してください。 コンストラクタルーチンは、dlopen() から戻る前に実行されます (または、ライブラリがプログラム開始時にロードされるならば main() 開始前)。 デストラクタルーチンは dlclose() から戻る前に実行されます (または、ライブラリがプログラム開始時にロードされたならば、exit() の後、もしくは main() 完了後)。 これらの関数の C 言語プロトタイプは次のようになります。

      void __attribute__ ((constructor)) my_init(void);
      void __attribute__ ((destructor)) my_fini(void);

共有ライブラリをコンパイルするときは、gcc オプションの「-nostartfiles」や「-nostdlib」を付けてはいけません。 これらのオプションが使われると、(特殊な方法を用いない限り) コンストラクタルーチンおよびデストラクタルーチンが実行されなくなってしまいます。

#### 特別な関数 _init と _fini (古い仕組み／危険)

歴史的な経緯により、コンストラクタとデストラクタを制御することができる二つの特別な関数、_init と _fini が存在しています。しかしながら、これらは古くなっており、使用すると、予測できない結果を招くことがあります。 あなたのライブラリでは、これらの関数を使用しないようにしてください。 かわりに、上で説明した関数属性の constructor と destructor を使用してください。

古いシステムや、_init または _fini を使用しているコードを扱わなければならないときのため、_init と _fini の動作をここで説明します。 二つの特別な関数 _init と _fini は、モジュールの初期化と終了処理のために定義されました。 「_init」関数がライブラリ内でエクスポートされている場合、そのライブラリが初めて (dlopen() により、または単に共有ライブラリとして) オープンされたときに呼び出されます。C プログラムでは、_init という名前の何らかの関数を定義しているということを意味します。_init に対応する関数として _fini が存在します。_fini は、(参照カウントをゼロにする dlclose() の呼出しか、またはプログラムの通常の終了により) クライアントがライブラリの使用を終了したときに呼び出されます。 これらの関数の C 言語プロトタイプは次のようになります。

      void _init(void);
      void _fini(void);

この場合は、gcc でファイルを「.o」ファイルにコンパイルするとき、忘れずに gcc オプション「-nostartfiles」を付けてください。 このオプションは、.so ファイルに対してシステムスタートアップライブラリをリンクしないよう、C コンパイラに伝えるものです。 このオプションを付けないと、「multiple-definition (重複定義)」エラーが発生してしまいます。 お勧めしている関数属性を用いてモジュールをコンパイルする方法と、この方法とは、全く異なるものなので注意してください。 _init と _fini に関する議論を加えることを提案してくれたこと、およびその記述を手伝ってくれたことに対して、Jim Mischel と Tim Gentry に感謝します。

### 共有ライブラリはスクリプト化できる

通常のライブラリフォーマットとは異なる、特別なスクリプト言語で記述されたテキストファイルを、GNU ローダが共有ライブラリとして扱えることは、注目に値します。 この機能は、他のライブラリを間接的に結合させる際に便利です。 例えば、私のシステムの一つでは、`/usr/lib/libc.so` の中身は次のようになっています。

      /* GNU ld スクリプト
         共有ライブラリを使うが、幾つかの関数は静的ライブラリ内にしか
         存在しない。そのため、共有ライブラリ内に関数が見つからなければ、
         静的ライブラリを検索しにいく。*/
      GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )

これに関するより詳しい情報は、ld リンカスクリプト (ld コマンド言語) に関する texinfo 文書を参照してください。 一般的な情報は info:ld#Options と info:ld#Commands にあり、よく使うコマンドは info:ld#Option Commands で説明されています。

### シンボルのバージョン付けとバージョンスクリプト

通常、外部関数への参照は必要に応じてバインドされます。 アプリケーションの起動時に全てがバインドされるわけではありません。 共有ライブラリが古いものである場合、必要なインターフェースが存在しないかもしれません。 アプリケーションがそのようなインターフェースを使おうとしたときになって初めて、アプリケーションは突然予期せぬエラーを起こします。

この問題に対する一つの解決方法は、バージョンスクリプトによるシンボルのバージョン付けです。 シンボルのバージョン付けにより、アプリケーションにより使用されるライブラリが古すぎる場合に、そのアプリケーションを起動したときに警告が出るようになります。 これについては、バージョンスクリプトに関する ld マニュアルの説明 (http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html) を参照してください。

### GNU libtool

多くのシステムに移植する必要のあるアプリケーションを作成しているならば、ライブラリの構築とインストールについて、GNU libtool を使用することを検討したほうがよいかもしれません。 GNU libtool は、汎用的なライブラリサポートスクリプトです。 libtool は、共有ライブラリ使用時の複雑さを、一貫性のある移植性の高いインターフェースで隠蔽します。 libtool は、オブジェクト作成、ライブラリのリンク (静的および共有)、実行可能ファイルのリンク、実行可能ファイルのデバッグ、ライブラリのインストール、実行可能ファイルのインストール、に対して、移植性の高いインターフェースを提供します。 また、libltdl という、プログラムを動的にロードするための移植性のあるラッパーも、libtool には含まれています。詳細については、libtool の文書 http://www.gnu.org/software/libtool/manual.html を参照してください。

### スペースを節約するためにシンボルを削除する

生成されたファイル内に含まれるシンボルは全て、デバッグの際に役に立ちますが、スペースを取ります。 スペースを節約する必要があるならば、シンボルの一部を削除することができます。

一番良い方法は、最初にいつも通りにオブジェクトファイルを生成し、デバッグとテストを全て実行してしまうことです (シンボルを含むオブジェクトファイルでは、デバッグとテストは非常に簡単です)。 その後、プログラムを完全にテストし終えたら、strip(1) を用いてシンボルを削除します。 strip(1) コマンドでは、どのシンボルを削除するかについて、いろいろと制御することができます。 詳細については strip(1) の文書を参照してください。

もう一つの方法は、GNU ld オプションの「-S」と「-s」を使用することです。 「-S」は、出力ファイルから、(全てではないですが) デバッグシンボル情報を除外します。 一方、「-s」は、出力ファイルから全てのシンボル情報を除外します。 「-Wl,-S」や「-Wl,-s」とすることにより、これらのオプションを gcc 経由で ld に渡せます。 常にシンボルを取り除くことにしていて、これらのオプションで十分というのならば、それでよいでしょう。 ただし、このやり方は、strip(1) に比べ柔軟性が下がります。

### 極端に小さな実行可能ファイル

「Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (本当に小さな Linux 用 ELF 実行可能ファイル作成についてのすぐ役立つチュートリアル)」という文書が、あなたの役に立つかもしれません。 この文書は、非常に小さな実行可能プログラムの作り方について説明しています。 率直に言えば、一般的な状況下では、この文書で紹介されているトリックのほとんどは、使わないほうがよいです。 しかしこの文書は、ELF が実際にどのように機能するかを示しているという点において、教育上極めて有益です。

### C++ vs. C

C++ プログラムを書いていて、C ライブラリ関数を呼び出すなら、C++ コード内でその C 関数を extern "C" として宣言する必要があるので注意してください。 そうしないと、リンカがその C 関数を見つけることができなくなってしまいます。 内部的に、C++ コンパイラは C++ 関数の名前を「変形 (mangle)」します (例えば、型情報を付加するために)。そのため、C++ コンパイラには、指定された関数を C 関数として呼び出すことを教えてやる必要があります (これにより、その C 関数の名前は変形されなくなります)。

C または C++ から呼び出されるプログラムライブラリを作成しているのなら、ライブラリユーザのため、この処理が自動的におこなわれるよう、ヘッダファイルに「extern "C"」を含めることをお勧めします。 ヘッダファイルの再読込みをスキップするためにヘッダファイルの先頭に置く、いつもの #ifndef と組み合わせて示すとすれば、C および C++ のどちらでも使用可能なヘッダファイルの典型例は、例えば foobar.h だとすると、次のようになります。

      /* foobar が何をするものなのか、ここで説明する。*/

      #ifndef FOOBAR_H
      #define FOOBAR_H

      #ifdef __cplusplus
      extern "C" {
      #endif

       ... foobar 用ヘッダコードをここに書く ...

      #ifdef  __cplusplus
      }
      #endif
      #endif

### C++ 初期処理の高速化

KDE 開発者は、大きな GUI C++ アプリケーションの起動に長い時間がかかり、その理由の一つが、数多くのリロケーションをおこなう必要があることだと気付いています。 この問題に対して、幾つか解決方法があります。詳細については、「Making C++ ready for the desktop (by Waldo Bastian) (C++ コードをデスクトップ向けにする (Waldo Bastian 著))」を参照してください。

### Linux Standard Base (LSB)

Linux Standard Base (LSB) プロジェクトの目的は、Linux ディストリビューション間の互換性を高め、LSB に準拠する全ての Linux システム上でソフトウェアアプリケーションの実行を可能とするための標準を開発し、普及させることです。 このプロジェクトのホームページは http://www.linuxbase.org/ です。

LSB 準拠アプリケーションの開発方法について簡単にまとめた、George Kraft IV (IBM Linux テクノロジーセンター上級ソフトウェアエンジニア) による素晴らしい文書、Developing LSB-certified applications: Five steps to binary-compatible Linux applications (訳注：日本語訳はこちら→ LSB 認定アプリケーション開発) が 2002 年 10 月に公開されました。 当然ながら、自分のコードの移植性を高めたいならば、標準化された移植層のみを使用してコードを書く必要があります。 さらに、LSB では、C/C++ プログラムのアプリケーション作成者が LSB に準拠しているかどうかをチェックするために使えるツールを、幾つか提供しています。 これらのツールは、リンカの幾つかの機能と、チェックをおこなうための特別なライブラリを使用しています。 もちろん、チェックをおこなうためには、ツール群をインストールする必要があります。 ツール群は LSB のウェブサイトから取得できます。 取得後は、C/C++ コンパイラとして単に "lsbcc" コンパイラを使ってください (lsbcc は、何かしらの LSB 規則が守られていないときにその旨を出力するためのリンク用環境変数を、内部的に作成します)。

      $ CC=lsbcc make myapplication
       (または)
      $ CC=lsbcc ./configure; make myapplication

続けて、当該プログラムが LSB で標準化されている関数だけを使用していることを確認するため、 lsbappchk プログラムを使用します。

      $ lsbappchk myapplication

LSB のパッケージングガイドラインに従う必要もあります (例えば、RPM バージョン 3 を使う、LSB 準拠のパッケージ名を使う、アドオンソフトウェアの場合はデフォルトで /opt にインストールしなければならない、など)。 詳細については、先に言及した文書と LSB ウェブサイトを参照してください。

### ライブラリ群を統合して大きな共有ライブラリへ

最初に小さいライブラリ群を作成しておき、後からそれらを大きなライブラリへとマージしたいという場合、どうしたらよいでしょうか？ このようなときは、ld の "--whole-archive" オプションが便利です。 このオプションは、.a ファイル群を強制的に一つの .so ファイルへリンクする際に使用できます。

--whole-archive の使い方の一例を挙げます。

      gcc -shared -Wl,-soname,libmylib.$(VER) -o libmylib.so $(OBJECTS) \
          -Wl,--whole-archive $(LIBS_TO_LINK) -Wl,--no-whole-archive \
          $(REGULAR_LIBS)

ld 文書でも示されているとおり、最後に --no-whole-archive オプションを使うようにしてください。 そうしないと、gcc は標準ライブラリ群もマージしようとしてしまいます。 --whole-archive に関する記述の提案と作成の両方に対して、Kendall Bennett に感謝します。

## 例

三つの方法 (静的ライブラリ、共有ライブラリ、動的ライブラリ) 全ての例を以下に挙げます。 libhello.c ファイルは簡単なライブラリで、そのヘッダファイルとして libhello.h があります。 demo_use.c ファイルは、libhello ライブラリを呼び出す簡単なプログラムです。 続けて、コメント付きのスクリプト (script_static と script_dynamic) を示します。 これらのスクリプトは、libhello ライブラリを静的ライブラリおよび共有ライブラリとして使う方法を示すものです。 さらに demo_dynamic.c と script_dynamic も挙げます。 これらは、共有ライブラリを動的ライブラリとして使う方法を示すものです。

### libhello.c ファイル

      /* libhello.c - ライブラリ使用方法を示します */

      #include <stdio.h>

      void hello(void) {
          printf("Hello, library world.\n");
      }

### libhello.h ファイル

      /* libhello.h - ライブラリ使用方法を示します */

      void hello(void);

### demo_use.c ファイル

      /* demo_use.c -- "hello" ルーチンを直接使用する方法を示します */

      #include "libhello.h"

      int main(void) {
          hello();
          return 0;
      }

### script_static ファイル

      #!/bin/sh
      # 静的ライブラリのデモ

      # 静的ライブラリのオブジェクトファイル libhello-static.o を
      # 作成します。静的ライブラリの例と動的ライブラリの例を明確に
      # 区別するため、libhello-static という名前を使用しています。
      # しかし、オブジェクトファイルや静的ライブラリの名前に
      # "-static" を使う必要はありません。

      gcc -Wall -g -c -o libhello-static.o libhello.c

      # 静的ライブラリを作成します。

      ar rcs libhello-static.a libhello-static.o

      # この段階で、libhello-static.a をどこか他の場所へコピーして
      # 使用することもできますが、デモが目的なので、libhello-static.a
      # ライブラリはカレントディレクトリ内に置いたままにします。

      # demo_use プログラムをコンパイルします。

      gcc -Wall -g -c demo_use.c -o demo_use.o

      # demo_use プログラムを作成します。-L. オプションにより、プロ
      # グラム作成中、カレントディレクトリ "." が検索されます。この
      # コマンドにより、libhello-static 内の関連するオブジェクト
      # ファイルが demo_use_static に組み込まれます。

      gcc -g -o demo_use_static demo_use.o -L. -lhello-static

      # プログラムを実行します。

      ./demo_use_static

### script_shared ファイル

      #!/bin/sh
      # 共有ライブラリのデモ

      # 共有ライブラリのオブジェクトファイル libhello.o を作成します。

      gcc -fPIC -Wall -g -c libhello.c

      # 共有ライブラリを作成します。libhello は C ライブラリに依存して
      # いるので、C ライブラリとリンクさせるために -lc オプションを使い
      # ます。

      gcc -g -shared -Wl,-soname,libhello.so.0 \
          -o libhello.so.0.0 libhello.o -lc

      # この段階で、libhello.so.0.0 を、/usr/local/lib 等のどこかの
      # ディレクトリへコピーしてもかまいません。

      # シンボリックリンクを修正するため、ldconfig を呼び出す必要が
      # あります。

      # soname を設定します。単に、
      #
      #   ln -sf libhello.so.0.0 libhello.so.0
      #
      # を実行するだけでもよいですが、ldconfig にやってもらいましょう。

      /sbin/ldconfig -n .

      # linker name を設定します。設定手順をより洗練させるならば、既に
      # linker name が存在するかどうかを調べ、存在する場合には linker
      # name を残すべきか否かを確認する必要があります。

      ln -sf libhello.so.0 libhello.so

      # demo_use プログラムをコンパイルします。

      gcc -Wall -g -c demo_use.c -o demo_use.o

      # demo_use プログラムを作成します。-L. オプションにより、プロ
      # グラム作成中、カレントディレクトリ "." が検索されます。これは、
      # プログラム実行時にカレントディレクトリ "." が検索されるという
      # 意味ではないので注意してください。

      gcc -g -o demo_use demo_use.o -L. -lhello

      # プログラムを実行します。LD_LIBRARY_PATH を使って、どこに共有
      # ライブラリが存在するかをプログラムに教える必要があることに
      # 注意してください。

      LD_LIBRARY_PATH="." ./demo_use

### demo_dynamic.c ファイル

      /*
       * demo_dynamic.c
       *
       * 動的ローディングと "hello" ルーチンの使用方法を示します
       */

      /*
       * 動的にライブラリをロードするルーチン用に dlfcn.h が必要
       */
      #include <dlfcn.h>

      #include <stdlib.h>
      #include <stdio.h>

      /*
       * "libhello.h" をインクルードする必要がないことに注意して
       * ください。但し、関連情報を指定する必要があります。
       * dlsym() で取得する値を保持するための型が必要です。
       */

      /*
       * "simple_demo_function" 型は、引数を取らず、何も値を返さない
       * 関数を示しています。
       */

      typedef void (*simple_demo_function)(void);

      int main(void) {
          const char *error;
          void *module;
          simple_demo_function demo_function;

          /* 動的ライブラリをロードする */
          module = dlopen("libhello.so", RTLD_LAZY);
          if (!module) {
              fprintf(stderr, "libhello.so をオープンできませんでした: %s\n", dlerror());
              exit(1);
          }

          /* シンボルを取得する */
          dlerror();
          demo_function = dlsym(module, "hello");
          if ((error = dlerror())) {
              fprintf(stderr, "hello が見つかりませんでした: %s\n", error);
              exit(1);
          }

          /* 動的ライブラリ内の関数を呼び出す */
          (*demo_function)();

          /* 全て終了。きちんとクローズする */
          dlclose(module);

          return 0;
      }

### script_dynamic ファイル

      #!/bin/sh
      # 動的ライブラリのデモ

      # libhello.so とその関連ファイルが既に作成されているものと
      # 仮定しています (共有ライブラリのデモを参照してください)。

      # demo_dynamic プログラムファイルをオブジェクトファイルへ
      # コンパイルします。

      gcc -Wall -g -c demo_dynamic.c

      # demo_use プログラムを作成します。このプログラムが使用する
      # 唯一の特別なライブラリは、プログラム起動後までロードされ
      # ないので、動的ライブラリをどこに探しにいけばよいかを教える
      # 必要はありません。但し、動的ライブラリをロードするための
      # ライブラリを含めるのに、-ldl オプションが必要となります。

      gcc -g -o demo_dynamic demo_dynamic.o -ldl

      # プログラムを実行します。LD_LIBRARY_PATH を使って、どこに
      # 動的ライブラリが存在するかをプログラムに教える必要がある
      # ことに注意してください。

      LD_LIBRARY_PATH="." ./demo_dynamic

## その他の情報源

ライブラリに関する特に有益な情報源を下記に挙げます。

- Daniel Barlow による「The GCC HOWTO」。特に、この HOWTO では、ライブラリ作成用のコンパイラオプションと、ライブラリへの問い合わせ方法が説明されています。 ここでは取り上げていない情報を扱っており、また、逆も真です。この HOWTO は、http://www.linuxdoc.org/ の Linux Documentation Project から入手できます (訳注：GCC HOWTO は、著者の希望により公開が中止されています)。

- Tool Interface Standards (TIS) 委員会による「Executable and Linkable Format (ELF)」 (実はこの文書は、同委員会による Portable Formats Specification Version 1.1 内の一つの章です)。この文書は、ELF フォーマット (Linux や GNU gcc に特化したものではありません) に関する大量の詳細情報を提供するものです。 ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz を参照してください。MIT からファイルを取得する場合、フォーマットが一般的なものではないので注意してください。 gunzip して tar で解凍すると、「hps」ファイルができます。 ファイルの最初と最後の行を削除し、「ps」ファイルに名前を変更すれば、いつものファイル名の、印字可能な PostScript ファイルを取得できます。

- Hongjui Lu による「ELF: From the Programmer's Perspective」。 Linux と GNU gcc に特化した ELF 関連情報があります。 ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz で取得できます。

- ld 文書「Using LD, the GNU linker」には、ld についてより詳しい説明があります。 http://www.gnu.org/software/binutils/manual/ld-2.9.1/ で参照できます。

- いつもの「info」文書、特に ld と gcc の info 文書も参照してください。

- (訳者による追加) 佐野武俊さんによる「Linux C Library (libc) について」。 Linux C Library (libc) の概要について、その役割と歴史などを簡単にまとめたものです。 http://www.linux.or.jp/JF/JFdocs/libc-intro.html で参照できます。

## 著作権とライセンス

この文書の著作権は David A. Wheeler にあり (Copyright (C) 2000)、GNU 一般公有使用許諾 (GPL) により保護されます。 代価なしで再配布しても構いません。 文書の原文を「プログラム」と解釈し、次の条項も守ってください。

> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

> 本プログラムはフリー・ソフトウェアです。あなたは、Free Software Foundation が公表した GNU 一般公有使用許諾の「バージョン 2」或いはそれ以降の各バージョンの中からいずれかを選択し、そのバージョンが定める条項に従って本プログラムを再頒布または変更することができます。

> This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

> 本プログラムは有用とは思いますが、頒布にあたっては、市場性及び特定目的適合性についての暗黙の保証を含めて、いかなる保証も行ないません。詳細については GNU 一般公有使用許諾書をお読みください。

> You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

> あなたは、本プログラムと一緒に GNU 一般公有使用許諾の写しを受け取っているはずです。 そうでない場合は、Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 0211-1307, USA へ手紙を書いてください。

これらの条項は、他のウェブサイトがミラーリングをすることを許可するものですが、

- あなたのミラーサイトがマスターサイトから最新情報を自動的に取得するようにし、

- マスターサイトへのハイパーリンクと共にマスターサイトのロケーション http://www.dwheeler.com/program-library/ を明示し、そして

- 著者として、私 (David A. Wheeler) に謝辞をお願いします。

はじめの二つは、主に、過去のバグについて何度も言及されることを防ぐためです。 あなたが文書を適切にミラーリングしていないというだけの理由で、一年前に直したバグに関する話を私は聞きたくはありません。 マスターサイトへリンクを張ることにより、ユーザはあなたのサイトが最新のものであるかどうかを確認できます。 非常に厳しいセキュリティ要求があり、そのためにインターネットへ通常に接続するリスクを取ることができないサイトの問題を、私は気にしています。 これがあなたの状況に当てはまるならば、少なくとも、他のポイントへの接続を試みたり、折に触れてあなたの環境へのスニーカーネット (sneakernet) アップデート (訳注：スニーカーネット ＝ FD 等を持ち運びすることにより情報を共有するネットワーク) を試みるなどしてください。

このライセンスによれば、あなたはドキュメントを変更しても構いませんが、あなたが書いたものではないものをあなたのものであると主張したり (つまり盗用です)、変更したバージョンが原作であるかのようなふりをすることはできません。 著作物の変更は、著作物全体の著作権をあなたに譲渡するものではありません。 これは、著作権法の用語でいうところの「パブリックドメイン」の著作物ではありません。 ライセンスを細部に渡って参照してください。 特に、「You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. (ファイルを変更した旨とその変更日とを、変更したファイル上に明確に表示すること)」 という点には注意してください。 ライセンスにより何が許可されているかについて質問がある場合は、私に連絡をください。 たいていの場合には、あなたの変更が他のみなさんの変更と共にマスターコピーへ統合されるよう、あなたの変更を統合者 (現在は David A. Wheeler) へ送るのがよいでしょう。

## 日本語訳について

Program Library HOWTO の日本語訳の維持管理は JF プロジェクト (http://www.linux.or.jp/JF/) がおこなっています。日本語訳についてのご意見等は JF プロジェクトのメーリングリスト <JF(a)linux.or.jp> までお願い致します。

### 日本語訳履歴

1.20-ja 2004 年 6 月 30 日 川崎 貴彦 原文バージョン 1.20 の対訳

### 謝辞

日本語に翻訳するにあたり、次の方々にご協力していただきました。 ここにお名前を挙げさせていただくとともに、感謝の意を表したいと思います (順不同、敬称略、1.20-ja 以降)。

- 中谷 千絵 日本語訳校正

                jeanne(a)mbox.kyoto-inet.or.jp

- Seiji Kaneko 日本語訳校正

                se-kane(a)itg.hitachi.co.jp

- その他 JF プロジェクトのメンバーの方々 *

                JF(a)linux.or.jp