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


<article id=index>

<artheader>
<title>Program Library HOWTO</title>
<authorgroup>
<author><firstname>David A.</firstname> <surname>Wheeler</surname>
</author>
</authorgroup>
<address><email>dwheeler@dwheeler.com</email></address>
<pubdate>version 0.75, 31 October 2000</pubdate>
<authorgroup>
  <author>
    <honorific>日本語訳</honorific>
    <othername>川崎貴彦</othername>
    <affiliation>
      <address>
        <email>takahiko@hakubi.co.jp</email>
      </address>
    </affiliation>
  </author>
</authorgroup>
<revhistory>
<revision>
  <revnumber>0.75-J1</revnumber>
  <date>4 Dec 2000</date>
</revision>
</revhistory>
<abstract>
<para>
<!--
This HOWTO for programmers
discusses how to create and use program libraries on Linux.
This includes static libraries, shared libraries, and
dynamically loaded libraries.
-->
プログラマ用のこの HOWTO では、Linux 上でプログラムライブラリを作成、
使用する方法を論じます。ここには、静的ライブラリ、共有ライブラリ、
動的にロードされるライブラリ、が含まれます。
</para>
</abstract>
</artheader>

<sect1 id="introduction">
<!--
<title>Introduction</title>
-->
<title>はじめに</title>
<para>
<!--
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.
-->
プログラマのためのこの HOWTO は、GNU ツールセットを使用している
Linux 上でプログラムライブラリを作成、使用する方法を論じます。
``プログラムライブラリ'' とは、単に、
あとでプログラムに組み込まれることになるコンパイル済みのコード
(及びデータ) を含むファイルのことです。プログラムライブラリは、
プログラムを、よりモジュール化し、より速く再コンパイルでき、
より簡単に更新できるものにします。プログラムライブラリは、
三つのタイプ――静的ライブラリ、共有ライブラリ、動的にロードされる
(dynamically loaded; DL) ライブラリ――に分類することができます。
</para>

<para>
<!--
This paper first discusses static libraries, which are installed
into a program executable before the program is 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.
-->
この文書は、最初に、静的ライブラリ
――プログラムが実行される前にその実行可能プログラムに組み込まれるライブラリ――
について論じます。それから、共有ライブラリ
――プログラム実行時にロードされ、かつ複数のプログラム間で共有されるライブラリ――
について論じます。最後に、動的にロードされる (dynamically loaded; DL) ライブラリ
――プログラム実行中の任意の時点でロードして使用することが可能なライブラリ――
について論じます。
DL ライブラリは、実際には異なるライブラリ形式というわけではありません
(静的ライブラリも共有ライブラリも DL ライブラリとして使用することが可能です)。
その代わりに、プログラマが DL ライブラリをどのように使用するか
という点において、違いがあります。HOWTO は、さらに多くの例を挙げている章、
その他の情報源への参照を挙げている章、をもって終了します。
</para>

<para>
<!--
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.
-->
この HOWTO は実行可能ファイルとライブラリのための
Executable and Linking Format (ELF) 形式
――昨今のほとんど全ての Linux ディストリビューションで使用されている形式――
についてのみ論じます。
GNU gcc ツールセットは、実際には ELF 以外のライブラリ形式を扱うことができます。
特に、ほとんどの Linux ディストリビューションでは、旧式の a.out
形式を今なお使用することが可能です。
しかしながら、これらの形式はこの文書の対象外です。
</para>

<para>
<!--
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.
-->
共有ライブラリを指して dynamically <emphasis>linked</emphasis> libraries
(DLL) という用語を使う人がいること、その DLL という用語を DL
ライブラリとして使用される任意のライブラリを意味するために使う人がいること、
また、どちらかの条件を満たすライブラリを意味するために
DLL という用語を使う人がいること、には注意したほうがよいです。
いずれの意味を取り上げるにしても、この HOWTO は
Linux 上でのこれら全ての DLL についてカバーします。
</para>

<para>
<!--
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.
-->
多くのシステムに移植されるアプリケーションを作成しているならば、
ライブラリを構築しインストールするのに、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 内の情報を欲されることでしょう。
</para>

<para>
<!--
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.
-->
この HOWTO の一次配布場所は
<ulink url="http://www.dwheeler.com/program-library">http://www.dwheeler.com/program-library</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) でライセンスされています。
さらなる情報については最後の章を読んでください。
</para>
</sect1>

<sect1 id="static-libraries">
<!--
<title>Static Libraries</title>
-->
<title>静的ライブラリ</title>
<para>
<!--
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.
-->
静的ライブラリは、通常のオブジェクトファイルの単なる集合体です。
慣習的に、静的ライブラリは ``.a'' という拡張子を持ちます。
この集合体は、ar (archiver) プログラムを使用して作成されます。
静的ライブラリは以前ほどには使われなくなっていますが、それは、
共有ライブラリのほうが優れていることによります (あとで述べます)。
それでもまだ、静的ライブラリは時々作成され
――はじめは歴史的な理由で存在していたのですが――、
説明するのもより簡単です。
</para>
<para>
<!--
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%), but in practice this
rarely seems to be the case due to other confounding factors.
-->
ユーザは、コードを再コンパイルする必要もなく静的ライブラリを
プログラムにリンクすることができ、再コンパイルにかかる時間を節約できます。
注――昨今のより高速なコンパイラのことを考えれば、
再コンパイル時間は重要ではなくなってきています
――そのためにこの理由付けは以前ほど有力ではありません。
静的ライブラリは、その開発者が、
ライブラリへリンクすることをプログラマに許可はしたいが
ライブラリソースコードは渡したくはない、という場合にしばしば役に立ちます
(これはライブラリベンダーにとっては好都合ですが、
そのライブラリを使おうとしているプログラマにとっては
明らかに好都合とは言えません)。論理的には、実行可能ファイルにリンクされる静的
ELF ライブラリ内のコードは若干速く (1-5%) 動作するはずですが、実際には、
他のごちゃごちゃした要因のため、その通りになることは稀のようです。
</para>
<para>
<!--
To create a static library, or to add additional object files to
an existing static library, use a command like this:
-->
静的ライブラリを作成する、もしくは既に存在する静的ライブラリに
さらにオブジェクトファイルを追加するには、次のようなコマンドを
使用してください――
</para>

<programlisting>
ar rcs my_library.a file1.o file2.o
</programlisting>

<para>
<!--
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).
-->
このコマンド例では、静的ライブラリ my_library.a にオブジェクトファイル
file1.o と file2.o を付け加えています。まだ my_library.a
が存在していなければ、作成します。
静的ライブラリ作成に関してさらに情報を得るには、ar(1) を参照してください。
</para>

<para>
<!--
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.
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.
-->
一度静的ライブラリを作成してしまうと、それを使いたくなることでしょう。
実行可能プログラムを作成するときにコンパイルとリンク処理の一部として
呼び込むことで、共有ライブラリを使用できます。実行可能ファイルを作成するのに
gcc(1) を使っているならば、ライブラリを指定するのに -l
オプションを使用できます。より詳しい情報については info:gcc を参照してください。
-l と -L オプションを使って、リンカ ld(1) を直接使用することもできます。
しかしながら、ld(1) のインターフェースは gcc(1) よりも変更されやすいので、
ほとんどの場合は gcc(1) を使うほうがよいです。
</para>
</sect1>

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

<para>
<!--
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:
-->
共有ライブラリは、プログラムが起動するときにロードされるライブラリです。
共有ライブラリが適切にインストールされると、
その後に起動される全てのプログラムは、
自動的にその新しい共有ライブラリを使うことになります。
実際には、これ以上にはるかに柔軟で洗練されています。というのは、
Linux によるアプローチは次のことを可能にするからです――
<!--
<itemizedlist>
<listitem><para>update libraries and still support programs that want to use older,
non-backward-compatible versions of those libraries;</para>
</listitem>
<listitem><para>override specific libraries or even specific functions
in a library when executing a particular program.</para>
</listitem>
<listitem><para>do all this while programs are running using existing libraries.
</para>
</listitem>
</itemizedlist>
-->
<itemizedlist>
<listitem><para>ライブラリを更新しながらも、
そのライブラリの古くて後方互換性のないバージョンを使いたいというプログラムを、
依然としてサポートできる</para>
</listitem>
<listitem><para>特別なプログラムを実行するとき、特定のライブラリ、
もしくはライブラリ内の特定の関数でさえオーバーライドできる</para>
</listitem>
<listitem><para>既に存在しているライブラリを使用してプログラムが
動いている間にも、この全てをおこなうことができる</para>
</listitem>
</itemizedlist>
</para>

<sect2>
<!--
<title>Conventions</title>
-->
<title>約束ごと</title>
<para>
<!--
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.
-->
これらの望ましい特性すべてを共有ライブラリがサポートするためには、
多くの慣習と指針に従わなければなりません。ライブラリの名前、
特に ``soname'' と ``real name'' の違いについて
(及びそれらがどのように相互作用するかについて) 理解する必要があります。
また、それらがファイルシステム内のどの場所に置かれるべきであるかについても、
理解する必要があります。
</para>

<sect3>
<!--
<title>Shared Library Names</title>
-->
<title>共有ライブラリ名</title>
<para>
<!--
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''.
-->
全ての共有ライブラリは、``soname'' と呼ばれる特別な名前を持っています。
soname は ``lib'' というプリフィックス、ライブラリの名前、``.so''
という句を持ち、ピリオドと、
インターフェースが変更されるときには必ず増やされるバージョン番号が後に続きます
(特別な例外として、最低レベルの C ライブラリは ``lib'' では始まりません) 。
完全に記述された soname は、
そのライブラリ自身が含まれるディレクトリをプリフィックスとして含んでいます。
実際のシステムでは、完全に記述された soname は、共有ライブラリの ``real name''
への単なるシンボリックリンクになっています。
</para>

<para>
<!--
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.
-->
全ての共有ライブラリは、``real name''
――実際のライブラリコードを含むファイル名――も持っています。real name は、
soname に、ピリオド、マイナー番号、もう一つピリオド、リリース番号、
を加えたものです。
最後のピリオドとリリース番号はなくてもかまいません。
マイナー番号とリリース番号は、
どのバージョンのライブラリがインストールされているかを正確に示し、
設定管理の助けとなります。これらの番号は、
――そのようにすれば物事をより単純化できるにもかかわらず――
ドキュメントの中でライブラリを説明するのに用いられている番号
と同じではないかもしれない、ということに注意してください。
</para>

<para>
<!--
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.
-->
加えて、ライブラリ要求時にコンパイラが使用する名前というものもあります
(``linker name'' と呼ぼうと思います) 。それは、単に、
一切のバージョン番号を取り除いた soname です。
</para>

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

<para>
<!--
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.
-->
<!-- Private correspondance, 10-April-2000 -->
ldconfig は linker name を設定しません。典型的には、
この設定はライブラリインストール時におこなわれ、``最新の'' soname
もしくは最新の realname への単なるシンボリックリンクとして、linker name
が作成されます。ほとんどの場合において、ライブラリを更新したら、
リンク時にそれを自動的に使用したいと思うでしょうから、soname
へのシンボリックリンクとして linker name を作っておくことを
お勧めします。私は、なぜ ldconfig は自動的に linker name
を設定しないのかを、H. J. Lu に尋ねました。彼の説明は、基本的には、
「ライブラリの最新バージョンを使ってコードを実行したい
と思われるかも知れませんが、そうではなく、(おそらく互換性のない)
古いライブラリにリンクする<emphasis>開発</emphasis>
を望んでいるということもありうるのです」、
というものでした。そのため、ldconfig は、
あなたがどのライブラリにプログラムをリンクさせたいのか
ということについては、何の仮定もおこないません。ですので、
リンカがライブラリに使うものを更新するためには、
インストーラがシンボリックリンクを明確に変更しなければならないのです。
</para>

<para>
<!--
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>.
-->
例えば、<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>
を参照するシンボリックリンクになることでしょう。
</para>
</sect3>

<sect3>
<!--
<title>Filesystem Placement</title>
-->
<title>ファイルシステム配置</title>
<para>
<!--
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.
-->
共有ライブラリはファイルシステムのどこかに配置されなければなりません。
ほとんどのオープンソースソフトウェアは、GNU 規準に従う傾向があります
――詳細は 
<ulink url="info:standards#Directory_Variables">
info:standards#Directory_Variables</ulink>
にある info ファイルドキュメントを見てください。
GNU 規準は、ソースコードを配布するとき、デフォルトでは
全てのライブラリを /usr/local/lib にインストールすることを推奨しています
(全てのコマンドが /usr/local/bin に入るべきだとも勧めています) 。
また、これらのデフォルトをオーバーライドしたり、
インストールルーチンを呼び出したりするための慣習をはっきり述べています。
</para>

<para>
<!--
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.
-->
ファイルシステム階層規準 (Filesystem Hierarchy Starndard; FHS) は、
ディストリビューションにおいて何がどこにインストールされるべきかを論じています
(<ulink url="http://www.pathname.com/fhs">http://www.pathname.com/fhs</ulink>
を見てください) 。 FHS に従えば、ほとんどのライブラリは /usr/lib
にインストールされるべきですが、起動に必要とされるライブラリは /lib に、
そしてシステムの一部になってはいないライブラリは /usr/local/lib
にインストールされるべきです。
</para>

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

<sect2>
<!--
<title>How Libraries are Used</title>
-->
<title>ライブラリはどのように使われるか</title>
<para>
<!--
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.
-->
GNU glibc ベースのシステム――全ての Linux システムを含みます――
では、ELF バイナリ実行ファイルを起動させると、
自動的にプログラムローダがロードされ、実行されます。
Linux システム上では、このローダは /lib/ld-linux.so.X
(X にはバージョン番号が入ります) という名前です。このローダは、
プログラムによって使用されるその他の全ての共有ライブラリを順次探し出し、
ロードします。
</para>

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

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

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

<sect2>
<!--
<title>Environment Variables</title>
-->
<title>環境変数</title>
<para>
<!--
Various environment variables can control this process,
and in fact there are environment variables that permit
you to override this process.
For example, 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 object files 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, similar functionality is available on HP-UX but as
SHLIB_PATH, and on AIX this functionality is through LIBPATH.
-->
<!--  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 -->
<!--
Also, LD_LIBRARY_PATH is handy for development and testing, but shouldn't
be modified by an installation process for normal use; 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.
-->
様々な環境変数がこの処理手順を制御できます。事実、
この処理手順をオーバーライドするのに使える環境変数が存在します。
例えば、この特殊な実行を、一時的に他のライブラリで代替することができます。
Linux では、環境変数 LD_LIBRARY_PATH は、標準的なディレクトリ群に
先立ってライブラリが検索されるべきディレクトリ群を、
コロンで区切って並べたものです。
これは、新しいライブラリをデバッグしているときや、
特別な目的のために非標準的なライブラリを使用しているときに便利です。
環境変数 LD_PRELOAD は、標準セットをオーバーライドするオブジェクトファイルを
関数と共に、ちょうど /etc/ld.so.preload でおこなわれているように、
列挙します。
これらの機能は、/lib/ld-linux.so ローダにより実装されています。
LD_LIBRARY_PATH は多くの Unix ライクなシステム上で機能しますが、
全てのシステム上で動くわけではないことに注意しましょう。
例えば、HP-UX でも同じ機能が利用できますが、それは SHLIB_PATH
としてですし、AIX では LIBPATH を通じてということになります。
<!-- LD_LIBRARY_PATH を使用しないシステム用のソース――
     Drazen Kacar dave@srce.hr,  20 Jul 2000 13:27:53 +0200,
     メーリングリスト gnome-devel-list@gnome.org -->
また、LD_LIBRARY_PATH は開発やテストには便利ではありますが、
通常使用のためにインストール時に修正されるべきではありません。
この理由の説明については、
<ulink url="http://www.visi.com/~barr/ldpath.html">http://www.visi.com/~barr/ldpath.html</ulink>
の ``なぜ LD_LIBRARY_PATH はいけないのか'' を参照してください。
</para>

<para>
<!--
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.
-->
実際には、ローディング処理手順を制御する環境変数は
ほかにもたくさん存在します。それらの名前は、LD_ や RTLD_
ではじまります。それらのほとんどは、ローダ処理の低レベルなデバッグや、
特殊化されたケイパビリティを実装するためのものです。
ほとんどは、十分にドキュメント化されていません。
それらについて知る必要があるならば、学習するもっともよい方法は、
ソースコードを読むことです。
</para>

<para>
<!--
Permitting user control over dynamically linked libraries
would be disastrous for setuid/setgid programs
if special measures weren't taken.
Therefore, in GNU loader, 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. 
-->
特別な対処がなされないならば、動的にリンクされるライブラリに対する
制御をユーザに認めるということは、setuid/setgid プログラムにとっては
悲惨なものになるでしょう。そのため、GNU ローダでは、
プログラムが setuid もしくは setgid されている場合、
これらの変数 (及び類似の変数) は無視されるか、もしくは、
それらができることは大幅に制限されます。
ローダは、プログラムの信任証 (credential) を調べることによって、
そのプログラムが setuid もしくは setgid されているかどうかを確認します。
もしも uid と euid が異なるか、もしくは gid と egid が異なるなら、
ローダはそのプログラムが setuid/setgid されている
(もしくはそのようなプログラムから実行された) と推定し、
リンク処理をコントロールする能力を大幅に制限します。
GNU glibc ライブラリのソースコードを読めば、
これについて見ることができるでしょう。特に、elf/rtld.c ファイルと
sysdeps/generic/dl-sysdep.c ファイルを見てください。
これは、uid と gid を euid と egid に等しくしてから
プログラムを呼べばこれらの変数が完全に機能する、
ということを意味しています。
その他の Unix ライクなシステムは、この状況を異なる方法で扱いますが、
同じ理由――setuid/setgid プログラムは環境変数群によって過度に影響を
受けるべきではないという理由――によります。
</para>
</sect2>

<sect2>
<!--
<title>Creating a Shared Library</title>
-->
<title>共有ライブラリの作成</title>
<para>
<!--
Creating a shared library is easy.
First, create the object files that will go into the shared
library using the gcc -fPIC flag (this enables the ``position independent
code'' generation, a requirement for shared libraries).
Then create the shared library using this format:
-->
共有ライブラリの作成は簡単です。
まずはじめに、gcc の -fPIC フラグ (これは、共有ライブラリに必要とされる
``位置独立コード (position independent code)'' の生成を可能にします) を使って、
共有ライブラリに組み込まれることになるオブジェクトファイルを作成します。
それから、次の形式を使って共有ライブラリを作成してください――
</para>

<programlisting>
gcc -shared -Wl,-soname,<replaceable>your_soname</replaceable> \
    -o <replaceable>library_name</replaceable> <replaceable>file_list</replaceable> <replaceable>library_list</replaceable>
</programlisting>

<para>
<!--
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 obviously includes
the required -fPIC option:
-->
二つのオブジェクトファイル (a.o と b.o) を作成し、
これら両方を含む共有ライブラリを作成する例をここに挙げます。
コンパイル処理が、デバッグ情報 (-g) を含み、警告メッセージを生成する (-Wall) 
ということ――これらは共有ライブラリに必要とはされませんが推奨されます――
には注意してください。
コンパイル処理は (-c を使って) オブジェクトファイルを生成し、
そして、要求される -fPIC オプションをはっきりと含むことになります。
</para>

<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>

<para>
<!--
Here are a few points worth noting:
-->
注意すべきことが幾つかあります――
<itemizedlist>
<!--
<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>
<listitem><para>Use -fPIC to generate code,
not -fpic (the latter may not work, because if branches need large
displacements -fpic may not generate fully position-independent code).</para>
</listitem>
-->
<listitem><para>生成されたライブラリを strip しないでください。また
本当に必要でない限りコンパイラオプション -fomit-frame-pointer
を使わないでください。生成されたライブラリは機能するでしょうが、
これらの作業は、デバッガをほとんど使い物にならなくしてしまいます。</para>
</listitem>
<listitem><para>コードを生成するには、-fpic ではなく、-fPIC を使ってください
(前者は機能しないこともあります。というのは、
分岐が大規模な配置転換を必要とする場合、-fpic
は完全な位置独立コードを生成しないかもしれないからです)。</para>
</listitem>
</itemizedlist>
</para>

</sect2>

<sect2>
<!--
<title>Installing and Using a Shared Library</title>
-->
<title>共有ライブラリのインストールと使用</title>
<para>
<!--
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).
-->
一度共有ライブラリを作成してしまうと、それをインストールしたくなることでしょう。
簡単な方法は、標準的なディレクトリ (例えば /usr/lib など)
の一つに、そのライブラリをコピーし、ldconfig(8) を実行することです。
</para>

<para>
<!--
If you can't do that (e.g., you don't have the right to modify
/usr/lib), then you can use environment variables to control things.
First, you'll need to create the shared libraries somewhere.
Then, you'll need to set up the necesary 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:
-->
もしもこれができないならば (例えば、あなたが /usr/lib
を変更する権利を持っていないなど)、
事態を制御するために環境変数を使用することができます。
まずはじめに、どこかに共有ライブラリを作成する必要があるでしょう。
それから、必要なシンボリックリンク、特に soname から real name
へのシンボリックリンク
(同様に、バージョン番号をまったく指定しないユーザのために、
バージョン番号のない soname 、つまり、``.so'' で終わる soname
からのシンボリックリンクも) 設定する必要があるでしょう。
もっとも簡単な方法は、次のコマンドラインを実行することです――
</para>

<programlisting>
 ldconfig -n <replaceable>directory_with_shared_libraries</replaceable>
</programlisting>

<para>
<!--
Then 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:
-->
それから、LD_LIBRARY_PATH ――いつもの場所よりも先に
共有ライブラリの検索対象となるディレクトリのリストをコロンで区切ったもの――
を設定します。bash をお使いでしたら、次の方法で my_program
を実行できます。
</para>

<programlisting>
LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH  my_program
</programlisting>

<para>
<!--
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.
-->
幾つかの選択された関数をオーバーライドしたいだけならば、
オーバーライドするオブジェクトファイルを作成して LD_PRELOAD
を設定するだけで可能です。このオブジェクトファイル内の関数は、
対象となっている関数だけをオーバーライドします。
</para>

<para>
<!--
Usually you can update libraries without concern; if there was an API
change, the library creator will change the soname.
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:
-->
普段は、心配する必要もなくライブラリを更新できます。もしも API
の変更があるならば、ライブラリ作成者は soname を変更するでしょう。
しかしながら、もしも同じ soname
のままのライブラリに対する更新個所において、
あるプログラムが中断してしまうようなら、
古いライブラリをどこかにコピーし、そのプログラムの名前を変更することによって
(古い名前に ``.orig'' を付け足すなど) 、
強制的に古いライブラリバージョンを使うことができます。
使用するライブラリを再設定し、実際に実行する (名前を変更された)
プログラムを呼び出すための小さな ``ラッパー'' スクリプトも作成してください。
番号付けの慣習は、
同一ディレクトリ内に複数のバージョンが存在することを可能にしていますが、
お望みなら、古いライブラリをそれ独自の特別な場所に置くこともできます。
ラッパースクリプトは、次のようなものになるでしょう――
<programlisting>
  #!/bin/sh
  export LD_LIBRARY_PATH=/usr/local/my_lib:$LD_LIBRARY_PATH
  exec /usr/bin/my_program.orig $*
</programlisting>
</para>

<para>
<!--
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:
-->
ldd(1) を使えば、
あるプログラムによって使用されている共有ライブラリのリストを
調べることができます。
例えば、次のようにタイプすれば、
ls によって使用されている共有ライブラリを確認することができます――
<programlisting>
  ldd /bin/ls
</programlisting>
<!--
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:
-->
一般的には、プログラムの依存する soname のリストが、
名前解決後のディレクトリ名と共に得られます。実際には全ての場合において、
少なくとも二つの依存要素を見ることになるでしょう――
<itemizedlist>
<!--
<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>
<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>
-->
<listitem><para>/lib/ld-linux.so.N (N は、1 かそれ以上。たいていは少なくとも 2) 。
これは、他の全てのライブラリをロードするためのライブラリです。
</para></listitem>
<listitem><para>libc.so.N (N は、6 かそれ以上) 。
これは C ライブラリです。他の言語でさえ、C ライブラリを使用する傾向があります
(少なくともそれら自身のライブラリを実装するために) 。そのため、
ほとんどのプログラムは少なくともこのライブラリは含んでいます。
</para></listitem>
</itemizedlist>
<!--
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 calling the
program directly; an untrusted program could execute unexpected code.
-->
注意――信用できないプログラムに対して ldd を実行しては
<emphasis>いけません</emphasis>。これについては、
ldd(1) のマニュアルで明確に述べられています。
ldd は、当該プログラムを直接呼び出すことで機能しています。
信用できないプログラムが予期していないコードを実行してしまうことがありえます。
</para>
</sect2>

<sect2>
<!--
<title>Incompatible Libraries</title>
-->
<title>非互換ライブラリ</title>
<para>
<!--
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:
-->
新しいバージョンのライブラリが古いものとバイナリ非互換であるときは、
soname を変更する必要があります。C においては、
ライブラリがバイナリ互換ではなくなってしまう四つの基本的な理由があります。
<orderedlist>
<!--
<listitem><para>The behavior of a function changes so that it no longer
meets its original specification,</para>
</listitem>
<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>
<listitem><para>An exported function is removed.</para>
</listitem>
<listitem><para>The interface of an exported function changes.</para>
</listitem>
-->
<listitem><para>元の仕様に適合しないように関数の動作が変更されてしまう</para>
</listitem>
<listitem><para>エクスポートされるデータ項目が変更されてしまう (例外
――構造体がライブラリ内でのみアロケートされる場合に限り、
構造体の末尾に任意の項目を追加するのは問題ない)</para>
</listitem>
<listitem><para>エクスポートされている関数が削除されてしまう</para>
</listitem>
<listitem><para>エクスポートされている関数のインターフェースが変更されてしまう</para>
</listitem>
</orderedlist>
</para>

<para>
<!--
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.
-->
これらの理由を回避できるならば、ライブラリをバイナリ互換に保つことができます。
別の言い方をすると、これらの変更を避ければ、Application Binary Interface (ABI)
互換を保つことができる、ということです。例えば、
新しい関数を追加したいけれども古い関数を削除したくはないかもしれません。
構造体の末尾にのみアイテムを追加し、
ライブラリにだけその構造体をアロケートすることを許可し
(アプリケーションには許可しない)、その追加のアイテムをオプション扱いにする
(もしくはライブラリがそれらを満たすようにする)、
などの操作をおこなって生じた変更が、
古いプログラムに対して影響を与えないことを確認できる場合にのみ、
アイテムを追加することができます。気を付けてください。
もしもユーザが構造体を配列で使っているならば、その構造体は拡張できません。
</para>

<para>
<!--
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>:
-->
C++ (および、コンパイル済み組込みテンプレート且つ／又は
コンパイル済みのディスパッチされるメソッドをサポートするその他の言語)
では、状況はより複雑になります。
上記の問題点全てが適用される上、さらに多くの問題があります。
理由は、幾つかの情報がコンパイルされたコード内に
``隠された状態で'' 実装されているということにあるのですが、
このことが、
C++ が一般的にどのように実装されているかを知らない人には
よく分からないような依存問題を引き起こしてしまうのです。
正確に言えば、それらは ``新しい'' 問題ではありません。
単に、コンパイル済みの C++ のコードが、あなたを驚かせる
ことになるかもしれない方法でそれらの問題を引き起こすということなのです。
次のものは、バイナリ互換を維持するために
C++ 内でやってはいけない項目のリスト (おそらく不完全ですが) であり、
<ulink url="http://www.trolltech.com/developer/faq/tech.html#bincomp">
Troll Tech テクニカル FAQ</ulink>
により報告されているものです。
<orderedlist>
<listitem><para>
<!--
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).
-->
メンバ関数を再実装したものを追加する
(古いバイナリが元の実装を呼び出すのが安全ではない場合)。というのは、
コンパイラは SuperClass::virtualFunction()
呼出しをコンパイル時に評価するからです
(リンク時ではありません)。
</para></listitem>
<listitem><para>
<!--
add or remove virtual member functions, because
this would change the size and layout of the vtbl of every subclass.
-->
仮想メンバ関数を追加または削除する。というのは、この作業は
全サブクラスの仮想関数テーブルのサイズと配置を変更するだろうからです。
</para></listitem>
<listitem><para>
<!--
change the type of any data members or move any data members
that can be accessed via inline member functions.
-->
インラインメンバ関数経由でアクセスされうるデータメンバのタイプを
変更したり、またはそれらを移動させたりする。
</para></listitem>
<listitem><para>
<!--
change the class hierarchy, except to add new leaves.
-->
クラス階層を変更する。ただし、リーフ
(訳注：下位クラスを持たないクラス) の新規追加を除く。
</para></listitem>
<listitem><para>
<!--
add or remove private data members, because
this would change the size and layout of every subclass.
-->
private データメンバを追加または削除する。というのは、
この作業は全サブクラスのサイズと配置を変更するだろうからです。
</para></listitem>
<listitem><para>
<!--
remove public or protected member functions unless they are inline.
-->
public もしくは protected メンバ関数がインライン関数でない場合に、
それらを削除する。
</para></listitem>
<listitem><para>
<!--
make a public or protected member function inline.
-->
public もしくは protected メンバ関数をインライン化する。
</para></listitem>
<listitem><para>
<!--
change what an inline function does, unless the old version continues working.
-->
インライン関数がおこなっていたことを変更する。
ただし、古いバージョンが動作し続けている場合を除く。
</para></listitem>
<listitem><para>
<!--
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.
-->
ポータブルなプログラムのメンバ関数のアクセス権 (すなわち、
public, protected または private) を変更する。というのは、
アクセス権を関数名に押し込んでしまうコンパイラも存在するからです。
</para></listitem>
</orderedlist>
</para>

<para>
<!--
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.
-->
C++ ライブラリの開発者は、この長ったらしいリストを手にして、
バイナリ互換性をなくすことになってしまう時折の更新作業以上のことを
特に考慮しなければなりません。
幸いにして、Unix ライクなシステム (Linux を含みます)
では一つのライブラリの複数のバージョンを同時にロードすることができるので、
ディスクスペースを失うことにはなりますが、
ユーザは古いライブラリを必要とする ``古い''
プログラムをその後も実行することが可能ではあります。
</para>
</sect2>
</sect1>

<sect1 id="dl-libraries">
<!--
<title>Dynamically Loaded (DL) Libraries</title>
-->
<title>動的にロードされる (Dynamically Loaded; DL) ライブラリ</title>
<para>
<!--
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.
This approach can be useful in implementing 
a just-in-time compiler or multi-user dungeon (MUD).
-->
動的にロードされる (dynamically loaded; DL) ライブラリは、
プログラムの起動時以外のときにロードされるライブラリです。
これはプラグインやモジュールを実装するのに特に役に立ちます。
というのは、プラグインが必要になるまで、
それをロードするのを待つことができるからです。例えば、
Pluggable Authentication Modules (PAM) システムは、
管理者が認証の設定や再設定をおこなえるようにするため、
DL ライブラリを使用しています。また、
全体を止めることなく、効率を上げる目的で、
その時々でコードをマシンコードにコンパイルし、
そのコンパイル後のものを使用するというインタプリタを実装するのにも役に立ちます。
この方法は、ジャストインタイムコンパイラや、マルチユーザダンジョン
(multi-user dungeon; MUD) の実装時にも役に立ちます。
</para>

<para>
<!--
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.
-->
Linux では、実際のところ、DL
ライブラリは形式という点においては特別ではありません。それらは、
標準的なオブジェクトファイル、
もしくは今までに述べたような標準的な共有ライブラリとして構築されています。
主な違いは、ライブラリが、
プログラムのリンク時や起動時に自動的にはロードされない、という点です。
その代わり、ライブラリをオープンし、シンボルを検索し、エラーを処理し、
ライブラリを閉じる、という API は存在します。この API を使うためには、
C ユーザはヘッダファイル &lt;dlfcn.h&gt; をインクルードする必要があります。
</para>

<para>
<!--
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 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.
-->
Linux によって使用されるインターフェースは本質的に Solaris
上のものと同じで、私が ``dlopen()'' API と呼ぼうとしているものです。
しかしながら、この同じインターフェースは全てのプラットフォームで
サポートされているわけではありません。HP-UX は shl_load()
という異なる機構を用いますし、Windows
プラットフォームは完全に異なるインターフェースの DLL を使用します。
あなたの最終目標が広範なポータビリティならば、おそらく、
プラットフォーム間の差違を隠すラッピングライブラリの使用
を考えたほうがよいでしょう。一つのアプローチは、
モジュールの動的ローディングをサポートする 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 のインターフェースはそのドキュメントの中で十分に説明されているので、
ここではこれ以上は述べません。
もう一つのアプローチは、libltdl を使うことです。これは、
<ulink url="http://www.gnu.org/software/libtool/libtool.html">GNU libtool</ulink>
の一部です。もっと多くの機能を望むならば、
CORBA Object Request Broker (ORB) を調べてみるのもよいでしょう。
Linux と Solaris でサポートされるインターフェースを
直接使うことに依然として興味をお持ちならば、読み進んでください。
</para>

<sect2>
<title>dlopen()</title>
<para>
<!--
The dlopen(3) function opens a library and prepares it for use.
In C its prototype is:
-->
dlopen(3) 関数は、ライブラリをオープンし、使用するための準備をします。
C では、そのプロトタイプは次のようになります――
<programlisting>
  void * dlopen(const char *filename, int flag);
</programlisting>
<!--
If filename begins with ``/'' (i.e., it's an absolute path),
dlopen() won't search for a library.
Otherwise, dlopen() will search for the library
in the following order:
-->
ファイル名が ``/'' ではじまるならば (つまり絶対パスならば) 、
dlopen() はライブラリを検索しません。そうでないならば、dlopen()
は次の順序でライブラリを検索します――
<orderedlist>
<!--
<listitem><para>A colon-separated list of directories in the user's
                LD_LIBRARY path environment variable.
</para></listitem>
<listitem><para>The list of libraries specified in /etc/ld.so.cache.
</para></listitem>
<listitem><para>/usr/lib, followed by /lib.
</para></listitem>
-->
<listitem><para>ユーザの LD_LIBRARY_PATH
                環境変数内のコロンで区切られたディレクトリリスト
</para></listitem>
<listitem><para>/etc/ld.so.cache に指定されたライブラリリスト
</para></listitem>
<listitem><para>/usr/lib, 次が /lib
</para></listitem>
</orderedlist>
<!--
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 inscrutible 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.
-->
dlopen() では、<replaceable>flag</replaceable> の値は、RTLD_LAZY
――``動的ライブラリのコードが実行されるときに、未定義シンボルを解決せよ''
という意味です――、もしくは、RTLD_NOW ――``dlopen()
がリターンする前に全ての未定義シンボルを解決せよ、
それができないようならば失敗せよ'' という意味です――、
のどちらかでなければいけません。RTLD_GLOBAL は、
<replaceable>flag</replaceable> のどちらかの値と任意に論理和結合されるもので、
続けてライブラリをロードすることによりライブラリ内で定義されている
外部シンボルを得られる、ということを意味しています。デバッグ中は、
おそらく RTLD_NOW を使いたくなるでしょう。RTLD_LAZY を使うと、
解決されない参照があったときに不可解なエラーが生成されます。
RTLD_NOW を使うと、ライブラリのオープンには若干時間が多くかかるようになります
(しかし、のちのちの検索スピードは速くなります) 。
このことがユーザインターフェースの問題になるようでしたら、
あとで RTLD_LAZY にかえることができます。
</para>

<para>
<!--
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).
-->
ライブラリがお互いに依存しているようなら (例えば、X が Y に依存している) 、
依存されているほうを先にロードしてください (この例で言えば、Y を先にロードし、
それから X をロードします) 。
</para>

<para>
<!--
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.
-->
dlopen() の戻り値は、他の DL ライブラリルーチンで使用される
``ハンドル''
――その実体は隠蔽されるぺきものと考えられている――
です。
ロードの試みが成功しない場合、dlopen() は NULL を返しますので、
この値をチェックする必要があります。
同じライブラリが dlopen() で二回以上ロードされると、
同じファイルハンドルが返されます。
</para>

<para>
<!--
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.
See <xref linkend="init-and-fini"> for more information.
-->
もしもライブラリが _init という名前のルーチンをエクスポートしていれば、
そのコードは dlopen() が戻る前に実行されます。あなたのライブラリでも、
初期化ルーチンを実装するためにこれを使うことができます。
詳細は <xref linkend="init-and-fini"> を参照してください。
</para>
</sect2>

<sect2>
<title>dlerror()</title>
<para>
<!--
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.
-->
dlerror() を呼べば、エラーを報告できます。dlerror() は、
dlopen(), dlsym() もしくは dlclose()
の最後の呼出しによるエラーについて記述してある文字列を返します。
一つ変わっているのは、dlerror() を呼び出すと、以降の dlerror() の呼出しは、
ほかのエラーが発生するまで NULL を返すという点です。
</para>
</sect2>

<sect2>
<title>dlsym()</title>
<para>
<!--
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:
-->
DL ライブラリが使えなければ、それをロードしても意味がありません。
DL ライブラリを使うための主となるルーチンは、dlsym(3) です。これは、
与えられた (オープン済みの) ライブラリ内にあるシンボルの値を検索するものです。
この関数は次のように定義されます――
<programlisting>
 void * dlsym(void *handle, char *symbol);
</programlisting>
<!--
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).
-->
handle は dlopen で返された値で、symbol はヌル文字で終端された文字列です。
回避可能ならば、dlsym() の結果を void* ポインタに格納しないでください。
というのは、それを利用するたびにキャストしなければいけなくなるからです
(プログラムをメンテナンスしようとしている人たちに、より少ない情報しか
与えないことにもなります) 。
</para>

<para>
<!--
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:
-->
dlsym() は、シンボルが見つからなければ NULL という結果を返します。
シンボルが NULL もしくはゼロという値をとることはありえないと分かっていれば、
それで構いません。しかし、そうでない場合は潜在的に曖昧さが残ります。
もしも NULL を受け取った場合、それは、
そんなシンボルは存在しないということを意味するのでしょうか、
もしくはそのシンボルの値が NULL であることを意味するのでしょうか?
標準的な解答は、dlerror() をはじめに呼び (存在しているかもしれない
エラー条件をクリアするためです)、それから シンボルを要求するために
dlsym() を呼び、エラーが発生しているかどうかを調べるために再度
dlerror() を呼び出すことです。
コードの断片は次のようになるでしょう――
<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 */
 }
-->
 dlerror(); /* エラーをクリアする */
 s = (actual_type) dlsym(handle, symbol_being_searched_for);
 if ((err = dlerror()) != NULL) {
  /* ハンドルエラー。シンボルを見つけられなかった */
 } else {
  /* シンボルが見つかった。その値は s に格納されている */
 }
</programlisting>
</para>
</sect2>

<sect2>
<title>dlclose()</title>
<para>
<!--
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);
see <xref linkend="init-and-fini"> for more information.
-->
dlopen() の逆が dlclose() で、これは DL ライブラリをクローズします。
dl ライブラリは動的なファイルハンドルへのリンク数を管理しているので、
同一動的ライブラリに対して、dlopen が成功した回数と同じ数の dlclose
が呼ばれない限り、当該ライブラリは実際にはメモリ上から削除されません。
そのため、同じプログラムが同じライブラリを何回ロードしても、
問題にはなりません。
ライブラリの割当てが解除される場合は、(もしも存在するならば)
_fini 関数が呼ばれます。
詳細は <xref linkend="init-and-fini"> を参照してください。
</para>
</sect2>

<sect2>
<!--
<title>DL Library Example</title>
-->
<title>DL ライブラリの例</title>
<para>
<!--
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):
-->
dlopen(3) の man ページからの例をここに載せます。
この例は、数学ライブラリをロードし、2.0 のコサインを出力し、また、
全てのステップでエラーをチェックしています (推奨されています) ――
<programlisting>
<![CDATA[

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

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

        handle = dlopen ("/lib/libm.so", 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>
</para>

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

<para>
<!--
The ``-Wl,export-dynamic'' option isn't actually required, but you
may sometimes find it useful.
It is defined in ld(1):
``When  creating  an ELF file, [this option adds] all symbols to the
dynamic symbol table.  Normally, the dynamic symbol
table contains only symbols which are used by a dynamic object.
This option is needed for some  uses of dlopen.''
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.
-->
``-Wl,export-dynamic'' オプションは実際には必要ありませんが、
時々役に立つことがあります。ld(1) で次のように明記されています
――``ELF ファイルを作成しているとき、このオプションが、
全てのシンボルを動的シンボルテーブルに加えます。通常、動的シンボルテーブルは
動的オブジェクトによって使われるシンボルだけを含んでいます。
このオプションは dlopen の使用のために必要となります''
Linux システムだけで作業をしているならば、``-Wl,export-dynamic''
のかわりに ``-rdynamic'' を使えるけれども、ELF ドキュメントによれば、
非 Linux システム上の gcc では ``-rdynamic'' フラグは必ずしも機能しない、
ということには注意しておいてください。
</para>
</sect2>

</sect1>

<sect1 id="miscellaneous">
<!--
<title>Miscellaneous</title>
-->
<title>雑録</title>

<sect2>
<!--
<title>nm command</title>
-->
<title>nm コマンド</title>
<para>
<!--
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).
-->
nm(1) コマンドは、与えられたライブラリ内のシンボルのリストを報告します。
静的ライブラリ、共有ライブラリのどちらに対しても機能します。
nm(1) は与えられたライブラリで定義されているシンボル名、シンボルの値、
シンボルのタイプを表示します。また、そのライブラリ内に情報が存在するならば
(-l オプションを見てください) 、シンボルがソースコード内のどこで
(ファイル名と行番号) 定義されているかということも特定できます。
</para>

<para>
<!--
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).
-->
シンボルタイプについてはもう少し説明が必要です。
タイプは一文字で表示されます。小文字はそのシンボルがローカルであることを意味し、
大文字はそのシンボルがグローバル (外部) であることを意味します。
典型的なシンボルのタイプは次のものを含みます――
T (コードセクション内の普通の定義)
D (初期化されたデータセクション)
B (初期化されていないデータセクション)
U (未定義。シンボルはライブラリによって使われているが、
  ライブラリ内では定義されていない)
W (weak. もしも他のライブラリもこのシンボルを定義していた場合、
  その定義がオーバーライドする)
</para>

<para>
<!--
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:
-->
関数の名前は覚えているけれども、
それがどのライブラリで定義されているか正確には思い出せない場合、
ライブラリ名を見つけるため、nm の ``-o'' オプション
(各ラインのファイル名の前に置きます) に grep を続けて使うことができます。
Bourne シェルであれば、/lib, /usr/lib, /usr/lib の直下のサブディレクトリ、
および /usr/local/lib 内の全ライブラリを対象にして ``cos'' を検索するには、
次のようにします――
<programlisting>
nm -o /lib/* /usr/lib/* /usr/lib/*/* \
      /usr/local/lib/* 2> /dev/null | grep 'cos$' 
</programlisting>
</para>
<para>
<!--
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>.
-->
nm に関するもっと多くの情報は、
<ulink url="info:binutils#nm">info:binutils#nm</ulink>
にローカルにインストールされている nm の ``info''
ドキュメントで得られます。
</para>
</sect2>

<sect2 id="init-and-fini">
<!--
<title>Special functions _init and _fini</title>
-->
<title>特別な関数 _init と _fini</title>
<para>
<!--
Two special functions aid in initializing and finalizing a module:
_init and _fini.
If a function ``_init'' is exported in a library,
then it is called whenever dllopen() is called to open the 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 calls dlclose() to release a library (and it's released).
The C prototypes for these functions are:
-->
二つの特別な関数 _init と _fini は、モジュールの初期処理と終了処理を支援します。
もしもライブラリ内で関数 ``_init'' がエクスポートされていると、
そのライブラリのオープン時に dlopen() が呼ばれるたび、
その関数が呼び出されます。
C のプログラムでは、_init という名前の関数を定義することを意味します。
これに対応する _fini と呼ばれる関数も存在し、
これは、クライアントがライブラリの解放時に dlclose()
を呼ぶたびに、呼び出されます (そして解放されます) 。
これらの関数の C プロトタイプは次のようになっています。
<programlisting>
  void _init(void);
  void _fini(void);
</programlisting>
</para>

<para>
<!--
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.
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.
-->
Gcc でファイルを ``.o'' ファイルへとコンパイルするときは、
忘れずに ``-nostartfiles'' オプションを付けてください。
このオプションは、C コンパイラが .so
ファイルに対してシステムスタートアップライブラリをリンクしないようにします。
このオプションを付けないと、``multiple-definition''
(重複定義) エラーになってしまいます。
_init と _fini に関する議論を加えることを提案してくれたこと、
およびその作成を手伝ってくれたことに対して、
Jim Mischel と Tim Gentry に感謝します。
</para>

</sect2>

<sect2>
<!--
<title>Shared Libraries Can Be Scripts</title>
-->
<title>共有ライブラリはスクリプト化できる</title>
<para>
<!--
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:
-->
通常のライブラリ形式の代わりに、
特殊なスクリプト言語を使っているテキストファイルを共有ライブラリとして
GNU ローダが認めることは、注目に値します。これは、
他のライブラリを間接的に結合させるのに役立ちます。例えば、
私の持つある一つのシステム上の <filename>/usr/lib/libc.so</filename>
をリスティングしたものは次のようになります。
<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 )
-->
/* GNU ld スクリプト
   共有ライブラリを使うが、幾つかの関数は静的ライブラリ内にしか
   存在しない。そのため、二番目に試みる。 */
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
</programlisting>
</para>
<para>
<!--
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.
-->
これに関するより詳しい情報は、ld リンカスクリプト (ld コマンド言語)
についての texinfo ドキュメントを参照してください。
一般的な情報は、info:ld#Options と info:ld#Commands
にあり、よく使うコマンドは info:ld#Option Commands
で説明されています。
</para>
</sect2>

<sect2>
<title>GNU libtool</title>
<para>
<!--
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>
-->
多くのシステムに移植されるアプリケーションを作成しているならば、
ライブラリを構築しインストールするのに、
<ulink url="http://www.gnu.org/software/libtool/libtool.html">GNU libtool</ulink>
を使用することを考慮したほうがよいかもしれません。
GNU libtool は、汎用的なライブラリサポートスクリプトです。
Libtool は、共有ライブラリ使用の複雑さを一貫性のあるポータブルな
インターフェースで隠します。Libtool は、
オブジェクト作成、ライブラリのリンク (静的および共有) 、
実行可能ファイルのリンク、実行可能ファイルのデバッグ、
ライブラリのインストール、実行可能ファイルのインストール、
についてポータブルなインターフェースを提供します。
また、プログラムを動的にロードするためのポータビリティラッパー
である libltdl も含んでいます。より詳細な情報は、
<ulink url="http://www.gnu.org/software/libtool/manual.html">http://www.gnu.org/software/libtool/manual.html</ulink>
を参照してください。
</para>

</sect2>
<sect2>
<!--
<title>Extremely small executables</title>
-->
<title>極端に小さな実行可能ファイル</title>
<para>
<!--
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.
-->
<ulink url="http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html">
「本当に小さな Linux 用 ELF 実行可能ファイル作成に関する慌ただしいチュートリアル」</ulink>
という文書が、よい参考となるでしょう。
これは、本当に小さな実行可能プログラムを作成する方法について論じています。
率直に言えば、一般的な環境では、これらのトリックのほとんどは使うべきではありませんが、
それらは、ELF が実際にどのように機能するかを示しているという点において、
極めて有益です。
</para>
</sect2>
</sect1>

<sect1 id="more-examples">
<!--
<title>More Examples</title>
-->
<title>さらに多くの例</title>
<para>
<!--
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.
-->
下記に、全三つのアプローチ (静的、共有、および動的にロードされるライブラリ)
の例をさらに挙げます。ファイル libhello.c は平凡なライブラリで、
ヘッダファイルとして libhello.h を持ちます。ファイル demo_use.c は、
そのライブラリの平凡な呼出しです。
静的ライブラリや動的ライブラリとして当該ライブラリを使う方法を示すため、
コメント付きのスクリプト (script_static と script_dynamic) があとに続きます。
さらに demo_dynamic.c と script_dynamic があとに続きます。
これらは共有ライブラリを動的にロードされるライブラリとして使う方法を示します。
</para>

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

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

#include <stdio.h>

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

]]>
-->
<![CDATA[
/* libhello.c - ライブラリ使用の実例 */

#include <stdio.h>

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

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


void hello(void);

]]>
-->
<![CDATA[
/* libhello.h - ライブラリ使用の実例 */


void hello(void);

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

#include "libhello.h"

int main(void) {
 hello();
 return 0;
}
]]>
-->
<![CDATA[
/* demo_use.c -- "hello" ルーチンを直接使用する実例 */

#include "libhello.h"

int main(void) {
 hello();
 return 0;
}
]]>
</programlisting>
</para>
</sect2>
<sect2>
<!--
<title>File script_static</title>
-->
<title>ファイル script_static</title>
<para>
<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
]]>
-->
<![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 を使うためにそれをどこか他の場所へ
# 単にコピーすることもできます。デモが目的なので、ライブラリは
# カレントディレクトリ内にとどめておきます。

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

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

# demo_use プログラムを作成します。-L. により、プログラム作成中に
# "." が検索されることになります。このコマンドは、libhello-static.a
# 内の関係するオブジェクトを demo_use_static に組み込むということ
# に注意してください。

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

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

./demo_use_static
]]>
</programlisting>
</para>
</sect2>
<sect2>
<!--
<title>File script_shared</title>
-->
<title>ファイル script_shared</title>
<para>
<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

]]>
-->
<![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 が存在するかを
# 確認し、もし存在すれば、それを残しておくべきか否かを調べます。

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>
</para>
</sect2>
<sect2>
<!--
<title>File demo_dynamic.c</title>
-->
<title>ファイル demo_dynamic.c</title>
<para>
<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 <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;
}
]]>
-->
<![CDATA[
/* demo_dynamic.c -- 動的ローディングと "hello" ルーチン使用の実例 */


/* 動的にライブラリをロードするルーチン用に dlfcn.h が必要 */
#include <dlfcn.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, "Couldn't open libhello.so: %s\n",
           dlerror());
   exit(1);
 }

 /* シンボルを得る */
 dlerror();
 demo_function = dlsym(module, "hello");
 if ((error = dlerror())) {
   fprintf(stderr, "Couldn't find hello: %s\n", error);
   exit(1);
 }

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

 /* 全てが終了したので、物事をきれいに片付ける */
 dlclose(module);
 return 0;
}
]]>
</programlisting>
</para>
</sect2>
<sect2>
<!--
<title>File script_dynamic</title>
-->
<title>ファイル script_dynamic</title>
<para>
<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
]]>
-->
<![CDATA[
#!/bin/sh
# 動的にロードされるライブラリの実例

# libhello.so とその仲間が既に作成されているものとします
# (共有ライブラリの例を見てください)。

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

gcc -Wall -g -c demo_dynamic.c

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

gcc -g -o demo_dynamic demo_dynamic.o -ldl

# プログラムを実行します。LD_LIBRARY_PATH を使い、動的にロード
# されるライブラリをどこで得られるかを教える必要があります。

LD_LIBRARY_PATH="." ./demo_dynamic
]]>
</programlisting>
</para>
</sect2>
<!-- END OF demo.sgml -->
</sect1>

<sect1 id="info-sources">
<!--
<title>Other Information Sources</title>
-->
<title>その他の情報源</title>
<para>
<!--
Particularly useful sources of information about libraries
include the following:
-->
下記のものは、ライブラリに関して特に役に立つ情報を含んでいます。
<itemizedlist>
<!--
<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>
-->
<listitem><para>Daniel Barlow による ``The GCC HOWTO''.
特にこの HOWTO は、ライブラリ作成用のオプションと、
どのようにライブラリに問い合わせをするかについて論じています。
ここでは取り上げていない情報を扱っていますが、逆のことも言えます。
この HOWTO は、
<ulink url="http://www.linuxdoc.org">http://www.linuxdoc.org</ulink>
の Linux Documentation Project から入手できます
(訳注：``The GCC HOWTO'' の日本語訳は
<ulink url="http://www.linux.or.jp/JF/JFdocs/GCC-HOWTO.html">
http://www.linux.or.jp/JF/JFdocs/GCC-HOWTO.html</ulink>
です)。
</para></listitem>
<!--
<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>
-->
<listitem><para>
The Tool Interface Standards (TIS) 委員会による
``Executable and Linkable Format (ELF)''
(実際にはこれは、同委員会による the 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 と untar を実行すると、``hps'' ファイルができます。
ファイルの最初と最後の行を削除し、``ps'' ファイルに名前を変更すれば、
普通のファイル名を持つ印字可能な Postscript ファイルを得られます。
</para></listitem>
<!--
<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>
-->
<listitem><para>
Hongjui Lu による ``ELF: From the Programmer's Perspective''.
これは、ELF に関する Linux と GNU gcc に特化した情報を提供します。
<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>
<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>
</itemizedlist>
</para>
</sect1>

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

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

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

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

<para>
<!--
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.
-->
はじめの二つは、
第一に、私が過去のバグについて繰り返し話を聞かされることを防ぎます。
単にあなたが文書を適切にミラーリングしていないという原因のために、
私は一年前に直したバグに関する話を聞きたくはありません。
マスターサイトへリンクを張ることにより、
ユーザはあなたのサイトが最新のものであるかどうかを確認できます。
非常に厳しいセキュリティ要求があり、そのためにインターネットへ
通常に接続するリスクを取ることができないサイトの問題に対して、
私は敏感です。このことがあなたの状況にあてはまるならば、
少なくとも、他のポイントへの接続を試みたり、
時折あなたの環境へのスニーカーネット・アップデート
(訳注：スニーカーネット (sneakernet) ――
FD 等を持ち運びすることにより情報を共有するネットワーク)
を試みるなどしてください。
</para>

<para>
<!--
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.
-->
このライセンスによれば、あなたはドキュメントを変更しても構いませんが、
あなたが書いたものではないものをあなたのものであると主張したり
(つまり盗用です) 、
変更されたバージョンが原作であるかのようなふりをすることはできません。
著作物の変更は、著作物全体の著作権をあなたに譲渡するものではありません。
これは、著作権法の用語でいうところの ``public domain''
の著作物ではありません。ライセンスを詳細に見てください。特に、
``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) へ送るのがよいでしょう。
</para>

</sect1>

</article>

