<!doctype linuxdoctr system>


<article>

<!-- Title information -->

<title>Building and Installing Software Packages for Linux

<author>
<em><url url="mailto:thegrendel@theriver.com"
name="Mendel Cooper"></em>
---
<url url="http://personal.riverusers.com/~thegrendel/"
name="http://personal.riverusers.com/~thegrendel/">

<date>v1.91, 27 July 1999
<trans>井田 司 <url url="mailto:tsukasa_i@bigfoot.com"> と
JF Project &lt;JF@linux.or.jp&gt;
<tdate>v1.91j, 18 January 2000

<abstract>
<!--O
This is a comprehensive guide to building and installing "generic" UNIX
software distributions under Linux. Additionally, there is some coverage
of "rpm" and "deb" pre-packaged binaries.
-->
この文書は Linux 上で「一般的」な UNIX のソフトウェアを構築・
インストールするための包括的なガイドです。さらに、 "rpm" や "deb" といっ
たコンパイル済みバイナリパッケージについてもいくらか扱っています。
</abstract>

<!-- Table of contents -->
<toc>

<!-- Begin the document -->

<!--O
<sect>Introduction
-->
<sect>はじめに
<p>
<!--O
Many software packages for the various flavors of UNIX and Linux come as
compressed archives of source files.  The same package may be "built"
to run on different target machines, and this saves the author of the
software from having to produce multiple versions. A single distribution
of a software package may thus end up running, in various incarnations,
on an Intel box, a DEC Alpha, a RISC workstation, or even a mainframe.
Unfortunately, this puts the responsibility of actually "building"
and installing the software on the end user, the de facto "system
administrator", the fellow sitting at the keyboard -/-  you.  Take heart,
though, the process is not nearly as terrifying or mysterious as it seems,
as this guide will demonstrate.
-->
各種 UNIX 系 OS や Linux 用のソフトウェアパッケージの多くは
ソースファイルを圧縮したアーカイブとして配布されています。同じ
ソフトウェアのパッケージをそれぞれのマシン毎に「構築」して実行すること
ができるので、ソフトウェアの作者はたくさんのバージョンを作る手間を省く
ことができます。ひとつだけのソフトウェアの配布パッケージが色々な形で構
築され、最終的には Intel のマシンや DEC Alpha, RISC ワークステーション、
あるいはメインフレーム機でさえ動作するようになります。
残念ながらこのことは、実際にソフトウェアを「構築」してインストールするこ
とがエンドユーザの仕事になるということです。
エンドユーザとは事実上の「システム管理者」、つまりキーボードに向かっ
て座っている――あなたのことです。しかし、元気を出してください。
手順は見ためほどわけのわからないものでも神秘的なものでもありません。こ
のガイドではそのことをわかってもらいます。


<!--O
<sect>Unpacking the Files
-->
<sect>ファイルの展開
<p>
<!--O
You have downloaded or otherwise acquired a software package.  Most likely
it is archived (<em>tarred</em>) and compressed (<em>gzipped</em>),
in <tt>.tar.gz</tt> or <tt>.tgz</tt> form (familiarly known as a
"tarball").  First copy it to a working directory. Then <em>untar</em>
and <em>gunzip</em> it. The appropriate command for this is <bf>tar
xzvf <em>filename</em></bf>, where <em>filename</em> is the name of the
software file, of course.  The de-archiving process will usually install
the appropriate files in subdirectories it will create.  Note that if
the package name has a <em>.Z</em> suffix, then the above procedure will
serve just as well, though running <bf>uncompress</bf>, followed by a
<bf>tar xvf</bf> also works. You may preview this process by a <bf>tar
tzvf filename</bf>, which lists the files in the archive without actually
unpacking them.
-->
必要なソフトウェアのパッケージは、ダウンロードするなどして既に入手して
いるものとします。もっとも出回っているのは、tar でアーカイブして gzip
で圧縮してある .tar.gz または .tgz の形式です(よく "tarball" と言われ
ます)。まずは、このアーカイブファイルを作業ディレクトリにコピーします。
次に、<em>tar の展開</em>と <em>gunzip</em> を行います。これを行うため
のコマンドは <bf>tar xzvf <em>&lsqb;ファイル名&rsqb;</em></bf>です。
言うまでもなく、&lsqb;ファイル名&rsqb; とはアーカイブファイルのことで
す。普通は、展開を行うと新たにディレクトリが作られて、そのディレクトリ
の中に適当なファイルが展開されます。注意: もしパッケージのファイル名に
<em>.Z</em> という拡張子がついていたら、上記の方法でも全く差し支えあり
ませんが、<bf>uncompress &lsqb;ファイル名&rsqb;</bf> とした後で、
<bf>tar xvf &lsqb;ファイル名&rsqb;</bf> としても展開できます。展開によっ
てどんなファイルが作られるかは、<bf>tar tzvf &lsqb;ファイル名&rsqb;</bf>
で前もって調べられます。このコマンドは実際にアーカイブを展開することな
く中に入っているファイルのリスト表示だけを行います。

<!--O
The above method of unpacking "tarballs" is equivalent to either of the following:
-->
"tarball" を展開する上記の方法は、以下の両方と同じ動作です:
<itemize>
<item>gzip -cd filename | tar xvf -
<item>gunzip -c filename | tar xvf -
</itemize>
<!--O
(The '-' causes the <em>tar</em> command to take its input from
<tt>stdin</tt>.)
-->
('-' を付けると、<em>tar</em> コマンドは<tt>標準入力</tt>から入力を行
います。)

<!--O
Source files in the new <em>bzip2</em> (<tt>.bz2</tt>) format
can be unarchived by a <bf>bzip2 -cd filename | tar xvf -</bf>,
or, more simply by a <bf>tar xyvf filename</bf>, assuming that
<tt>tar</tt> has been appropriately patched (refer to the <htmlurl
url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/mini/Bzip" name="Bzip2
HOWTO"> for details). Debian Linux uses a different patch for
<tt>tar</tt>, one written by Hiroshi Takekawa, so that the <em>-I,
-/-bzip2, -/-bunzip2</em> options work with that particular <tt>tar</tt>
version.
-->
<em>bzip2</em>(<tt>.bz2</tt>)という新しい圧縮形式で圧縮されたソースファイル
は <bf>bzip2 -cd &lsqb;ファイル名&rsqb; | tar xvf -</bf> とすれば展開
できます。あるいは、<tt>tar</tt>p に bzip2 のためのパッチが当たってい
るなら、単に <bf>tar xyvf &lsqb;ファイル名&rsqb;</bf> とすれば展開できます
(詳しくは Bzip2 HOWTO 
(日本語版：<url url="http://www.linux.or.jp/JF/JFdocs/Bzip2/Bzip2.html/">,
英語版：<url url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/mini/Bzip">)
を参照してください)。Debian GNU/Linux では Hiroshi Takekawa が書いた別
のパッチを <tt>tar</tt> に当てており、そのバージョンの <tt>tar</tt> で
は <em>-I, --bzip2, --bunzip2</em> オプションが使えます。

<!--O
[Many thanks to R. Brock Lynn and Fabrizio Stefani for corrections and
updates on the above information.]
-->
&lsqb;上記の情報の訂正と更新について R. Brock Lynn と
Fabrizio Stefani に深く感謝します。&rsqb;


<!--O
Sometimes the archived file must be untarred and installed from the
user's home directory, or perhaps in a certain other directory, such
as <tt>/</tt>, <tt>/usr/src</tt>, or <tt>/opt</tt>, as specified in
the package's config info.  Should you get an error message attempting
to untar it, this may be the reason. Read the package docs, especially
the <tt>README</tt> and/or <tt>Install</tt> files, if present, and edit
the config files and/or <tt>Makefiles</tt> as necessary, consistent
with the installation instructions. Note that you would <bf>not</bf>
ordinarily alter the <tt>Imake</tt> file, since this could have unforseen
consequences.  Most software packages permit automating this process by
running <bf>make install</bf> to emplace the binaries in the appropriate
system areas.
-->
場合によっては、アーカイブファイルはユーザのホームディレクトリや、ある
いは別の特定のディレクトリ(<tt>/</tt>, <tt>/usr/src</tt>, <tt>/opt</tt>
等)に展開しなければなりません。これはソフトウェアパッケージの設定情報
で指定されているでしょう。アーカイブファイルを展開しているときにエラー
が出たなら、このことが原因かもしれません。パッケージ付属のドキュメントファイル
(特に <tt>README</tt> や <tt>Install</tt> ファイル)があれば、そのドキュ
メントを読み、必要に応じて設定ファイルや <tt>Makefile</tt> を編集してください。
注意: 思いもよらない結果になることがあるので、普通は
<tt>Imakefile</tt> ファイルは編集しない方がいいでしょう。
ほとんどのソフトウェアパッケージでは、この手順は自動化されており、
<bf>make install</bf> と実行すればバイナリファイルが所定のシステム領域
に自動的に置かれます。

<itemize>

<!--O
<item>You might encounter <tt>shar</tt> files, or <em>shell archives</em>,
especially in the source code newsgroups on the Internet.  These remain
in use because they are readable to humans, and this permits newsgroup
moderators to sort through them and reject unsuitable ones.  They may
be unpacked by the <bf>unshar filename.shar</bf> command. Otherwise the
procedure for dealing with them is the same as for "tarballs".
-->
<item>インターネット上のニュースグループあたりだと
<tt>shar</tt> ファイル、つまり<em>シェルアーカイブ(SHell ARchive)</em>
形式のファイルに出食わすかもしれません。<tt>shar</tt> 形式が未だに使わ
れているのは、この形式は人間が読めるので、ニュースグループのモデレータ
が <tt>shar</tt> 形式で投稿された記事を整理し、不適切なものを排除でき
るからです。この形式は <bf>unshar &lsqb;ファイル名&rsqb;.shar</bf> 
コマンドで展開できます。その他の点では "tarball" と同じように扱います。

</itemize>


<itemize>

<!--O
<item>Some source archives have been processed using nonstandard DOS,
Mac, or even Amiga compression utilities such <em>zip</em>, <em>arc</em>,
<em>lha</em>, <em>arj</em>, <em>zoo</em>, <em>rar</em>, and <em>shk</em>.
Fortunately, <url url="http://metalab.unc.edu" name="Sunsite"> and
other places have Linux uncompression utilities that can deal with most
or all of these.
-->
<item>一部のソースアーカイブは、DOS や Mac, ことによっては Amiga の
標準でない圧縮ユーティリティで処理されていることがあります。これには
<em>zip</em>, <em>arc</em>, <em>lha</em>, <em>arj</em>, <em>zoo</em>,
<em>rar</em>, and <em>shk</em> 等があります。幸い、
<url url="http://metalab.unc.edu" name="Sunsite"> 等のサイトには Linux
用の圧縮ユーティリティが置いてあり、これらのほとんど全てを扱えます。

</itemize>

<!--O
Occasionally, you may need to update or incorporate bug fixes into the
unarchived source files using a <tt>patch</tt> or <tt>diff</tt> file
that lists the changes.  The doc files and/or <tt>README</tt> file will
inform you should this be the case. The normal syntax for invoking Larry
Wall's powerful <em>patch</em> utility is <bf>patch < patchfile</bf>.
-->
時として、元のソースファイルからの変更点を記してある <tt>パッチ</tt>
ファイルや <tt>diff</tt> ファイルを使って、展開したソースファイルを更
新したり、バグ修正を取り込んだりすることが必要な場合があります。
こういった場合にすべきことは、ドキュメントファイルや <tt>README</tt>
ファイルにのっています。Larry Wall が開発した強力な
<em>patch</em> ユーティリティの普通の使い方は
<bf>patch &lt; &lsqb;パッチファイル&rsqb;</bf>です。

<!--O
You may now proceed to the build stage of the process.
-->
さて、それでは、構築の段階へと進みましょう。


<!--O
<sect>Using Make
-->
<sect>Make の使用
<p>
<!--O
The <tt>Makefile</tt> is the key to the build process. In its simplest
form, a Makefile is a script for compiling or building the "binaries",
the executable portions of a package. The Makefile can also provide a
means of updating a software package without having to recompile every
single source file in it, but that is a different story (or a different
article).
-->
<tt>Makefile</tt> は構築の段階で鍵となるファイルです。Makefile の最も
単純な使い方は、「バイナリ」つまりパッケージの実行部分のコンパイルや
構築を行うスクリプトとしてのものです。
Makefile を使えば、ソフトウェアパッケージの更新をする際に全部のファイル
をいちいち再コンパイルしないで済ませることもできるのですが、この使い方
はここでは関係ないのでまた別の話になります。

<!--O
At some point, the Makefile launches <tt>cc</tt> or <tt>gcc</tt>. This
is actually a preprocessor, a C (or C++) compiler, and a linker, invoked
in that order.  This process converts the source into the binaries, the
actual executables.
-->
いくつかのタイミングで Makefile は <tt>cc</tt> や <tt>gcc</tt> を実行
します。正確には、プリプロセッサ、C (や C++) のコンパイラ、リンカを順に
実行します。

<!--O
Invoking <em>make</em> usually involves just typing <bf>make</bf>. This
generally builds all the necessary executable files for the package in
question. However, make can also do other tasks, such as installing the
files in their proper directories (<bf>make install</bf>) and removing
stale object files (<bf>make clean</bf>).  Running <bf>make -n</bf>
permits previewing the build process, as it prints out all the commands
that would be triggered by a make, without actually executing them.
-->
普通、<tt>make</tt> を実行するには <bf>make</bf> とタイプするだけです。
<tt>make</tt> を実行すると、普通はパッケージに必要な全ての実行可能ファ
イルが構築されます。しかし、make にできることはこれだけではありません。
例えば、ファイルを適切なディレクトリにインストールしたり(<bf>make install</bf>)、
古いオブジェクトファイルを消去できます(<bf>make clean</bf>)。<bf>make -n</bf>
を実行すると、make が呼び出す全ての命令を実際の処理を行わずに表示だけ
させることにより、構築のプロセスをあらかじめ確認できます。

<!--O
Only the simplest software uses a generic Makefile. More complex
installations require tailoring the Makefile according to the location
of libraries, include files, and resources on your particular machine.
This is especially the case when the build needs the <tt>X11</tt>
libraries to install. <em>Imake</em> and <em>xmkmf</em> accomplish this
task.
-->
一般的な Makefile を使うのは非常に単純なソフトだけです。もっと複雑な
インストール作業では、あなたのマシンのライブラリやインクルードファイル、
リソースに合わせて Makefile の設定を必要があります。このことは
インストールに <tt>X11</tt> のライブラリが必要なときによく起こります。
<tt>X11</tt> では <em>Imake</em> と <em>xmkmf</em> がこの作業をしてく
れます。

<!--O
An <tt>Imakefile</tt> is, to quote the man page, a "template"
Makefile. The imake utility constructs a Makefile appropriate for your
system from the Imakefile. In almost all cases, however, you would run
<bf>xmkmf</bf>, a shell script that invokes imake, a front end for it.
Check the README or INSTALL file included in the software archive for
specific instructions.  (If, after dearchiving the source files, there
is an <tt>Imake</tt> file present in the base directory, this is a dead
giveaway that <bf>xmkmf</bf> should be run.)  Read the <tt>Imake</tt> and
<tt>xmkmf</tt> man pages for a more detailed analysis of the procedure.
-->
man ページからの引用によると、<tt>Imakefile</tt> は Makefile の
「テンプレート」です。 imake ユーティリティは Imakefile を元にして
システムに合った Makefile を作ります。しかし、ほとんどの場合は、imake
を直接使うのではなく <bf>xmkmf</bf> を実行することになるでしょう。
<tt>xmkmf</tt> は imake を実行するためのシェルスクリプトであり、
フロントエンドです。個別のインストールの際の具体的な作業については、ソ
フトウェアアーカイブに入っている README や INSTALL という名前の
ファイルをチェックしてください。(ソースファイルを展開した後に、メイン
のディレクトリに <tt>Imakefile</tt> ができていれば、<bf>xmkmf</bf> を
使うはずだという動かぬ証拠になります。) <tt>imake</tt> と
<tt>xmkmf</tt> の細かい動作については man ページを読んでください。

<!--O
Be aware that <tt>xmkmf</tt> and <tt>make</tt> may need to be invoked as
root, especially when doing a <bf>make install</bf> to move the binaries
over to the <tt>/usr/bin</tt> or <tt>/usr/local/bin</tt> directories.
Using make as an ordinary user without root privileges will likely
result in <em>write access denied</em> error messages because you lack
write permission to system directories. Check also that the binaries
created have the proper execute permissions for you and any other
appropriate users.
-->
<tt>xmkmf</tt> や <tt>make</tt> は root で実行することが必要な場合があ
ることに注意してください。特に、<tt>make install</tt> を実行して
<tt>/usr/bin</tt> や <tt>/usr/local/bin</tt> ディレクトリにバイナリ
ファイルを移動させる場合はそうです。root 権限を持たない普通のユーザに
はシステムディレクトリへの書き込み権限がないので、make を使用するとお
そらく<em>書き込み拒否のエラー(write access denied)</em>が出るでしょう。
また、バイナリファイルの実行許可が適切なユーザに与えられているかどうか
も確認してください。

<!--O
Invoking <bf>xmkmf</bf> uses the <tt>Imake</tt> file to build a new
Makefile appropriate for your system. You would normally invoke
<bf>xmkmf</bf> with the <bf>-a</bf> argument, to automatically do a
<em>make Makefiles, make includes,</em> and <em>make depend</em>.  This
sets the variables and defines the library locations for the compiler
and linker.  Sometimes, there will be no <tt>Imake</tt> file, instead
there will be an <tt>INSTALL</tt> or <tt>configure</tt> script that will
accomplish this purpose. Note that if you run <tt>configure</tt>, it
should be invoked as <bf>./configure</bf> to ensure that the correct
<tt>configure</tt> script in the current directory is called. In most
cases, the <tt>README</tt> file included with the distribution will
explain the install procedure.
-->
<bf>xmkmf</bf> は <tt>Imakefile</tt> を使って、システムに合った
<bf>Makefile</bf> を新しく作ります。通常は <bf>-a</bf> オプションを付
けて <bf>xmkmf</bf> を実行し、
<em>make Makefiles, make includes, make depend</em> を自動的に行わせます。
これにより変数の設定や、コンパイラやリンカに与えるライブラリの位置の
定義が行われます。場合によっては、<tt>Imakefile</tt> がなく、
その代わりに同様の設定を行うための <tt>INSTALL</tt> スクリプトや
<tt>configure</tt> スクリプトが付いていることもあります。この際の注意
ですが、<tt>configure</tt> を実行する場合には、確実にカレントディレクトリ
の <tt>configure</tt> スクリプトを実行するために <tt>./configure</tt>
として実行すべきです。大抵の場合、インストールの手順を説明した
<tt>README</tt>ファイルがパッケージに入っています。

<!--O
It is usually a good idea to visually inspect the <tt>Makefile</tt> that
<tt>xmkmf</tt> or one of the install scripts builds. The Makefile will
normally be correct for your system, but you may occasionally be
required to "tweak" it or correct errors manually.
-->
<tt>xmkmf</tt> や何らかのインストールスクリプトが作成した
<tt>Makefile</tt> を実際に見て詳しく点検するとよいでしょう。
Makefile は通常、あなたのシステムに合わせて正しく設定されているはずで
すが、時として手作業で Makefile を「いじったり」、間違いを直す必要に迫
られることがあります。

<!--O
Installing the freshly built binaries into the appropriate system directories
is usually a matter of running <bf>make install</bf> as root. The usual
directories for system-wide binaries on modern Linux distributions are
<tt>/usr/bin</tt>, <tt>/usr/X11R6/bin</tt>, and <tt>/usr/local/bin</tt>. The
preferred directory for new packages is <tt>/usr/local/bin</tt>, as this will
keep separate binaries not part of the original Linux installation.
-->
できたてのバイナリを適切なシステムディレクトリにインストールするには、
普通は root になって <bf>make install</bf> します。最近のディストリビューション
では、システム全体で使うバイナリを置くための一般的なディレクトリは
<tt>/usr/bin</tt>, <tt>/usr/X11R6/bin</tt>, <tt>/usr/local/bin</tt> で
す。新しいパッケージを入れるのに適切なディレクトリは <tt>/usr/local/bin</tt>
で、そうしておけば新しく入れた部分と元々 Linux にインストールされてい
た部分を分けておけます。

<!--
Packages originally targeted for commercial versions of UNIX may attempt
to install in the <tt>/opt</tt> or other unfamiliar directory. This will,
of course, result in an installation error if the intended installation
directory does not exist. The simplest way to deal with this is to
create, as root, an <tt>/opt</tt> directory, let the package install
there, then add that directory to the <tt>PATH</tt> environmental
variable. Alternatively, you may create symbolic links to the
<tt>/usr/local/bin</tt> directory.
-->
もともと商用 UNIX 用を対象にしていたパッケージは、<tt>/opt</tt> 等の見
慣れないディレクトリにインストールしようとするかもしれません。もちろん、
インストール先のディレクトリが存在していなければ、エラーになります。
これを回避する最も簡単な方法は、root になって <tt>/opt</tt> ディレクトリ
を作って、そこにパッケージをインストールし、<tt>PATH</tt> 環境変数に
そのディレクトリを追加することです。別のやり方としては、
<tt>/usr/local/bin</tt> にシンボリックリンクを張ってもかまいません。

<!--O
Your general installation procedure will therefore be:
-->
したがって、一般的なインストールの手順は以下のようになります:
<itemize>
<!--O
<item>Read the <tt>README</tt> file and other applicable docs.
-->
<item><tt>README</tt> ファイルや他の適当なドキュメントを読みます。
<!--O
<item>Run <bf>xmkmf -a</bf>, or the <tt>INSTALL</tt> or <tt>configure</tt> script.
-->
<item><bf>xmkmf -a</bf> または <tt>INSTALL</tt> や <tt>configure</tt> といったスクリプトを実行します。
<!--O
<item>Check the <tt>Makefile</tt>.
-->
<item><tt>Makefile</tt> をチェックします。
<!--O
<item>If necessary, run <bf>make clean</bf>, <bf>make Makefiles</bf>,
<bf>make includes</bf>, and <bf>make depend</bf>.
-->
<item>必要に応じて、<bf>make clean</bf>, <bf>make Makefiles</bf>,
<bf>make includes</bf>, <bf>make depend</bf> を実行します。
<!--O
<item>Run <bf>make</bf>.
-->
<item><bf>make</bf> を実行します。
<!--O
<item>Check file permissions.
-->
<item>ファイルのパーミッションを確認します。
<!--O
<item>If necessary, run <bf>make install</bf>.
-->
<item>必要なら <bf>make install</bf> を実行します。
</itemize>


<!--O
<em>Notes:</em>
-->
<em>注意:</em>

<itemize>
<!--O
<item>You would not normally build a package as root. Doing an <bf>su</bf>
to root is only necessary for installing the compiled binaries into
system directories.
-->
<item>普通は、パッケージを root ユーザでコンパイルしてはいけません。
<bf>su</bf> して root する必要があるのは、コンパイルが終わったバイナリ
をシステムディレクトリにインストールするときだけです。

<!--O
<item>After becoming familiar with <em>make</em> and its uses,
you may wish to add additional optimization options passed to
<tt>gcc</tt> in the standard <tt>Makefile</tt> included or created
in the package you are installing. Some of these common options are
<em>-O2</em>, <em>-fomit-frame-pointer</em>, <em>-funroll-loops</em>,
and <em>-mpentium</em> (if you are running a Pentium cpu). Use caution
and good sense when modifying a <tt>Makefile</tt>!
-->
<item><em>make</em>とその使い方に慣れたら、インストールしようとしてい
るパッケージに含まれている、あるいはパッケージが自動的に生成する標準の 
<tt>Makefile</tt> に手を入れて、<tt>gcc</tt> に渡す最適化オプションを
追加するといいでしょう。こういったオプションでよく使われるのは、
<em>-O2</em>, <em>-fomit-frame-pointer</em>, <em>-funroll-loops</em>,
<em>-mpentium</em>(Pentium を使っている場合)です。<tt>Makefile</tt>
をいじる時は、用心と常識を忘れないように!

<!--O
<item>After the <em>make</em> creates the binaries, you may wish to
<bf>strip</bf> them. The <bf>strip</bf> command removes the symbolic
debugging information from the binaries, and reduces their size, often
drastically. This also disables debugging, of course.
-->
<item><em>make</em> でバイナリを作った後は、バイナリに対して
<bf>strip</bf> を実行するとよいでしょう。<bf>strip</bf> コマンドは
バイナリからデバッグ用のシンボル情報を取り除いてサイズを小さくします。
劇的に小さくなることもよくあります。これを実行すると、当然ながらデバッ
グには使えなくなります。

<!--O
<item>The <url url="http://sunsite.auc.dk/pack/" name="Pack Distribution
Project"> offers a different approach to creating archived software
packages, based on a set of Python scripting tools for managing
symbolic links to files installed in separate <em>collection
directories</em>. These archives are ordinary <em>tarballs</em>, but
they install in <tt>/coll</tt> and <tt>/pack</tt> directories. You may
find it necessary to download the <em>Pack-Collection</em> from the
above site should you ever run across one of these distributions.
-->
<item><url url="http://sunsite.auc.dk/pack/" name="Pack Distribution
Project"> は、先程までの説明とは別のアプローチでソフトウェアパッケージ
のアーカイブを作れるようにしようとしています。このアプローチは、ばらば
らの<em>コレクションディレクトリ</em>にインストールされたファイルへの
シンボリックリンクを Python スクリプト群を使って管理するというものです。
このアプローチでもアーカイブは <em>tarball</em> ですが、これらは
<tt>/coll</tt> ディレクトリや <tt>/pack</tt> ディレクトリに
インストールされます。これらのディストリビューションのどれかをちょっと
試してみるにも、<em>パックコレクション(Pack-Collection)</em>を上記の
サイトから入手する必要があるでしょう。
</itemize>


<!--O
<sect>Prepackaged Binaries
-->
<sect>コンパイル済バイナリパッケージ
<p>

<!--O
<sect1> Whats wrong with rpms?
-->
<sect1> RPM の悪いところ
<p>

<!--O
Manually building and installing packages from source is apparently so
daunting a task for some Linux users that they have embraced the popular
<em>rpm</em> and <em>deb</em> or the newer Stampede <em>slp</em> package
formats. While it may be the case that an <em>rpm</em> install normally
runs as smoothly and as fast as a software install in a certain other
notorious operating system, some thought should certainly be given to
the disadvantages of self-installing, prepackaged binaries.
-->
自分の手でパッケージをソースファイルから作ってインストールするのはおっ
くうな作業だからといって、人気のある <em>rpm</em> 形式や
<em>deb</em> 形式のパッケージや、新しい Stampede <em>slp</em> 形式の
パッケージを利用する Linuxユーザがいます。
通常は rpm を使うと例の悪名高いオペレーティングシステムと同じくらい簡
単かつ速くパッケージをインストールできるのは確かでしょうが、勝手にイン
ストールされるコンパイル済みのバイナリパッケージには間違いなく欠点もい
くつかあります。

<!--O
First, be aware that software packages are normally released first as
"tarballs", and that prepackaged binaries follow days, weeks, even
months later.  A current <em>rpm</em> package is typically at least a
couple of minor version behind the latest "tarball".  So, if you wish
to keep up with all the 'bleeding edge' software, you might not wish to
wait for an <em>rpm</em> or <em>deb</em> to appear. Some less popular
packages may never be <em>rpm</em>'ed.
-->
まず、ソフトウェアのパッケージは普通、"tarball" のソースファイルが最初
にリリースされ、コンパイル済みのバイナリパッケージはそれより数日、数週
間、場合によっては数ヵ月遅れてリリースされる点に注意してください。
最新の <em>rpm</em> パッケージでも、最新の "tarball" よりマイナー
バージョンが 1 つか 2 つ遅れているのが普通です。
ですから、常に「最先端」のソフトウェアを追いかけ続けたいのであれば、
<em>rpm</em> や <em>deb</em> が出るのを待つのは得策ではないでしょう。
あまり人気のないパッケージについては、<em>rpm</em> 化されないこともあ
るかもしれません。

<!--O
Second, the "tarball" package may well be more complete, have more
options, and lend itself better to customization and tweaking.  The binary
rpm version may be missing some of the functionality of the full release.
Source <em>rpm</em>'s contain the full source code and are equivalent
to the corresponding "tarballs", and they likewise need to be built and
installed using either of the <bf>rpm -/-recompile packagename.rpm</bf>
or <bf>rpm -/-rebuild packagename.rpm</bf> options.
-->
2 番目に、"tarball" パッケージの方がより完全であり、オプションも多く、
カスタマイズしたりいじったりする余地も多くあります。バイナリ rpm 版で
は、完全リリース版の一部の機能が消えていることもあります。
ソース <em>rpm</em> には完全なソースコードが入っているので、対応する
"tarball" と同等です。したがって、<bf>rpm --recompile packagename.rpm</bf> か
<bf>rpm --rebuild packagename.rpm</bf> のどちらかのオプションを使って
構築とインストールを行う必要があるでしょう。

<!--O
Third, some prepackaged binaries will not properly install, and even
if they do install, they could crash and core-dump. They may depend on
different library versions than are present in your system, or they may
be improperly prepared or just plain broken. In any case, when installing
an <em>rpm</em> or <em>deb</em> you necessarily trust the expertise of
the persons who have packaged it.
-->
2 番目に、コンパイル済みのパッケージの一部には正しくインストールできな
いものがあります。あるいはインストールしたとしても、クラッシュしてコア
を吐くかもしれません。これはシステムに入っているライブラリのバージョン
の違いに依存するかもしれないし、rpm パッケージの用意がうまくできていな
いのかもしれませんし、単にパッケージが壊れているのかもしれません。いず
れの場合にせよ、<em>rpm</em> や <em>deb</em> をインストールする時には、
パッケージを作った人の技術を信じるしかありません。

<!--O
Finally, it helps to have the source code on hand, to be able to tinker
with and learn from it. It is much more straightforward to have the
source in the archive you are building the binaries from, and not in a
separate source <em>rpm</em>.
-->
最後に、ソースコードを持っていればいじったり、勉強する時の役に立ちます。
ソースコードはバイナリを作成した元々のアーカイブで持つ方が、それとは別
のソース <em>rpm</em> の形で持っているよりもずっと分かりやすいでしょう。

<!--O
Installing an <em>rpm</em> package is not necessarily a no-brainer.
If there is a dependency conflict, an <em>rpm</em> install will
fail. Likewise, should the <em>rpm</em> require a different version of
libraries than the ones present on your system, the install may not work,
even if you create symbolic links to the missing libraries from the ones
in place.  Despite their convenience, <em>rpm</em> installs often fail
for the same reasons "tarball" ones do.
-->
<em>rpm</em> パッケージのインストールは、必ずしもバカなわけではありま
せん。もし、依存関係で競合があれば、<em>rpm</em> のインストールは失敗
するでしょう。同様に、現在のシステム上で動作しているライブラリと
バージョンが違うライブラリを <em>rpm</em> が要求しているならば、
たとえ足りないライブラリの名前で既存のライブラリにシンボリックリンクを
張ってもインストールは実行されません。便利であるにもかかわらず、
<em>rpm</em> でのインストールは "tarball" のインストールと同じ理由で失
敗してしまいます。

<!--O
You must install <em>rpm</em>'s and <em>deb</em>'s as root, in order
to have the necessary write permissions, and this opens a potentially
serious security hole, as you may inadvertently clobber system binaries
and libraries, or even install a <em>Trojan horse</em> that might wreak
havoc upon your system.  It is therefore important to obtain <em>rpm</em>
and <em>deb</em> packages from a "trusted source". In any case, you should
run a 'signature check' (against the MD5 checksum) on the package, <bf>rpm
-/-checksig packagename.rpm</bf>, before installing. Likewise highly
recommended is running <bf>rpm -K -/-nopgp packagename.rpm</bf>.  The
corresponding commands for <em>deb</em> packages are <bf>dpkg -I | -/-info
packagename.deb</bf> and <bf>dpkg -e | -/-control packagename.deb</bf>.
-->
書き込みに必要なパーミッションを得るためには、<em>rpm</em> や 
<em>deb</em> パッケージは root になってインストールする必要がありますが、
これは重大なセキュリティホールの可能性をもたらします。というのも、
うっかりとシステムのバイナリやライブラリを壊してしまうかもしれないし、
システムに大損害をもたらす<em>トロイの木馬</em>をインストールしてしま
うことさえあるかもしれません。したがって、「信頼できる所」から 
<em>rpm</em> や <em>deb</em> のパッケージを入手するというのは重要なこ
とです。いずれにせよ、インストールの前には
<bf>rpm --checksig &lsqb;パッケージ名&rsqb;.rpm</bf>
を実行し、「(MD5 チェックサムに対する)署名の確認」をパッケージに対して
行うべきです。同様に強くお勧めするのは、
<bf>rpm -K --nopgp &lsqb;パッケージ名&rsqb;.rpm</bf> の実行です。
<em>deb</em> パッケージでこれに対応するコマンドは
<bf>dpkg -I | --info &lsqb;パッケージ名&rsqb;.deb</bf> と
<bf>dpkg -e | --control &lsqb;パッケージ名&rsqb;.deb</bf>
です。

<itemize>
<item><tt>rpm --checksig gnucash-1.1.23-4.i386.rpm</tt>
<tscreen><verb>
</verb></tscreen>
<tt>gnucash-1.1.23-4.i386.rpm: size md5 OK</tt>
</itemize>

<itemize>
<item><tt>rpm -K --nopgp gnucash-1.1.23-4.i386.rpm</tt>
<tscreen><verb>
</verb></tscreen>
<tt>gnucash-1.1.23-4.i386.rpm: size md5 OK</tt>
</itemize>

<!--O
For the truly paranoid (and, in this case there is much
to be said for paranoia), there are the <em>unrpm</em>
and <em>rpmunpack</em> utilities available from the <htmlurl
url="ftp://metalab.unc.edu/pub/Linux/utils/package" name="Sunsite
utils/package directory"> for unpacking and checking the individual
components of the packages.
-->
本当に細かいことが気になる人のために(そして、こういった場合はよく
偏執病と言われます)、パッケージの個々の要素を展開してチェックするため
の <em>unrpm</em> や <em>rpmunpack</em> というユーティリティがありま
す。これは
<htmlurl url="ftp://metalab.unc.edu/pub/Linux/utils/package"
name="Sunsite のユーティリティ/パッケージ用ディレクトリ"> にあります。

<!--O
<url url="mailto:klee@debian.org" name="Klee Diene"> has written an
experimental <em>dpkgcert</em> package for verifying the integrity of
installed <em>.deb</em> files against MD5 checksums.  It is available from
the <url url="ftp://ftp.debian.org/pub/debian/project/experimental"
name="Debian ftp archive">.  The current package name
/ version is <em>dpkgcert_0.2-4.1_all.deb</em>. The <url
url="http://dpkgcert.jimpick.com" name="Jim Pick Software"> site maintains
an experimental server database to provide <em>dpkgcert</em> certificates
for the packages in a typical Debian installation.
-->
<url url="mailto:klee@debian.org" name="Klee Diene"> は、インストール
された <em>.deb</em> ファイルが改変されていないことを MD5 チェックサム
で調べるための実験的な <em>dpkgcert</em> パッケージを作りました。この
パッケージは <url url="ftp://ftp.debian.org/pub/debian/project/experimental"
name="Debian の ftp アーカイブ">から入手できます。現在のパッケージ名と
バージョンは <em>dpkgcert_0.2-4.1_all.deb</em> です。
<url url="http://dpkgcert.jimpick.com" name="Jim Pick Software"> の
サイトでは、Debian の通常のインストール対象となっているパッケージに対
して <em>dpkgcert</em> 証明書を提供するための実験的なサーバデータベース
が動かされています。

<!--O
In their most simple form, the commands <bf>rpm -i packagename.rpm</bf>
and <bf>dpkg -/-install packagename.deb</bf> automatically unpack and
install the software.  Exercise caution, though, since using these
commands blindly may be dangerous to your system's health!
-->
最も単純な形では、<bf>rpm -i &lsqb;ファイル名&rsqb;</bf> や
<bf>dpkg --install &lsqb;ファイル名&rsqb;</bf> コマンドでソフトウェア
の展開とインストールが自動的に行われます。しかし注意してください。
これらのコマンドをむやみに使うと、システムが不安定になる恐れがあります!

<!--O
Note that the above warnings also apply, though to a lesser extent,
to Slackware's <em>pkgtool</em> installation utility. All "automatic"
software installations require caution.
-->
ここで注意ですが、上記の警告は (被害の範囲こそ少ないものの) Slackware の 
インストールユーティリティである <em>pkgtool</em> にも当てはまります。
ソフトウェアの「自動的な」インストールはどんなものであっても注意が必要
です。

<!--O
The <url
url="http://www.people.cornell.edu/pages/rc42/program/martian.html"
name="martian"> and <url url="http://kitenet.net/programs/alien/"
name ="alien"> programs allow conversion between the <em>rpm</em>,
<em>deb</em>, Stampede <em>slp</em>, and <em>tar.gz</em> package
formats. This makes these packages accessible to all Linux distributions.
-->
<url url="http://www.people.cornell.edu/pages/rc42/program/martian.html" name="martian">
プログラムと <url url="http://kitenet.net/programs/alien/" name ="alien"> 
プログラムを使うと、<em>rpm</em>, <em>deb</em>, Stampede の 
<em>slp</em>, <em>tar.gz</em> 形式の各ファイルを互いに変換できます。
これにより、これらのパッケージがどの Linux ディストリビューションでも
使えるようになります。

<!--O
Carefully read the man pages for the <em>rpm</em>
and <em>dpkg</em> commands, and refer to the <htmlurl
url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/RPM-HOWTO" name="RPM
HOWTO">, TFUG's <url url="http://www.tfug.org/helpdesk/linux/rpm.html"
name="Quick Guide to Red Hat's Package Manager">, and <url
url="http://www.debian.org/doc/FAQ/debian-faq-7.html" name="The Debian
Package Management Tools"> for more detailed information.
-->
<em>rpm</em> コマンドや <em>dpkg</em> コマンドの man ページはじっくり
読んでください。また、詳しい情報については
<htmlurl
url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/RPM-HOWTO" name="RPM
HOWTO"> や TFUG の <url url="http://www.tfug.org/helpdesk/linux/rpm.html"
name="Quick Guide to Red Hat's Package Manager">、
<url url="http://www.debian.org/doc/FAQ/debian-faq-7.html" name="The Debian
Package Management Tools"> を見てください。


<!--O
<sect1>Problems with rpms: an example
-->
<sect1>RPM で起こる問題の例
<p>

<!--O
<url url="mailto:hubicka@paru.cas.cz" name="Jan Hubicka"> wrote
a very nice fractal package called <em>xaos</em>.  At his <url
url="http://www.paru.cas.cz/~hubicka/XaoS" name="home page">, both
<tt>.tar.gz</tt> and <tt>rpm</tt> packages are available.  For the sake
of convenience, let us try the rpm version, rather than the "tarball".
-->
<url url="mailto:hubicka@paru.cas.cz" name="Jan Hubicka"> は、
<em>xaos</em> というとっても良い感じのフラクタル表示パッケージを作って
います。彼の
<url url="http://www.paru.cas.cz/~hubicka/XaoS" name="ホームページ">
には、<tt>.tar.gz</tt> 形式と <tt>rpm</tt> 形式のパッケージが両方あり
ます。ここは便利さをとって、"tarball" ではなく rpm 版を試しましょう。

<!--O
Unfortunately, the rpm of <em>xaos</em> fails to install. Two separate
rpm versions misbehave.
-->
残念なことに、<em>xaos</em> の rpm パッケージはインストールできません。
おかしな動作をするバージョンは 2 つあります。

<bf>rpm -i --test XaoS-3.0-1.i386.rpm</bf>
<tscreen><verb>
error: failed dependencies:
        libslang.so.0 is needed by XaoS-3.0-1
        libpng.so.0 is needed by XaoS-3.0-1
        libaa.so.1 is needed by XaoS-3.0-1
</verb></tscreen>

<bf>rpm -i --test xaos-3.0-8.i386.rpm</bf>
<tscreen><verb>
error: failed dependencies:
        libaa.so.1 is needed by xaos-3.0-8
</verb></tscreen>

<!--O
The strange thing is that <tt>libslang.so.0</tt>, <tt>libpng.so.0</tt>,
and <tt>libaa.so.1</tt> are all present in <tt>/usr/lib</tt> on the
system tested. The rpms of <em>xaos</em> must have been built with
slightly different versions of those libraries, even if the release
numbers are identical.
-->
ここでおかしいのは、<tt>libslang.so.0</tt>, <tt>libpng.so.0</tt>,
<tt>libaa.so.1</tt> は全部、テストを行ったマシンの <tt>/usr/lib</tt>
にあることです。ライブラリのリリース番号は同じであっても、
<em>xaos</em> はちょっとバージョンが違うライブラリを使っているに違いあ
りません。

<!--O
As a test, let us try installing <tt>xaos-3.0-8.i386.rpm</tt> with the
<em>-/-nodeps</em> option to force the install. A trial run of <em>xaos</em>
crashes.
-->
テストとして、<em>--nodeps</em> オプションを使って
<tt>xaos-3.0-8.i386.rpm</tt> を強制的にインストールし
てみましょう。ところが、試しに <em>xaos</em> を実行してもクラッシュし
てしまいます。
<tscreen><verb>
xaos: error in loading shared libraries: xaos: undefined symbol: __fabsl
</verb></tscreen>

<!--O
Let us stubbornly try to get to the bottom of this.  Running <em>ldd</em>
on the <em>xaos</em> binary to find its library dependencies shows
all the necessary shared libraries present. Running <em>nm</em> on the
<tt>/usr/lib/libaa.so.1</tt> library to list its symbolic references
shows that it is indeed missing <em>__fabsl</em>.  Of course, the absent
reference <em>could</em> be missing from one of the other libraries...
There is nothing to be done about that, short of replacing one or more
libraries.
-->
ここでくじけないで真相を追求してみましょう。<em>xaos</em> のバイナリ
に対して <em>ldd</em> を実行してライブラリの依存関係を調べると、必要な
全ての共有ライブラリが表示されます。<tt>/usr/lib/libaa.so.1</tt> 
ライブラリに対して <em>nm</em> を実行してシンボル参照を表示させると、
本当に <em>__fabsl</em> がないことが分かります。もちろん、足りない参照
が他のライブラリのどれかから抜けている<em>可能性</em>はあります…。
この問題、つまりライブラリの入れ換えにより足りないものが出てくることに
ついては、対処の方法はありません。

<!--O
Enough! Download the "tarball", <tt>XaoS-3.0.tar.gz</tt>, available from
the <url url="ftp://ftp.ta.jcu.cz/pub/linux/hubicka/XaoS/3.0" name="ftp
site">, as well as from the home page.  Try building it. Running
<bf>./configure</bf>, <bf>make</bf>, and finally (as root) <bf>make
install</bf>, works flawlessly.
-->
でも大丈夫! "tarball" の <tt>XaoS-3.0.tar.gz</tt> を
<url url="ftp://ftp.ta.jcu.cz/pub/linux/hubicka/XaoS/3.0" name="FTP サイト">
から入手しましょう。ホームページからも入手できます。これを構築してみま
しょう。<bf>./configure</bf>, <bf>make</bf> を実行し、最後に(root になっ
て) <bf>make install</bf> を実行すれば問題なくインストールできます。

<!--O
This is one of an number of examples of prepackaged binaries being more
trouble than they are worth.
-->
これはパッケージ済みのバイナリで起こる、便利というよりも問題が先に立つ
ようなたくさんの例のうちのひとつです。


<!--O
<sect>Termcap and Terminfo Issues
-->
<sect>Termcap と Terminfo の問題
<p>


<!--O
According to its man page, <em>"terminfo is a data base describing
terminals, used by screen-oriented programs..."</em>.  It defines a
generic set of control sequences (escape codes) used to display text on
terminals, and makes possible support for different terminal hardware
without the need for special drivers. The <em>terminfo</em> libraries
are located in <tt>/usr/share/terminfo</tt> on modern Linux distributions.
-->
man ページには<em>「terminfo は画面指向のプログラムが使う、端末
を記述するデータベースで…」</em> とあります。terminfo は端末にテキスト
を表示するために使う制御シーケンス(エスケープコード)の一般的な集合を
定義し、特殊なドライバを使う必要なしにさまざまな端末ハードウェアに対応
できるようにします。最近のほとんどの Linux ディストリビューションでは、
<em>terminfo</em> ライブラリは <tt>/usr/share/terminfo</tt> にあります。

<!--O
The <em>terminfo</em> database has largely supplanted the older
<em>termcap</em> and the totally obsolete <em>termlib</em> ones. This
is usually of no concern for program installation except when dealing
with a package that requires <em>termcap</em>.
-->
<em>terminfo</em> は比較的古めの <em>termcap</em> にほとんどとって代わ
り、<em>termlib</em> を完全に過去のものにしました。
<em>termcap</em> を必要とするパッケージを扱う時を除いて、普通は
プログラムのインストールをする際に端末ライブラリに気を使う必要はありま
せん。

<!--O
Most Linux distributions now use <em>terminfo</em>, but still retain the
older termcap libraries for compatibility with legacy applications (see
<tt>/etc/termcap</tt>). Sometimes there is a special compatibility package
that needs to be installed to facilitate use of termcap linked binaries.
Very occasionally, an <em>#define termcap</em> statement might need to
be commented out of a source file.  Check the appropriate doc files for
your particular distribution for definitive information on this.
-->
ほとんどの Linux のディストリビューションは現在 <em>terminfo</em> を使
用しています。しかし、昔ながらのアプリケーションとの互換性のために
いまだに古い termcap が残っています(<tt>/etc/termcap</tt> を参照)。
場合によっては、termcap をリンクしたバイナリを楽に使うためにインストール
する必要がある互換性維持のための特別なパッケージがあります。
よくあるケースとして、ソースファイルの <em>#define termcap</em> という行を
コメントアウトする必要がある場合があります。こういった事情の確かな情報
については、お使いのディストリビューションの関連ドキュメントを調べてく
ださい。


<!--O
<sect>Backward Compatibility With a.out Binaries
-->
<sect>a.out 形式のバイナリの後方互換性
<p>

<!--O
In a very few cases, it is necessary to use a.out binaries, either because
the source code is not available or because it is not possible to build
new ELF binaries from the source for some reason.
-->
まれにしかないことなのですが、ソースコードが入手できなかったり、さまざ
まな要因でソースコードから ELF バイナリが作れないといった理由で a.out 
バイナリを使う必要に迫られることがあります。

<!--O
As it happens, ELF installations almost always have a complete set
of a.out libraries in the <tt>/usr/i486-linuxaout/lib</tt> directory.
The numbering scheme for a.out libraries differs from that of ELF ones,
cleverly avoiding conflicts that could cause confusion.  The a.out
binaries should therefore be able to find the correct libraries at
runtime, but this might not always be the case.
-->
こういうことも起こるので、ELF で組んであるシステムでも大抵は a.out の
ライブラリを全部用意しています。これは
<tt>/usr/i486-linuxaout/lib</tt> ディレクトリに置かれます。
a.out ライブラリの番号付けの規則は ELF の場合の規則と違うので、問題を
起こしかねないような衝突はうまく避けられます。したがって、a.out バイナ
リは実行時に正しいライブラリを見つけられるのですが、これが常に正しいわ
けでもありません。

<!--O
Note that the kernel needs to have a.out support built into it, either
directly or as a loadable module. It may be necessary to rebuild the
kernel to enable this. Moreover, some Linux distributions require
installation of a special compatibility package, such as Debian's
<tt>xcompat</tt> for executing a.out X applications.
-->
カーネルには a.out のサポートを組み込む必要があるので注意してください。
これは直接組み込んでもかまいませんし、ローダブルモジュールにしてもかま
いません。これを有効にするにはカーネルを再構築する必要があるかもしれま
せん。さらに、Linux ディストリビューションによっては互換性保持のための
特殊なライブラリをインストールする必要があります。例えば、Debian には
a.out の X アプリケーションを実行するための <tt>xcompat</tt>  がありま
す。


<!--O
<sect1>An Example
-->
<sect1>事例
<p>

<!--O
Jerry Smith wrote a very handy <em>rolodex</em> program some years
back. It uses the Motif libraries, but fortunately is available
as a statically linked binary in a.out format. Unfortunately, the
source requires numerous tweaks to rebuild using the <em>lesstif</em>
libraries. Even more unfortunately, the a.out binary bombs on an ELF
system with the following error message.
-->
何年か前に Jerry Smith がとても便利な <em>rolodex</em> というプログラム
を書きました。このプログラムは Motif ライブラリ(訳注: フリーで手に入ら
ない)を使っていますが、好運なことに a.out のライブラリを静的リンクして
あるバイナリが入手できます。残念なことに、<em>lesstif</em> ライブラリ
を使ってソースを再構築するには大幅に手を入れる必要があります。さらに残
念なことに、ELF システム上では a.out のバイナリは次のようなエラーメッ
セージを出力してふっ飛んでしまいます。
<tscreen><verb>
xrolodex: can't load library '//lib/libX11.so.3'
No such library
</verb></tscreen>

<!--O
As it happens, there is such a library, in
<tt>/usr/i486-linuxaout/lib</tt>, but xrolodex is unable to locate it
at run time. The simple solution is to provide a symbolic link in the
<tt>/lib</tt> directory:
-->
このようなことがあるために、この手のライブラリが <tt>/usr/i486-linuxaout/lib</tt>
に置かれているのですが、xrolodex は実行時にライブラリの位置を見つける
ことができません。単純な解決法はシンボリックリンクを <tt>/lib</tt>
ディレクトリに作ることです。

<tt>ln -s /usr/i486-linuxaout/lib/X11.so.3.1.0 libX11.so.3</tt>

<!--O
It turns out to be necessary to provide similar links for the libXt.so.3
and libc.so.4 libraries. This needs to be done as root, of course. Note
that you should make absolutely certain you will not overwrite or cause
version number conflicts with pre-existing libraries.  Fortunately, the
new ELF libraries have higher version numbers than the older a.out ones,
to anticipate and forestall just such problems.
-->
同様のリンクを libXt.so.3 と libc.so.4 ライブラリについて作る必要が
あることもわかります。この作業はもちろん root で行う必要があります。
ここで注意ですが、既に入っているライブラリを上書きしたり、バージョン番
号の衝突が絶対に起こらないように確かめてください。幸い、こういった問題
が起こらないようにするため、新しい ELF ライブラリのバージョン番号は古
い a.out ライブラリよりも大きくされています。

<!--O
After creating the three links, <em>xrolodex</em> runs fine.
-->
上記 3 つのリンクを張れば、<em>xrolodex</em> はうまく動きます。

<!--O
The <em>xrolodex</em> package was originally posted on <url
url="http://www.spectro.com/" name="Spectro">, but seems to
vanished from there. It may currently be downloaded from <url
url="http://metalab.unc.edu/pub/Linux/apps/reminder/xrolodex.tar.z"
name="Sunsite"> as a <em>tar.Z</em> format source file [512k].
-->
<em>xrolodex</em> パッケージは元々
<url url="http://www.spectro.com/" name="Spectro"> に投稿されていまし
たが、今はここから消えてしまったようです。現在は
<url url="http://metalab.unc.edu/pub/Linux/apps/reminder/xrolodex.tar.z" name="Sunsite">
から <em>tar.Z</em> 形式で入手できます(サイズは 512K バイトです)。

<!--O
<sect>Troubleshooting
-->
<sect>トラブルシューティング
<p>

<!--O
If <em>xmkmf</em> and/or <em>make</em> succeeded without errors,
you may proceed to the <ref id="finalsteps" name="next section">.
However, in "real life", few things work right the first time.
This is when your resourcefulness is put to the test.
-->
<em>xmkmf</em> や <em>make</em> がエラーを出さずに正常終了したら、
<ref id="finalsteps" name="次の節">に進んでください。
しかし「実際」には一発でうまく行くことはほとんどありません。
ここで、あなたの知恵が問われるのです。

<!--O
<sect1>Link Errors
-->
<sect1>リンクエラー
<p>
<itemize>
<!--O
<item>Suppose <em>make</em> fails with a <tt>Link error: -lX11: No such
file or directory</tt>, even after xmkmf has been invoked. This may mean
that the <em>Imake</em> file was not set up properly. Check the first
part of the <em>Makefile</em> for lines such as:
-->
<item>xmkmf を実行していたのに
<tt>Link error: -lX11: No such file or directory</tt> というエラーで 
<em>make</em> が失敗する場合。これは <em>Imakefile</em> が適切に設定さ
れていないということかもしれません。
<em>Makefile</em> の最初あたりで以下のような行を確認してください:

<tscreen><verb>
LIB=            -L/usr/X11/lib
INCLUDE=        -I/usr/X11/include/X11
LIBS=           -lX11 -lc -lm
</verb></tscreen>

<!--O
The <tt>-L</tt> and <tt>-I</tt> switches tell the compiler and linker
where to look for the <em>library</em> and <em>include</em> files,
respectively. In this example, the <em>X11 libraries</em> should be in
the <tt>/usr/X11/lib</tt> directory, and the <em>X11 include files</em>
should be in the <tt>/usr/X11/include/X11</tt> directory. If this is
incorrect for your machine, make the necessary changes to the
<em>Makefile</em> and try the <em>make</em> again.
-->
<tt>-L</tt> オプションは<em>ライブラリ</em>を探す場所をリンカに対して
指定し、<tt>-I</tt> オプションは<em>インクルードファイル</em>を探す場
所をコンパイラに対して指定します。この例の場合、<em> X11のライブラリ</em>
は <tt>/usr/X11/lib</tt> ディレクトリにあり、 <em>X11 のインクルードファイル</em>は 
<tt>/usr/X11/include/X11</tt> ディレクトリでなければなりません。もし、
これがあなたのマシンのディレクトリ構成と違っていたら、
<em>Makefile</em> に適当な変更を加えてから、もう一度 <em>make</em> を
実行してください。

</itemize>

<itemize>

<!--O
<item>Undefined references to math library functions, such as the following:
-->
<item>下のように計算のライブラリで関数の参照先が定義されていないという
エラーが出る場合:
<tscreen><verb>
         /tmp/cca011551.o(.text+0x11): undefined reference to `cos'
</verb></tscreen>
<!--O
The fix for this is to explicitly link in the <tt>math library</tt>,
by adding an <bf>-lm</bf> to the <em>LIB</em> or <em>LIBS</em> flags in
the <tt>Makefile</tt> (see previous example).
-->
この問題を解決するには、<em>Makefile</em> の <em>LIB</em> と 
<em>LIBS</em> に <bf>-lm</bf> を加えて、明示的に<tt>計算ライブラリ</tt>
にリンクさせてください(前の例を参照してください)。

</itemize>



<itemize>

<!--O
<item>Yet another thing to try if <em>xmkmf</em> fails is the following script:
-->
<item>xmkmf が失敗するときには、下記のスクリプト
を実行してみるのもいいでしょう。
<tscreen><verb>
         make -DUseInstalled -I/usr/X386/lib/X11/config
</verb></tscreen>
<!--O
This is a sort of bare bones equivalent of <em>xmkmf</em>.
-->
これは、機能をそぎ落として骨と皮だけにした <em>xmkmf</em> と同じ働きを
します。

</itemize>

<itemize>

<!--O
<item>In a very few cases, running <em>ldconfig</em> as <em>root</em>
may be the solution:
-->
<item>ごく稀にですが、<em>root</em> になって <em>ldconfig</em> を実行
すると問題が解決することがあります:
<tscreen><verb>
</verb></tscreen>

<!--O
<bf># ldconfig</bf> updates the shared library symbolic links. <em>This
may not be necessary .</em>
-->
<bf># ldconfig</bf> を実行すると、共有ライブラリへのシンボリックリンク
が張り直されます。<em>これは必要でないかもしれません。</em>

</itemize>

<itemize>

<!--O
<item>Some <tt>Makefiles</tt> use unrecognized aliases for libraries
present in your system. For example, the build may require
<tt>libX11.so.6</tt>, but there exists no such file or link in
<tt>/usr/X11R6/lib</tt>. Yet, there is a <tt>libX11.so.6.1</tt>. The
solution is to do a <bf>ln -s /usr/X11R6/lib/libX11.so.6.1
/usr/X11R6/lib/libX11.so.6</bf>, as root. This may need to be followed
by a <bf>ldconfig</bf>.
-->
<item><tt>Makefiles</tt> によっては、あなたのシステムにあるライブラリ
を、識別できないエイリアスで使っていることがあります。例えば、構築に
<tt>libX11.so.6</tt> が必要なのに、<tt>/usr/X11R6/lib</tt> にはそのような
ファイルやリンクが存在しない場合です。しかし <tt>libX11.so.6.1</tt>
はあるとします。この場合の解決方法は、
<bf>ln -s /usr/X11R6/lib/libX11.so.6.1 /usr/X11R6/lib/libX11.so.6</bf>
を root になって実行することです。リンクを張った後には
<bf>ldconfig</bf> が必要かもしれません。
</itemize>


<itemize>

<!--O
<item>Sometimes the source needs the older release X11R5 libraries to
build.  If you have the R5 libs in /usr/X11R6/lib (you were given the
option of having them when first installing Linux), then you need only
ensure that you have the links that the software needs to build.  The
<tt>R5 libs</tt> are named <tt>libX11.so.3.1.0</tt>,
<tt>libXaw.so.3.1.0</tt>, and <tt>libXt.so.3.1.0</tt>. You generally
need links, such as <em>libX11.so.3 -> libX11.so.3.1.0</em>. Possibly
the software will also need a link of the form <em>libX11.so ->
libX11.so.3.1.0</em>.  Of course, to create a "missing" link, use the
command <bf>ln -s libX11.so.3.1.0 libX11.so</bf>, <em>as root</em>.
-->
<item>たまに、ソースコードを構築するのに古い X11R5 のライブラリが必要
なことがあります。もし、/usr/X11R6/lib の中に R5 のライブラリがある
(最初に Linux をインストールするときにオプションとしてインストール
するかどうか聞かれます)場合には、ソフトウェアの構築に必要なライブラリ
にリンクを張るだけで大丈夫です。R5 のライブラリの名前は、
<tt>libX11.so.3.1.0</tt>, <tt>libXaw.so.3.1.0</tt>, <tt>libXt.so.3.1.0</tt>
です。通常は、<em>libX11.so.3 -&gt; libX11.so.3.1.0</em> といったリン
クが必要です。このソフトウェアにはさらに
<em>libX11.so -&gt; libX11.so.3.1.0</em> のようなリンクも必要でしょう。
もちろん、「足りない」リンクを作るには、<em>root</em> になって
コマンド <bf>ln -s libX11.so.3.1.0 libX11.so</bf> を使います。
</itemize>


<itemize>

<item>
<!--O
Some packages will require you to install updated versions of one or
more libraries. For example, the 4.x versions of the <em>StarOffice</em>
suite from StarDivision GmbH were notorious for needing a <tt>libc</tt>
version 5.4.4 or greater. Even the more recent <em>StarOffice</em> 5.0
will not run after installation with the new <tt>glibc 2.1</tt> libs.
Fortunately, the newer <em>StarOffice</em> 5.1 solves these problems.
If running an older version of <em>StarOffice</em> you would, as
<em>root</em>, need to copy one or more libraries to the appropriate
directories, remove the old libraries, then reset the symbolic links
(check the latest version of the <tt>StarOffice miniHOWTO</tt> for more
information on this).
-->
パッケージによっては一つまたは複数のライブラリを更新する必要があるでしょ
う。例えば、StarDivision 社の <em>StarOffice</em> というオフィススイート
のバージョン 4.x は、バージョン 5.4.4 以上の <tt>libc</tt> が必要なこ
とで悪評が高かったです。もっと新しい <em>StarOffice</em> 5.0 でさえ、
新しい <tt>glibc 2.1</tt> ライブラリのシステムにインストールすると動作
しません。幸いなことに、さらに新しい <em>StarOffice</em> 5.1 では、こ
ういった問題は解決しています。古いバージョンの <em>StarOffice</em> を
使っているなら、<em>root</em> になって、いくつかのライブラリを適切な
ディレクトリにコピーし、古いライブラリを削除し、それから
シンボリックリンクを再設定する必要があるでしょう(この作業に関する詳し
い情報については、<tt>StarOffice miniHOWTO</tt> の最新版を見てください)。

<!--O
<bf>Caution: Exercise extreme care in this, as you can render your
system nonfunctional if you screw up.</bf>
-->
<bf>注意: もし、失敗するとシステムが動作しなくなってしまうので、この作
業は十分注意して行ってください。</bf>

<!--O
You can usually find the latest updated libraries at <htmlurl
url="ftp://metalab.unc.edu/pub/Linux/libs" name="Sunsite">.
-->
通常、最新のライブラリは
<url url="ftp://metalab.unc.edu/pub/Linux/libs/" name="Sunsite">
で入手できます。

</itemize>

<!--O
<sect1>Other Problems
-->
<sect1>その他の問題
<p>

<itemize>

<!--O
<item>An installed <em>Perl</em> or shell script gives you a <tt>No such
file or directory</tt> error message. In this case, check the file
permissions to make sure the file is executable and check the file
header to ascertain whether the shell or program invoked by the script
is in the place specified.
For example, the scrip may begin with:
-->
<item><em>Perl</em> やシェルスクリプトがインストールされているのに
<tt>No such file or directory</tt> といったエラーメッセージが出る場合。
この場合は、そのファイルが実行可能かどうかパーミッションを確認してくだ
さい。また、スクリプトの最初の行を確認して、スクリプトが呼び出すシェル
やプログラムが正しく指定されているかどうかを確かめてください。
例えば、スクリプトは次のように始まると思います:
<tscreen><verb>
#!/usr/local/bin/perl
</verb></tscreen>
<!--O
If <em>Perl</em> is in fact installed in your <tt>/usr/bin</tt>
directory instead of the <tt>/usr/local/bin</tt> one, then the script
will not run.  There are two methods of correcting this. The
script file header may be changed to <tt>#!/usr/bin/perl</tt>, or
a symbolic link to the correct directory may be added, <bf>ln -s
/usr/bin/perl /usr/local/bin/perl</bf>.
-->
もし <em>Perl</em> が <tt>/usr/local/bin</tt> ではなく 
<tt>/usr/bin</tt> にインストールされていたらスクリプトは動作しないでしょ
う。これを動作させるには 2 つの方法があります。スクリプトファイルの最
初の行を <tt>&num;!/usr/bin/perl</tt> と書き換えるか、
<tt>ln -s /usr/bin/perl /usr/local/bin/perl</tt> を実行して、適切な
ディレクトリへシンボリックリンクを張ってください。

</itemize>

<itemize>

<!--O
<item>Some X11 software requires the Motif libraries to build.
The standard Linux distributions do not have the Motif libraries
installed, and at present Motif costs an extra $100-$200 (though the
freeware <url url="http://www.lesstif.org/" name="Lesstif"> also works
in many cases). If you need Motif to build a certain package, but lack
the Motif libraries, it may be possible to obtain <em>statically linked
binaries</em>. Static linking incorporates the library routines in the
binaries themselves.  This results in much larger binary files, but the
code will run on systems lacking the libraries.
-->
<item>X11 のソフトウェアの中には、構築するのに Motif のライブラリが必
要なものがあります。普通の Linux ディストリビューションには Motif の
ライブラリは入っておらず、現在は Motif を使うには別途 &dollar;100〜&dollar;200 
のお金を出さなければなりません(ただし、フリーウェアの
<url url="http://www.lesstif.org/" name="Lesstif">
でも多くの場合は動作します)。あるパッケージを構築するのに Motif が必要
なのに Motif ライブラリがない場合でも、<em>静的にリンクされたバイナリファイル</em>
が入手できるかもしれません。静的なリンクとはライブラリルーチンを
バイナリ自身の中に組み込んだものです。その結果、バイナリファイルは巨大
になりますが、ライブラリの入っていないシステム上でもバイナリを動かすこ
とができます。

<tscreen><verb>
</verb></tscreen>

<!--O
When a package requires libraries not present on your system for the
build, it will result in link errors (<tt>undefined reference</tt>
errors).  The libraries may be expensive proprietary ones or difficult
to find for sone other reason.  In that case, obtaining a <em>statically
linked</em> binary either from the author of the package or from a Linux
user group may be the easiest to implement fix.
-->
あるパッケージの構築を行うためにシステムに入っていないライブラリが必要
な場合にはリンクエラーが起こります(<tt>undefined reference</tt> エラー)。
ライブラリは高価な上に中身が秘密になっているかもしれませんし、何か別の
理由で見つけるのが困難なこともあります。こういった場合には、
<em>静的にリンクした</em>バイナリをパッケージの作者から入手するか、
Linux のユーザグループから入手するのがもっとも簡単な対処です。
</itemize>


<itemize>
<!--O
Running a <em>configure</em> script creates a strange Makefile, one
seemingly unrelated to the package you are attempting to build. This
means the wrong <em>configure</em> ran, one found somewhere else in your
path. Always invoke <em>configure</em> as <bf>./configure</bf> to
prevent this.
-->
<em>configure</em> を実行するとおかしな Makefile、つまり構築しようとし
ているパッケージに関係がないように見える Makefile ができることがありま
す。これは間違った <em>configure</em>、つまりパス中のどこか別のディレ
クトリにある <em>configure</em> が実行されたということです。こんなこと
にならないように、<em>configure</em> を実行するときは必ず
<bf>./configure</bf> という指定で呼び出してください。
</itemize>


<itemize>
<!--O
Most Linux distributions have changed over to the <tt>libc 6 / glibc
2</tt> libraries from the older <tt>libc 5</tt>. Precompiled binaries
that worked with the older library may bomb if you have upgraded your
library. The solution is to either recompile the applications from the
source or to obtain newer precompiled binaries.  If you are in the process
of upgrading your system to <tt>libc 6</tt> and are experiencing problems,
refer to Eric Green's <em>Glibc 2 HOWTO</em>.
-->
ほとんどの Linux ディストリビューションは、古い <tt>libc 5</tt> 
ライブラリから <tt>libc 6 / glibc 2</tt> ライブラリに移行しました。
古いライブラリで動いていたコンパイル済みバイナリは、ライブラリを
アップグレードすると動かなくなるかもしれません。この問題に対処するには、
アプリケーションをソースからコンパイルしなおすか、新しいライブラリに
対応したコンパイル済みバイナリを入手してください。システムを
<tt>libc 6</tt> にアップグレードしようとしていて問題に遭ったなら
Eric Green の <em>Glibc 2 HOWTO</em> を見るとよいでしょう。

<tscreen><verb>
</verb></tscreen>

<!--O
Note that there are some minor incompatibilities between <tt>glibc</tt>
versions, so a binary built with <tt>glibc 2.1</tt> may not work with
<tt>glibc 2.0</tt>, and vice versa.
-->
<tt>glibc</tt> にはバージョン間の互換性のない部分が少しあるので、
<tt>glibc 2.1</tt> で作ったバイナリは <tt>glibc 2.0</tt> では動かない
かもしれませんし、その逆も起こるかもしれません。

</itemize>

<itemize>
<!--O
Sometimes it is necessary to remove the <em>-ansi</em> option from the
compile flags in the <tt>Makefile</tt>. This enables gcc's extra, non-ANSI features,
and allows building packages that require these extensions. (Thanks to Sebastien
Blondeel for pointing this out.)
-->
<tt>Makefile</tt> のコンパイルオプションから <em>-ansi</em> オプション
を外さなければならないことが時々あります。これを行うと、gcc の
非 ANSI 拡張機能が使えるようになり、その拡張機能を必要とするパッケージ
を構築できるようになります。(この点について指摘してくれた 
Sebastien Blondeel に感謝します。)

</itemize>

<itemize>

<!--O
<item>Some programs require having <em>setuid root</em>, in order to run
with <em>root privileges</em>. The command to implement this is
<bf>chmod u+s filename</bf>, <em>as root</em> (note that the program
must already be owned by root). This has the effect of setting
the <em>setuid</em> bit in the file permissions.  This issue comes up
when the program accesses the system hardware, such as a modem or CD ROM
drive, or when the SVGA libs are invoked from console mode, as in one
particularly notorious emulation package. If a program works when run by
root, but gives <em>access denied</em> error messages to an ordinary
user, suspect this as the cause.
-->
<item>プログラムによっては <em>root 権限</em>で動作させるために 
<em>setuid root</em> する必要があります。この設定を行うには <em>root になって</em>
から <bf>chmod u+s &lsqb;ファイル名&rsqb;</bf> を実行します。(プログラム
の所有者はあらかじめ root にしておかなければならないので注意してくださ
い。)こうすることで、ファイルのパーミッションの <em>setuid</em> ビット
が立ちます。<em>setuid root </em>しなければならないという問題は、
プログラムがモデムや CD-ROM ドライブのようなシステムのハードウェアに
アクセスするときや、とある有名エミュレータのように SVGAlib(SVGA操作
ライブラリ)をコンソールモードから呼び出すときに起こります。
root ならプログラムが動作するけれど一般ユーザだと
<em>access denied</em> エラーが起こる場合には、この問題を疑いましょう。

<P>

<!--O
<bf>Warning:</bf>
-->
<!--O
A program with <em>setuid</em> as root may pose a security risk to your
system. The program runs with root privileges and thus has the potential
for doing significant damage. Make certain that you know what the
program does, by looking at the source if possible, before setting the
<em>setuid</em> bit.
-->
警告: root に <em>setuid</em> したプログラムはシステムのセキュリティ上
の危険を伴います。root に <em>setuid</em> したプログラムは root 権限で
動作するので、致命的な被害を与える可能性があります。setuid ビットを立
てる前には、可能であればソースコードを読んでて、プログラムが何をするの
かを確かめてください。

</itemize>


<!--O
<sect1>Tweaking and fine tuning
-->
<sect1>改善と最適化
<p>

<!--O
You may wish to examine the <tt>Makefile</tt> to make certain that
the best compilation options for your system are invoked. For example,
setting the <em>-O2</em> flag chooses the highest level of optimization
and the <em>-fomit-frame-pointer</em> flag results in a smaller binary
(though debugging will then be disabled). <bf>Do not play around with
this unless you know what you are doing, and in any case, not until
after a trial <em>build</em> works.</bf>
-->
<em>Makefile</em> を調べて、あなたのシステムに最適なオプションが設定さ
れているかどうかを確かめるといいでしょう。例えば、<em>-O2</em> オプション
は最高レベルの最適化を行い、<em>-fomit-frame-pointer</em> オプションは
小さいバイナリを作成します(ただし、デバッグはできなくなります)。
<bf>自分が何をやっているか分からない場合や、どんな場合であれうまく
<em>構築</em>できることが確かめられる前にはこれらのオプションをいじら
ないようにしてください。</bf>

<!--O
<sect1>Where to go for more help
-->
<sect1>さらなる情報の入手先
<p>

<!--O
In my experience, perhaps 25% of applications build "right out
of the box". Another 50% or so can be "persuaded" to build with
an effort ranging from trivial to herculean. That still means a
significant number of packages will not build no matter what. Even
then, the Intel <tt>ELF</tt> and/or <tt>a.out</tt> binaries for
these might possibly be found at <htmlurl url="ftp://metalab.unc.edu"
name="Sunsite"> or the <htmlurl url="ftp://tsx-11.mit.edu" name = "TSX-11
archive">.  <url url="http://redhat.com" name="Red Hat"> and <url
url="http://www.debian.org" name="Debian"> have extensive archives of
prepackaged binaries of most of the popular Linux software.  Perhaps
the author of the software can supply the binaries compiled for your
particular flavor of machine.
-->
私の経験によると、アプリケーションの 25% くらいは「何もしなくても」
うまく構築できます。50% かそこらは、ちょっとしたことから大変な苦労まで
の違いはありますが「何とか」構築できます。ということは、頑張っても
インストールできないようなパッケージがかなりあるということです。
それでももしかすると
<htmlurl url="ftp://metalab.unc.edu" name="Sunsite">
や
<htmlurl url="ftp://tsx-11.mit.edu" name = "TSX-11 アーカイブ">
で <tt>ELF</tt> や <tt>a.out</tt> のバイナリが見つかるかもしれません。
<url url="http://redhat.com" name="Red Hat"> や
<url url="http://www.debian.org" name="Debian">
には、Linux でよく使われるソフトウェアのパッケージ化済みのバイナリを大
量にアーカイブしています。もしかすると、ソフトウェアの作者がちょうどあ
なたのマシンで使えるようなコンパイル済みのバイナリを用意しているかもし
れません。

<!--O
<tt>Note that if you obtain precompiled binaries, you will need to check
for compatibility with your system:</tt>
-->
<tt>コンパイル済みのバイナリを入手したら、お使いのシステムとの互換性を
確認する必要がある点に注意してください:</tt>
<itemize>
<!--O
<item><tt>The binaries must run on your hardware (i.e., Intel
x86).</tt>
-->
<item><tt>バイナリがあなたのハードウェア(例えば Intel x86 系マシン)で
動作するか。</tt>
<!--
fujiwara: "i.e." だから、ほんとは「例えば」じゃいけないんだろうけど。
nakano: まあいいんじゃないすか.
-->
<!--O
<item><tt>The binaries must be compatible with your kernel (i.e., a.out or
ELF).</tt>
-->
<item><tt>バイナリはお使いのカーネルとの互換性があるか(つまり a.out 
形式なのか ELF 形式なのか)。</tt>
<!--O
<item><tt>Your libraries must be up to date.</tt>
-->
<item><tt>最新のライブラリを必要とするかどうか。</tt>
<!--O
<item><tt>Your system must have the appropriate installation utility (rpm or
deb)</tt>.
-->
<item><tt>(rpm や deb)のような適切なユーティリティが必要かどうか。</tt>
</itemize>

<!--O
If all else fails, you may find help in the appropriate
newsgroups, such as <htmlurl url="news://comp.os.linux.x"
name="comp.os.linux.x"> or <htmlurl url="news://comp.os.linux.development"
name="comp.os.linux.development">.
-->
これ以外の原因でだめだったら、 
<htmlurl url="news://comp.os.linux.x" name="comp.os.linux.x">
や
<htmlurl url="news://comp.os.linux.development" name="comp.os.linux.development">
といったニュースグループで助けてもらえるかもしれません。

&lsqb;訳注:
日本語のニュースグループなら fj.os.linux、jlug.ml.users があります。
しかし、これらのニュースグループで答えてくれる人は皆自分の空いた時間を
使ってボランティアで答えてくれています。決してメーカーのサポートでは
ないので、失礼な態度を取らないようにしてください。また、質問するときには、
わかりやすく、具体的に質問しましょう。また、問題が解決したなら、解決した
ことの報告、解決の要因を忘れずに報告しましょう。&rsqb;

<!--O
If nothing at all works, at least you gave it your best effort, and you
learned a lot.
-->
それでもダメだとしても、少なくとも最善を尽くし、たくさんのことを学んだ
のだから、それはそれでいいのではないでしょうか。


<!--O
<sect>Final Steps<label id="finalsteps">
-->
<sect>最後の仕上げ
<p>
<!--O
Read the software package documentation to determine whether certain
environmental variables need setting (in <tt>.bashrc</tt>
or <tt>.cshrc</tt>) and
if the <tt>.Xdefaults</tt> and <tt>.Xresources</tt> files need customizing.
-->
パッケージのドキュメントを読んで、(<tt>.bashrc</tt> や <tt>.cshrc</tt>
で)環境変数の設定が必要かどうか、あるいは <tt>.Xdefaults</tt> や
<tt>.Xresources</tt> のカスタマイズが必要かどうかを確認してください。

<!--O
There may be an applications default file, usually named <tt>Xfoo.ad</tt>
in the original Xfoo distribution. If so, edit the Xfoo.ad file to
customize it for your machine, then rename (<bf>mv</bf>) it Xfoo
and install it in the <tt>/usr/lib/X11/app-defaults</tt> directory,
<em>as root</em>.  Failure to do this may cause the software to behave
strangely or even refuse to run.
-->
アプリケーションのパッケージにはデフォルトの設定ファイルがついているこ
とがあります。普通、パッケージの名前が <tt>Xfoo</tt> なら、
<tt>Xfoo.ad</tt> という名前になっています。もし設定ファイルがあれば、
<tt>Xfoo.ad</tt> をマシンに合わせてカスタマイズしてから、(<bf>mv</bf>
を使って)名前を <tt>Xfoo</tt> に変え、<tt>/usr/lib/X11/app-defaults</tt>
ディレクトリにインストールしてください。インストールは
<em>root になって</em>やってください。この作業に失敗すると、
ソフトウェアの挙動がおかしくなったり、最悪、動作さえしなくなることがあ
ります。

<!--O
Most software packages come with one or more preformatted man
pages.  <em>As root</em>, copy the Xfoo.man file to the appropriate
<tt>/usr/man</tt>, <tt>/usr/local/man</tt>, or <tt>/usr/X11R6/man</tt>
directory (<tt>man1</tt> - <tt>man9</tt>), and rename it accordingly.
For example, if Xfoo.man ends up in /usr/man/man4, it should be
renamed Xfoo.4 (mv Xfoo.man Xfoo.4).  By convention, user commands go
in <tt>man1</tt>, games in <tt>man6</tt>, and administration packages in
<tt>man8</tt> (see the <em>man docs</em> for more details).  Of course,
you may deviate from this on your own system, if you like.
-->
ほとんどのソフトウェアには、整形済みの man ページが付属しています。
<em>root になって</em> Xfoo.man というファイルを <tt>/usr/man</tt> や
<tt>/usr/local/man</tt> や <tt>/usr/X11R6/man</tt> の適切なディレクトリ
(<tt>man1</tt> - <tt>man9</tt>)にコピーして、適切な名前に変えてくださ
い。例えば Xfoo.man を /usr/man/man4 に置く場合、(mv Xfoo.man Xfoo.4
を実行して) Xfoo.4 という名前に変えてください。リネームしてください。
慣例では、ユーザコマンドは <tt>man1</tt> に、ゲームは <tt>man6</tt> に、
システム管理のコマンドは <tt>man8</tt> に入れることになっています(詳し
くは <em>man docs</em> コマンドを実行してください)。もちろん、そうした
ければ、この慣習を守らなくてもかまいません。
<!--nakano: man docs なんてある？ -->
<!--fujiwara: ここは man [1-9] intro かなあ… -->

<!--O
A few packages will not install the binaries in the appropriate system
directories, that is, they are missing the <em>install</em> option in the
<tt>Makefile</tt>. Should this be the case, you can install the binaries
manually by copying the binaries to the appropriate system directory,
<tt>/usr/bin</tt>, <tt>/usr/local/bin</tt> or <tt>/usr/X11R6/bin</tt>,
<em>as root</em>, of course. Note that <tt>/usr/local/bin</tt> is
the preferred directory for binaries that are not part of the Linux
distribution's base install.
-->
パッケージによっては、適切なシステムディレクトリにバイナリファイルを
インストールしてくれないものがあります。つまり、<tt>Makefile</tt> の
<em>install</em> オプションの設定がないのです。このような場合は、
バイナリを手動で適切なシステムディレクトリ(<tt>/usr/bin</tt>,
<tt>/usr/local/bin</tt>, <tt>/usr/X11R6/bin</tt>)にコピーして
インストールしてください。もちろん作業は<em>root になって</em>行います。
Linux ディストリビューションの基本コマンドでないようなバイナリは、
<tt>/usr/local/bin</tt> ディレクトリに入れるのが好ましいことも覚えてお
いてください。

<!--O
Some or all of the above procedures should, in most cases, be handled
automatically by a <bf>make install</bf>, and possibly a <bf>make
install.man</bf> or <bf>make install_man</bf>. If so, the <tt>README</tt>
or <tt>INSTALL</tt> doc file will specify this.
-->
大抵の場合、上記の一部あるいは全ての手順は <bf>make install</bf>
や <bf>make install.man</bf>, <bf>make install_man</bf> 等で自動的に
処理されます。そうなっているのであれば、<tt>README</tt> や
<tt>INSTALL</tt> といったドキュメントファイルに明記されているはずです。

<!--O
<sect>First Example: Xscrabble
-->
<sect>最初の例: Xscrabble
<p>
<!--O
Matt Chapman's <tt>Xscrabble</tt> seemed like a program that would be
interesting to have, since I happen to be an avid Scrabble<tt>TM</tt>
player. I downloaded it, uncompressed it,  and built it following the
procedure in the README file:
-->
私は Scrabble<tt>TM</tt> にハマっているので、Matt Chapman の 
<tt>Xscrabble</tt> がとても面白そうなプログラムに思えました。私は、こ
れをダウンロードして、展開した後、README ファイルに書かれている手順に
沿って構築しました。
<tscreen><verb>
     xmkmf
     make Makefiles
     make includes
     make
</verb></tscreen>

<!--O
<em>Of course it did not work...</em>
-->
<em>もちろん動作しませんでした…。</em>

<tscreen><verb>
gcc -o xscrab -O2 -O -L/usr/X11R6/lib 
init.o xinit.o misc.o moves.o cmove.o main.o xutils.o mess.o popup.o
widgets.o display.o user.o CircPerc.o
-lXaw -lXmu -lXExExt -lXext -lX11 -lXt -lSM -lICE -lXExExt -lXext -lX11
-lXpm -L../Xc -lXc

BarGraf.o(.text+0xe7): undefined reference to `XtAddConverter'
BarGraf.o(.text+0x29a): undefined reference to `XSetClipMask'
BarGraf.o(.text+0x2ff): undefined reference to `XSetClipRectangles'
BarGraf.o(.text+0x375): undefined reference to `XDrawString'
BarGraf.o(.text+0x3e7): undefined reference to `XDrawLine'
etc.
etc.
etc...
</verb></tscreen>

<!--O
I enquired about this in the <htmlurl url="news://comp.os.linux.x"
name="comp.os.linux.x"> newsgroup, and someone kindly pointed out that
apparently the Xt, Xaw, Xmu, and X11 libs were not being found at the
link stage. Hmmm...
-->
私は、この問題についてニュースグループの
<htmlurl url="news://comp.os.linux.x" name="comp.os.linux.x">
で尋ねてみました。すると、どうもリンクの段階で Xt, Xaw, Xmu, X11 の
ライブラリが見つけられていないようだと親切な方が指摘してくれました。
うーむ…。

<!--O
There were two main Makefiles, and the one in the <tt>src</tt> directory
caught my interest. One line in the Makefile defined LOCAL_LIBS as:
LOCAL_LIBS = $(XAWLIB) $(XMULIB) $(XTOOLLIB) $(XLIB) Here were
references to the libs not being found by the linker.
-->
Makefile は 2 つありますが、私は <tt>src</tt> ディレクトリにある方の 
Makefile に注目しました。Makefile の中で
「LOCAL_LIBS = $(XAWLIB) $(XMULIB) $(XTOOLLIB) $(XLIB)」
のように LOCAL_LIBS を定義している部分がありました。これらは、
はリンカが見つけられ損ねているライブラリを参照しています。

<!--O
Looking for the next reference to LOCAL_LIBS, I saw on line 495 of that
Makefile:
-->
次に LOCAL_LIBS を参照している部分を探すと、 Makefile の 495 行目が以
下のようになっていました:
<tscreen><verb>
      $(CCLINK) -o $@ $(LDOPTIONS) $(OBJS) $(LOCAL_LIBS) $(LDLIBS) $(EXTRA_LOAD_FLAGS)
</verb></tscreen>

<!--O
Now what were these LDLIBS?
-->
この LDLIBS とは何なのでしょう?
<tscreen><verb>
      LDLIBS = $(LDPOSTLIB) $(THREADS_LIBS) $(SYS_LIBRARIES)
$(EXTRA_LIBRARIES)
</verb></tscreen>

<!--O
The SYS_LIBRARIES were:
-->
SYS_LIBRARIES は以下の通りです:
<tscreen><verb>
 SYS_LIBRARIES = -lXpm -L../Xc -lXc
</verb></tscreen>
<!--O
Yes! Here were the missing libraries.
-->
これだ! 見つからなかったライブラリがありました。

<!--O
Possibly the linker needed to see the LDLIBS before the LOCAL_LIBS...
So, the first thing to try was to modify the Makefile by transposing the
$(LOCAL_LIBS) and $(LDLIBS) on line 495, so it would now read:
-->
もしかすると、リンカは LOCAL_LIBS よりも前に LDLIBS を見に行く必要があ
るのかもしれません…。そこで、最初に試したのは Makefile の 495行目の 
&dollar;(LOCAL_LIBS) と &dollar;(LDLIBS) を入れ換えることでした。
そうすればライブラリを読みに行ってくれるでしょう:
<tscreen><verb>
        $(CCLINK) -o $@ $(LDOPTIONS) $(OBJS) $(LDLIBS) $(LOCAL_LIBS)
$(EXTRA_LOAD_FLAGS)                          ^^^^^^^^^^^^^^^^^^^^^^^
</verb></tscreen>

<!--O
I tried running <em>make</em> again with the above change, and lo and
behold, it worked this time. Of course,  Xscrabble still needed some
fine tuning and twiddling, such as renaming the dictionary and
commenting out some assert statements in one of the source files, but
since then it has provided me with many hours of pleasure.
-->
上記の変更を加えてから再び <em>make</em> を実行すると――まあ見てくだ
さいよ――今回はうまくいきました。もちろん、 Xscrabble には
まだ微調整したり手を加えたりする必要があり、ディレクトリ
の名前を変えたり、ソースファイルの一つで宣言されている文を
コメントアウトするといった事をしなければなりませんでした。
でもこれ以降の作業は、私に数時間の楽しい時間を与えてくれました。

<!--O
[Note that a newer version of Xscrabble is now available in rpm format, and
this installs without problems.]
-->
&lsqb;現在、新しいバージョンの Xscrabble は rpm 形式で入手できます。
また、新しいバージョンは問題なくインストールできます。&rsqb;

<!--O
You may e-mail <url url="mailto:matt@belgarath.demon.co.uk" name="Matt
Chapman">, and download <em>Xscrabble</em> from his <url
url="http://www.belgarath.demon.co.uk/programs/index.html" name="home
page">.
-->
作者のメールでの連絡先は
<url url="mailto:matt@belgarath.demon.co.uk" name="Matt Chapman">
であり、<em>Xscrabble</em> は彼の
<url url="http://www.belgarath.demon.co.uk/programs/index.html" name="ホームページ">
からダウンロードできます。

<!--O
<tscreen><verb>
       Scrabble is a registered trademark of the Milton Bradley Co., Inc.
</verb></tscreen>
-->
<tscreen><verb>
         Scrabble は the Milton Bradley Co., Inc の登録商標です。
</verb></tscreen>



<!--O
<sect>Second Example: Xloadimage
-->
<sect>2 番目の例: Xloadimage
<p>
<!--O
This example poses an easier problem. The <em>xloadimage</em> program
seemed a useful addition to my set of graphic tools.  I copied the
<tt>xloadi41.gz</tt> file directly from the source directory on the CD
included with the excellent <ref id="refs" name="X User Tools"> book, by
Mui and Quercia. As expected, <em>tar xzvf</em> unarchives the files.
The <em>make</em>, however, produces a nasty-looking error and
terminates.
-->
この例の問題は割と簡単です。<em>xloadimage</em> は私のグラフィック
ツール集に加えると便利なプログラムのようです。私は 
Mui と Quercia が書いた素晴らしい本である
<ref id="refs" name="X User Tools"> の付属 CD-ROM のソースディレクトリ
から <tt>xloadi41.gz</tt> を コピーしました。もちろん
<em>tar xzvf</em> でファイルを展開しました。しかし、<em>make</em> する
とタチの悪そうなエラーが出て終了してしまいます。

<tscreen><verb>
gcc -c -O -fstrength-reduce -finline-functions -fforce-mem
-fforce-addr -DSYSV  -I/usr/X11R6/include
-DSYSPATHFILE=\"/usr/lib/X11/Xloadimage\" mcidas.c

In file included from /usr/include/stdlib.h:32,
                 from image.h:23,
                 from xloadimage.h:15,
                 from mcidas.c:7:
/usr/lib/gcc-lib/i486-linux/2.6.3/include/stddef.h:215:
conflicting types for `wchar_t'
/usr/X11R6/include/X11/Xlib.h:74: previous declaration of
`wchar_t'
make[1]: *** [mcidas.o] Error 1
make[1]: Leaving directory
`/home/thegrendel/tst/xloadimage.4.1'
make: *** [default] Error 2
</verb></tscreen>

<!--O
The error message contains the essential clue.
-->
このエラーメッセージには重要な手がかりが含まれています。

<!--O
Looking at the file <tt>image.h</tt>, line 23...
-->
<tt>image.h</tt> の 23 行目を見ると…。
<tscreen><verb>
       #include <stdlib.h>
</verb></tscreen>

<!--O
Aha, somewhere in the source for <em>xloadimage</em>, <em>wchar_t</em>
has been redefined from what was specified in the standard include file,
<tt>stdlib.h</tt>. Let us first try commenting out line 23 in
<tt>image.h</tt>, as perhaps the <em>stdlib.h include</em> is
not, after all, necessary.
-->
なるほど、<em>xloadimage</em> のソースファイルのどこかで、
<em>wchar_t</em> が標準のインクルードファイルである 
<tt>stdlib.h</tt> の定義から再定義されていました。
まずは <tt>image.h</tt> の 23 行目をコメントアウトしてみましょう。
同様に、たぶん <em>stdlib.h</em> もインクルードする必要はないだろうと
見当をつけ、実際そのとおりでした。

<!--O
At this point, the build proceeds without any fatal errors. The
<em>xloadimage</em> package functions correctly now.
-->
この時点で、致命的なエラーも起こらずに構築できました。そして今でも、
<em>xloadimage</em> プログラムはちゃんと動いています。



<!--O
<sect>Third Example: Fortune
-->
<sect>3 番目の例: Fortune
<p>
<!--O
This example requires some knowledge of C programming. The majority
of UNIX/Linux software is written in C, and learning at least a little
bit of C would certainly be an asset for anyone serious about software
installation.
-->
この例は C 言語のプログラミングの知識をある程度必要とします。UNIX や 
Linux のソフトウェアのほとんどは C 言語で書かれているので、ソフトウェ
アのインストールをまじめにやろうとするなら多少でも C 言語を覚えておけ
ばきっと役に立つでしょう。

<!--O
The notorious <em>fortune</em> program displays up a humorous saying, a
"fortune cookie", every time Linux boots up. Unfortunately (pun intended),
attempting to build fortune on a Red Hat distribution with a 2.0.30
kernel generates fatal errors.
-->
有名な <em>fortune</em> プログラムはユーモアのあることわざ、いわゆる
&dquot;fortune cookie&dquot; を Linux がブートするたびに表示します。
不運なことに(ここは unfortune にかけたシャレのつもり)、
<!--
fujiwara: 日本語にするとおもしろくない…
-->
カーネルのバージョンが 2.0.30 の RedHat ディストリビューションでは致命
的なエラーが発生します。

<tscreen><verb>
~/fortune# make all


gcc -O2 -Wall -fomit-frame-pointer -pipe   -c fortune.c -o
fortune.o
fortune.c: In function `add_dir':
fortune.c:551: structure has no member named `d_namlen'
fortune.c:553: structure has no member named `d_namlen'
make[1]: *** [fortune.o] Error 1
make[1]: Leaving directory `/home/thegrendel/for/fortune/fortune'
make: *** [fortune-bin] Error 2
</verb></tscreen>



<!--O
Looking at <tt>fortune.c</tt>, the pertinent lines are these.
-->
<tt>fortune.c</tt> を見てみると、エラーの起こっている部分は以下の場所
です。

<tscreen><verb>
   if (dirent->d_namlen == 0)
            continue;
        name = copy(dirent->d_name, dirent->d_namlen);
</verb></tscreen>

<!--O
We need to find the structure <tt>dirent</tt>, but it is not declared in
the <em>fortune.c</em> file, nor does a <bf>grep dirent</bf> show it in
any of the other source files. However, at the top of
<em>fortune.c</em>, there is the following line.
-->
<tt>dirent</tt> 構造体を見付ける必要がありますが、<em>fortune.c</em> 
では定義されていませんし、<bf>grep dirent</bf> で探してみても他の
ソースファイルで宣言されているわけでもありません。しかし 
<em>fortune.c</em> の最初に次のような行があります。

<tscreen><verb>
#include <dirent.h>
</verb></tscreen>

<!--O
This appears to be a system library include file, therefore, the logical
place to look for <em>dirent.h</em> is in <em>/usr/include</em>.
Indeed, there does exist a <em>dirent.h</em> file in
<em>/usr/include</em>, but that file does not contain the declaration of
the <tt>dirent</tt> structure.  There is, however, a reference to
another <em>dirent.h</em> file.
-->
これはシステムライブラリのインクルードファイルのようです。したがって、
必然的に <em>dirent.h</em> を探しに行く場所は <em>/usr/include</em> と
なります。実を言うと、<em>/usr/include</em> に <em>dirent.h</em> はあ
るのですが、<em>dirent.h</em> には <tt>dirent</tt> 構造体の宣言はあり
ません。しかし、他の <em>dirent.h</em> ファイルを参照するようになって
います。

<tscreen><verb>
#include <linux/dirent.h>
</verb></tscreen>


<!--O
At last, going to <em>/usr/include/linux/dirent.h</em>, we find the
structure declaration we need.
-->
やっと <em>/usr/include/linux/dirent.h</em> までくれば、探している
構造体の宣言が見つかります。

<tscreen><verb>
struct dirent {
        long            d_ino;
        __kernel_off_t  d_off;
        unsigned short  d_reclen;
        char            d_name[256]; /* We must not include
limits.h! */
};
</verb></tscreen>

<!--O
Sure enough, the structure declaration contains no <em>d_namelen</em>,
but there are a couple of "candidates" for its equivalent. The most
likely of these is <em>d_reclen</em>, since this structure member
probably represents the length of something and it is a short integer.
The other possibility, <em>d_ino</em>, could be an inode number, judging
by its name and type. As a matter of fact, we are probably dealing with
a "directory entry" structure, and these elements represent attributes
of a file, its name, inode, and length (in blocks).  This would seem to
validate our guess.
-->
やっぱり、構造体の宣言に <em>d_namelen</em> が入っていませんでした。し
かし、それに相当しそうな「候補」が 2 つあります。そのうちもっともそれ
らしいのは <em>d_reclen</em> です。というのも、この構造体メンバは
何かの長さを表しているようですし、short 型の整数だからです。もう一つの
方は <em>d_ino</em> ですが、これは名前と型から考えると inode 番号のよ
うです。実をいうと、ここでは「ディレクトリエントリ」構造体を扱っていて、
各要素はファイルの属性、ファイル名、inode 番号、(ブロック単位での)長さ
を表しています。この事実と突き合わせると推測が確実になるでしょう。

<!--O
Let us edit the file <tt>fortune.c</tt>, and change the two
<em>d_namelen</em> references in lines 551 and 553 to <em>d_reclen</em>.
Try a <em>make all</em> again. <bf>Success.</bf> It builds without
errors. We can now get our "cheap thrills" from fortune.
-->
<tt>fortune.c</tt> を編集して、551 行目と 553 行目にある <em>d_namelen</em>
への参照を <em>d_reclen</em> に書き換えてみましょう。それから
<em>make all</em> をもう一度試しましょう。<bf>成功しました。</bf>
エラーもなしに構築できました。これで fortune を使って
「ちょっとどきどき」できますね。

<!--O
<sect>Fourth Example: Hearts
-->
<sect>4 番目の例: Hearts
<p>

<!--O
Here is the hoary old game of Hearts, written for UNIX systems by Bob
Ankeney sometime in the '80's, revised in 1992 by Mike Yang, and currently
maintained by <url url="mailto:badger@phylo.life.uiuc.edu" name="Jonathan
Badger">. Its predecessor was an even older Pascal program by Don
Backus of Oregon Software, later updated by Jeff Hemmerling. Originally
intended as a multiplayer client, it also works well in single-player
mode against computer opponents. The graphics are nice, though the game
lacks sophisticated features and the computer players are not particularly
strong. All the same, it seems to be the only decent Hearts game available
for UNIX and Linux machines even at this late date.
-->
とても古い Hearts というゲームがあります。これは 1980 年代のどこかで
Bob Ankeney が UNIX 用に作成し、1992 年に Mike Yang が改訂し、現在は
<url url="mailto:badger@phylo.life.uiuc.edu" name="Jonathan Badger">
がメンテナンスしています。その前身は、Oregon Software の Don Backus が
書いたもっと古い Pascal のプログラムであり、後に Jeff Hemmerling が更
新しています。もともとは複数の人間で遊ぶことを想定したゲームですが、
コンピュータを相手にして一人で遊ぶこともできます。グラフィックスはいい
感じですが、このゲームには凝った機能はありませんし、コンピュータと対戦
してもあまり強くありません。それにもかかわらず、現在においても UNIX
マシンや Linux マシンで生き残っているゲームはこの Hearts だけのようです。

<!--O
Due to its age and lineage, this package is particularly difficult to
build on a Linux system. It requires solving a long and perplexing series
of puzzles.  It is an exercise in patience and determination.
-->
古いため、また歴史的な経緯のため、このパッケージを
Linux システム上で構築するのは特に
困難です。この作業では長くて複雑なパズルを解く必要があります。忍耐と
決断力の訓練になるでしょう。

<!--O
<em>Before beginning, make certain that you have either the <tt>motif</tt> or
<tt>lesstif</tt> libraries installed.</em>
-->
<em>作業を始める前には、必ず <tt>motif</tt> または <tt>lesstif</tt>
ライブラリをインストールしておいてください。</em>

<itemize>
<item><bf></bf>
</itemize>

<bf>xmkmf</bf>

<bf>make</bf>

<tscreen><verb>
client.c: In function `read_card':
client.c:430: `_tty' undeclared (first use in this function)
client.c:430: (Each undeclared identifier is reported only once
client.c:430: for each function it appears in.)
client.c: In function `scan':
client.c:685: `_tty' undeclared (first use in this function)
make: *** [client.o] Error 1
</verb></tscreen>


<!--O
These are the culprits in the file <tt>client.c</tt>:
-->
<tt>client.c</tt> ファイル中の問題を起こした部分を以下に示します:

<tscreen><verb>
#ifndef SYSV
        (buf[2] != _tty.sg_erase) && (buf[2] != _tty.sg_kill)) {
 #else
        (buf[2] != CERASE) && (buf[2] != CKILL)) {
#endif
</verb></tscreen>




<itemize>
<item><bf></bf>
</itemize>

<!--O
In <tt>client.c</tt>, add
-->
<tt>client.c</tt> の 30 行目に
<tscreen><verb>
#define SYSV
</verb></tscreen>
<!--O
at line 39. This will bypass the reference to <em>_tty</em>.
-->
を追加してください。これにより <em>_tty</em> への参照が回避されます。

<bf>make</bf>

<tscreen><verb>
client.c:41: sys/termio.h: No such file or directory
make: *** [client.o] Error 1
</verb></tscreen>


<itemize>
<item><bf></bf>
</itemize>

<!--O
The include file <tt>termio.h</tt> is in the <tt>/usr/include</tt>
directory on a Linux system, rather than the <tt>/usr/include/sys</tt>
one, as was the case on older UNIX machines.  Therefore, change line 41
of <tt>client.c</tt> from
-->
インクルードファイル <tt>termio.h</tt> は Linux システムでは
<tt>/usr/include</tt> ディレクトリにあります。比較的古い UNIX マシンの
場合のような <tt>/usr/include/sys</tt> ではありません。したがって、
<tt>client.c</tt> の 41行目を

<tscreen><verb>
#include <sys/termio.h>
</verb></tscreen>
<!--O
to
-->
から
<tscreen><verb>
#include <termio.h>
</verb></tscreen>
に変更してください。

<bf>make</bf>

<tscreen><verb>
gcc -o hearts -g      -L/usr/X11R6/lib client.o hearts.o select.o connect.o
sockio.o start_dist.o  -lcurses -ltermlib       
/usr/bin/ld: cannot open -ltermlib: No such file or directory
collect2: ld returned 1 exit status
make: *** [hearts] Error 1
</verb></tscreen>



<itemize>
<item><bf></bf>
</itemize>

<!--O
Modern Linux distributions use the <em>terminfo</em> and/or
<em>termcap</em> database, rather than the obsolete <em>termlib</em> one.
-->
最近の Linux ディストリビューションは、時代遅れの <em>termlib</em>
データベースではなく <em>terminfo</em>データベース や <em>termcap</em>
データベースを使っています。

<!--O
Edit the <tt>Makefile</tt>.
-->
したがって <tt>Makefile</tt> を編集します。

<!--O
Line 655:
-->
655 行目の
<tscreen><verb>
CURSES_LIBRARIES = -lcurses -ltermlib
</verb></tscreen>

<!--O
changes to:
-->
を
<tscreen><verb>
CURSES_LIBRARIES = -lcurses -ltermcap
</verb></tscreen>
に変更します。

<bf>make</bf>

<tscreen><verb>
gcc -o xmhearts -g      -L/usr/X11R6/lib xmclient.o hearts.o select.o
connect.o sockio.o start_dist.o gfx.o  -lXm_s -lXt -lSM -lICE -lXext -lX11
-lPW       
/usr/bin/ld: cannot open -lXm_s: No such file or directory
collect2: ld returned 1 exit status
</verb></tscreen>



<itemize>
<item><bf></bf>
</itemize>

<!--O
The main <em>lesstif</em> library is <tt>libXm</tt>, rather than
<tt>libXm_s</tt>. Therefore, edit the <tt>Makefile</tt>.
-->
メインの <em>lesstif</em> ライブラリは <tt>libXm_s</tt> ではなく
<tt>libXm</tt> です。したがって、<tt>Makefile</tt> を編集して、

<!--O
In line 653:
-->
653 行目の
<tscreen><verb>
XMLIB = -lXm_s $(XTOOLLIB) $(XLIB) -lPW
</verb></tscreen>

<!--O
changes to:
-->
を
<tscreen><verb>
XMLIB = -lXm $(XTOOLLIB) $(XLIB) -lPW
</verb></tscreen>
にします。

<bf>make</bf>

<tscreen><verb>
gcc -o xmhearts -g      -L/usr/X11R6/lib xmclient.o hearts.o select.o
connect.o sockio.o start_dist.o gfx.o  -lXm -lXt -lSM -lICE -lXext -lX11 -lPW       
/usr/bin/ld: cannot open -lPW: No such file or directory
collect2: ld returned 1 exit status
make: *** [xmhearts] Error 1
</verb></tscreen>



<itemize>
<item><bf></bf>
</itemize>

<!--O
Round up the usual suspects.
-->
ここではいつもの容疑者を逮捕しましょう。

<!--O
There is no <tt>PW</tt> library.  Edit the <tt>Makefile</tt>.
-->
<tt>PW</tt> というライブラリはありません。<tt>Makefile</tt> を編集して、

<!--O
Line 653:
-->
653 行目を
<tscreen><verb>
XMLIB = -lXm $(XTOOLLIB) $(XLIB) -lPW
</verb></tscreen>

<!--O
changes to:
-->
から
<tscreen><verb>
XMLIB = -lXm $(XTOOLLIB) $(XLIB) -lPEX5
</verb></tscreen>
<!--O
(The <tt>PEX5</tt> lib comes closest to <tt>PW</tt>.)
に変更します(<tt>PEX5</tt> は <tt>PW</tt> に非常に近くなりました)。
-->


<bf>make</bf>


<tscreen><verb>
rm -f xmhearts
gcc -o xmhearts -g      -L/usr/X11R6/lib xmclient.o hearts.o select.o
connect.o sockio.o start_dist.o gfx.o  -lXm -lXt -lSM -lICE -lXext -lX11 -lPEX5       
</verb></tscreen>

<!--O
The <tt>make</tt> finally works (hurray!).
-->
<tt>make</tt> がやっとうまくいきました(ばんざーい!)。


<itemize>
<item><bf></bf>
</itemize>

<!--O
<em>Installation:</em>
-->
<em>インストール:</em>

<!--O
As root,
-->
root になって以下を実行します。

<tscreen><verb>
[root@localhost hearts]# make install
install -c -s  hearts /usr/X11R6/bin/hearts
install -c -s  xmhearts /usr/X11R6/bin/xmhearts
install -c -s  xawhearts /usr/X11R6/bin/xawhearts
install in . done
</verb></tscreen>





<itemize>
<item><bf></bf>
</itemize>

<!--O
<em>Test run:</em>
-->
<em>実行テスト:</em>

<bf>rehash</bf>

<!--O
(We're running the <tt>tcsh</tt> shell.)
-->
(<tt>tcsh</tt> を使っているものとします。)

<bf>xmhearts</bf>

<tscreen><verb>
localhost:~/% xmhearts
Can't invoke distributor!
</verb></tscreen>



<itemize>
<item><bf></bf>
</itemize>

<!--O
From <tt>README</tt> file in the <tt>hearts</tt> package: 
-->
<tt>hearts</tt> 付属の <tt>README</tt> を見ると以下のように書いてあり
ます:

<!--O
<tscreen><verb>
     Put heartsd, hearts_dist, and hearts.instr in the HEARTSLIB
     directory defined in local.h and make them world-accessible.
</verb></tscreen>
-->
<tscreen><verb>
     heartsd, hearts_dist, hearts.instr ファイルを local.h で定義され
     ている HEARTSLIB ディレクトリに置き、誰でもアクセスできるようにし
     てください。
</verb></tscreen>
   
<!--O 
From the file <tt>local.h</tt>:
-->
<tt>local.h</tt> には以下のように書いてあります:

<tscreen><verb>
/* where the distributor, dealer and instructions live */

#define HEARTSLIB "/usr/local/lib/hearts"
</verb></tscreen>

<!--O
This is a classic case of RTFM.
-->
これは「マニュアルをちゃんと読め!」の典型例ですね。

<!--O
As <em>root</em>,
-->
<em>root</em> になって以下の作業を行います。

<bf>cd /usr/local/lib</bf>

<bf>mkdir hearts</bf>

<bf>cd !$</bf>

<!--O
Copy the <tt>distributor</tt> files to this directory.
-->
それから、<tt>distributor</tt> ファイルをこのディレクトリにコピーしま
す。

<bf>cp /home/username/hearts/heartsd .</bf>

<bf>cp /home/username/hearts/hearts_dist .</bf>

<bf>cp /home/username/hearts/hearts.instr .</bf>



<itemize>
<item><bf></bf>
</itemize>

<!--O
<em>Try another test run.</em>
-->
<em>もう一度実行テストをしてみましょう。</em>

<bf>xmhearts</bf>

<!--O
It works some of the time, but more often than not crashes with a
<tt>dealer died!</tt> message.
-->
これは動くことも時々ありますが、大抵の場合は <tt>dealer died!</tt> と
いうメッセージを出して止まってしまうでしょう。


<itemize>
<item><bf></bf>
</itemize>

<!--O
The "distributor" and "dealer" scan the hardware ports. We should thus
suspect that those programs need root user privileges.
-->
"distributor" と "dealer" はハードウェアのポートを叩きます。したがって、
これらのプログラムが root 権限が必要としていることを疑うべきです。

<!--O
Try, as <em>root</em>,
-->
<em>root</em> になって以下の作業をしてみましょう。

<bf>chmod u+s /usr/local/lib/heartsd</bf>

<bf>chmod u+s /usr/local/lib/hearts_dist</bf>

<!--O
(Note that, as previously discussed, <em>suid</em> binaries may create
security holes.)
-->
(前にも述べましたが、<em>suid</em> したバイナリはセキュリティホールに
なるかもしれないので注意してください。)

<bf>xmhearts</bf>


<!--O
<em>It finally works!</em>
-->
<em>これでやっと動くようになりました!</em>


<!--O
<tt><em>Hearts</em> is available from <htmlurl
url="ftp://metalab.unc.edu/pub/Linux/games/multiplayer/hearts.tgz"
name="Sunsite">.</tt>
-->
<tt><em>Hearts</em> は <htmlurl
url="ftp://metalab.unc.edu/pub/Linux/games/multiplayer/hearts.tgz" name="Sunsite">
から入手できます。</tt>

<!--O
<sect>Fifth Example: XmDipmon
-->
<sect>5 番目の例: XmDipmon
<p>

<!--O
<tscreen><verb>
Bullwinkle: Hey Rocky, watch me pull a rabbit out of my hat.
Rocky:      But that trick never works.
Bullwinkle: This time for sure.
            Presto!
	    Well, I'm gettin' close.
Rocky:      And now it's time for another special feature.
            -/-/- "Rocky and His Friends"
</verb></tscreen>
-->	     
<tscreen><verb>
ブルウィンクル: やあ、ロッキー。帽子からウサギを出すから見ててくれよ。
ロッキー:       でも、うまくいったことなんかないじゃん。
ブルウィンクル: 今度こそうまくいくよ。
                それっ!
	        うーん、あとちょっとだね。
ロッキー:       ということはそろそろ別の特殊機能を用意しなきゃね。
            --- 「ロッキーとその仲間たち」より
</verb></tscreen>

<!--O
XmDipmon is a nifty little application that displays a button showing the
status of an Internet connection. It flashes and beeps when the connection
is broken, as is all too often the case in on rural telephone systems.
Unfortunately, XmDipmon works only with <em>dip</em>, making it useless
for those people, the majority, who use <em>chat</em> to connect.
-->
XmDipmon はインターネット接続の状態を表示するボタンを画面に出す気の利
いた小さなプログラムです。このプログラムは接続が切れると光ってビープ音
を出します。こういった事態は田舎の電話システムではとてもよく起こります。
残念ながら、XmDipmon は <em>dip</em> と組み合わせてしか使えないので、
接続に <em>chat</em> を使っている人達(こちらが多数派なのですが)の役に
は立ちません。

<!--O
Building XmDipmon is not a problem.  XmDipmon links to the <em>Motif</em>
libraries, but it builds and works fine with <em>Lesstif</em>. The
challenge is to alter the package to work when using <em>chat</em>. This
involves actually tinkering with the source code, and necessarily requires
some programming knowledge.
-->
XmDipmon の構築は難しくありません。XmDipmon は <em>Motif</em> ライブラリ
をリンクしますが、<em>Lesstif</em> をリンクしてもうまく構築できます。
難しいのは <em>chat</em> を使っている時にもこのパッケージが動作するよ
うに変えることです。これは実際のソースコードの改造を含むので、
プログラミングの知識がある程度必要です。

<!--O
<tscreen><verb>
        "When xmdipmon starts up, it checks for a file called /etc/dip.pid
         (you can let it look at another file by using the -pidfile
         command line option).  This file contains the PID of the dip
         deamon (dip switches itself into deamon mode once it has
         established a connection)."
                       -/-/- from the XmDipmon README file
</verb></tscreen>	 
-->
<tscreen><verb>
        「xmdipmon は起動時に /etc/dip.pid というファイルをチェックし
          ます(コマンドラインオプション -pidfile を使うと、別のファイ
          ルを参照させることもできます)。このファイルには dip デーモン
          のプロセス ID が入っています(dip はいったん接続が確立すると、
          自分自身をデーモンモードに切り替えます)」
                       --- XmDipmon の README ファイルより
</verb></tscreen>	 

<!--O
Using the <em>-pidfile</em> option, the program can be directed to
check for a different file upon startup, one that exists only during
a successful <em>chat</em> login.  The obvious candidate is the modem
lock file. We could therefore try invoking the program with <bf>xmdipmon
-pidfile /var/lock/LCK..ttyS3</bf> (this assumes that the modem is on
com port #4, ttyS3). This only solves part of the problem, however. The
program continually monitors the <em>dip daemon</em>, and we need to
change this so it instead polls a process associated with <em>chat</em>
or <em>ppp</em>.
-->
<em>-pidfile</em> オプションを使うと、起動時に別のファイルをチェックす
るようにプログラムに指示できます。このファイルは、<em>chat</em> ログイン
が正常にできている間だけ存在するものでなければなりません。すぐ思い付く
候補としてはモデムのロックファイルがあります。したがって、
<bf>xmdipmon -pidfile /var/lock/LCK..ttyS3</bf>
としてプログラムを起動すればよいかもしれません(この例ではモデムは COM 
ポート 4 番、ttyS3 にあるものとしています)。しかし、この方法で解決する
のは問題の一部分だけです。プログラムは <em>dip デーモン</em>を連続的に
監視するので、このプロセスではなく <em>chat</em> や <em>ppp</em> に対
応するプロセスをポーリングするように動作を変えてやる必要があります。

<!--O
There is only a single source file, and fortunately it is
well-commented. Scanning the <tt>xmdipmon.c</tt> file, we find the
<em>getProcFile</em> function, whose header description reads as follows.
-->
ソースファイルは 1 つだけですし、幸いなことに詳しいコメントが付けられ
ています。<tt>xmdipmon.c</tt> を眺めてみると <em>getProcFile</em> とい
う関数がありますが、その先頭には以下のように書いてあります。

<!--O
<tscreen><verb>
/*****
* Name:                 getProcFile
* Return Type:  Boolean
* Description:  tries to open the /proc entry as read from the dip pid file.
<snip>
*****/
</verb></tscreen>
-->
<tscreen><verb>
/*****
* Name:                 getProcFile
* Return Type:  Boolean
* Description:  dip の pid ファイルから読み出した /proc エントリのオープンを試みる
<snip>
*****/
</verb></tscreen>

<!--O
We are hot on the trail now. Tracing into the body of the function...
-->
ここは頑張って調べるところです。関数の中身を読んでみましょう…。

<tscreen><verb>
			/* we watch the status of the real dip daemon */
			sprintf(buf, "/proc/%i/status", pid);
			procfile = (String)XtMalloc(strlen(buf)*sizeof(char)+1);
			strcpy(procfile, buf);
			procfile[strlen(buf)] = '\0';
</verb></tscreen>

<!--O
The culprit is line 2383:
-->
問題になるのは 2383 行目です:
<tscreen><verb>
			sprintf(buf, "/proc/%i/status", pid);
			              ^^^^^^^^^^^^^^^^^^^^^
</verb></tscreen>

<!--O
This checks whether the dip daemon process is running . So, how can we
change this to monitor the pppd daemon instead?
-->
このコードは dip デーモンのプロセスが動作中かどうかを調べています。
ここで、どうすれば dip でなく pppd デーモンを監視するように変更できる
でしょうか?

<!--O
Looking at the <em>pppd</em> manpage:
-->
<em>pppd</em> の man ページを読んでみましょう:
<!--O
<tscreen><verb>
FILES
       /var/run/pppn.pid (BSD or Linux), /etc/ppp/pppn.pid (others)
                     Process-ID for pppd process on ppp interface unit n.
</verb></tscreen>
-->
<tscreen><verb>
FILES
       /var/run/pppn.pid (BSD または Linux), /etc/ppp/pppn.pid (others)
                     ppp インタフェースユニット n の pppd プロセスのプロセス ID
</verb></tscreen>

<!--O
Change line 2383 in <tt>xmdipmon.c</tt> to:
-->
そこで、<tt>xmdipmon.c</tt> の 2383 行目を以下のように変更します:
<tscreen><verb>
			sprintf(buf, "/var/run/ppp0.pid" );
</verb></tscreen>

<!--O
Rebuild the revised package. No problems with the build. Now test it
with the new command line argument. It works like a charm. The little
blue button indicates when a <tt>ppp</tt> connection to the ISP has
been established, and flashes and beeps when the connection is broken.
Now we have a fully functional <em>chat</em> monitor.
-->
修正したパッケージを再構築します。構築は問題ないはずです。次に、新しい
コマンドライン引数をテストします。これは見事に動作します。ISP への
<tt>ppp</tt> 接続が確立すると小さな青いボタンがそれを示し、接続が切れ
るとボタンが光り、ビープ音がします。これで <em>chat</em> を完璧に監視
できるツールができました。

<!--O
XmDipmon can be downloaded from <htmlurl
url="http://www.xs4all.nl/~ripley/RSD/linux.html" name="Ripley Linux Tools">.
-->
XmDipmon は
<htmlurl url="http://www.xs4all.nl/~ripley/RSD/linux.html" name="Ripley Linux Tools">
から入手できます。

<!--O
<sect>Where to Find Source Archives
-->
<sect>ソースアーカイブの入手先
<p>
<!--O
Now that you are eager to use your newly acquired
knowledge to add utilities and other goodies to
your system, you may find them online at the <url
url="http://www.redhat.com/linux-info/linux-app-list/linapps.html"
name="Linux Applications and Utilities Page">, or on one of the very
reasonably priced CD ROM archives by <url url="http://www.redhat.com/"
name="Red Hat">, <url url="http://www.infomagic.com" name="InfoMagic">,
<url url="http://www.lsl.com" name="Linux Systems Labs">, <url
url="http://www.cheapbytes.com" name="Cheap Bytes">, and others.
-->
この文書で新しく覚えた知識を使って、ユーティリティや素晴らしいソフトを
システムに追加したいと思ったら、ネットワーク上では
<url url="http://www.redhat.com/linux-info/linux-app-list/linapps.html"
name="Linux Applications and Utilities Page"> で見つかるでしょうし、
<url url="http://www.redhat.com/" name="Red Hat">,
<url url="http://www.infomagic.com" name="InfoMagic">,
<url url="http://www.lsl.com" name="Linux Systems Labs">,
<url url="http://www.cheapbytes.com" name="Cheap Bytes">
等からはとてもお買い得な CD-ROM アーカイブが売られています。

<!--O
A comprehensive repository of source code is the <htmlurl
url="ftp://ftp.vix.com/pub/usenet/comp.sources.unix/" name="comp sources
UNIX archive">.
-->
ソースコードがたくさん置いてある場所としては、
<htmlurl url="ftp://ftp.vix.com/pub/usenet/comp.sources.unix/" name="comp sources UNIX archive">
があります。

<!--O
Much UNIX source code is posted on the <htmlurl url="news://alt.sources"
name="alt.sources"> newsgroup. If you are looking for particular source
code packages, you may post on the related <htmlurl
url="news://alt.sources.wanted" name="alt.sources.wanted"> newsgroup.
Another good place to check is the <htmlurl
url="news://comp.os.linux.announce"
name="comp.os.linux.announce"> newsgroup.  To get on the <htmlurl
url="mailto:unix-sources@pa.dec.com" name="Unix sources"> mailing list,
send a <em>subscribe</em> message there.
-->
たくさんの UNIX のソースコードがニュースグループの
<htmlurl url="news://alt.sources" name="alt.sources">
にポストされています。もし、特定のソースコードのパッケージを探している
のなら、
<htmlurl url="news://alt.sources.wanted" name="alt.sources.wanted">
以下の関連ニュースグループに投稿して聞いてみるとよいでしょう。
チェックするとよい別の場所としては、
<htmlurl url="news://comp.os.linux.announce" name="comp.os.linux.announce">
ニュースグループがあります。
<htmlurl url="mailto:unix-sources@pa.dec.com" name="Unix sources">
メーリングリストに入るには、本文に
<em>subscribe</em>
と書いたメールをこのメーリングリスト宛に送ってください。

<!--O
Archives for the <htmlurl url="news://alt.sources" name="alt.sources">
newsgroup are at the following ftp sites:
-->
<htmlurl url="news://alt.sources" name="alt.sources"> ニュースグループ
のアーカイブは以下の FTP サイトにあります。

<itemize>
<item><htmlurl url="ftp://ftp.sterling.com/usenet/alt.sources/"
name="ftp.sterling.com/usenet/alt.sources/">
<item><htmlurl
url="ftp://wuarchive.wustl.edu/usenet/alt.sources/articles"
name="wuarchive.wustl.edu/usenet/alt.sources/articles">
<item><htmlurl
url="ftp://src.doc.ic.ac.uk/usenet/alt.sources/articles"
name="src.doc.ic.ac.uk/usenet/alt.sources/articles">

</itemize>



<!--O
<sect>Final Words
-->
<sect>最後に
<p>
<!--O
To sum up, persistence makes all the difference  (and a high frustration
threshold certainly helps). As in all endeavors, learning from mistakes
is critically important.  Each misstep, every failure contributes to the
body of knowledge that will lead to mastery of <bf>the art of building
software</bf>.
-->
まとめると、とにかく粘り強さが問題になります(また、フラストレーション
への耐性があると役に立つでしょう)。努力することと同じく、間違いから学
ぶことも非常に大切です。それぞれの誤りや失敗により知識が豊富になり、
<bf>ソフトウェアの構築の技術</bf>を究めることができるでしょう。


<!--O
<sect>References and Further Reading<label id="refs">
-->
<sect>参考文献
<p>

<!--O
<tscreen><verb>
BORLAND C++ TOOLS AND UTILITIES GUIDE, Borland International, 1992,
pp. 9-42.
[One of the manuals distributed with Borland C++, ver. 3.1. Gives
a fairly good intro to make syntax and concepts, using Borland's
crippled implementation for DOS.]

DuBois, Paul: SOFTWARE PORTABILITY WITH IMAKE, O'Reilly and Associates,
1996, ISBN 1-56592-226-3.
[This is reputed to be the definitive imake reference, though I did not
have it available when writing this article.]

Frisch, Aeleen: ESSENTIAL SYSTEM ADMINISTRATION (2nd ed.), O'Reilly and
Associates, 1995, ISBN 1-56592-127-5.
[This otherwise excellent sys admin handbook has only sketchy coverage
of software building.]

Hekman, Jessica: LINUX IN A NUTSHELL, O'Reilly and Associates, 1997, ISBN
1-56592-167-4.
[Good all-around reference to Linux commands.]

Lehey, Greg: PORTING UNIX SOFTWARE, O'Reilly and Associates, 1995, ISBN
1-56592-126-7.

Mayer, Herbert G.: ADVANCED C PROGRAMMING ON THE IBM PC, Windcrest Books,
1989, ISBN 0-8306-9363-7.
[An idea-filled book for the intermediate to advanced C programmer.
Superb coverage of algorithms, quirks of the language, and even
amusements.  Unfortunately, out of print.]

Mui, Linda and Valerie Quercia: X USER TOOLS, O'Reilly and Associates,
1994, ISBN 1-56592-019-8, pp. 734-760.

Oram, Andrew and Steve Talbott: MANAGING PROJECTS WITH MAKE, O'Reilly
and Associates, 1991, ISBN 0-937175-90-0.

Peek, Jerry and Tim O'Reilly and Mike Loukides: UNIX POWER TOOLS,
O'Reilly and Associates / Random House, 1997, ISBN 1-56592-260-3.
[A wonderful source of ideas, and tons of utilities you may end up
building from the source code, using the methods discussed in
this article.]

Stallman, Richard M. and Roland McGrath: GNU MAKE, Free Software
Foundation, 1995, ISBN 1-882114-78-7.
[Required reading.]

Waite, Mitchell, Stephen Prata, and Donald Martin: C PRIMER PLUS, Waite Group 
Press, ISBN 0-672-22090-3,.
[Probably the best of the introductions to C programming.  Extensive
coverage for a primer.  Newer editions now available.]

Welsh, Matt and Lar Kaufman: RUNNING LINUX, O'Reilly and Associates,
1996, ISBN 1-56592-151-8.
[Still the best overall Linux reference, though lacking in depth
in some areas.]


The man pages for dpkg, gcc, gzip, imake, ldconfig, ldd, make, nm, patch,
rpm, shar, strip, tar, termcap, terminfo, and xmkmf.


The BZIP2 HOWTO, by David Fetter.

The Glibc2 HOWTO, by Eric Green

The LINUX ELF HOWTO, by Daniel Barlow.

The RPM HOWTO, by Donnie Barnes.

The StarOffice miniHOWTO, by Matthew Borowski.

</verb></tscreen>
-->
<tscreen><verb>
BORLAND C++ TOOLS AND UTILITIES GUIDE, Borland International, 1992,
pp. 9-42.
&lsqb;Borland C++ バージョン 3.1 に付属のマニュアルのひとつ。Borland 
の DOS 用のダメな実装を使って、構文や概念を作るためのかなりよい入門書
です&rsqb;

DuBois, Paul: SOFTWARE PORTABILITY WITH IMAKE, O'Reilly and Associates,
1996, ISBN 1-56592-226-3.
&lsqb;これは imake のリファレンスの決定版と言われていますが、この文書
の執筆の時点では入手できませんでした&rsqb;

Frisch, Aeleen: ESSENTIAL SYSTEM ADMINISTRATION (2nd ed.), O'Reilly and
Associates, 1995, ISBN 1-56592-127-5.
&lsqb;これも素晴らしいシステム管理ハンドブックですが、ソフトウェアの
構築については概要しか書かれていません&rsqb;

Hekman, Jessica: LINUX IN A NUTSHELL, O'Reilly and Associates, 1997, ISBN
1-56592-167-4.
&lsqb;Linux のコマンドに関する万能のリファレンスです&rsqb;

Lehey, Greg: PORTING UNIX SOFTWARE, O'Reilly and Associates, 1995, ISBN
1-56592-126-7.

Mayer, Herbert G.: ADVANCED C PROGRAMMING ON THE IBM PC, Windcrest Books,
1989, ISBN 0-8306-9363-7.
&lsqb;中級から上級の C プログラマのためのアイディアが詰まった本です。
素晴らしく広い分野のアルゴリズム、プログラム言語の技法、そして
アミューズメントについても書かれています。残念なことに絶版です&rsqb;

Mui, Linda and Valerie Quercia: X USER TOOLS, O'Reilly and Associates,
1994, ISBN 1-56592-019-8, pp. 734-760.

Oram, Andrew and Steve Talbott: MANAGING PROJECTS WITH MAKE, O'Reilly
and Associates, 1991, ISBN 0-937175-90-0.

Peek, Jerry and Tim O'Reilly and Mike Loukides: UNIX POWER TOOLS,
O'Reilly and Associates / Random House, 1997, ISBN 1-56592-260-3.
&lsqb;アイディアの素晴らしい源であり、最終的には本文書で説明した手法を
使って構築することになるようなユーティリティが山ほど入っています&rsqb;

Stallman, Richard M. and Roland McGrath: GNU MAKE, Free Software
Foundation, 1995, ISBN 1-882114-78-7.
&lsqb;ぜひ読んでください&rsqb;

Waite, Mitchell, Stephen Prata, and Donald Martin: C PRIMER PLUS, Waite Group 
Press, ISBN 0-672-22090-3,.
&lsqb;たぶん C 言語の一番優れた入門書です。初心者向けの話題を広く扱っ
ています。新しい版が出ました&rsqb;

Welsh, Matt and Lar Kaufman: RUNNING LINUX, O'Reilly and Associates,
1996, ISBN 1-56592-151-8.
&lsqb;未だに Linux 全体のリファレンスとしては一番優れていますが、一部
の分野については詳しい説明がありません&rsqb;


dpkg, gcc, gzip, imake, ldconfig, ldd, make, nm, patch,
rpm, shar, strip, tar, termcap, terminfo, xmkmf の man ページ。

The BZIP2 HOWTO(著者: David Fetter)

The Glibc2 HOWTO(著者: Eric Green)

The LINUX ELF HOWTO(著者: Daniel Barlow)

The RPM HOWTO(著者: Donnie Barnes)

The StarOffice miniHOWTO(著者: Matthew Borowski)

</verb></tscreen>

<!--O
[These HOWTOs should be in the <tt>/usr/doc/HOWTO</tt>  or
<tt>/usr/doc/HOWTO/mini</tt> directory on your system. Updated
versions are available in text, HTML, and SGML format from the <url
url="http://metalab.unc.edu/LDP/HOWTO" name="LDP site">, and usually
from the respective authors' home sites.]
-->
&lsqb;これらの HOWTO は、お使いのシステムの <tt>/usr/doc/HOWTO</tt>
ディレクトリか <tt>/usr/doc/HOWTO/mini</tt> ディレクトリにあるはずです。
最新版は <url url="http://metalab.unc.edu/LDP/HOWTO" name="LDP のサイト">
からテキスト、HTMO, SGML 形式で入手できます。また、普通はそれぞれの
著者のホームページからも入手できます&rsqb;

<!--O
<sect>Credits
-->
<sect>クレジット
<p>

<!--O
The author of this HOWTO would like to thank the following persons for their
helpful suggestions, corrections, and encouragement.
-->
本 HOWTO の著者は、有益な提案、訂正、応援をしてくださった以下の方々に
感謝します。

<itemize>
<item>R. Brock Lynn
<item>Michael Jenner
<item>Fabrizio Stefani
</itemize>

<!--O
Kudos also go to the fine people who have translated this HOWTO into Italian
and Japanese.
-->
この HOWTO をイタリア語・日本語に翻訳してくれた人々にも称賛を捧げます。

<!--O
And, of course, thanks, praise, benedictions and hosannahs to Greg
Hankins and Tim Bynum of the <url url="http://metalab.unc.edu/LDP/"
name="Linux Documentation Project">, which has made all this possible.
-->
そして、もちろん
<url url="http://metalab.unc.edu/LDP/" name="Linux Documentation Project">
の Greg Hankins と Tim Bynum にお礼と称賛、感謝、熱い賛辞を送ります。
LDP のおかげで全てができたのですから。

<sect>日本語訳について
<p>
日本語訳は Linux Japanese FAQ Project が行いました。
翻訳に関するご意見は JF プロジェクト
&lt;JF@linux.or.jp&gt;
宛に連絡してください。

改訂履歴を以下に示します。

<descrip>
<tag>v1.10, 8 September 1998</tag>
翻訳:
井田 司 &lt;tsukasa_i@bigfoot.com&gt;

<tag>v1.91j, 18 January 2000</tag>
更新:
藤原 輝嘉 &lt;fujiwara@linux.or.jp&gt;

校正:
<itemize>
<item>中野 武雄 &lt;nakano@apm.seikei.ac.jp&gt;
<item>武井 伸光 &lt;takei@cc.kochi-u.ac.jp&gt;
</itemize>

</descrip>

</article>
