<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">

<!-- Linux Documentation Project trick - make the article's id "index" so
     the default HTML page is the title page: -->

<article id="index">

<artheader>
<title>Program Library HOWTO</title>
<author><firstname>David A.</firstname> <surname>Wheeler</surname>
<!--start_japanese-->
  <affiliation>
    <address>
      <email>dwheeler(a)dwheeler.com</email>
    </address>
  </affiliation>
<!--end_japanese-->
</author>
<!--start_original
<address><email>dwheeler@dwheeler.com</email></address>
end_original-->
<!--start_original
<pubdate>version 1.20, 28 April 2003</pubdate>
end_original-->
<!--start_japanese-->
<pubdate>日本語訳：2004 年 9 月 17 日 (原文：2003 年 4 月 28 日、バージョン 1.20)</pubdate>
<!--end_japanese-->
<!--start_japanese-->
<othercredit>
  <othername>川崎 貴彦</othername>
  <contrib>日本語訳</contrib>
  <affiliation>
    <address>
      <email>takahiko(a)hakubi.co.jp</email>
    </address>
  </affiliation>
</othercredit>
<!--end_japanese-->
<abstract>
<para>
<!--start_original
This HOWTO for programmers
discusses how to create and use program libraries on Linux.
This includes static libraries, shared libraries, and
dynamically loaded libraries.
end_original-->
<!--start_japanese-->
この HOWTO はプログラマ向けであり、Linux におけるプログラムライブラリの作成方法と使用方法を説明するものです。
「静的ライブラリ (static library)」、「共有ライブラリ (shared library)」、「動的ライブラリ (dynamically
loaded library)」を対象とします。
(訳注：この訳文では、「dynamically loaded library」のことを「動的ライブラリ」と呼ぶことにします。
世の中では、shared library のことを指して動的ライブラリと表現する例もありますが、それとは異なりますので注意してください。)
<!--end_japanese-->
</para>
</abstract>
</artheader>

<sect1 id="introduction">
<!--start_original
<title>Introduction</title>
end_original-->
<!--start_japanese-->
<title>はじめに</title>
<!--end_japanese-->
<para>
<!--start_original
This HOWTO for programmers
discusses how to create and use program libraries on Linux
using the GNU toolset.
A ``program library'' is simply a file containing compiled code (and data)
that is to be incorporated later into a program;
program libraries allow programs to be more modular, faster to recompile,
and easier to update.
Program libraries can be divided into three types:
static libraries, shared libraries, and
dynamically loaded (DL) libraries.
end_original-->
<!--start_japanese-->
この HOWTO はプログラマ向けであり、GNU ツールセットを利用して、Linux
上でプログラムライブラリを作成する方法、およびその使用方法を説明するものです。
「プログラムライブラリ」とは、のちのちプログラムに組み込むためのコンパイル済みコード (およびデータ)
を含む、単なるファイルのことです。プログラムライブラリは、プログラムを、よりモジュール化され、より速く再コンパイルでき、より簡単に更新できるものにします。
プログラムライブラリは三つのタイプ、すなわち、静的ライブラリ
(static library)、共有ライブラリ (shared library)、動的ライブラリ
(dynamically loaded library)、に分類することができます。
<!--end_japanese-->
</para>

<para>
<!--start_original
This paper first discusses static libraries, which are installed
into a program executable before the program can be run.
It then discusses shared libraries, which are loaded at program
start-up and shared between programs.
Finally, it discusses dynamically loaded (DL) libraries, which can
be loaded and used at any time while a program is running.
DL libraries aren't really a different kind of library format
(both static and shared libraries can be used as DL libraries);
instead, the difference is in how DL libraries are used by programmers.
The HOWTO wraps up with a section with more examples and a section
with references to other sources of information.
end_original-->
<!--start_japanese-->
この文書は、最初に、静的ライブラリ
(プログラムが実行される前にその実行可能プログラムに組み込まれるライブラリ)
について説明します。それから、共有ライブラリ
(プログラム実行時にロードされ、かつ複数のプログラム間で共有されるライブラリ)
について説明します。最後に、動的ライブラリ
(プログラム実行中の任意の時点でロードして使用することが可能なライブラリ)
について説明します。
動的ライブラリのライブラリフォーマットは、実際には別の種類というわけではありません
(静的ライブラリも共有ライブラリも動的ライブラリとして使用することが可能です)。
その代わりに、プログラマが動的ライブラリを使用する方法に違いがあります。
この HOWTO は、例を挙げている章と、その他の情報源への参照を挙げている章で締めくくります。
<!--end_japanese-->
</para>

<para>
<!--start_original
Most developers who are developing libraries should create shared libraries,
since these allow users to update their libraries separately from the
applications that use the libraries.
Dynamically loaded (DL) libraries are useful, but they require a little more
work to use and many programs don't need the flexibility they offer.
Conversely, static libraries make upgrading libraries far more troublesome,
so for general-purpose use they're hard to recommend.
Still, each have their advantages, and the advantages of each type
are described in the section discussing that type.
Developers using C++ and dynamically loaded (DL) libraries should also
consult the ``C++ dlopen mini-HOWTO''.
end_original-->
<!--start_japanese-->
ライブラリを開発しているほとんどの開発者は、共有ライブラリを作成すべきです。
というのは、ユーザが、そのライブラリを使用するアプリケーションとは別々にライブラリを更新できるようになるからです。
動的ライブラリは便利ですが、使用するには少し手間がかかります。
また、多くのプログラムでは、動的ライブラリが提供する柔軟性を必要とはしません。
これとは逆に、静的ライブラリの場合、ライブラリを更新するのは非常に厄介です。
そのため、日常的に利用しようとしているならば、静的ライブラリはお勧めしません。
ただし、各ライブラリにはそれぞれの利点があります。
利点については、各ライブラリごとの章でそれぞれ説明します。
C++ と動的ライブラリを使用する開発者は、「<ulink url="http://www.tldp.org/HOWTO/C++-dlopen/"
>C++ dlopen mini HOWTO</ulink>」も参照してください。
<!--end_japanese-->
</para>

<para>
<!--start_original
It's worth noting that some people use the term
dynamically <emphasis>linked</emphasis> libraries (DLLs)
to refer to shared libraries,
some use the term DLL to mean any library that is used
as a DL library, and some
use the term DLL to mean a library meeting either condition.
No matter which meaning you pick, this HOWTO covers DLLs on Linux.
end_original-->
<!--start_japanese-->
共有ライブラリを指して dynamically <emphasis>linked</emphasis> library (DLL) という用語を使う人がいること、その DLL
という用語を動的ライブラリとして使用される任意のライブラリを指すために使う人がいること、また、どちらかの条件を満たすライブラリを指すために
DLL という用語を使う人がいること、には注意したほうがよいです。
いずれを指すにしても、この HOWTO では Linux における DLL を扱います。
<!--end_japanese-->
</para>

<para>
<!--start_original
This HOWTO discusses only the Executable and Linking Format
(ELF) format for executables and libraries, the format
used by nearly all Linux distributions today.
The GNU gcc toolset can actually handle library formats other than ELF;
in particular, most Linux distributions can still
use the obsolete a.out format.
However, these formats are outside the scope of this paper.
end_original-->
<!--start_japanese-->
この HOWTO では、実行可能ファイルおよびライブラリ用の Executable and Linking Format (ELF) フォーマット
(昨今のほとんど全ての Linux ディストリビューションで使用されているフォーマット) についてのみ扱います。
GNU gcc ツールセットは、実際には ELF 以外のライブラリフォーマットを扱うことができます。特に、ほとんどの
Linux ディストリビューションでは、旧式の a.out フォーマットを今なお使用することが可能です。
しかしながら、これらのフォーマットはこの文書の対象外とします。
<!--end_japanese-->
</para>

<para>
<!--start_original
If you're building an application that should port to many systems,
you might consider using
<ulink url="http://www.gnu.org/software/libtool/libtool.html">GNU libtool</ulink>
to build and install libraries instead of using the Linux tools directly.
GNU libtool is a generic library support script that
hides the complexity of using shared libraries
(e.g., creating and installing them) behind a consistent, portable interface.
On Linux, GNU libtool is built on top of the tools and conventions
described in this HOWTO.
For a portable interface to dynamically loaded libraries,
you can use various portability wrappers.
GNU libtool includes such a wrapper, called ``libltdl''.
Alternatively, you could use the glib library (not to be confused
with glibc) with its portable support for Dynamic Loading of Modules.
You can learn more about glib at
<ulink url="http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html">http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html</ulink>.
Again, on Linux this functionality is implemented using the constructs
described in this HOWTO.
If you're actually developing or debugging the code on Linux,
you'll probably still want the information in this HOWTO.
end_original-->
<!--start_japanese-->
多くのシステムへと移植する必要のあるアプリケーションを作成しているならば、ライブラリを構築してインストールするとき、Linux
ツールを直接使用する代わりに、<ulink
url="http://www.gnu.org/software/libtool/libtool.html">GNU libtool</ulink>
を使用することを考慮したほうがよいかもしれません。
GNU libtool は、共有ライブラリ使用時の複雑さ (例えば、共有ライブラリの作成やインストール等)
を一貫性のある移植性の高いインターフェースで隠蔽する、汎用的なライブラリサポートスクリプトです。
Linux 上では、GNU libtool は、この HOWTO で説明されているツール群と約束ごとの上に構築されています。
動的ライブラリに対する移植性の高いインターフェースとして、様々なポータビリティラッパーを使用することができます。
GNU libtool には「libltdl」と呼ばれるラッパーが含まれています。
他の選択肢としては、移植性のある方法でモジュールの動的ローディングをサポートする
glib ライブラリ (glibc と混同しないでください) を使用することもできます。
glib の詳細については
<ulink url="http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html"
>http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html</ulink>
で学習することができます。再度述べますが、Linux 上では、この機能は、この HOWTO
内で説明されている構成物を利用することによって実装されています。もしもあなたが実際に Linux
上でコードの開発またはデバッグをされているなら、おそらく、この HOWTO
内の情報をこれから先必要とされることでしょう。
<!--end_japanese-->
</para>

<para>
<!--start_original
This HOWTO's master location is
<ulink url="http://www.dwheeler.com/program-library">http://www.dwheeler.com/program-library</ulink>, and it has been
contributed to the Linux Documentation Project
(<ulink url="http://www.linuxdoc.org">http://www.linuxdoc.org</ulink>).
It is Copyright (C) 2000 David A. Wheeler and is licensed through the
General Public License (GPL); see the last section for more information.
end_original-->
<!--start_japanese-->
この HOWTO の一次配布場所は
<ulink url="http://www.dwheeler.com/program-library/"
>http://www.dwheeler.com/program-library/</ulink>
であり (訳注：日本語訳は
<ulink url="http://www.linux.or.jp/JF/JFdocs/Program-Library-HOWTO/"
>http://www.linux.or.jp/JF/JFdocs/Program-Library-HOWTO/</ulink>
にあります)、Linux Documentation Project
(<ulink url="http://www.linuxdoc.org/">http://www.linuxdoc.org/</ulink>)
に寄贈されています。著作権は David A. Wheeler にあり (Copyright (C)
2000)、General Public License (GPL)
でライセンスされています。詳細な情報については最後の章を読んでください。
<!--end_japanese-->
</para>
</sect1>

<sect1 id="static-libraries">
<!--start_original
<title>Static Libraries</title>
end_original-->
<!--start_japanese-->
<title>静的ライブラリ</title>
<!--end_japanese-->
<para>
<!--start_original
Static libraries are simply a collection of ordinary object files;
conventionally, static libraries end with the ``.a'' suffix.
This collection is created using the ar (archiver) program.
Static libraries aren't used as often as they once were, because of the
advantages of shared libraries (described below).
Still, they're sometimes created, they existed first historically,
and they're simpler to explain.
end_original-->
<!--start_japanese-->
静的ライブラリは、通常のオブジェクトファイルの単なる集合体です。
慣習として、静的ライブラリは「.a」という拡張子を持ちます。
この集合体は、ar (archiver) プログラムを使用して作成されます。
静的ライブラリは以前ほどには使われなくなっていますが、これは、共有ライブラリのほうが優れているためです
(あとで説明します)。それでもまだ、静的ライブラリは折に触れて作成され
(はじめは歴史的な理由で存在していました)、また、説明するのも簡単です。
<!--end_japanese-->
</para>
<para>
<!--start_original
Static libraries permit users to link to programs without having to
recompile its code, saving recompilation time.
Note that recompilation time is less important given today's faster compilers,
so this reason is not as strong as it once was.
Static libraries are often useful for developers if they wish to
permit programmers to link to their library, but don't want to give
the library source code (which is an advantage to the library vendor, but
obviously not an advantage to the programmer trying to use the library).
In theory, code in static ELF libraries that is linked into an
executable should run slightly faster (by 1-5%) than a shared library
or a dynamically loaded library, but in practice this
rarely seems to be the case due to other confounding factors.
end_original-->
<!--start_japanese-->
ユーザは、コードを再コンパイルする必要なく静的ライブラリをプログラムにリンクすることができるので、再コンパイルにかかる時間を節約できます。
ただ、昨今の高速なコンパイラのことを考えると、再コンパイル時間は重要ではなくなってきているので、この理由付けは以前ほど有力ではありません。
静的ライブラリは、その開発者が、ライブラリをリンクすることをプログラマに許可はしたいがライブラリのソースコードは渡したくはない、という場合にしばしば役に立ちます
(これはライブラリベンダにとっては好都合ですが、そのライブラリを使おうとしているプログラマにとっては、どう考えても好都合とは言えません)。
論理的には、実行可能ファイルにリンクされる静的 ELF ライブラリ内のコードは若干速く
(1 〜 5%) 動作するはずですが、実際には、他のごちゃごちゃした要因のため、その通りになることは稀のようです。
<!--end_japanese-->
</para>
<para>
<!--start_original
To create a static library, or to add additional object files to
an existing static library, use a command like this:
end_original-->
<!--start_japanese-->
静的ライブラリを作成する、もしくは既に存在する静的ライブラリにさらにオブジェクトファイルを追加するためには、次のようなコマンドを使用してください。
<!--end_japanese-->
</para>

<!--start_original
<programlisting>
ar rcs my_library.a file1.o file2.o
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  ar rcs my_library.a file1.o file2.o
</programlisting>
<!--end_japanese-->

<para>
<!--start_original
This sample command adds the object files file1.o and file2.o to the
static library my_library.a, creating my_library.a if it doesn't
already exist.
For more information on creating static libraries, see ar(1).
end_original-->
<!--start_japanese-->
このコマンド例では、静的ライブラリ my_library.a にオブジェクトファイル file1.o と file2.o
を追加しています。まだ my_library.a が存在していなければ、作成します。
静的ライブラリ作成に関する詳細な情報については ar(1) を参照してください。
<!--end_japanese-->
</para>

<para>
<!--start_original
Once you've created a static library, you'll want to use it.
You can use a static library by invoking it as part of the compilation
and linking process when creating a program executable.
If you're using gcc(1) to generate your executable, you can use the -l
option to specify the library; see info:gcc for more information.
end_original-->
<!--start_japanese-->
静的ライブラリを作成したら、それを使いたくなることでしょう。
実行可能プログラムを作成するときにコンパイルとリンク処理の一部として取り込むことで、静的ライブラリを使用できます。
実行可能ファイルを作成するときに gcc(1) を使っているならば、ライブラリを指定するのに -l オプションを使用できます。
より詳しい情報については info:gcc を参照してください。
<!--end_japanese-->
</para>

<para>
<!--start_original
Be careful about the order of the parameters when using gcc;
the -l option is a linker option, and thus needs to be placed
AFTER the name of the file to be compiled.
This is quite different from the normal option syntax.
If you place the -l option before the filename, it may fail to link at all,
and you can end up with mysterious errors.
end_original-->
<!--start_japanese-->
gcc を使うときにはパラメータの順番に気をつけてください。-l
オプションはリンカオプションなので、コンパイルするファイル名の「後に」置く必要があります。
これは、通常のオプション構文とはだいぶ異なります。-l
オプションをファイル名の前に置いた場合、リンクは完全に失敗し、不可解なエラーになってしまうでしょう。
<!--end_japanese-->
</para>

<para>
<!--start_original
You can also use the linker ld(1) directly, using its -l and -L options;
however, in most cases it's better to use gcc(1) since the interface of
ld(1) is more likely to change.
end_original-->
<!--start_japanese-->
-l と -L オプションを使ってリンカ ld(1) を直接使用することもできます。
しかしながら、ld(1) のインターフェースは gcc(1) よりも変更されやすいので、ほとんどの場合は
gcc(1) を使うほうがよいです。
<!--end_japanese-->
</para>
</sect1>

<sect1 id="shared-libraries">
<!--start_original
<title>Shared Libraries</title>
end_original-->
<!--start_japanese-->
<title>共有ライブラリ</title>
<!--end_japanese-->

<para>
<!--start_original
Shared libraries are libraries that are loaded by programs when they start.
When a shared library is installed properly, all programs that start afterwards
automatically use the new shared library.
It's actually much more flexible and sophisticated than this, because the
approach used by Linux permits you to:
end_original-->
<!--start_japanese-->
共有ライブラリは、プログラム起動時にロードされるライブラリです。
共有ライブラリが適切にインストールされると、その後に起動される全てのプログラムは、自動的にその新しい共有ライブラリを使うことになります。
実際には、これよりもはるかに柔軟で洗練されています。なぜなら、Linux
における共有ライブラリの実現方法のおかげで、次のことが可能となるからです。
<!--end_japanese-->
<itemizedlist>
<!--start_original
<listitem><para>update libraries and still support programs that want to use older,
non-backward-compatible versions of those libraries;</para>
</listitem>
end_original-->
<!--start_japanese-->
<listitem>
<para>ライブラリを更新しながらも、そのライブラリの古くて後方互換性のないバージョンを使いたいというプログラムを、引き続きサポートすることができる</para>
</listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>override specific libraries or even specific functions
in a library when executing a particular program.</para>
</listitem>
end_original-->
<!--start_japanese-->
<listitem>
<para>特定のプログラムを実行するとき、特定のライブラリ、もしくはライブラリ内の特定の関数でさえもオーバーライドすることができる</para>
</listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>do all this while programs are running using existing libraries.
</para>
</listitem>
end_original-->
<!--start_japanese-->
<listitem>
<para>既存のライブラリを使用してプログラムが動いている間にも、これら全てをおこなうことができる</para>
</listitem>
<!--end_japanese-->
</itemizedlist>
</para>

<sect2>
<!--start_original
<title>Conventions</title>
end_original-->
<!--start_japanese-->
<title>約束ごと</title>
<!--end_japanese-->
<para>
<!--start_original
For shared libraries to support all of these desired properties,
a number of conventions and guidelines must be followed.
You need to understand the difference between a library's
names, in particular its ``soname'' and ``real name'' (and how they interact).
You also need to understand where they should be placed in the filesystem.
end_original-->
<!--start_japanese-->
これらの望ましい特性すべてを共有ライブラリがサポートするためには、多くの慣習と指針に従わなければなりません。
ライブラリの名前、特に「soname」と「real name」の違いについて
(及びそれらがどのように相互作用するかについて) 学ばなければなりません。
また、それらがファイルシステム内のどの場所に置かれるべきであるかについても、知っておかなければなりません。
<!--end_japanese-->
</para>

<sect3>
<!--start_original
<title>Shared Library Names</title>
end_original-->
<!--start_japanese-->
<title>共有ライブラリ名</title>
<!--end_japanese-->
<para>
<!--start_original
Every shared library has a special name called the ``soname''.
The soname has the prefix ``lib'', the name of the library,
the phrase ``.so'', followed by a period and a
version number that is incremented whenever the interface changes
(as a special exception, the lowest-level C libraries don't start
with ``lib'').
A fully-qualified soname includes as a prefix the directory it's in;
on a working system a fully-qualified soname is simply a symbolic
link to the shared library's ``real name''.
end_original-->
<!--start_japanese-->
全ての共有ライブラリは「soname」と呼ばれる特別な名前を持っています。
soname は、「lib」というプレフィックス、ライブラリの名前、「.so」という語句で構成され、さらに後ろに、ピリオドと、インターフェース変更時に必ず増加するバージョン番号、が続きます
(特別な例外として、最下層の C ライブラリは「lib」では始まりません)。
完全記述の soname は、そのライブラリ自身が含まれるディレクトリをプレフィックスとして含んでいます。
実際のシステムでは、完全記述の soname は、共有ライブラリの「real name」への単なるシンボリックリンクになっています。
<!--end_japanese-->
</para>

<para>
<!--start_original
Every shared library also has a ``real name'', which is the filename
containing the actual library code.
The real name adds to the soname a period, a
minor number, another period, and the release number.
The last period and release number are optional.
The minor number and release number
support configuration control by letting you know exactly what version(s)
of the library are installed.  Note that these numbers might not be
the same as the numbers used to describe the library in documentation,
although that does make things easier.
end_original-->
<!--start_japanese-->
全ての共有ライブラリには「real name」(実際のライブラリコードを含むファイルの名前)
があります。real name は、soname に、ピリオド、マイナー番号、もう一つのピリオド、リリース番号、を加えたものです。
最後のピリオドとリリース番号は任意です。
マイナー番号とリリース番号は、ライブラリのどのバージョンがインストールされているかを正確に示すもので、設定管理に役立ちます。
これらの番号は (同じにしてくれれば話が分かりやすくなるのですが)
文書中でライブラリを説明する際に用いられている番号と同じではないかもしれない、という点に注意してください。
<!--end_japanese-->
</para>

<para>
<!--start_original
In addition, there's the name that the compiler uses when requesting a library,
(I'll call it the ``linker name''), which is simply the soname without
any version number.
end_original-->
<!--start_japanese-->
加えて、ライブラリ要求時にコンパイラが使用する名前というものもあります (「linker name」と呼ぼうと思います)。
この名前は、単純に一切のバージョン番号を取り除いた soname です。
<!--end_japanese-->
</para>

<para>
<!--start_original
The key to managing shared libraries is the separation of these names.
Programs, when they internally list the shared libraries they need,
should only list the soname they need.
Conversely, when you create a shared library, you only create the
library with a specific filename (with more detailed version information).
When you install a new version of a library, you
install it in one of a few special directories and then run the
program ldconfig(8).
ldconfig examines the existing files and creates the sonames as
symbolic links to the real names, as well as setting up the
cache file /etc/ld.so.cache (described in a moment).
end_original-->
<!--start_japanese-->
共有ライブラリを管理する鍵となるのは、これらの名前の使い分けです。
必要とする共有ライブラリの一覧表を内部に持つときには、プログラムは、必要とする
soname のみをリストアップするようにします。
逆に、共有ライブラリを作成するときには、(より詳細なバージョン情報を持つ)
特定のファイル名を持つライブラリのみを作成するようにします。
新しいバージョンのライブラリをインストールするときには、二、三の特別なディレクトリのうちの一つにそれをインストールし、それから
ldconfig(8) プログラムを実行します。
ldconfig は、既に存在するファイルを調べ、real name へのシンボリックリンクとして soname 群を作成します。
同様にして、キャッシュファイル <filename>/etc/ld.so.cache</filename> も作成します (すぐに説明します)。
<!--end_japanese-->
</para>

<para>
<!--start_original
ldconfig doesn't set up the linker names; typically this is done during
library installation, and the linker name is simply created as a symbolic
link to the ``latest'' soname or the latest real name.
I would recommend having the linker name be a symbolic link to the soname,
since in most cases if you update the library
you'd like to automatically use it when linking.
I asked H. J. Lu why ldconfig doesn't automatically set up the linker names.
His explanation was basically that
you might want to run code using the latest version of a library,
but might instead want <emphasis>development</emphasis> to link
against an old (possibly incompatible) library.
Therefore, ldconfig makes no assumptions about what you want programs to
link to, so installers must specifically modify symbolic links to
update what the linker will use for a library.
end_original-->
<!-- Private correspondance, 10-April-2000 -->
<!--start_japanese-->
ldconfig は linker name を作成しません。
通常、この作成作業はライブラリインストール時におこない、単純に、「最新の」soname もしくは最新の
real name へのシンボリックリンクとして linker name を作成します。
ほとんどの場合において、ライブラリを更新したら、リンク時にそれを自動的に利用したいと思うでしょうから、soname
へのシンボリックリンクとして linker name を作っておくことをお勧めします。
なぜ ldconfig が自動的に linker name を作成しないのかを、私は H. J. Lu に尋ねました。
彼の説明は、基本的には、「ライブラリの最新バージョンを使ってコードを実行したいと思われるかも知れませんが、そうではなく、(おそらく互換性のない)
古いライブラリをリンクしながらの<emphasis>開発作業</emphasis>を希望されることもありうるでしょう」、というものでした。
そのため、ldconfig は、プログラムをどのライブラリにリンクさせたいのかということについては、何の仮定もおこなわないのです。
ですから、ライブラリとしてリンカに使わせるものを実際に更新するためには、インストーラがシンボリックリンクを個別に変更しなければならないのです。
<!--end_japanese-->
</para>

<para>
<!--start_original
Thus, <filename>/usr/lib/libreadline.so.3</filename>
is a fully-qualified soname, which
ldconfig would set to be a symbolic link to some realname like
<filename>/usr/lib/libreadline.so.3.0</filename>.
There should also be a linker name,
<filename>/usr/lib/libreadline.so</filename>
which could be a symbolic link referring to
<filename>/usr/lib/libreadline.so.3</filename>.
end_original-->
<!--start_japanese-->
例えば、<filename>/usr/lib/libreadline.so.3</filename> は完全記述の soname であり、これは
ldconfig が <filename>/usr/lib/libreadline.so.3.0</filename> というような何らかの real name
に対するシンボリックリンクとして作成するものです。
<filename>/usr/lib/libreadline.so</filename> という linker name
も作成するべきであり、それは、<filename>/usr/lib/libreadline.so.3</filename>
を参照するシンボリックリンクとなるでしょう。
<!--end_japanese-->
</para>
</sect3>

<sect3>
<!--start_original
<title>Filesystem Placement</title>
end_original-->
<!--start_japanese-->
<title>ファイルシステム配置</title>
<!--end_japanese-->
<para>
<!--start_original
Shared libraries must be placed somewhere in the filesystem.
Most open source software tends to follow the GNU standards; for more
information see the info file documentation at
<ulink url="info:standards#Directory_Variables">
info:standards#Directory_Variables</ulink>.
The GNU standards recommend
installing by default all libraries in /usr/local/lib
when distributing source code
(and all commands should go into /usr/local/bin).
They also define the convention for overriding these defaults
and for invoking the installation routines.
end_original-->
<!--start_japanese-->
共有ライブラリはファイルシステム内のどこかに配置しなければなりません。
ほとんどのオープンソースソフトウェアは、GNU 規約に従う傾向があります。
詳細は <ulink url="info:standards#Directory_Variables"
>info:standards#Directory_Variables</ulink>
にある info ファイルドキュメントを参照してください。
GNU 規約は、ソースコードを配布するとき、デフォルト設定時にはライブラリを全て
<filename>/usr/local/lib</filename> にインストールするよう推奨しています
(コマンドを全て <filename>/usr/local/bin</filename> に配置するようにとも推奨しています)。
また、これらのデフォルト設定をオーバーライドしたり、インストールルーチンを呼び出したりする際の約束ごとも定義しています。
<!--end_japanese-->
</para>

<para>
<!--start_original
The Filesystem Hierarchy Standard (FHS) discusses what should go where
in a distribution (see 
<ulink url="http://www.pathname.com/fhs">http://www.pathname.com/fhs</ulink>).
According to the FHS, most libraries should
be installed in /usr/lib, but libraries required for startup
should be in /lib and libraries that are not
part of the system should be in /usr/local/lib.
end_original-->
<!--start_japanese-->
ファイルシステム階層規約 (Filesystem Hierarchy Standard; FHS)
は、ディストリビューションにおいて何をどこにインストールすべきかを説明しています
(<ulink url="http://www.pathname.com/fhs/">http://www.pathname.com/fhs/</ulink>
を参照してください)。FHS によると、ほとんどのライブラリは <filename>/usr/lib</filename>
にインストールし、起動時に必要とされるライブラリは
<filename>/lib</filename> に、システムの一部ではないライブラリは
<filename>/usr/local/lib</filename> にインストールするのが良い、ということになります。
<!--end_japanese-->
</para>

<para>
<!--start_original
There isn't really a conflict between these two documents;
the GNU standards recommend the default for developers
of source code, while the FHS recommends the default for distributors
(who selectively override the source code defaults, usually via the
system's package management system).
In practice this works nicely: the ``latest'' (possibly buggy!) source
code that you download automatically installs itself in the ``local''
directory (<filename>/usr/local</filename>),
and once that code has matured the package managers can
trivially override the default to place the code in the standard
place for distributions.
Note that if your library calls programs that can only be called via
libraries, you should place those programs in /usr/local/libexec
(which becomes /usr/libexec in a distribution).
One complication is that Red Hat-derived systems don't include
/usr/local/lib by default in their search for libraries;
see the discussion below about /etc/ld.so.conf.
Other standard library locations include
/usr/X11R6/lib for X-windows.
Note that /lib/security is used for PAM modules, but those are usually
loaded as DL libraries (also discussed below).
end_original-->
<!--start_japanese-->
実際には、これら二つの規約間に矛盾はありません。
GNU 規約は、ソースコード開発者のためのデフォルト設定を推奨しているのであり、一方で FHS
は、ディストリビュータ (通常、システムパッケージ管理システムによりソースコードのデフォルト設定を選択的にオーバーライドする人々)
のためのデフォルト設定を推奨しているのです。
実際にこれはうまく機能しています。あなたがダウンロードした「最新の」(おそらくバグだらけの！)
ソースコードは、自動的に自分自身を「ローカルな」ディレクトリ (<filename>/usr/local</filename>)
にインストールします。
そしてコードが成熟してきたら、ディストリビューション用の標準的な位置にコードを配置するため、パッケージ管理ツールでデフォルト設定を簡単にオーバーライドできます。
あなたのライブラリが、ライブラリ経由でしか呼び出されることのないプログラムを呼び出しているのならば、それらのプログラムを
<filename>/usr/local/libexec</filename> (あるディストリビューションでは
<filename>/usr/libexec</filename> になります) に配置するべきです。
厄介なのは、Red Hat から派生したシステムがデフォルト設定では
<filename>/usr/local/lib</filename> をライブラリ検索対象に含めていないということです。
<filename>/etc/ld.so.conf</filename> に関する下記の議論を参照してください。
他の標準的なライブラリ配置場所としては、X Window System 用の
<filename>/usr/X11R6/lib</filename> があります。<filename>/lib/security</filename> は PAM
モジュール用に使われますが、通常、PAM モジュール群は動的ライブラリ (これもあとで説明します)
としてロードされるので注意してください。
<!--end_japanese-->
</para>
</sect3>
</sect2>

<sect2>
<!--start_original
<title>How Libraries are Used</title>
end_original-->
<!--start_japanese-->
<title>ライブラリはどのように使われるか</title>
<!--end_japanese-->
<para>
<!--start_original
On GNU glibc-based systems, including all Linux systems,
starting up an ELF binary executable automatically causes the program loader
to be loaded and run.
On Linux systems, this loader is named
/lib/ld-linux.so.X (where X is a version number).
This loader,
in turn, finds and loads all other shared libraries used by the program.
end_original-->
<!--start_japanese-->
GNU glibc ベースのシステム (全ての Linux システムが含まれます) では、ELF
バイナリ実行ファイルを起動すると、自動的にプログラムローダがロードされ、実行されます。
Linux システムでは、このローダは <filename>/lib/ld-linux.so.X</filename>
(X にはバージョン番号が入ります) という名前です。
このローダは、プログラムによって使用されるその他の全ての共有ライブラリを順次探し出し、ロードします。
<!--end_japanese-->
</para>

<para>
<!--start_original
The list of directories to be searched is stored in the file /etc/ld.so.conf.
Many Red Hat-derived distributions don't normally include /usr/local/lib in the
file /etc/ld.so.conf. I consider this a bug, and adding
/usr/local/lib to /etc/ld.so.conf is a common ``fix'' required
to run many programs on Red Hat-derived systems.
end_original-->
<!--start_japanese-->
検索対象となるディレクトリのリストは、<filename>/etc/ld.so.conf</filename>
ファイル内に記述されています。
Red Hat から派生しているディストリビューションの多くは、通常
<filename>/etc/ld.so.conf</filename> ファイル内に <filename>/usr/local/lib</filename>
を含めていません。私はこれをバグだと考えており、また、<filename>/usr/local/lib</filename> を
<filename>/etc/ld.so.conf</filename> に追加することは、Red Hat
から派生しているシステム上で多くのプログラムを走らせるのに必要な、共通の「修正」だと思っています。
<!--end_japanese-->
</para>

<para>
<!--start_original
If you want to just override a few functions in a library, but
keep the rest of the library, you can enter the names of overriding
libraries (.o files) in /etc/ld.so.preload; these
``preloading'' libraries will take precedence over the standard set.
This preloading file is typically used for emergency patches;
a distribution usually won't include such a file when delivered.
end_original-->
<!--start_japanese-->
ライブラリ内の幾つかの関数をオーバーライドしたいだけで、残りはそのままにしておきたいならば、オーバーライドするライブラリ
(.o ファイル) の名前を <filename>/etc/ld.so.preload</filename> に入れることができます。
これらの「先行ロード」ライブラリは、標準集合よりも先行します。
この先行ロードファイルは、典型的には緊急用のパッチとして使われます。
通常、ディストリビューションが配布される際、このようなファイルは含まれないでしょう。
<!--end_japanese-->
</para>

<para>
<!--start_original
Searching all of these directories at program start-up
would be grossly inefficient, so a caching arrangement is actually used.
The program ldconfig(8) by default reads in the file /etc/ld.so.conf,
sets up the appropriate symbolic links in the dynamic link directories
(so they'll follow the standard conventions), and then writes a cache to
/etc/ld.so.cache that's then used by other programs.
This greatly speeds up access to libraries.
The implication is that
ldconfig must be run whenever a DLL is added, when a DLL is removed,
or when the set of DLL directories changes;
running ldconfig is often one of the steps performed by package
managers when installing a library.
On start-up, then, the dynamic loader actually uses
the file /etc/ld.so.cache and then loads the libraries it needs. 
end_original-->
<!--start_japanese-->
プログラム起動時にこれら全てのディレクトリを検索するのは、とても非効率的なので、実際にはキャッシュ処理がおこなわれます。
ldconfig(8) プログラムはデフォルトで <filename>/etc/ld.so.conf</filename>
ファイルを読み込み、適切なシンボリックリンクを動的リンクディレクトリ内に作成します
(これにより、標準的な慣習に沿うことになります)。
それから、あとで他のプログラムから利用されることになるキャッシュを
<filename>/etc/ld.so.cache</filename> に書き込みます。
これにより、ライブラリへのアクセスが非常に速くなります。
結果として言えることは、DLL を追加したとき、または、DLL
を削除したり、DLL ディレクトリのセットを変更したりしたときには必ず、ldconfig
を実行しなければならない、ということです。
ldconfig の実行は、ライブラリインストール時にパッケージ管理ツールによっておこなわれるステップの一つであることが多いです。
ldconfig 以降、動的ローダは起動時、実際には <filename>/etc/ld.so.cache</filename>
ファイルを使い、必要とするライブラリをロードすることになります。
<!--end_japanese-->
</para>

<para>
<!--start_original
By the way, FreeBSD uses slightly different filenames for this cache.
In FreeBSD, the ELF cache is /var/run/ld-elf.so.hints
and the a.out cache is /var/run/ld.so.hints.
These are still updated by ldconfig(8), so this difference in location
should only matter in a few exotic situations.
end_original-->
<!-- Advanced Unix Programming by Warren W. Gay, Sams Publishing, 2000,
 Indianapolis, Indiana, page 258.  -->
<!--start_japanese-->
話は変わりますが、FreeBSD は、このキャッシュ用のファイル名が少し異なります。
FreeBSD では、ELF キャッシュは <filename>/var/run/ld-elf.so.hints</filename>
で、a.out キャッシュは <filename>/var/run/ld.so.hints</filename> になります。
これらのファイルもまた ldconfig(8)
により更新されるので、場所の違いが問題となるのは、幾つかの特別な状況においてのみでしょう。
<!--end_japanese-->
</para>
</sect2>

<sect2>
<!--start_original
<title>Environment Variables</title>
end_original-->
<!--start_japanese-->
<title>環境変数</title>
<!--end_japanese-->
<para>
<!--start_original
Various environment variables can control this process,
and there are environment variables that permit
you to override this process.
end_original-->
<!--start_japanese-->
様々な環境変数により、共有ライブラリのロード処理を制御できます。
ロード処理をオーバーライドするための環境変数が存在するのです。
<!--end_japanese-->
</para>

<sect3>
<title>LD_LIBRARY_PATH</title>
<para>
<!--start_original
You can temporarily substitute a different library for
this particular execution.
In Linux, the environment variable LD_LIBRARY_PATH
is a colon-separated set of directories where libraries should be
searched for first, before
the standard set of directories; this is useful when debugging
a new library or using a nonstandard library for special purposes.
The environment variable LD_PRELOAD lists shared libraries with functions that
override the standard set, just as /etc/ld.so.preload does. 
These are implemented by the loader /lib/ld-linux.so.
I should note that, while LD_LIBRARY_PATH works on many
Unix-like systems, it doesn't work on all;
for example, this functionality is available on HP-UX but as
the environment variable SHLIB_PATH,
and on AIX this functionality is through the variable LIBPATH
(with the same syntax, a colon-separated list).
end_original-->
<!--  Source for the systems that don't use LD_LIBRARY_PATH:
      Drazen Kacar dave@srce.hr,  20 Jul 2000 13:27:53 +0200,
      Mailing list gnome-devel-list@gnome.org.
      Confirmed by "Advanced Unix Programming", page 259. -->
<!--start_japanese-->
特定のプログラムを実行する際、一時的に別のライブラリを代替的に使用することができます。Linux
では、環境変数 LD_LIBRARY_PATH
に、標準的なディレクトリ群に先立ってライブラリ検索対象とすべきディレクトリ群を、コロンで区切って並べます。
これは、新しいライブラリをデバッグするときや、特殊な目的のために非標準的なライブラリを使用するときなどに便利です。
環境変数 LD_PRELOAD には、ちょうど <filename>/etc/ld.so.preload</filename>
でやっているのと同じように、共有ライブラリ群を、標準集合をオーバーライドする関数群と共に列挙します。
これらの機能は、ローダ <filename>/lib/ld-linux.so</filename> により実装されています。
LD_LIBRARY_PATH は多くの Unix 系システムで機能しますが、全てのシステムにおいて機能するわけではないので注意しましょう。
例えば、HP-UX でも同じ機能を利用できますが、それは SHLIB_PATH ですし、AIX
では LIBPATH となります (構文は同じで、コロン区切りのリストです)。
<!--end_japanese-->
</para>

<para>
<!--start_original
LD_LIBRARY_PATH is handy for development and testing, but shouldn't
be modified by an installation process for normal use by normal users; see
``Why LD_LIBRARY_PATH is Bad'' at
<ulink url="http://www.visi.com/~barr/ldpath.html">http://www.visi.com/~barr/ldpath.html</ulink>
for an explanation of why.
But it's still useful for development or testing, and for working around
problems that can't be worked around otherwise.
If you don't want to set the LD_LIBRARY_PATH environment variable, on Linux
you can even invoke the program loader directly and pass it arguments.
For example, the following will use the given PATH instead
of the content of the environment variable LD_LIBRARY_PATH, and run
the given executable:
end_original-->
<!--start_japanese-->
LD_LIBRARY_PATH は開発やテストには便利ですが、一般ユーザに日常的に使用させようとして、インストール処理で変更すべきではありません。
この理由については、<ulink url="http://www.visi.com/~barr/ldpath.html">http://www.visi.com/~barr/ldpath.html</ulink>
の「Why LD_LIBRARY_PATH is bad」(なぜ LD_LIBRARY_PATH はいけないのか) を参照してください。
とは言うものの、LD_LIBRARY_PATH は、開発やテスト、そして、他の方法では回避できない問題に対処するためには、やはり便利です。
LD_LIBRARY_PATH 環境変数を設定したくない場合、Linux では、プログラムローダを直接起動して引数を与えることもできます。
例えば、次のようにすると、指定の実行ファイルが、環境変数 LD_LIBRARY_PATH
の内容ではなく、与えられた PATH を使用して実行されます。
</para>
<!--end_japanese-->
<programlisting>
  /lib/ld-linux.so.2 --library-path PATH EXECUTABLE
</programlisting>
<!--start_original
Just executing ld-linux.so without arguments will give you more help on
using this, but again, don't use this for normal use - these are all
intended for debugging.
end_original-->
<!--start_japanese-->
<para>
引数を与えずに ld-linux.so を実行すると、使い方についてのヘルプが表示されます。
しかし、もう一度言いますが、普段はこれを使わないようにしてください。
これらの機能は全てデバッグのためにあるのです。
<!--end_japanese-->
</para>
</sect3>

<sect3>
<title>LD_DEBUG</title>
<para>
<!--start_original
Another useful environment variable in the GNU C loader is LD_DEBUG.
This triggers the dl* functions so that they give quite verbose information
on what they are doing. For example:
end_original-->
<!--start_japanese-->
GNU C ローダのもう一つの便利な環境変数は LD_DEBUG です。
これにより、dl*() 関数群が、実行中の処理に関する情報を大量に出力するようになります。
例えば、次のコマンド
</para>
<!--end_japanese-->
<programlisting>
  export LD_DEBUG=files
  command_to_run
</programlisting>
<!--start_original
displays the processing of files and libraries when handling libraries,
telling you what dependencies are detected and which SOs are loaded
in what order.
Setting LD_DEBUG to ``bindings'' displays information
about symbol binding, setting it to ``libs'' displays the
library search paths, and setting ti to ``versions'' displays the
version depdendencies.
end_original-->
<!--start_japanese-->
<para>
は、ライブラリを扱うときに処理するファイル群とライブラリ群を表示し、検出された依存関係、および、どの
so ファイルがどの順番でロードされたか、を教えてくれます。LD_DEBUG
を「bindings」にセットすると、シンボルのバインディングに関する情報を表示します。
「libs」にセットすると、ライブラリ検索パスを表示します。
「versions」にセットすると、バージョン依存関係を表示します。
<!--end_japanese-->
</para>
<para>
<!--start_original
Setting LD_DEBUG to ``help'' and then trying to run a program
will list the possible options.
Again, LD_DEBUG isn't intended for normal use, but it can be handy
when debugging and testing.
end_original-->
<!--start_japanese-->
LD_DEBUG を「help」に設定し、プログラムの実行を試みると、指定可能なオプションがリストアップされます。
再度申しますが、LD_DEBUG は日常的に使用するためのものではなく、デバッグ時やテスト時に役立つものです。
<!--end_japanese-->
</para>
</sect3>

<sect3>
<!--start_original
<title>Other Environment Variables</title>
end_original-->
<!--start_japanese-->
<title>その他の環境変数</title>
<!--end_japanese-->
<para>
<!--start_original
There are actually a number of other environment variables that control
the loading process; their names begin with LD_ or RTLD_.
Most of the others are for low-level debugging of the loader process or
for implementing specialized capabilities.
Most of them aren't well-documented; if you need to know about them, the
best way to learn about them is to read the source code of the loader
(part of gcc).
end_original-->
<!--start_japanese-->
実際には、ロード処理を制御する環境変数は他にもたくさん存在します。それらの名前は LD_ や RTLD_
ではじまり、そのほとんどが、ローダ処理の低レベルなデバッグや特殊な機能を実装するためのものです。
ほとんどのものにはまだ文書がありません。
これらについて調べたいなら、(gcc の一部である) ローダのソースコードを読むのが一番です。
<!--end_japanese-->
</para>

<para>
<!--start_original
Permitting user control over dynamically linked libraries
would be disastrous for setuid/setgid programs
if special measures weren't taken.
Therefore, in the GNU loader (which loads the rest of the program
on program start-up), if the
program is setuid or setgid these variables
(and other similar variables) are ignored or greatly limited in
what they can do.
The loader determines if a program is setuid or setgid by
checking the program's credentials; if the uid and euid differ,
or the gid and the egid differ,
the loader presumes the program is setuid/setgid (or descended from one)
and therefore greatly limits its abilities to control linking.
If you read the GNU glibc library source code, you can see this;
see especially the files elf/rtld.c and sysdeps/generic/dl-sysdep.c.
This means that if you cause the uid and gid
to equal the euid and egid, and then call a program,
these variables will have full effect.
Other Unix-like systems handle the situation differently but
for the same reason: a setuid/setgid program
should not be unduly affected by the environment variables set. 
end_original-->
<!--start_japanese-->
特別な対応をおこなっていない場合、動的にリンクされるライブラリに対する制御をユーザに許可してしまうと、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
プログラムは、設定されている環境変数群によって過度に影響を受けるべきではない」、という考え方は同じです。
<!--end_japanese-->
</para>
</sect3>
</sect2>

<sect2>
<!--start_original
<title>Creating a Shared Library</title>
end_original-->
<!--start_japanese-->
<title>共有ライブラリの作成</title>
<!--end_japanese-->
<para>
<!--start_original
Creating a shared library is easy.
First, create the object files that will go into the shared
library using the gcc -fPIC or -fpic flag.
The -fPIC and -fpic options enable ``position independent code'' generation,
a requirement for shared libraries; see below for the differences.
You pass the soname using the -Wl gcc option.
The -Wl option passes options
along to the linker (in this case the -soname linker option) -
the commas after -Wl are not a typo, and you
must not include unescaped whitespace in the option.
Then create the shared library using this format:
end_original-->
<!--start_japanese-->
共有ライブラリの作成は簡単です。
まずはじめに、共有ライブラリに組み込むオブジェクトファイルを、gcc
の -fPIC または -fpic フラグを使って作成します。
-fPIC と -fpic オプションにより、共有ライブラリに対する要求事項である「位置独立コード
(position independent code)」を生成することができます。
二つのオプションの違いについては、後の説明を参照してください。
soname は、gcc の -Wl オプションを使って指定します。
-Wl オプションは、オプション群 (今回の例では -soname リンカオプション) 
をリンカに渡すためのものです。-Wl の後ろのカンマはタイプミスではありません。
-Wl オプションには、エスケープされていないスペースを含めてはならないのです
(訳注：-Wl の直後に続く「,-soname,your_soname」という文字列は、カンマの部分で分割されてからリンカに渡されます。
つまり、リンカには「-soname your_soname」というオプションが渡されます)。
次の書式を用いて共有ライブラリを作成してください。
<!--end_japanese-->
</para>

<!--start_original
<programlisting>
gcc -shared -Wl,-soname,<replaceable>your_soname</replaceable> \
    -o <replaceable>library_name</replaceable> <replaceable>file_list</replaceable> <replaceable>library_list</replaceable>
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  gcc -shared -Wl,-soname,<replaceable>your_soname</replaceable> \
      -o <replaceable>library_name</replaceable> <replaceable>file_list</replaceable> <replaceable>library_list</replaceable>
</programlisting>
<!--end_japanese-->

<para>
<!--start_original
Here's an example, which creates two object files (a.o and b.o) and then
creates a shared library that contains both of them.
Note that this compilation includes debugging information (-g) and
will generate warnings (-Wall), which aren't required for shared libraries
but are recommended.
The compilation generates object files (using -c), and includes
the required -fPIC option:
end_original-->
<!--start_japanese-->
二つのオブジェクトファイル (a.o と b.o) を作成し、これら両方のオブジェクトファイルを含む共有ライブラリを作成する例を挙げます。
下記のコンパイル処理では、オブジェクトファイルにデバッグ情報 (-g)
が含まれることになり、また、警告メッセージ (-Wall)
も表示されます。これらのオプションは、共有ライブラリ作成に必須ではありませんが、お勧めします。
このコンパイル処理で、(-c オプションにより) オブジェクトファイルが生成されます。
なお、-fPIC オプションの指定は必須です。
<!--end_japanese-->
</para>

<!--start_original
<programlisting>
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
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  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
</programlisting>
<!--end_japanese-->

<para>
<!--start_original
Here are a few points worth noting:
end_original-->
<!--start_japanese-->
注意すべきことが幾つかあります。
<!--end_japanese-->
<itemizedlist>
<!--start_original
<listitem><para>Don't strip the resulting library, and don't use the
compiler option -fomit-frame-pointer unless you really have to.
The resulting library will work, but these actions make debuggers
mostly useless.</para>
</listitem>
end_original-->
<!--start_japanese-->
<listitem><para>
生成されたライブラリを strip しないでください。
また、本当に必要でない限り、コンパイラオプション -fomit-frame-pointer を使わないでください。
これらをおこなっても生成されたライブラリは機能しますが、デバッガがほとんど使い物にならなくなってしまいます。
</para></listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>Use -fPIC or -fpic to generate code.
Whether to use -fPIC or -fpic to generate code is target-dependent.
The -fPIC choice always works, but may produce larger code than -fpic
(mnenomic to remember this is that PIC is in a larger case,
so it may produce larger amounts of code).
Using -fpic option usually generates
smaller and faster code, but will have platform-dependent
limitations, such as the number of globally visible symbols or
the size of the code.  The linker will tell you whether it fits
when you create the shared library.
When in doubt, I choose -fPIC, because it always works.
</para>
</listitem>
end_original-->
<!--start_japanese-->
<listitem><para>
コードの生成には -fPIC または -fpic を使用してください。
コードの生成に -fPIC と -fpic のどちらを使うかは、ターゲットに依存します。
-fPIC を選んでおけば常に動きますが、-fpic よりも大きなコードを生成する可能性があります
(これを覚えておく方法は、「PIC は大文字だから大きなコードを生成する可能性がある」、です)。
-fpic オプションを使うと、通常は小さくて速いコードが生成されますが、グローバルで可視にできるシンボルの数やコードのサイズといった、プラットフォームに依存する制限があります。
共有ライブラリを作成するとき、うまくいくかどうかをリンカが教えてくれます。
疑わしいとき、私は -fPIC の方を選択します。なぜなら、-fPIC は常に機能するからです。
</para></listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>
In some cases, the call to gcc to create the object file
will also need to include the option ``-Wl,-export-dynamic''.
Normally, the dynamic symbol
table contains only symbols which are used by a dynamic object.
This option (when creating an ELF file) adds all symbols to the
dynamic symbol table (see ld(1) for more information).
You need to use this option when there are 'reverse dependencies', i.e.,
a DL library has unresolved symbols that by convention must be defined
in the programs that intend to load these libraries.
For ``reverse dependencies'' to work, the master program must make its
symbols dynamically available.
end_original-->
<!-- http://www.gnu.org/software/libtool/manual.html#Building%20modules -->
<!--start_original
Note that you could say ``-rdynamic'' instead of ``-Wl,export-dynamic''
if you only work with Linux systems, but according to the ELF documentation
the ``-rdynamic'' flag doesn't always work for gcc on non-Linux systems.
</para>
</listitem>
end_original-->
<!--start_japanese-->
<listitem><para>
場合によっては、gcc を呼び出してオブジェクトファイルを生成するとき、「-Wl,-export-dynamic」オプションを含めなければならないこともあります。
通常、動的シンボルテーブルには、動的オブジェクトが使用するシンボルのみが含まれています。
このオプションは、(ELF ファイルを生成する場合) 全てのシンボルを動的シンボルテーブルに追加します
(詳細については ld(1) を参照してください)。
「逆依存関係」が存在するとき、つまり、ライブラリをロードしようとしているプログラムの内部で (慣習により)
宣言しておかなければならないシンボルが、動的ライブラリにおいて未解決のとき、このオプションを使う必要があります。
「逆依存関係」を機能させるには、主プログラムが、シンボル群を動的に利用可能にする必要があります。
Linux システムだけで作業するのであれば、「-Wl,-export-dynamic」のかわりに「-rdynamic」でもよいです。
しかし、ELF 文書によると、Linux 以外のシステムにおける gcc では、「-rdynamic」フラグは常に機能するわけではありません。
</para></listitem>
<!--end_japanese-->
</itemizedlist>
</para>

<para>
<!--start_original
During development, there's the potential problem of modifying a library
that's also used by many other programs &#045;&#045; and you don't want the
other programs to use the ``developmental''library, only a particular
application that you're testing against it.
One link option you might use is ld's ``rpath'' option, which specifies
the runtime library search path of that particular program
being compiled.
From gcc, you can invoke the rpath option by specifying it this way:
end_original-->
<!--start_japanese-->
開発中は、「他の多くのプログラムからも利用されているライブラリを修正してしまうかもしれない」という潜在的な問題があります。
開発段階のライブラリを対象にしてテストをおこなっている特定のアプリケーション以外には、その開発段階のライブラリを使わせたくないでしょう。
使用することになると思われるリンクオプションは、ld の「-rpath」です。
これは、コンパイルする個々のプログラムの、実行時のライブラリ検索パスを指定するものです。
gcc からは、次のように指定することで、-rpath オプションを渡すことができます。
</para>
<!--end_japanese-->
<!--start_original
<programlisting>
 -Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  -Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)
</programlisting>
<!--end_japanese-->
<!--start_original
If you use this option when building the library client program,
you don't need to bother with LD_LIBRARY_PATH (described next) other
than to ensure it's not conflicting, or using other techniques to
hide the library.
end_original-->
<!--start_japanese-->
<para>
ライブラリのクライアントプログラムをビルドするときにこのオプションを使えば、そのプログラムが当該ライブラリを隠蔽してしまうような他の技術と競合していないこと、または、そのような技術を使用していないこと、を確認する必要があることを除いて、LD_LIBRARY_PATH
(次で説明します) について悩む必要がなくなります。
<!--end_japanese-->
</para>

</sect2>

<sect2>
<!--start_original
<title>Installing and Using a Shared Library</title>
end_original-->
<!--start_japanese-->
<title>共有ライブラリのインストールと使用</title>
<!--end_japanese-->
<para>
<!--start_original
Once you've created a shared library, you'll want to install it.
The simple approach is simply to copy the library into one of the
standard directories (e.g., /usr/lib) and run ldconfig(8).
end_original-->
<!--start_japanese-->
共有ライブラリを作成したら、それをインストールしたくなることでしょう。
簡単な方法は、標準的なディレクトリ (例えば /usr/lib など)
の一つに、そのライブラリをコピーし、ldconfig(8) を実行することです。
<!--end_japanese-->
</para>

<para>
<!--start_original
First, you'll need to create the shared libraries somewhere.
Then, you'll need to set up the necessary symbolic links, in particular
a link from a soname to the real name (as well as from a versionless
soname, that is, a soname that ends in ``.so'' for users who don't specify
a version at all).  The simplest approach is to run:
end_original-->
<!--start_japanese-->
まず、共有ライブラリをどこかに作成する必要があるでしょう。
それから、必要なシンボリックリンク、特に soname から real name
へのリンクを作成する必要もあるでしょう
(同様に、バージョン番号を全く指定しないユーザのため、バージョン番号の無い
soname, つまり「.so」で終わる soname からのリンクも必要です)。
最も簡単な方法は、次のとおり実行することです。
</para>
<!--end_japanese-->
<!--start_original
<programlisting>
 ldconfig -n <replaceable>directory_with_shared_libraries</replaceable>
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  ldconfig -n <replaceable>directory_with_shared_libraries</replaceable>
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->

<para>
<!--start_original
Finally, when you compile your programs, you'll need to tell the
linker about any static and shared libraries that you're using.
Use the -l and -L options for this.
end_original-->
<!--start_japanese-->
最後に、プログラムをコンパイルするときに、使おうとしている全ての静的ライブラリと共有ライブラリについて、リンカに教えてやる必要があります。
これは、-l オプションと -L オプションを使っておこないます。
<!--end_japanese-->
</para>

<para>
<!--start_original
If you can't or don't want to install a library in a standard place
(e.g., you don't have the right to modify /usr/lib),
then you'll need to change your approach.
In that case, you'll need to install it somewhere, and then
give your program enough information so the program can find the library...
and there are several ways to do that.
You can use gcc's -L flag in simple cases.
You can use the ``rpath'' approach (described above), particularly if
you only have a specific program to use the library being placed in
a ``non-standard'' place.
You can also use environment variables to control things.
In particular, you can set LD_LIBRARY_PATH, which is a colon-separated
list of directories in which to search for shared libraries before
the usual places.
If you're using bash, you could invoke my_program this way using:
end_original-->
<!--start_japanese-->
標準的な場所にライブラリをインストールできない、もしくはインストールしたくないなら
(例えばあなたが /usr/lib を変更する権限を持っていないなど)、別の手順を踏まなければなりません。
このような場合、ライブラリをどこかにインストールしておき、そのライブラリを見つけるために十分な量の情報をプログラムに与えなければなりません。
これをおこなうには、幾つか方法があります。
単純な場合では、gcc の -L フラグを使用できます。
また、特に、ある特定のプログラム以外は非標準的な場所に置いてあるライブラリを利用しないというのであれば、(上で説明した)「-rpath」を使うこともできます。
環境変数を使っていろいろ制御することもできます。
特に、LD_LIBRARY_PATH を設定することができます。
LD_LIBRARY_PATH には、共有ライブラリを検索するときに通常の場所に先立って検索対象とするディレクトリ群を、コロンで区切って列挙します。
bash をお使いでしたら、次の方法で my_program を実行できます。
<!--end_japanese-->
</para>

<!--start_original
<programlisting>
LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH  my_program
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH my_program
</programlisting>
<!--end_japanese-->

<para>
<!--start_original
If you want to override just a few selected functions,
you can do this by creating an overriding object file and setting
LD_PRELOAD; the functions in this object file will override just
those functions (leaving others as they were).
end_original-->
<!--start_japanese-->
幾つかの関数を選択的にオーバーライドしたいだけならば、オーバーライドするオブジェクトファイルを作成して
LD_PRELOAD を設定するだけで実現できます。
このオブジェクトファイル内の関数により、対象となっている関数だけがオーバーライドされます
(他の関数は元のままです)。
<!--end_japanese-->
</para>

<para>
<!--start_original
Usually you can update libraries without concern; if there was an API
change, the library creator is supposed to change the soname.
That way, multiple libraries can be on a single system, and the right
one is selected for each program.
However, if a program breaks on an update to a library that kept the
same soname, you can force it to use the older library version by
copying the old library back somewhere,
renaming the program (say to the old name plus ``.orig''),
and then create a small
``wrapper'' script that resets the library to use and
calls the real (renamed) program.
You could place the old library in its own special area, if you like,
though the numbering conventions do permit multiple versions to live
in the same directory.
The wrapper script could look something like this:
end_original-->
<!--start_japanese-->
通常、ライブラリの更新は、何も気にせずにおこなうことができます。
もしも API に変更があるならば、ライブラリ作成者により soname も変更されていることでしょう。
そういうわけで、一つのシステム上に複数のライブラリが存在でき、各プログラムに対するライブラリが正しく選択されるのです。
しかし、もしも、ライブラリの更新で soname は変更されなかったのにプログラムがうまく動かなくなってしまった、ということがあるのならば、古いライブラリをどこかにコピーし、そのプログラムの名称を変更する
(古い名前に「.orig」を付け足すなど) ことによって、そのプログラムが古いバージョンのほうのライブラリを使うように強制することができます。
これらの作業をおこなったあと、利用するライブラリを再設定して実際の (名称変更された)
プログラムを呼び出す、小さな「ラッパー」スクリプトを作成してください。
番号付けの約束ごとのおかげで、同一ディレクトリ内に複数のバージョンのライブラリを置くこともできますが、お望みなら、古いライブラリをそれ独自の特別な場所に置くこともできます。
ラッパースクリプトは、次のようなものになるでしょう。
</para>
<!--end_japanese-->
<!--start_original
<programlisting>
  #!/bin/sh
  export LD_LIBRARY_PATH=/usr/local/my_lib:$LD_LIBRARY_PATH
  exec /usr/bin/my_program.orig $*
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  #!/bin/sh
  export LD_LIBRARY_PATH=/usr/local/my_lib:$LD_LIBRARY_PATH
  exec /usr/bin/my_program.orig "$@"
</programlisting>
<!--end_japanese-->
<!--start_original
Please don't depend on this when you write your own programs; try to
make sure that your libraries are either backwards-compatible or that
you've incremented the version number in the soname every time
you make an incompatible change.
This is just an ``emergency'' approach to deal with worst-case problems.
end_original-->
<!--start_japanese-->
<para>
自分でプログラムを書くときには、この方法に依存しないようにしてください。
ライブラリの後方互換性を持たせるか、もしくは、互換性の無い変更をおこなうときは必ず
soname のバージョン番号を増やすよう、気を払ってください。
この方法は、最悪の場合の問題を扱うための「緊急時」対応なのです。
<!--end_japanese-->
</para>

<para>
<!--start_original
You can see the list of the shared libraries used by a program using ldd(1).
So, for example, you can see the shared libraries used by ls by typing:
end_original-->
<!--start_japanese-->
ldd(1) を使えば、プログラムによって使用されている共有ライブラリのリストを見ることができます。
例えば、次のようにタイプすれば、ls によって使用される共有ライブラリを確認できます。
</para>
<!--end_japanese-->
<programlisting>
  ldd /bin/ls
</programlisting>
<!--start_original
Generally you'll see a list of the sonames being depended on, along with
the directory that those names resolve to.
In practically all cases you'll have at least two dependencies:
end_original-->
<!--start_japanese-->
<para>
通常、プログラムが依存する各 soname について、それぞれどのディレクトリに存在するかが特定され、
その特定されたディレクトリ名とともに、当該 soname 群のリストが表示されます。
実質的に全ての状況において、少なくとも二つの依存情報が表示されるでしょう。
<!--end_japanese-->
<itemizedlist>
<!--start_original
<listitem><para>/lib/ld-linux.so.N (where N is 1 or more, usually at least 2).
This is the library that loads all other libraries.
</para></listitem>
end_original-->
<!--start_japanese-->
<listitem><para>/lib/ld-linux.so.N (N は 1 以上。通常は少なくとも 2).
これは、他の全てのライブラリをロードするためのライブラリです。
</para></listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>libc.so.N (where N is 6 or more).
This is the C library.  Even other languages tend to use the C
library (at least to implement their own libraries), so most programs
at least include this one.
</para></listitem>
end_original-->
<!--start_japanese-->
<listitem><para>libc.so.N (N は 6 以上).
これは C ライブラリです。C 言語以外の言語でさえ、C ライブラリを使用する傾向があります
(少なくともそれら自身のライブラリを実装するため)。
そのため、ほとんどのプログラムは、少なくともこのライブラリを含んでいます。
</para></listitem>
<!--end_japanese-->
</itemizedlist>
<!--start_original
Beware: do <emphasis>not</emphasis> run ldd on a program you don't trust.
As is clearly stated in the ldd(1) manual, ldd works by (in certain cases)
by setting a special environment variable
(for ELF objects, LD_TRACE_LOADED_OBJECTS) and then executing the program.
It may be possible for an untrusted program to force the ldd user to
run arbitrary code (instead of simply showing the ldd information).
So, for safety's sake, don't use ldd on programs you don't trust to execute.
end_original-->
<!--start_japanese-->
注意：信頼できないプログラムに対して ldd を実行しては<emphasis>いけません</emphasis>。
ldd(1) のマニュアルで明確に述べられているとおり、ldd は、(幾つかの状況においては)
特別な環境変数 (ELF オブジェクトの場合は LD_TRACE_LOADED_OBJECTS)
を設定してプログラムを実行することにより、動作しています。
信頼できないプログラムが、(ldd 情報を単に表示するかわりに)
任意のコードを ldd ユーザに強制実行させてしまうことも可能かもしれません。
<!--end_japanese-->
</para>
</sect2>

<sect2>
<!--start_original
<title>Incompatible Libraries</title>
end_original-->
<!--start_japanese-->
<title>互換性のないライブラリ</title>
<!--end_japanese-->
<para>
<!--start_original
When a new version of a library is binary-incompatible with the old one
the soname needs to change.
In C, there are four basic reasons that a library would cease to
be binary compatible:
end_original-->
<!--start_japanese-->
新しいバージョンのライブラリが古いものとのバイナリ互換性を持たないときには、soname
を変更する必要があります。
C 言語では、ライブラリがバイナリ互換ではなくなってしまう四つの基本的な原因があります。
<!--end_japanese-->
<orderedlist>
<!--start_original
<listitem><para>The behavior of a function changes so that it no longer
meets its original specification,</para>
</listitem>
end_original-->
<!--start_japanese-->
<listitem><para>関数の挙動が変更され、元々の仕様に適合しなくなる
</para></listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>Exported data items change (exception: adding optional
items to the ends of structures is okay, as long as those structures
are only allocated within the library).</para>
</listitem>
end_original-->
<!--start_japanese-->
<listitem><para>エクスポートされているデータが変更される
(例外：構造体がライブラリ内でのみアロケートされる場合に限り、構造体の末尾に任意のメンバーを追加することには問題がない)
</para></listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>An exported function is removed.</para>
</listitem>
end_original-->
<!--start_japanese-->
<listitem><para>エクスポートされている関数が削除される
</para></listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>The interface of an exported function changes.</para>
</listitem>
end_original-->
<!--start_japanese-->
<listitem><para>エクスポートされている関数のインターフェースが変更される
</para></listitem>
<!--end_japanese-->
</orderedlist>
</para>

<para>
<!--start_original
If you can avoid these reasons, you can keep your libraries binary-compatible.  Said another way, you can keep your
Application Binary Interface (ABI) compatible if you avoid such changes.
For example, you might want to add new functions but not delete the old ones.
You can add items to structures but only if you can make sure that old
programs won't be sensitive to such changes by adding items
only to the end of the structure, only allowing the library (and not the
application) to allocate the structure, making the extra items optional
(or having the library fill them in), and so on.
Watch out - you probably
can't expand structures if users are using them in arrays.
end_original-->
<!--start_japanese-->
これらの原因を回避できれば、ライブラリをバイナリ互換に保つことができます。
別の言い方をすると、これらの変更を避ければ、Application Binary Interface (ABI)
互換を保つことができる、ということです。
例えば、古い関数を削除せずに新しい関数を追加したい、というのは問題ないでしょう。
構造体の末尾にのみメンバーを追加し、その構造体をアロケートするのはライブラリ内だけとし
(アプリケーションにはアロケートさせない)、追加のメンバーをオプション扱いにする
(ライブラリがそのメンバーを設定する)、などの操作をおこなって生じる変更が、古いプログラムに対して影響を与えないことが確かな場合にのみ、メンバーを追加することができます。
もしもユーザが構造体を配列で使っているならば、その構造体を拡張することはほとんどできないので十分注意してください。
<!--end_japanese-->
</para>

<para>
<!--start_original
For C++ (and other languages supporting compiled-in templates and/or
compiled dispatched methods), the situation is trickier.
All of the above issues apply, plus many more issues.
The reason is that some information is implemented ``under the covers''
in the compiled code, resulting in dependencies that may not be obvious
if you don't know how C++ is typically implemented.
Strictly speaking, they aren't ``new'' issues, it's just that compiled C++
code invokes them in ways that may be surprising to you.
The following is a (probably incomplete) list of things that you cannot
do in C++ and retain binary compatibility, as reported by
<ulink url="http://www.trolltech.com/developer/faq/tech.html#bincomp">
Troll Tech's Technical FAQ</ulink>:
end_original-->
<!--start_japanese-->
C++ (および、テンプレートやディスパッチされるメソッドをコンパイル時に組み込むという方法でサポートするその他の言語)
では、状況はより複雑になります。
上記に述べたことが全て当てはまる上、さらに多くの注意点があります。
幾つかの情報が、コンパイルされるコード内に「隠蔽された状態で」組み込まれるという点にその原因があるのですが、このために、C++
が通常どのように実装されているかを知らない人には理解しにくい依存問題が、引き起こされてしまうのです。
正確に言えば、これは「新しい」問題ではありません。単に、コンパイル済みの
C++ コードが、人によっては驚くかもしれない動作をして問題を引き起こす、というだけの話です。
次のリストは、バイナリ互換を維持するために C++ 内でやってはいけない項目のリスト
(おそらく完全ではありませんが) であり、<ulink
url="http://www.trolltech.com/developer/faq/tech.html#bincomp">Troll Tech 社テクニカル FAQ</ulink>
で公開されているものです。
<!--end_japanese-->
<orderedlist>
<listitem><para>
<!--start_original
add reimplementations of virtual functions
(unless it it safe for older binaries to call the original implementation),
because the compiler evaluates SuperClass::virtualFunction() calls
at compile-time (not link-time).
end_original-->
<!--start_japanese-->
仮想関数の再実装を追加する
(古いバイナリが元の実装を呼び出すのが安全ではない場合)。
コンパイラは SuperClass::virtualFunction()
呼出しをコンパイル時に評価するため (リンク時ではない)。
<!--end_japanese-->
</para></listitem>
<listitem><para>
<!--start_original
add or remove virtual member functions, because
this would change the size and layout of the vtbl of every subclass. 
end_original-->
<!--start_japanese-->
仮想メンバ関数を追加または削除する。
これにより全サブクラスの仮想関数テーブルのサイズとレイアウトが変更されてしまうため。
<!--end_japanese-->
</para></listitem>
<listitem><para>
<!--start_original
change the type of any data members or move any data members
that can be accessed via inline member functions.
end_original-->
<!--start_japanese-->
インラインメンバ関数経由でアクセス可能なデータメンバを移動させたり、データメンバの型を変更する。
<!--end_japanese-->
</para></listitem>
<listitem><para>
<!--start_original
change the class hierarchy, except to add new leaves. 
end_original-->
<!--start_japanese-->
クラス階層を変更する。ただし、リーフ (訳注：下位クラスを持たないクラス)
の新規追加を除く。
<!--end_japanese-->
</para></listitem>
<listitem><para>
<!--start_original
add or remove private data members, because
this would change the size and layout of every subclass. 
end_original-->
<!--start_japanese-->
プライベートデータを追加、または削除する。
これにより全サブクラスのサイズとレイアウトが変更されてしまうため。
<!--end_japanese-->
</para></listitem>
<listitem><para>
<!--start_original
remove public or protected member functions unless they are inline.
end_original-->
<!--start_japanese-->
public もしくは protected メンバ関数がインライン関数でない場合に、それらを削除する。
<!--end_japanese-->
</para></listitem>
<listitem><para>
<!--start_original
make a public or protected member function inline.
end_original-->
<!--start_japanese-->
public もしくは protected メンバ関数をインライン化する。
<!--end_japanese-->
</para></listitem>
<listitem><para>
<!--start_original
change what an inline function does, unless the old version continues working.
end_original-->
<!--start_japanese-->
インライン関数の挙動を変更する。ただし、古いバージョンが機能し続ける場合を除く。
<!--end_japanese-->
</para></listitem>
<listitem><para>
<!--start_original
change the access rights
(i.e. public, protected or private) of a member function in a
portable program, because
some compilers mangle the access rights into the function name.
end_original-->
<!--start_japanese-->
可搬性を持たせたいプログラム内のメンバ関数のアクセス権 (すなわち、public, protected
または private) を変更する。
アクセス権情報を関数名に組み入れるコンパイラもあるため。
<!--end_japanese-->
</para></listitem>
</orderedlist>
</para>

<para>
<!--start_original
Given this lengthy list, developers of C++ libraries in particular must
plan for more than occasional updates that break binary compatibility.
Fortunately, on Unix-like systems (including Linux) you can have
multiple versions of a library loaded at the same time, so while there
is some disk space loss, users can still run ``old'' programs needing
old libraries.
end_original-->
<!--start_japanese-->
この長いリストのことを考えると (訳注：＝こんな長いリストの全項目を守り続けることは無理だろうから)、特に
C++ ライブラリの開発者は、バイナリ互換性を維持できない更新を頻繁に実施することを計画しておく必要があります。
幸いにして、Unix 系システム (Linux を含みます)
では、一つのライブラリの複数のバージョンを同時にロードすることができるので、ディスクスペースを消費することにはなりますが、古いライブラリを必要とする「古い」プログラムを引き続き実行することが可能です。
<!--end_japanese-->
</para>
</sect2>
</sect1>

<sect1 id="dl-libraries">
<!--start_original
<title>Dynamically Loaded (DL) Libraries</title>
end_original-->
<!--start_japanese-->
<title>動的ライブラリ</title>
<!--end_japanese-->
<para>
<!--start_original
Dynamically loaded (DL) libraries are libraries that are loaded
at times other than during the startup of a program.
They're particularly useful for implementing plugins or modules, because
they permit waiting to load the plugin until it's needed.
For example, the Pluggable Authentication Modules (PAM) system
uses DL libraries to permit administrators to configure and reconfigure
authentication.
They're also useful for implementing interpreters that wish to
occasionally compile their code into machine code and use the compiled
version for efficiency purposes, all without stopping.
For example, this approach can be useful in implementing 
a just-in-time compiler or multi-user dungeon (MUD).
end_original-->
<!--start_japanese-->
動的ライブラリは、プログラムの起動時以外のときにロードされるライブラリです。
動的ライブラリは、プラグインやモジュールを実装するときに特に便利です。
というのは、必要になるまで、プラグインのロードを待機させることができるからです。
例えば、Pluggable Authentication Modules (PAM)
システムでは、管理者が認証の設定／再設定をおこなえるよう、動的ライブラリを使用しています。
また、効率を上げるために途中で休止せずにその時々でコードをマシンコードにコンパイルし、そのコンパイルされたものを使用するというインタプリタを実装するのにも役に立ちます。
この方法は、例えばジャストインタイム・コンパイラや、マルチユーザ・ダンジョン (MUD)
を実装するときに使えます。
<!--end_japanese-->
</para>

<para>
<!--start_original
In Linux, DL libraries aren't actually special from the point-of-view of their
format; they are built as standard object files or standard shared libraries
as discussed above.
The main difference is that the libraries aren't automatically loaded
at program link time or start-up; instead, there is an API for
opening a library, looking up symbols, handling errors, and closing the library.
C users will need to include the header file &lt;dlfcn.h&gt;
to use this API.
end_original-->
<!--start_japanese-->
Linux では、実際のところ、フォーマットという視点から見ると、動的ライブラリは特別なものではありません。
今まで述べてきたものと同じで、標準的なオブジェクトファイルや共有ライブラリとしてビルドされています。
主な違いは、動的ライブラリは、プログラムのリンク時や起動時に自動的にはロードされない、という点です。
そのかわりに、ライブラリをオープンし、シンボルを検索し、エラーを処理し、ライブラリを閉じる、という
API が存在します。
この API を使用するためには、C プログラマはヘッダファイル
&lt;dlfcn.h&gt; をインクルードする必要があります。
<!--end_japanese-->
</para>

<para>
<!--start_original
The interface used by Linux is essentially the same as that used in Solaris,
which I'll call the ``dlopen()'' API.
However, this same interface is not supported by all platforms;
HP-UX uses the different shl_load() mechanism, and Windows platforms use
DLLs with a completely different interface.
If your goal is wide portability, you probably ought to consider using
some wrapping library that hides differences between platforms.
One approach is
the glib library with its support for Dynamic Loading of Modules; it uses
the underlying dynamic loading routines of the platform to implement
a portable interface to these functions.
You can learn more about glib at
<ulink url="http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html">http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html</ulink>.
Since the glib interface is well-explained in its documentation,
I won't discuss it further here.
Another approach is to use libltdl, which is part of
<ulink url="http://www.gnu.org/software/libtool/libtool.html">GNU libtool</ulink>.
If you want much more functionality than this, you might want to
look into a CORBA Object Request Broker (ORB).
If you're still interested in directly using the interface supported
by Linux and Solaris, read on.
end_original-->
<!--start_japanese-->
Linux で使用されるインターフェースは、基本的に Solaris のものと同じです。
これを「dlopen()」API と呼ぼうと思います。
しかし、このインターフェースは全てのプラットフォームでサポートされているわけではありません。
HP-UX では shl_load() という別の仕組みが使用され、Windows
プラットフォームでは全く異なるインターフェースである DLL が使用されます。
広範な移植性を最終目標とするならば、おそらく、プラットフォーム間の差違を隠蔽するラッパーライブラリの使用を検討したほうがよいでしょう。
方法の一つとして、モジュールの動的ローディングをサポートする glib ライブラリがあります。
glib ライブラリは、プラットフォーム固有の動的ローディング・ルーチン群を内部で使用し、動的ローディング用の移植性の高いインターフェースを実装しています。
glib については、<ulink url="http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html"
>http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html</ulink>
を参照してください。
glib のインターフェースについては、glib のドキュメントで十分に説明されているので、ここではこれ以上言及しません。
もう一つの方法は、libltdl を使う方法です。
libltdl は、<ulink url="http://www.gnu.org/software/libtool/libtool.html">GNU libtool</ulink> の一部です。
もっと多くの機能が必要ならば、CORBA Object Request Broker (ORB) を調べてみるのもよいでしょう。
Linux と Solaris でサポートされるインターフェースを直接使用することにまだ興味をお持ちならば、読み進んでください。
<!--end_japanese-->
</para>

<para>
<!--start_original
Developers using C++ and dynamically loaded (DL) libraries should also
consult the ``C++ dlopen mini-HOWTO''.
end_original-->
<!--start_japanese-->
C++ と動的ライブラリを使用する開発者の方は、「<ulink url="http://www.tldp.org/HOWTO/C++-dlopen/"
>C++ dlopen mini HOWTO</ulink>」も参照してください。
<!--end_japanese-->
</para>

<sect2 id="dlopen">
<title>dlopen()</title>
<para>
<!--start_original
The dlopen(3) function opens a library and prepares it for use.
In C its prototype is:
end_original-->
<!--start_japanese-->
dlopen(3) 関数は、ライブラリをオープンし、使用前の準備をおこないます。
C のプロトタイプは次のようになります。
</para>
<!--end_japanese-->
<programlisting>
  void * dlopen(const char *filename, int flag);
</programlisting>
<!--start_original
If filename begins with ``/'' (i.e., it's an absolute path),
dlopen() will just try to use it (it won't search for a library).
Otherwise, dlopen() will search for the library
in the following order:
end_original-->
<!--start_japanese-->
<para>
ファイル名が「/」で始まるならば (つまり絶対パスならば)、dlopen()
は単にそのファイル名を使おうとします (ライブラリを検索しようとはしません)。
それ以外ならば、dlopen() は次の順番でライブラリを検索します。
<!--end_japanese-->
<orderedlist>
<!--start_original
<listitem><para>A colon-separated list of directories in the user's
                LD_LIBRARY_PATH environment variable.
</para></listitem>
end_original-->
<!--start_japanese-->
<listitem><para>ユーザの LD_LIBRARY_PATH 環境変数内のコロンで区切られたディレクトリリスト
</para></listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>The list of libraries specified in /etc/ld.so.cache
(which is generated from /etc/ld.so.conf).
</para></listitem>
end_original-->
<!--start_japanese-->
<listitem><para>/etc/ld.so.cache 内に指定されたライブラリリスト
(/etc/ld.so.cache は /etc/ld.so.conf をもとに生成されます)
</para></listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>/lib, followed by /usr/lib.
Note the order here; this is the reverse of the order used by the
old a.out loader.
The old a.out loader, when loading a program, first searched
/usr/lib, then /lib (see the man page ld.so(8)).
This shouldn't normally matter, since
a library should only be in one or the other directory
(never both), and different libraries with the same name are a disaster
waiting to happen.
end_original-->
<!--start_japanese-->
<listitem><para>/lib, 次に /usr/lib.
この順番に注意してください。この順番は、古い a.out ローダで使われていた順番とは逆です。
古い a.out ローダは、プログラムをロードするとき、最初に /usr/lib を検索し、そのあとで
/lib を検索していました (man ページ ld.so(8) を参照してください)。
このことは、通常は問題にならないはずです。
なぜなら、ライブラリはどちらか一方のディレクトリのみに置いてあるはずだからです。
異なるライブラリに同じ名前を付けると、混乱を招きます。
<!--end_japanese-->
<!-- Michael Kerrisk found that it's /lib, then /usr/lib -->
</para></listitem>
</orderedlist>
<!--start_original
In dlopen(), the value of
<replaceable>flag</replaceable> must be either RTLD_LAZY,
meaning
``resolve undefined symbols as code from the dynamic library is executed'',
or RTLD_NOW,
meaning ``resolve all undefined symbols before
dlopen() returns and fail if this cannot be done''.
RTLD_GLOBAL may be optionally or'ed with either value
in <replaceable>flag</replaceable>,
meaning that the external symbols defined in the library will be made
available to subsequently loaded libraries.
While you're debugging, you'll probably want to use RTLD_NOW; using
RTLD_LAZY can create inscrutable errors if there are unresolved references.
Using RTLD_NOW makes opening the library take slightly longer
(but it speeds up lookups later); if this causes a user interface problem
you can switch to RTLD_LAZY later.
end_original-->
<!--start_japanese-->
dlopen() では、<replaceable>flag</replaceable> の値は
RTLD_LAZY か RTLD_NOW のどちらかでなければなりません。
RTLD_LAZY は、「動的ライブラリのコードが実行されるときに未定義シンボルを解決せよ」という意味で、RTLD_NOW
は、「dlopen() がリターンする前に全ての未定義シンボルを解決せよ、それができないようならば失敗せよ」という意味です。
RTLD_GLOBAL は、<replaceable>flag</replaceable> のどちらかの値と任意で論理和結合させることができます。
RTLD_GLOBAL フラグを付けてロードされたライブラリ内で定義されている外部シンボルは、後からロードされるライブラリからでも使用できるようになります。
デバッグ中は、おそらく RTLD_NOW を使いたくなるでしょう。
RTLD_LAZY を使うと、未解決の参照があったときに不可解なエラーが生成されます。
RTLD_NOW を使うと、ライブラリのオープンには若干時間がかかるようになります
(しかし、のちのちの検索速度は速くなります)。
このことがユーザインターフェース上問題になるようでしたら、あとで
RTLD_LAZY に切り替えることができます。
<!--end_japanese-->
</para>

<para>
<!--start_original
If the libraries depend on each other (e.g., X depends on Y), then you
need to load the dependees first (in this example, load Y first, and then X).
end_original-->
<!--start_japanese-->
ライブラリが他のライブラリに依存しているなら
(例えば、X が Y に依存している)、依存されているほうを先にロードしてください
(この例で言えば、Y を先にロードし、それから X をロードします)。
<!--end_japanese-->
</para>

<para>
<!--start_original
The return value of dlopen() is a ``handle'' that should be considered an
opaque value to be used by the other DL library routines.
dlopen() will return NULL if the attempt to load does not succeed, and
you need to check for this.
If the same library is loaded more than once with dlopen(),
the same file handle is returned.
end_original-->
<!--start_japanese-->
dlopen() の戻り値は、他の動的ライブラリ・ルーチンによって使用される「ハンドル」です
(このハンドルの実体は隠蔽されているものとして扱ってください)。
ロードが失敗した場合、dlopen() は NULL を返しますので、戻り値をチェックする必要があります。
同じライブラリが dlopen() で二回以上ロードされると、同じファイルハンドルが返されます。
<!--end_japanese-->
</para>

<para>
<!--start_original
In older systems, if the library exports a routine named  _init,  then  that
code  is  executed  before  dlopen() returns.
You can use this fact in your own libraries to implement
initialization routines.
However, libraries should not export routines named _init or _fini.
Those mechanisms are obsolete, and may result in undesired behavior.
Instead, libraries should export routines using the
__attribute__((constructor)) and __attribute__((destructor)) function
attributes (presuming you're using gcc).
See <xref linkend="init-and-cleanup"> for more information.
end_original-->
<!--start_japanese-->
古いシステムでは、ライブラリが _init という名前のルーチンをエクスポートしている場合、dlopen()
から戻る前にそのコードが実行されます。
この仕組みを使って、ライブラリの初期化ルーチンを実装することができます。
しかし、ライブラリは、_init や _fini といった名前のルーチンをエクスポートすべきではありません。
これらの仕組みは古くなっており、望んでいない動作をする可能性があります。
かわりに、ライブラリでは、__attribute__((constructor)) 関数属性と
__attribute__((destructor)) 関数属性を使用してルーチンをエクスポートしてください
(gcc を使用しているものと仮定しています)。
詳細については <xref linkend="init-and-cleanup"> を参照してください。
<!--end_japanese-->
</para>
</sect2>

<sect2 id="dlerror">
<title>dlerror()</title>
<para>
<!--start_original
Errors can be reported by calling dlerror(), which returns a string
describing the error from the last call to dlopen(), dlsym(), or dlclose().
One oddity is that after calling dlerror(), future calls to dlerror()
will return NULL until another error has been encountered.
end_original-->
<!--start_japanese-->
dlerror() によりエラーを報告できます。
dlerror() は、最後の dlopen(), dlsym(), または dlclose() 呼出しのエラーについて説明する文字列を返します。
一つ変わっているのは、dlerror() を呼び出すと、以降の dlerror()
の呼出しは他のエラーが発生するまで NULL を返すという点です。
<!--end_japanese-->
</para>
</sect2>

<sect2 id="dlsym">
<title>dlsym()</title>
<para>
<!--start_original
There's no point in loading a DL library if you can't use it.
The main routine for using a DL library is dlsym(3), which
looks up the value of a symbol in a given (opened) library.
This function is defined as:
end_original-->
<!--start_japanese-->
動的ライブラリをロードしても、それを使えなければ意味がありません。
動的ライブラリを使用する上で中心となるルーチンは dlsym(3) です。
dlsym() は、与えられた (オープン済みの) ライブラリ内にあるシンボルの値を検索します。
この関数は次のように定義されています。
</para>
<!--end_japanese-->
<!--start_original
<programlisting>
 void * dlsym(void *handle, char *symbol);
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  void * dlsym(void *handle, char *symbol);
</programlisting>
<!--end_japanese-->
<!--start_original
the handle is the value returned from dlopen, and symbol is a
NIL-terminated string.
If you can avoid it, don't store the result of dlsym() into a void*
pointer, because then you'll have to cast it each time you use it
(and you'll give less information to other people trying to
maintain the program).
end_original-->
<!--start_japanese-->
<para>
handle は dlopen() から返される値で、symbol はヌル文字で終端された文字列です。
dlsym() の結果を void * ポインタに格納することは、できるだけ避けてください。
なぜなら、そのポインタを使用するたびにキャストしなければならなくなるからです
(そのプログラムをメンテナンスしようとする他の方々が受け取れる情報量も減ってしまいます)。
<!--end_japanese-->
</para>

<para>
<!--start_original
dlsym() will return a NULL result if the symbol wasn't found.
If you know that the symbol could never have the value of NULL or zero,
that may be fine, but there's a potential ambiguity otherwise: if you got
a NULL, does that mean there is no such symbol, or that NULL is the
value of the symbol?
The standard solution is to call dlerror() first (to clear any error
condition that may have existed), then call dlsym() to request a symbol,
then call dlerror() again to see if an error occurred.
A code snippet would look like this:
end_original-->
<!--start_japanese-->
dlsym() は、シンボルが見つからなければ NULL を返します。
シンボルが NULL もしくはゼロという値をとることはありえないと分かっていれば、問題ありません。
しかし、そうでない場合は潜在的に曖昧さが残ります。もしも NULL
を受け取った場合、それは、「そんなシンボルは存在しない」ということを意味するのでしょうか、それとも「そのシンボルの値は
NULL である」ということを意味するのでしょうか？
標準的な方法は、(存在している可能性のあるエラー条件をクリアするために)
まず最初に dlerror() を呼び、次に、シンボルを要求するために dlsym()
を呼び、最後に、エラーが発生しているかどうかを調べるために再度
dlerror() を呼び出す、というものです。
コードは次のようになるでしょう。
</para>
<!--end_japanese-->
<!--start_original
<programlisting>
 dlerror(); /* clear error code */
 s = (actual_type) dlsym(handle, symbol_being_searched_for);
 if ((err = dlerror()) != NULL) {
  /* handle error, the symbol wasn't found */
 } else {
  /* symbol found, its value is in s */
 }
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  dlerror(); /* エラーコードをクリアする。*/
  s = (actual_type) dlsym(handle, symbol_being_searched_for);
  if ((err = dlerror()) != NULL) {
      /* ハンドルエラー。シンボルは見つからなかった。*/
  } else {
      /* シンボルが見つかった。値は s に格納されている。*/
  }
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->
</sect2>

<sect2 id="dlclose">
<title>dlclose()</title>
<para>
<!--start_original
The converse of dlopen() is dlclose(), which closes a DL library.
The dl library maintains link counts for
dynamic file handles, so a dynamic library is not actually deallocated
until dlclose has been called on it as many times as
dlopen has succeeded on it.
Thus, it's not a problem for the same program
to load the same library multiple times.
If a library is deallocated, its function _fini is called (if it exists)
in older libraries, but _fini is an obsolete mechanism and shouldn't
be relied on.
Instead, libraries should export routines using the
__attribute__((constructor)) and __attribute__((destructor)) function
attributes.
See <xref linkend="init-and-cleanup"> for more information.
Note: dlclose() returns 0 on success, and non-zero on error; some
Linux manual pages don't mention this.
end_original-->
<!--start_japanese-->
dlopen() の逆が dlclose() です。dlclose() で動的ライブラリをクローズします。
dl ライブラリは動的なファイルハンドルへのリンク数を管理しているので、同一の動的ライブラリに対して、dlopen()
が成功した回数と同じ数の dlclose() が呼ばれない限り、当該ライブラリは実際にはメモリ上から削除されません。
ですので、同じプログラムが同じライブラリを何回ロードしても、問題にはなりません。
ライブラリの割当てが解除されるとき、古いライブラリでは、(もしも存在するならば) _fini 関数が呼ばれます。
しかし、_fini は古い仕組みなので、これに依存してはいけません。
かわりに、ライブラリでは、__attribute__((constructor)) 関数属性と
__attribute__((destructor)) 関数属性を使用してルーチンをエクスポートしてください。
詳細については <xref linkend="init-and-cleanup"> を参照してください。
注意：dlclose() は、成功ならば 0 を、エラーならば非ゼロを返します。
この返り値について言及していない Linux man ページもあります。
<!--end_japanese-->
</para>
</sect2>

<sect2 id="dl-library-example">
<!--start_original
<title>DL Library Example</title>
end_original-->
<!--start_japanese-->
<title>動的ライブラリの例</title>
<!--end_japanese-->
<para>
<!--start_original
Here's an example from the man page of dlopen(3).
This example loads the math library and prints the cosine of 2.0, and
it checks for errors at every step (recommended):
end_original-->
<!--start_japanese-->
dlopen(3) の man ページ内の例をここに掲載します。
この例では、数学ライブラリをロードし、2.0 のコサインを出力しています。
また、全てのステップでエラーをチェックしています (推奨)。
</para>
<!--end_japanese-->
<!--start_original
<programlisting>
<![CDATA[

    #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);
    }
]]>
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
<![CDATA[

  #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);
  }
]]>
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->

<para>
<!--start_original
If  this  program were in a file named "foo.c",
you would build the program with the following command:
end_original-->
<!--start_japanese-->
このプログラムが "foo.c" という名前のファイルだとすると、次のコマンドでプログラムを作成することができます。
</para>
<!--end_japanese-->
<!--start_original
<programlisting>
    gcc -o foo foo.c -ldl
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  gcc -o foo foo.c -ldl
</programlisting>
<!--end_japanese-->
<!-- Removed ``-Wl,-export-dynamic'', it's not necessary -->
<!--start_original
</para>
end_original-->

</sect2>

</sect1>

<sect1 id="miscellaneous">
<!--start_original
<title>Miscellaneous</title>
end_original-->
<!--start_japanese-->
<title>雑録</title>
<!--end_japanese-->

<sect2 id="nm">
<!--start_original
<title>nm command</title>
end_original-->
<!--start_japanese-->
<title>nm コマンド</title>
<!--end_japanese-->
<para>
<!--start_original
The nm(1) command can report the list of
symbols in a given library.
It works on both static and shared libraries. 
For a given library nm(1) can list the symbol names defined, each
symbol's value, and the symbol's type.
It can also identify where the symbol was defined in the source code
(by filename and line number), if that information is available in
the library (see the -l option).
end_original-->
<!--start_japanese-->
nm(1) コマンドは、指定されたライブラリ内に存在するシンボルのリストを表示します。
静的ライブラリ、共有ライブラリのどちらに対しても機能します。
指定されたライブラリについて、nm(1) は、定義されているシンボルの名前、それぞれのシンボルの値、シンボルのタイプ、を表示できます。
また、そのライブラリ内に情報が存在するならば
(-l オプションを参照してください)、シンボルがソースコード内のどこで
(ファイル名と行番号) 定義されているかということも特定できます。
<!--end_japanese-->
</para>

<para>
<!--start_original
The symbol type requires a little more explanation.
The type is displayed as a letter; lowercase means that the symbol is
local, while uppercase means that the symbol is global (external).
Typical symbol types include
T (a normal definition in the code section),
D (initialized data section),
B (uninitialized data section),
U (undefined; the symbol is used by the library
  but not defined by the library), and
W (weak; if another library also defines this symbol, that definition
   overrides this one).
end_original-->
<!--start_japanese-->
シンボルタイプについては、もう少し説明が必要です。
小文字はそのシンボルがローカルであることを意味し、大文字はそのシンボルがグローバル
(外部定義) であることを意味します。
典型的なシンボルタイプは次のとおりです。
</para>
<itemizedlist>
<listitem><para>T (コードセクション内の普通の定義)</para></listitem>
<listitem><para>D (初期化されたデータセクション)</para></listitem>
<listitem><para>B (初期化されないデータセクション)</para></listitem>
<listitem><para>U (未定義。シンボルはライブラリによって使われているが、ライブラリ内では定義されていない)</para></listitem>
<listitem><para>W (weak. もしも他のライブラリも同じシンボルを定義している場合、その定義によりオーバーライドされる)</para></listitem>
</itemizedlist>
<!--end_japanese-->
<!--start_original
</para>
end_original-->

<para>
<!--start_original
If you know the name of a function, but
you truly can't remember what library it was defined in, you can use
nm's ``-o'' option (which prefixes the filename in each line) along
with grep to find the library name.  From a Bourne shell, you
can search all the libraries in /lib, /usr/lib, direct subdirectories of
/usr/lib, and /usr/local/lib for ``cos'' as follows:
end_original-->
<!--start_japanese-->
関数の名前は覚えているけれども、それがどのライブラリで定義されているか正確には思い出せない場合、nm
の「-o」オプションを使い (コマンドラインではファイル名より前に置きます)、出力を grep
することによって、ライブラリ名を見つけ出すことができます。
Bourne シェルであれば、/lib, /usr/lib, /usr/lib 直下のサブディレクトリ、および
/usr/local/lib 内の全ライブラリを対象にして「cos」を検索するには、次のようにします。
</para>
<!--end_japanese-->
<!--start_original
<programlisting>
nm -o /lib/* /usr/lib/* /usr/lib/*/* \
      /usr/local/lib/* 2> /dev/null | grep 'cos$' 
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  nm -o /lib/* /usr/lib/* /usr/lib/*/* \
        /usr/local/lib/* 2> /dev/null | grep 'cos$' 
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->
<para>
<!--start_original
Much more information about nm can be found in the nm ``info''
documentation locally installed at
<ulink url="info:binutils#nm">info:binutils#nm</ulink>.
end_original-->
<!--start_japanese-->
nm に関する詳細な情報は、お手元のマシンにインストールされている
nm の「info」文書 (<ulink url="info:binutils#nm">info:binutils#nm</ulink>)
内にあります。
<!--end_japanese-->
</para>
</sect2>

<sect2 id="init-and-cleanup">
<!--start_original
<title>Library constructor and destructor functions</title>
end_original-->
<!--start_japanese-->
<title>ライブラリのコンストラクタ関数およびデストラクタ関数</title>
<!--end_japanese-->

<para>
<!--start_original
Libraries should export initialization and cleanup routines using the
gcc __attribute__((constructor)) and __attribute__((destructor)) function
attributes.  See the gcc info pages for information on these.
Constructor routines are executed before dlopen returns
(or before main() is started if the library is loaded at load time).
Destructor routines are executed before dlclose returns
(or after exit() or completion of main() if the library is loaded at load time).
The C prototypes for these functions are:
end_original-->
<!--start_japanese-->
ライブラリの初期化ルーチンと終了処理ルーチンは、gcc の
__attribute__((constructor)) 関数属性と __attribute__((destructor))
関数属性を使用してエクスポートします。
これらの関数属性に関する情報は gcc の info ページを参照してください。
コンストラクタルーチンは、dlopen() から戻る前に実行されます
(または、ライブラリがプログラム開始時にロードされるならば main() 開始前)。
デストラクタルーチンは dlclose() から戻る前に実行されます
(または、ライブラリがプログラム開始時にロードされたならば、exit()
の後、もしくは main() 完了後)。
これらの関数の C 言語プロトタイプは次のようになります。
</para>
<!--end_japanese-->
<programlisting>
  void __attribute__ ((constructor)) my_init(void);
  void __attribute__ ((destructor)) my_fini(void);
</programlisting>
<!--start_original
</para>
end_original-->

<para>
<!--start_original
Shared libraries must not be compiled with the gcc arguments
``-nostartfiles'' or ``-nostdlib''.
If those arguments are used, the
constructor/destructor routines will not be executed
(unless special measures are taken).
end_original-->
<!--start_japanese-->
共有ライブラリをコンパイルするときは、gcc オプションの「-nostartfiles」や「-nostdlib」を付けてはいけません。
これらのオプションが使われると、(特殊な方法を用いない限り)
コンストラクタルーチンおよびデストラクタルーチンが実行されなくなってしまいます。
<!--end_japanese-->
</para>

<sect3 id="init-and-fini-obsolete">
<!--start_original
<title>Special functions _init and _fini (OBSOLETE/DANGEROUS)</title>
end_original-->
<!--start_japanese-->
<title>特別な関数 _init と _fini (古い仕組み／危険)</title>
<!--end_japanese-->
<para>
<!--start_original
Historically there have been two special functions, _init and _fini
that can be used to control constructors and destructors.
However, they are obsolete, and their use can lead to unpredicatable results.
Your libraries should not use these;
use the function attributes constructor and destructor above instead.
end_original-->
<!--start_japanese-->
歴史的な経緯により、コンストラクタとデストラクタを制御することができる二つの特別な関数、_init
と _fini が存在しています。しかしながら、これらは古くなっており、使用すると、予測できない結果を招くことがあります。
あなたのライブラリでは、これらの関数を使用しないようにしてください。
かわりに、上で説明した関数属性の constructor と destructor を使用してください。
<!--end_japanese-->
</para>

<para>
<!--start_original
If you must work with old systems or code that used _init or _fini, here's
how they worked.
Two special functions were defined for initializing and finalizing a module:
_init and _fini.
If a function ``_init'' is exported in a library,
then it is called when the library is first opened
(via dlopen() or simply as a shared library).
In a C program, this just means that you defined some function
named _init.
There is a corresponding function called _fini, which is called whenever a
client finishes using the library
(via a call dlclose() that brings its reference count to zero, or
on normal exit of the program).
The C prototypes for these functions are:
end_original-->
<!--start_japanese-->
古いシステムや、_init または _fini を使用しているコードを扱わなければならないときのため、_init
と _fini の動作をここで説明します。
二つの特別な関数 _init と _fini は、モジュールの初期化と終了処理のために定義されました。
「_init」関数がライブラリ内でエクスポートされている場合、そのライブラリが初めて
(dlopen() により、または単に共有ライブラリとして)
オープンされたときに呼び出されます。C
プログラムでは、_init という名前の何らかの関数を定義しているということを意味します。_init
に対応する関数として _fini が存在します。_fini は、(参照カウントをゼロにする dlclose()
の呼出しか、またはプログラムの通常の終了により)
クライアントがライブラリの使用を終了したときに呼び出されます。
これらの関数の C 言語プロトタイプは次のようになります。
</para>
<!--end_japanese-->
<programlisting>
  void _init(void);
  void _fini(void);
</programlisting>
<!--start_original
</para>
end_original-->

<para>
<!--start_original
In this case,
when compiling the file into a ``.o'' file in gcc, be sure to add the
gcc option ``-nostartfiles''.
This keeps the C compiler from
linking the system startup libraries against the .so file.
Otherwise, you'll get a ``multiple-definition'' error.
Note that this is completely different than compiling modules using
the recommended function attributes.
My thanks to Jim Mischel and Tim Gentry for their suggestion to add
this discussion of _init and _fini,
as well as help in creating it.
end_original-->
<!--start_japanese-->
この場合は、gcc でファイルを「.o」ファイルにコンパイルするとき、忘れずに
gcc オプション「-nostartfiles」を付けてください。
このオプションは、.so ファイルに対してシステムスタートアップライブラリをリンクしないよう、C
コンパイラに伝えるものです。
このオプションを付けないと、「multiple-definition (重複定義)」エラーが発生してしまいます。
お勧めしている関数属性を用いてモジュールをコンパイルする方法と、この方法とは、全く異なるものなので注意してください。
_init と _fini に関する議論を加えることを提案してくれたこと、およびその記述を手伝ってくれたことに対して、Jim
Mischel と Tim Gentry に感謝します。
<!--end_japanese-->
</para>

</sect3>
</sect2>

<sect2 id="shared-scripts">
<!--start_original
<title>Shared Libraries Can Be Scripts</title>
end_original-->
<!--start_japanese-->
<title>共有ライブラリはスクリプト化できる</title>
<!--end_japanese-->
<para>
<!--start_original
It's worth noting that the GNU loader
permits shared libraries to be text files using a
specialized scripting language instead of the usual library format.
This is useful for indirectly combining other libraries.
For example, here's the listing of
<filename>/usr/lib/libc.so</filename>
on one of my systems:
end_original-->
<!--start_japanese-->
通常のライブラリフォーマットとは異なる、特別なスクリプト言語で記述されたテキストファイルを、GNU
ローダが共有ライブラリとして扱えることは、注目に値します。
この機能は、他のライブラリを間接的に結合させる際に便利です。
例えば、私のシステムの一つでは、<filename>/usr/lib/libc.so</filename>
の中身は次のようになっています。
</para>
<!--end_japanese-->
<!--start_original
<programlisting>
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  /* GNU ld スクリプト
     共有ライブラリを使うが、幾つかの関数は静的ライブラリ内にしか
     存在しない。そのため、共有ライブラリ内に関数が見つからなければ、
     静的ライブラリを検索しにいく。*/
  GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->
<para>
<!--start_original
For more information about this, see the texinfo documentation on ld
linker scripts (ld command language).
General information is at
info:ld#Options and info:ld#Commands,
with likely commands discussed in
info:ld#Option Commands.
end_original-->
<!--start_japanese-->
これに関するより詳しい情報は、ld リンカスクリプト
(ld コマンド言語) に関する texinfo 文書を参照してください。
一般的な情報は info:ld#Options と info:ld#Commands にあり、よく使うコマンドは
info:ld#Option Commands で説明されています。
<!--end_japanese-->
</para>
</sect2>

<sect2 id="version-scripts">
<!--start_original
<title>Symbol Versioning and Version Scripts</title>
end_original-->
<!--start_japanese-->
<title>シンボルのバージョン付けとバージョンスクリプト</title>
<!--end_japanese-->
<para>
<!--start_original
Typically references to external functions are bound on an as-needed basis,
and are not all bound when the application starts up.
If a shared library is out of date, a required interface may
be missing; when the application tries to use that interface,
it may suddenly and unexpectedly fail.
end_original-->
<!--start_japanese-->
通常、外部関数への参照は必要に応じてバインドされます。
アプリケーションの起動時に全てがバインドされるわけではありません。
共有ライブラリが古いものである場合、必要なインターフェースが存在しないかもしれません。
アプリケーションがそのようなインターフェースを使おうとしたときになって初めて、アプリケーションは突然予期せぬエラーを起こします。
<!--end_japanese-->
</para>

<para>
<!--start_original
A solution to this problem are symbol versioning coupled with
version scripts.
With symbol versioning,
the user can get a warning when they start their program if
the libraries being used with the application are too old.
You can learn more about this from ld manual's descussion of
version scripts at
<ulink url="http://www.gnu.org/manual/ld-2.9.1/html_node/ld_25.html">
http://www.gnu.org/manual/ld-2.9.1/html_node/ld_25.html</ulink>.
end_original-->
<!--start_japanese-->
この問題に対する一つの解決方法は、バージョンスクリプトによるシンボルのバージョン付けです。
シンボルのバージョン付けにより、アプリケーションにより使用されるライブラリが古すぎる場合に、そのアプリケーションを起動したときに警告が出るようになります。
これについては、バージョンスクリプトに関する ld マニュアルの説明
(<ulink url="http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html"
>http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html</ulink>)
を参照してください。
<!--end_japanese-->
</para>
</sect2>

<sect2 id="gnu-libtool">
<title>GNU libtool</title>
<para>
<!--start_original
If you're building an application that should port to many systems,
you might consider using
<ulink url="http://www.gnu.org/software/libtool/libtool.html">GNU libtool</ulink>
to build and install libraries.
GNU libtool is a generic library support script.
Libtool hides the complexity of using shared libraries
behind a consistent, portable interface.
Libtool provides portable interfaces to
create object files, link libraries (static and shared), link executables,
debug executables, install libraries, install executables.
It also includes libltdl, a portability wrapper for
dynamically loading programs.
For more information, see its documentation at
<ulink url="http://www.gnu.org/software/libtool/manual.html">http://www.gnu.org/software/libtool/manual.html</ulink>
end_original-->
<!--start_japanese-->
多くのシステムに移植する必要のあるアプリケーションを作成しているならば、ライブラリの構築とインストールについて、<ulink
url="http://www.gnu.org/software/libtool/libtool.html">GNU libtool</ulink>
を使用することを検討したほうがよいかもしれません。
GNU libtool は、汎用的なライブラリサポートスクリプトです。
libtool は、共有ライブラリ使用時の複雑さを、一貫性のある移植性の高いインターフェースで隠蔽します。
libtool は、オブジェクト作成、ライブラリのリンク
(静的および共有)、実行可能ファイルのリンク、実行可能ファイルのデバッグ、ライブラリのインストール、実行可能ファイルのインストール、に対して、移植性の高いインターフェースを提供します。
また、libltdl という、プログラムを動的にロードするための移植性のあるラッパーも、libtool
には含まれています。詳細については、libtool の文書
<ulink url="http://www.gnu.org/software/libtool/manual.html"
>http://www.gnu.org/software/libtool/manual.html</ulink>
を参照してください。
<!--end_japanese-->
</para>

</sect2>

<sect2 id="removing-symbols">
<!--start_original
<title>Removing symbols for space</title>
end_original-->
<!--start_japanese-->
<title>スペースを節約するためにシンボルを削除する</title>
<!--end_japanese-->
<para>
<!--start_original
All the symbols included in generated files are useful for debugging,
but take up space.
If you need space, you can eliminate some of it.
end_original-->
<!--start_japanese-->
生成されたファイル内に含まれるシンボルは全て、デバッグの際に役に立ちますが、スペースを取ります。
スペースを節約する必要があるならば、シンボルの一部を削除することができます。
<!--end_japanese-->
</para>

<para>
<!--start_original
The best approach is to first generate the object files normally,
and do all your debugging and testing first
(debugging and testing is much easier with them).
Afterwards, once you've tested the program thoroughly, use
strip(1) to remove the symbols.
The strip(1) command gives you a good deal of control over
what symbols to eliminate; see its documentation for details.
end_original-->
<!--start_japanese-->
一番良い方法は、最初にいつも通りにオブジェクトファイルを生成し、デバッグとテストを全て実行してしまうことです
(シンボルを含むオブジェクトファイルでは、デバッグとテストは非常に簡単です)。
その後、プログラムを完全にテストし終えたら、strip(1) を用いてシンボルを削除します。
strip(1) コマンドでは、どのシンボルを削除するかについて、いろいろと制御することができます。
詳細については strip(1) の文書を参照してください。
<!--end_japanese-->
</para>
<para>
<!--start_original
Another approach is to use the GNU ld options ``-S'' and ``-s'';
``-S'' omits debugger symbol information (but not all symbols)
from the output file, while
``-s'' omits all symbol information from the output  file.
You can invoke these options through gcc as ``-Wl,-S'' and ``-Wl,-s''.
If you always strip the symbols and these options are sufficient, feel
free, but this is a less flexible approach.
end_original-->
<!--start_japanese-->
もう一つの方法は、GNU ld オプションの「-S」と「-s」を使用することです。
「-S」は、出力ファイルから、(全てではないですが) デバッグシンボル情報を除外します。
一方、「-s」は、出力ファイルから全てのシンボル情報を除外します。
「-Wl,-S」や「-Wl,-s」とすることにより、これらのオプションを
gcc 経由で ld に渡せます。
常にシンボルを取り除くことにしていて、これらのオプションで十分というのならば、それでよいでしょう。
ただし、このやり方は、strip(1) に比べ柔軟性が下がります。
<!--end_japanese-->
</para>
</sect2>

<sect2 id="small-executables">
<!--start_original
<title>Extremely small executables</title>
end_original-->
<!--start_japanese-->
<title>極端に小さな実行可能ファイル</title>
<!--end_japanese-->
<para>
<!--start_original
You might find the paper
<ulink url="http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html">Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux</ulink>
useful.
It describes how to make a truly tiny program executable.
Frankly, you shouldn't use most of these tricks under normal
circumstances, but they're quite instructive in showing how
ELF really works.
end_original-->
<!--start_japanese-->
「<ulink url="http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html"
>Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux</ulink>
(本当に小さな Linux 用 ELF 実行可能ファイル作成についてのすぐ役立つチュートリアル)」という文書が、あなたの役に立つかもしれません。
この文書は、非常に小さな実行可能プログラムの作り方について説明しています。
率直に言えば、一般的な状況下では、この文書で紹介されているトリックのほとんどは、使わないほうがよいです。
しかしこの文書は、ELF が実際にどのように機能するかを示しているという点において、教育上極めて有益です。
<!--end_japanese-->
</para>
</sect2>

<sect2 id="cpp-vs-c">
<title>C++ vs. C</title>
<para>
<!--start_original
It's worth noting that if you're writing a C++ program, and you're
calling a C library function, in your C++ code you'll need to define 
the C function as extern "C".
Otherwise, the linker won't be able to locate the C function.
Internally, C++ compilers ``mangle'' the names of C++ functions
(e.g., for typing purposes), and they need to be told that a given
function should be called as a C function (and thus, not have its
name mangled).
end_original-->
<!--start_japanese-->
C++ プログラムを書いていて、C ライブラリ関数を呼び出すなら、C++ コード内でその
C 関数を extern "C" として宣言する必要があるので注意してください。
そうしないと、リンカがその C 関数を見つけることができなくなってしまいます。
内部的に、C++ コンパイラは C++ 関数の名前を「変形 (mangle)」します
(例えば、型情報を付加するために)。そのため、C++ コンパイラには、指定された関数を
C 関数として呼び出すことを教えてやる必要があります
(これにより、その C 関数の名前は変形されなくなります)。
<!--end_japanese-->
</para>

<para>
<!--start_original
If you're writing a program library that could be called from C or C++,
it's recommended that you include 'extern "C"' commands right in your
header files so that you do this automatically for your users.
When combined with the usual #ifndef at the top of a file to skip
re-executing header files, this means that a typical header file usable
by either C or C++ for some header file foobar.h would look like this:
end_original-->
<!--start_japanese-->
C または C++ から呼び出されるプログラムライブラリを作成しているのなら、ライブラリユーザのため、この処理が自動的におこなわれるよう、ヘッダファイルに「extern
"C"」を含めることをお勧めします。
ヘッダファイルの再読込みをスキップするためにヘッダファイルの先頭に置く、いつもの #ifndef
と組み合わせて示すとすれば、C および C++ のどちらでも使用可能なヘッダファイルの典型例は、例えば
foobar.h だとすると、次のようになります。
</para>
<!--end_japanese-->
<!--start_original
<programlisting>
<![CDATA[
/* Explain here what foobar does */

#ifndef FOOBAR_H
#define FOOBAR_H

#ifdef __cplusplus
extern "C" {
#endif

 ... header code for foobar goes here ...

#ifdef  __cplusplus
}
#endif
#endif
]]>
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
<![CDATA[
  /* foobar が何をするものなのか、ここで説明する。*/

  #ifndef FOOBAR_H
  #define FOOBAR_H

  #ifdef __cplusplus
  extern "C" {
  #endif

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

  #ifdef  __cplusplus
  }
  #endif
  #endif
]]>
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->
</sect2>

<sect2 id="speeding-cpp-init">
<!--start_original
<title>Speeding up C++ initialization</title>
end_original-->
<!--start_japanese-->
<title>C++ 初期処理の高速化</title>
<!--end_japanese-->
<para>
<!--start_original
The KDE developers have noticed that large GUI C++ applications can take
a long time to start up, in part due to its needing to do many relocations.
There are several solutions to this.
See
<ulink url="http://www.suse.de/~bastian/Export/linking.txt">Making C++
ready for the desktop (by Waldo Bastian)</ulink>
for more information.
end_original-->
<!--start_japanese-->
KDE 開発者は、大きな GUI C++ アプリケーションの起動に長い時間がかかり、その理由の一つが、数多くのリロケーションをおこなう必要があることだと気付いています。
この問題に対して、幾つか解決方法があります。詳細については、「<ulink
url="http://www.suse.de/~bastian/Export/linking.txt">Making C++
ready for the desktop (by Waldo Bastian)</ulink>
(C++ コードをデスクトップ向けにする (Waldo Bastian 著))」を参照してください。
<!--end_japanese-->
</para>
</sect2>

<sect2 id="lsb">
<title>Linux Standard Base (LSB)</title>
<para>
<!--start_original
The goal of the Linux Standard Base (LSB) project
is to develop and promote a set of standards that will
increase compatibility among Linux distributions and
enable software applications to run on any compliant Linux system.
The project's home page is at
<ulink url="http://www.linuxbase.org">http://www.linuxbase.org</ulink>.
end_original-->
<!--start_japanese-->
Linux Standard Base (LSB) プロジェクトの目的は、Linux
ディストリビューション間の互換性を高め、LSB に準拠する全ての Linux
システム上でソフトウェアアプリケーションの実行を可能とするための標準を開発し、普及させることです。
このプロジェクトのホームページは
<ulink url="http://www.linuxbase.org/">http://www.linuxbase.org/</ulink>
です。
<!--end_japanese-->
</para>
<para>
<!--start_original
A nice article that summarizes how to develop LSB-compliant applications
was published in October 2002,
<ulink url="http://www-106.ibm.com/developerworks/linux/library/l-lsb.html?t=gr,lnxw02=LSBapps">Developing LSB-certified applications:
Five steps to binary-compatible Linux applications</ulink>
by George Kraft IV
(Senior software engineer, IBM's Linux Technology Center).
Of course, you need to write code that only accesses the standardized
portability layer if you want your code to be portable.
In addition, the LSB provides some tools so that application writers of C/C++
programs can check for LSB compliance; these tools use some capabilities
of the linker and special libraries to do these checks.
Obviously, you'll need to install the tools to do these checks;
you can get them from the LSB website.
Then, simply use the "lsbcc" compiler as your C/C++ compiler
(lsbcc internally creates a linking environment that will complain if
certain LSB rules aren't followed):
end_original-->
<!--start_japanese-->
LSB 準拠アプリケーションの開発方法について簡単にまとめた、George Kraft IV
(IBM Linux テクノロジーセンター上級ソフトウェアエンジニア)
による素晴らしい文書、<ulink url="http://www-106.ibm.com/developerworks/linux/library/l-lsb.html?t=gr,lnxw02=LSBapps"
>Developing LSB-certified applications: Five steps to binary-compatible Linux applications</ulink>
(訳注：日本語訳はこちら→ <ulink url="http://www-6.ibm.com/jp/developerworks/linux/030117/j_l-lsb.html"
>LSB 認定アプリケーション開発</ulink>)
が 2002 年 10 月に公開されました。
当然ながら、自分のコードの移植性を高めたいならば、標準化された移植層のみを使用してコードを書く必要があります。
さらに、LSB では、C/C++ プログラムのアプリケーション作成者が LSB
に準拠しているかどうかをチェックするために使えるツールを、幾つか提供しています。
これらのツールは、リンカの幾つかの機能と、チェックをおこなうための特別なライブラリを使用しています。
もちろん、チェックをおこなうためには、ツール群をインストールする必要があります。
ツール群は LSB のウェブサイトから取得できます。
取得後は、C/C++ コンパイラとして単に "lsbcc" コンパイラを使ってください
(lsbcc は、何かしらの LSB 規則が守られていないときにその旨を出力するためのリンク用環境変数を、内部的に作成します)。
</para>
<!--end_japanese-->
<!--start_original
<programlisting>
 $ CC=lsbcc make myapplication
  (or)
 $ CC=lsbcc ./configure; make myapplication 
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  $ CC=lsbcc make myapplication
   (または)
  $ CC=lsbcc ./configure; make myapplication 
</programlisting>
<!--end_japanese-->
<!--start_original
You can then use the lsbappchk program to ensure that
the program only uses functions standardized by the LSB:
end_original-->
<!--start_japanese-->
<para>
続けて、当該プログラムが LSB で標準化されている関数だけを使用していることを確認するため、
lsbappchk プログラムを使用します。 
</para>
<!--end_japanese-->
<!--start_original
<programlisting>
 $ lsbappchk myapplication
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
  $ lsbappchk myapplication
</programlisting>
<!--end_japanese-->
<!--start_original
You also need to follow the LSB packaging guidelines
(e.g., use RPM v3, use LSB-conforming package names, and
for add-on software must install in /opt by default).
See the article and LSB website for more information.
end_original-->
<!--start_japanese-->
<para>
LSB のパッケージングガイドラインに従う必要もあります
(例えば、RPM バージョン 3 を使う、LSB 準拠のパッケージ名を使う、アドオンソフトウェアの場合はデフォルトで
/opt にインストールしなければならない、など)。
詳細については、先に言及した文書と LSB ウェブサイトを参照してください。
<!--end_japanese-->
</para>
</sect2>

<sect2 id="merging-libraries-into-larger">
<!--start_original
<title>Merging Libraries into Larger Shared Libraries</title>
end_original-->
<!--start_japanese-->
<title>ライブラリ群を統合して大きな共有ライブラリへ</title>
<!--end_japanese-->
<para>
<!--start_original
What if you want to first create smaller libraries, then later
merge them into larger libraries?
In this case, you may find ld's "&#045;&#045;whole-archive" option useful,
which can be used to forcibly bring .a files and link them into an .so file.
end_original-->
<!--start_japanese-->
最初に小さいライブラリ群を作成しておき、後からそれらを大きなライブラリへとマージしたいという場合、どうしたらよいでしょうか？
このようなときは、ld の "--whole-archive" オプションが便利です。
このオプションは、.a ファイル群を強制的に一つの .so ファイルへリンクする際に使用できます。
<!--end_japanese-->
</para>

<para>
<!--start_original
Here's an example of how to use &#045;&#045;whole-archive:
end_original-->
<!--start_japanese-->
--whole-archive の使い方の一例を挙げます。
</para>
<!--end_japanese-->
<!--start_original
<programlisting>
<![CDATA[
 gcc -shared -Wl,-soname,libmylib.$(VER) -o libmylib.so $(OBJECTS) \
 -Wl,&#045;&#045;whole-archive $(LIBS_TO_LINK) -Wl,&#045;&#045;no-whole-archive \
 $(REGULAR_LIBS)
]]>
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
<![CDATA[
  gcc -shared -Wl,-soname,libmylib.$(VER) -o libmylib.so $(OBJECTS) \
      -Wl,--whole-archive $(LIBS_TO_LINK) -Wl,--no-whole-archive \
      $(REGULAR_LIBS)
]]>
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->

<para>
<!--start_original
As the ld documentation notes, be sure to use &#045;&#045;no-whole-archive option
at the end, or gcc will try to merge in the standard libraries as well.
My thanks to Kendall Bennett for both suggesting this recipe, as
well as providing it.
end_original-->
<!--start_japanese-->
ld 文書でも示されているとおり、最後に --no-whole-archive オプションを使うようにしてください。
そうしないと、gcc は標準ライブラリ群もマージしようとしてしまいます。
--whole-archive に関する記述の提案と作成の両方に対して、Kendall Bennett
に感謝します。
<!--end_japanese-->
</para>
</sect2>

</sect1>

<sect1 id="more-examples">
<!--start_original
<title>More Examples</title>
end_original-->
<!--start_japanese-->
<title>例</title>
<!--end_japanese-->
<para>
<!--start_original
The following are more examples of all three approaches
(static, shared, and dynamically loaded libraries).
File libhello.c is a trivial library,
with libhello.h as its header.
File demo_use.c is a trivial caller of the library.
This is followed by commented scripts (script_static and script_dynamic)
showing how to use the library as a static and shared library.
This is followed by demo_dynamic.c and script_dynamic, which show
how to use the shared library as a dynamically loaded library.
end_original-->
<!--start_japanese-->
三つの方法 (静的ライブラリ、共有ライブラリ、動的ライブラリ) 全ての例を以下に挙げます。
libhello.c ファイルは簡単なライブラリで、そのヘッダファイルとして libhello.h があります。
demo_use.c ファイルは、libhello ライブラリを呼び出す簡単なプログラムです。
続けて、コメント付きのスクリプト (script_static と script_dynamic) を示します。
これらのスクリプトは、libhello ライブラリを静的ライブラリおよび共有ライブラリとして使う方法を示すものです。
さらに demo_dynamic.c と script_dynamic も挙げます。
これらは、共有ライブラリを動的ライブラリとして使う方法を示すものです。
<!--end_japanese-->
</para>

<!-- BEGINNING OF demo.sgml -->

<sect2>
<!--start_original
<title>File libhello.c</title>
end_original-->
<!--start_japanese-->
<title>libhello.c ファイル</title>
<!--end_japanese-->
<!--start_original
<para>
end_original-->
<!--start_original
<programlisting>
<![CDATA[
/* libhello.c - demonstrate library use. */

#include <stdio.h>

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

]]>
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
<![CDATA[
  /* libhello.c - ライブラリ使用方法を示します */

  #include <stdio.h>

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

]]>
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->
</sect2>
<sect2>
<!--start_original
<title>File libhello.h</title>
end_original-->
<!--start_japanese-->
<title>libhello.h ファイル</title>
<!--end_japanese-->
<!--start_original
<para>
end_original-->
<!--start_original
<programlisting>
<![CDATA[
/* libhello.h - demonstrate library use. */


void hello(void);

]]>
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
<![CDATA[
  /* libhello.h - ライブラリ使用方法を示します */

  void hello(void);

]]>
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->
</sect2>
<sect2>
<!--start_original
<title>File demo_use.c</title>
end_original-->
<!--start_japanese-->
<title>demo_use.c ファイル</title>
<!--end_japanese-->
<!--start_original
<para>
end_original-->
<!--start_original
<programlisting>
<![CDATA[
/* demo_use.c &#045;&#045; demonstrate direct use of the "hello" routine */

#include "libhello.h"

int main(void) {
 hello();
 return 0;
}
]]>
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
<![CDATA[
  /* demo_use.c -- "hello" ルーチンを直接使用する方法を示します */

  #include "libhello.h"

  int main(void) {
      hello();
      return 0;
  }
]]>
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->
</sect2>
<sect2>
<!--start_original
<title>File script_static</title>
end_original-->
<!--start_japanese-->
<title>script_static ファイル</title>
<!--end_japanese-->
<!--start_original
<para>
end_original-->
<!--start_original
<programlisting>
<![CDATA[
#!/bin/sh
# Static library demo

# Create static library's object file, libhello-static.o.
# I'm using the name libhello-static to clearly
# differentiate the static library from the
# dynamic library examples, but you don't need to use
# "-static" in the names of your
# object files or static libraries.

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

# Create static library.

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

# At this point we could just copy libhello-static.a
# somewhere else to use it.
# For demo purposes, we'll just keep the library
# in the current directory.

# Compile demo_use program file.

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

# Create demo_use program; -L. causes "." to be searched during
# creation of the program.  Note that this command causes
# the relevant object file in libhello-static.a to be
# incorporated into file demo_use_static.

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

# Execute the program.

./demo_use_static
]]>
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
<![CDATA[
  #!/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
]]>
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->
</sect2>
<sect2>
<!--start_original
<title>File script_shared</title>
end_original-->
<!--start_japanese-->
<title>script_shared ファイル</title>
<!--end_japanese-->
<!--start_original
<para>
end_original-->
<!--start_original
<programlisting>
<![CDATA[
#!/bin/sh
# Shared library demo

# Create shared library's object file, libhello.o.

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

# Create shared library.
# Use -lc to link it against C library, since libhello
# depends on the C library.

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

# At this point we could just copy libhello.so.0.0 into
# some directory, say /usr/local/lib.

# Now we need to call ldconfig to fix up the symbolic links.
 
# Set up the soname.  We could just execute:
# ln -sf libhello.so.0.0 libhello.so.0
# but let's let ldconfig figure it out.

/sbin/ldconfig -n .

# Set up the linker name.
# In a more sophisticated setting, we'd need to make
# sure that if there was an existing linker name,
# and if so, check if it should stay or not.

ln -sf libhello.so.0 libhello.so

# Compile demo_use program file.

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

# Create program demo_use.
# The -L. causes "." to be searched during creation
# of the program; note that this does NOT mean that "."
# will be searched when the program is executed.

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

# Execute the program.  Note that we need to tell the program
# where the shared library is, using LD_LIBRARY_PATH.

LD_LIBRARY_PATH="." ./demo_use

]]>
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
<![CDATA[
  #!/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

]]>
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->
</sect2>
<sect2>
<!--start_original
<title>File demo_dynamic.c</title>
end_original-->
<!--start_japanese-->
<title>demo_dynamic.c ファイル</title>
<!--end_japanese-->
<!--start_original
<para>
end_original-->
<!--start_original
<programlisting>
<![CDATA[
/* demo_dynamic.c &#045;&#045; demonstrate dynamic loading and
   use of the "hello" routine */


/* Need dlfcn.h for the routines to
   dynamically load libraries */
#include <dlfcn.h>

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

/* Note that we don't have to include "libhello.h".
   However, we do need to specify something related;
   we need to specify a type that will hold the value
   we're going to get from dlsym(). */

/* The type "simple_demo_function" describes a function that
   takes no arguments, and returns no value: */

typedef void (*simple_demo_function)(void);


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

 /* Load dynamically loaded library */
 module = dlopen("libhello.so", RTLD_LAZY);
 if (!module) {
   fprintf(stderr, "Couldn't open libhello.so: %s\n",
           dlerror());
   exit(1);
 }

 /* Get symbol */
 dlerror();
 demo_function = dlsym(module, "hello");
 if ((error = dlerror())) {
   fprintf(stderr, "Couldn't find hello: %s\n", error);
   exit(1);
 }

 /* Now call the function in the DL library */
 (*demo_function)();

 /* All done, close things cleanly */
 dlclose(module);
 return 0;
}
]]>
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
<![CDATA[
  /*
   * 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;
  }
]]>
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->
</sect2>
<sect2>
<!--start_original
<title>File script_dynamic</title>
end_original-->
<!--start_japanese-->
<title>script_dynamic ファイル</title>
<!--end_japanese-->
<!--start_original
<para>
end_original-->
<!--start_original
<programlisting>
<![CDATA[
#!/bin/sh
# Dynamically loaded library demo

# Presume that libhello.so and friends have
# been created (see dynamic example).

# Compile demo_dynamic program file into an object file.

gcc -Wall -g -c demo_dynamic.c

# Create program demo_use.
# Note that we don't have to tell it where to search for DL libraries,
# since the only special library this program uses won't be
# loaded until after the program starts up.
# However, we DO need the option -ldl to include the library
# that loads the DL libraries.

gcc -g -o demo_dynamic demo_dynamic.o -ldl

# Execute the program.  Note that we need to tell the
# program where get the dynamically loaded library,
# using LD_LIBRARY_PATH.

LD_LIBRARY_PATH="." ./demo_dynamic
]]>
</programlisting>
end_original-->
<!--start_japanese-->
<programlisting>
<![CDATA[
  #!/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
]]>
</programlisting>
<!--end_japanese-->
<!--start_original
</para>
end_original-->
</sect2>
<!-- END OF demo.sgml -->
</sect1>

<sect1 id="info-sources">
<!--start_original
<title>Other Information Sources</title>
end_original-->
<!--start_japanese-->
<title>その他の情報源</title>
<!--end_japanese-->
<para>
<!--start_original
Particularly useful sources of information about libraries
include the following:
end_original-->
<!--start_japanese-->
ライブラリに関する特に有益な情報源を下記に挙げます。
<!--end_japanese-->
<itemizedlist>
<!--start_original
<listitem><para>``The GCC HOWTO'' by Daniel Barlow.
In particular, this HOWTO discusses
compiler options for creating libraries and how to query
libraries.
It covers information not covered here, and vice versa.
This HOWTO is available through the Linux Documentation Project at
<ulink url="http://www.linuxdoc.org">http://www.linuxdoc.org</ulink>.
</para></listitem>
end_original-->
<!--start_japanese-->
<listitem><para>Daniel Barlow による「The GCC HOWTO」。特に、この HOWTO
では、ライブラリ作成用のコンパイラオプションと、ライブラリへの問い合わせ方法が説明されています。
ここでは取り上げていない情報を扱っており、また、逆も真です。この HOWTO
は、<ulink url="http://www.linuxdoc.org/">http://www.linuxdoc.org/</ulink>
の Linux Documentation Project から入手できます
(訳注：GCC HOWTO は、著者の希望により公開が中止されています)。
</para></listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>``Executable and Linkable Format (ELF)'' by
the Tool Interface Standards (TIS) committee
(this is actually one chapter of the Portable Formats Specification
Version 1.1 by the same committee).
This provides information about the ELF format
(it isn't specific to Linux or GNU gcc), and provides a great deal of
detail on the ELF format.
See
<ulink url="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz">ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz</ulink>
If you get the file from MIT, note that the format is unusual;
after gunzipping and untarring, you'll get an ``hps'' file; just
strip off the top and bottom lines, rename it to a ``ps'' file,
and you'll get a printable Postscript file with the usual filename.
</para></listitem>
end_original-->
<!--start_japanese-->
<listitem><para>Tool Interface Standards (TIS)
委員会による「Executable and Linkable Format (ELF)」
(実はこの文書は、同委員会による Portable Formats Specification
Version 1.1 内の一つの章です)。この文書は、ELF フォーマット
(Linux や GNU gcc に特化したものではありません) に関する大量の詳細情報を提供するものです。
<ulink url="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz"
>ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz</ulink>
を参照してください。MIT からファイルを取得する場合、フォーマットが一般的なものではないので注意してください。
gunzip して tar で解凍すると、「hps」ファイルができます。
ファイルの最初と最後の行を削除し、「ps」ファイルに名前を変更すれば、いつものファイル名の、印字可能な
PostScript ファイルを取得できます。
</para></listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>
``ELF: From the Programmer's Perspective'' by
Hongjui Lu. This gives Linux and GNU gcc-specific information on ELF, and is
available at
<ulink url="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz">ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz</ulink>.
</para></listitem>
end_original-->
<!--start_japanese-->
<listitem><para>Hongjui Lu による「ELF: From the Programmer's Perspective」。
Linux と GNU gcc に特化した ELF 関連情報があります。
<ulink url="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz"
>ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz</ulink>
で取得できます。
</para></listitem>
<!--end_japanese-->

<!--start_original
<listitem><para>
The ld documentation ``Using LD, the GNU Linker'' describes ld in
far more detail.
It is available at
<ulink url="http://www.gnu.org/manual/ld-2.9.1">
http://www.gnu.org/manual/ld-2.9.1</ulink>.
</para></listitem>
end_original-->
<!--start_japanese-->
<listitem><para>ld 文書「Using LD, the GNU linker」には、ld
についてより詳しい説明があります。
<ulink url="http://www.gnu.org/software/binutils/manual/ld-2.9.1/"
>http://www.gnu.org/software/binutils/manual/ld-2.9.1/</ulink>
で参照できます。
</para></listitem>
<!--end_japanese-->

<!--start_original
<listitem><para>
You should also look at the normal "info" documentation, especially for
ld and gcc.
</para></listitem>
end_original-->
<!--start_japanese-->
<listitem><para>いつもの「info」文書、特に
ld と gcc の info 文書も参照してください。
</para></listitem>
<!--end_japanese-->
<!--start_japanese-->
<listitem><para>(訳者による追加)
佐野武俊さんによる「Linux C Library (libc) について」。
Linux C Library (libc) の概要について、その役割と歴史などを簡単にまとめたものです。
<ulink url="http://www.linux.or.jp/JF/JFdocs/libc-intro.html"
>http://www.linux.or.jp/JF/JFdocs/libc-intro.html</ulink>
で参照できます。
</para></listitem>
<!--end_japanese-->


</itemizedlist>
</para>
</sect1>

<sect1 id="copyright">
<!--start_original
<title>Copyright and License</title>
end_original-->
<!--start_japanese-->
<title>著作権とライセンス</title>
<!--end_japanese-->
<para>
<!--start_original
This document is Copyright (C) 2000 David A. Wheeler.
It is covered by the GNU General Public License (GPL).
You may redistribute it without cost.
Interpret the document's source text
as the ``program'' and adhere to the following terms:
end_original-->
<!--start_japanese-->
この文書の著作権は David A. Wheeler にあり (Copyright (C) 2000)、GNU
一般公有使用許諾 (GPL) により保護されます。
代価なしで再配布しても構いません。
文書の原文を「プログラム」と解釈し、次の条項も守ってください。 
<!--end_japanese-->
<blockquote>
<para>
    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.
</para>
<!--start_japanese-->
<para>
本プログラムはフリー・ソフトウェアです。あなたは、Free Software Foundation が公表した
GNU 一般公有使用許諾の「バージョン 2」或いはそれ以降の各バージョンの中からいずれかを選択し、そのバージョンが定める条項に従って本プログラムを再頒布または変更することができます。
</para>
<!--end_japanese-->

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

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

<para>
<!--start_original
These terms do permit mirroring by other web sites,
but please:
end_original-->
<!--start_japanese-->
これらの条項は、他のウェブサイトがミラーリングをすることを許可するものですが、
<!--end_japanese-->
<itemizedlist>
<!--start_original
<listitem><para>make sure your mirrors automatically get
  upgrades from the master site,</para></listitem>
end_original-->
<!--start_japanese-->
<listitem><para>あなたのミラーサイトがマスターサイトから最新情報を自動的に取得するようにし、
</para></listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>clearly show the location of the master site,
<ulink url="http://www.dwheeler.com/program-library">http://www.dwheeler.com/program-library</ulink>,
with a hypertext link
to the master site, and</para></listitem>
end_original-->
<!--start_japanese-->
<listitem><para>マスターサイトへのハイパーリンクと共にマスターサイトのロケーション
<ulink url="http://www.dwheeler.com/program-library/"
>http://www.dwheeler.com/program-library/</ulink>
を明示し、そして
</para></listitem>
<!--end_japanese-->
<!--start_original
<listitem><para>give me (David A. Wheeler) credit as the author.
</para></listitem>
end_original-->
<!--start_japanese-->
<listitem><para>著者として、私
(David A. Wheeler) に謝辞をお願いします。
</para></listitem>
<!--end_japanese-->
</itemizedlist>
</para>

<para>
<!--start_original
The first two points primarily protect me from repeatedly hearing about
obsolete bugs.
I do not want to hear about bugs I fixed a year ago, just because you
are not properly mirroring the document.
By linking to the master site,
users can check and see if your mirror is up-to-date.
I'm sensitive to the problems of sites which have very
strong security requirements and therefore cannot risk normal
connections to the Internet; if that describes your situation,
at least try to meet the other points
and try to occasionally sneakernet updates into your environment.
end_original-->
<!--start_japanese-->
はじめの二つは、主に、過去のバグについて何度も言及されることを防ぐためです。
あなたが文書を適切にミラーリングしていないというだけの理由で、一年前に直したバグに関する話を私は聞きたくはありません。
マスターサイトへリンクを張ることにより、ユーザはあなたのサイトが最新のものであるかどうかを確認できます。
非常に厳しいセキュリティ要求があり、そのためにインターネットへ通常に接続するリスクを取ることができないサイトの問題を、私は気にしています。
これがあなたの状況に当てはまるならば、少なくとも、他のポイントへの接続を試みたり、折に触れてあなたの環境へのスニーカーネット
(sneakernet) アップデート 
(訳注：スニーカーネット ＝ FD 等を持ち運びすることにより情報を共有するネットワーク)
を試みるなどしてください。
<!--end_japanese-->
</para>

<para>
<!--start_original
By this license, you may modify the document,
but you can't claim that what you didn't write is yours (i.e., plagiarism)
nor can you pretend that a modified version is identical to
the original work.
Modifying the work does not transfer copyright of the entire work to you;
this is not a ``public domain'' work in terms of copyright law.
See the license for details, in particular noting that
``You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.''
If you have questions about what the license allows, please contact me.
In most cases, it's better if you send your changes to the master
integrator (currently David A. Wheeler), so that your changes will be
integrated with everyone else's changes into the master copy.
end_original-->
<!--start_japanese-->
このライセンスによれば、あなたはドキュメントを変更しても構いませんが、あなたが書いたものではないものをあなたのものであると主張したり
(つまり盗用です)、変更したバージョンが原作であるかのようなふりをすることはできません。
著作物の変更は、著作物全体の著作権をあなたに譲渡するものではありません。
これは、著作権法の用語でいうところの「パブリックドメイン」の著作物ではありません。
ライセンスを細部に渡って参照してください。
特に、「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) へ送るのがよいでしょう。
<!--end_japanese-->
</para>

</sect1>

<!--start_japanese-->
<sect1 id="japanese-translation">
<title>日本語訳について</title>
<para>
Program Library HOWTO の日本語訳の維持管理は JF プロジェクト
(<ulink url="http://www.linux.or.jp/JF/">http://www.linux.or.jp/JF/</ulink>)
がおこなっています。日本語訳についてのご意見等は
JF プロジェクトのメーリングリスト &lt;JF(a)linux.or.jp&gt;
までお願い致します。
</para>

<sect2 id="japanese-translation-history">
<title>日本語訳履歴</title>
<para>
<revhistory>
<revision>
  <revnumber>1.20-ja</revnumber>
  <date>2004 年 6 月 30 日</date>
  <authorinitials>川崎 貴彦</authorinitials>
  <revremark>原文バージョン 1.20 の対訳</revremark>
</revision>
</revhistory>
</para>
</sect2>

<sect2 id="japanese-translation-credits">
<title>謝辞</title>
<para>
日本語に翻訳するにあたり、次の方々にご協力していただきました。
ここにお名前を挙げさせていただくとともに、感謝の意を表したいと思います
(順不同、敬称略、1.20-ja 以降)。
</para>
<itemizedlist>
<listitem>
  <para>
    <othercredit>
      <othername>中谷 千絵</othername>
      <contrib>日本語訳校正</contrib>
      <affiliation>
        <address>
          <email>jeanne(a)mbox.kyoto-inet.or.jp</email>
        </address>
      </affiliation>
    </othercredit>
  </para>
</listitem>
<listitem>
  <para>
    <othercredit>
      <othername>Seiji Kaneko</othername>
      <contrib>日本語訳校正</contrib>
      <affiliation>
        <address>
          <email>se-kane(a)itg.hitachi.co.jp</email>
        </address>
      </affiliation>
    </othercredit>
  </para>
</listitem>
<listitem>
  <para>
    <othercredit>
      <othername>その他 JF プロジェクトのメンバーの方々</othername>
      <contrib>*</contrib>
      <affiliation>
        <address>
          <email>JF(a)linux.or.jp</email>
        </address>
      </affiliation>
    </othercredit>
  </para>
</listitem>
</itemizedlist>
</sect2>

</sect1>
<!--end_japanese-->
</article>

