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 <JF@linux.or.jp> <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>[ファイル名]</em></bf>です。 言うまでもなく、[ファイル名] とはアーカイブファイルのことで す。普通は、展開を行うと新たにディレクトリが作られて、そのディレクトリ の中に適当なファイルが展開されます。注意: もしパッケージのファイル名に <em>.Z</em> という拡張子がついていたら、上記の方法でも全く差し支えあり ませんが、<bf>uncompress [ファイル名]</bf> とした後で、 <bf>tar xvf [ファイル名]</bf> としても展開できます。展開によっ てどんなファイルが作られるかは、<bf>tar tzvf [ファイル名]</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 [ファイル名] | tar xvf -</bf> とすれば展開 できます。あるいは、<tt>tar</tt>p に bzip2 のためのパッチが当たってい るなら、単に <bf>tar xyvf [ファイル名]</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.] --> [上記の情報の訂正と更新について R. Brock Lynn と Fabrizio Stefani に深く感謝します。] <!--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 [ファイル名].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 < [パッチファイル]</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 [パッケージ名].rpm</bf> を実行し、「(MD5 チェックサムに対する)署名の確認」をパッケージに対して 行うべきです。同様に強くお勧めするのは、 <bf>rpm -K --nopgp [パッケージ名].rpm</bf> の実行です。 <em>deb</em> パッケージでこれに対応するコマンドは <bf>dpkg -I | --info [パッケージ名].deb</bf> と <bf>dpkg -e | --control [パッケージ名].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 [ファイル名]</bf> や <bf>dpkg --install [ファイル名]</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 -> libX11.so.3.1.0</em> といったリン クが必要です。このソフトウェアにはさらに <em>libX11.so -> 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>#!/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 を使うには別途 $100〜$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 [ファイル名]</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"> といったニュースグループで助けてもらえるかもしれません。 [訳注: 日本語のニュースグループなら fj.os.linux、jlug.ml.users があります。 しかし、これらのニュースグループで答えてくれる人は皆自分の空いた時間を 使ってボランティアで答えてくれています。決してメーカーのサポートでは ないので、失礼な態度を取らないようにしてください。また、質問するときには、 わかりやすく、具体的に質問しましょう。また、問題が解決したなら、解決した ことの報告、解決の要因を忘れずに報告しましょう。] <!--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行目の $(LOCAL_LIBS) と $(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.] --> [現在、新しいバージョンの Xscrabble は rpm 形式で入手できます。 また、新しいバージョンは問題なくインストールできます。] <!--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 deamon */ 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. [Borland C++ バージョン 3.1 に付属のマニュアルのひとつ。Borland の DOS 用のダメな実装を使って、構文や概念を作るためのかなりよい入門書 です] DuBois, Paul: SOFTWARE PORTABILITY WITH IMAKE, O'Reilly and Associates, 1996, ISBN 1-56592-226-3. [これは imake のリファレンスの決定版と言われていますが、この文書 の執筆の時点では入手できませんでした] Frisch, Aeleen: ESSENTIAL SYSTEM ADMINISTRATION (2nd ed.), O'Reilly and Associates, 1995, ISBN 1-56592-127-5. [これも素晴らしいシステム管理ハンドブックですが、ソフトウェアの 構築については概要しか書かれていません] Hekman, Jessica: LINUX IN A NUTSHELL, O'Reilly and Associates, 1997, ISBN 1-56592-167-4. [Linux のコマンドに関する万能のリファレンスです] 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. [中級から上級の C プログラマのためのアイディアが詰まった本です。 素晴らしく広い分野のアルゴリズム、プログラム言語の技法、そして アミューズメントについても書かれています。残念なことに絶版です] 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. [アイディアの素晴らしい源であり、最終的には本文書で説明した手法を 使って構築することになるようなユーティリティが山ほど入っています] Stallman, Richard M. and Roland McGrath: GNU MAKE, Free Software Foundation, 1995, ISBN 1-882114-78-7. [ぜひ読んでください] Waite, Mitchell, Stephen Prata, and Donald Martin: C PRIMER PLUS, Waite Group Press, ISBN 0-672-22090-3,. [たぶん C 言語の一番優れた入門書です。初心者向けの話題を広く扱っ ています。新しい版が出ました] Welsh, Matt and Lar Kaufman: RUNNING LINUX, O'Reilly and Associates, 1996, ISBN 1-56592-151-8. [未だに Linux 全体のリファレンスとしては一番優れていますが、一部 の分野については詳しい説明がありません] 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.] --> [これらの HOWTO は、お使いのシステムの <tt>/usr/doc/HOWTO</tt> ディレクトリか <tt>/usr/doc/HOWTO/mini</tt> ディレクトリにあるはずです。 最新版は <url url="http://metalab.unc.edu/LDP/HOWTO" name="LDP のサイト"> からテキスト、HTMO, SGML 形式で入手できます。また、普通はそれぞれの 著者のホームページからも入手できます] <!--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 プロジェクト <JF@linux.or.jp> 宛に連絡してください。 改訂履歴を以下に示します。 <descrip> <tag>v1.10, 8 September 1998</tag> 翻訳: 井田 司 <tsukasa_i@bigfoot.com> <tag>v1.91j, 18 January 2000</tag> 更新: 藤原 輝嘉 <fujiwara@linux.or.jp> 校正: <itemize> <item>中野 武雄 <nakano@apm.seikei.ac.jp> <item>武井 伸光 <takei@cc.kochi-u.ac.jp> </itemize> </descrip> </article>