Building and Installing Software Packages for Linux Mendel Cooper --- http://personal.riverusers.com/~thegrendel/ v1.91, 27 July 1999 井田 司 と JF Project v1.91j, 18 January 2000 この文書は Linux 上で「一般的」な UNIX のソフトウェアを構築・インス トールするための包括的なガイドです。さらに、 "rpm" や "deb" といったコ ンパイル済みバイナリパッケージについてもいくらか扱っています。 ______________________________________________________________________ 目次 1. はじめに 2. ファイルの展開 3. Make の使用 4. コンパイル済バイナリパッケージ 4.1 RPM の悪いところ 4.2 RPM で起こる問題の例 5. Termcap と Terminfo の問題 6. a.out 形式のバイナリの後方互換性 6.1 事例 7. トラブルシューティング 7.1 リンクエラー 7.2 その他の問題 7.3 改善と最適化 7.4 さらなる情報の入手先 8. 最後の仕上げ 9. 最初の例: Xscrabble 10. 2 番目の例: Xloadimage 11. 3 番目の例: Fortune 12. 4 番目の例: Hearts 13. 5 番目の例: XmDipmon 14. ソースアーカイブの入手先 15. 最後に 16. 参考文献 17. クレジット 18. 日本語訳について ______________________________________________________________________ 1. はじめに 各種 UNIX 系 OS や Linux 用のソフトウェアパッケージの多くはソースファ イルを圧縮したアーカイブとして配布されています。同じソフトウェアのパッ ケージをそれぞれのマシン毎に「構築」して実行することができるので、ソフ トウェアの作者はたくさんのバージョンを作る手間を省くことができます。ひ とつだけのソフトウェアの配布パッケージが色々な形で構築され、最終的には Intel のマシンや DEC Alpha, RISC ワークステーション、あるいはメインフ レーム機でさえ動作するようになります。残念ながらこのことは、実際にソフ トウェアを「構築」してインストールすることがエンドユーザの仕事になると いうことです。エンドユーザとは事実上の「システム管理者」、つまりキー ボードに向かって座っている――あなたのことです。しかし、元気を出してく ださい。手順は見ためほどわけのわからないものでも神秘的なものでもありま せん。このガイドではそのことをわかってもらいます。 2. ファイルの展開 必要なソフトウェアのパッケージは、ダウンロードするなどして既に入手して いるものとします。もっとも出回っているのは、tar でアーカイブして gzip で圧縮してある .tar.gz または .tgz の形式です(よく "tarball" と言われ ます)。まずは、このアーカイブファイルを作業ディレクトリにコピーしま す。次に、tar の展開と gunzip を行います。これを行うためのコマンドは tar xzvf [ファイル名]です。言うまでもなく、[ファイル名] とはアーカイブ ファイルのことです。普通は、展開を行うと新たにディレクトリが作られて、 そのディレクトリの中に適当なファイルが展開されます。注意: もしパッケー ジのファイル名に .Z という拡張子がついていたら、上記の方法でも全く差し 支えありませんが、uncompress [ファイル名] とした後で、 tar xvf [ファイ ル名] としても展開できます。展開によってどんなファイルが作られるか は、tar tzvf [ファイル名] で前もって調べられます。このコマンドは実際に アーカイブを展開することなく中に入っているファイルのリスト表示だけを行 います。 "tarball" を展開する上記の方法は、以下の両方と同じ動作です: o gzip -cd filename | tar xvf - o gunzip -c filename | tar xvf - ('-' を付けると、tar コマンドは標準入力から入力を行います。) bzip2(.bz2)という新しい圧縮形式で圧縮されたソースファイルは bzip2 -cd [ファイル名] | tar xvf - とすれば展開できます。あるいは、tarp に bzip2 のためのパッチが当たっているなら、単に tar xyvf [ファイル名] とすれば 展開できます (詳しくは Bzip2 HOWTO (日本語版: , 英語版: ) を参照してくだ さい)。Debian GNU/Linux では Hiroshi Takekawa が書いた別のパッチを tar に当てており、そのバージョンの tar では -I, --bzip2, --bunzip2 オプ ションが使えます。 [上記の情報の訂正と更新について R. Brock Lynn と Fabrizio Stefani に深 く感謝します。] 場合によっては、アーカイブファイルはユーザのホームディレクトリや、ある いは別の特定のディレクトリ(/, /usr/src, /opt 等)に展開しなければなりま せん。これはソフトウェアパッケージの設定情報で指定されているでしょう。 アーカイブファイルを展開しているときにエラーが出たなら、このことが原因 かもしれません。パッケージ付属のドキュメントファイル (特に README や Install ファイル)があれば、そのドキュメントを読み、必要に応じて設定 ファイルや Makefile を編集してください。注意: 思いもよらない結果になる ことがあるので、普通は Imakefile ファイルは編集しない方がいいでしょ う。ほとんどのソフトウェアパッケージでは、この手順は自動化されており、 make install と実行すればバイナリファイルが所定のシステム領域に自動的 に置かれます。 o インターネット上のニュースグループあたりだと shar ファイル、つまり シェルアーカイブ(SHell ARchive) 形式のファイルに出食わすかもしれま せん。shar 形式が未だに使われているのは、この形式は人間が読めるの で、ニュースグループのモデレータが shar 形式で投稿された記事を整理 し、不適切なものを排除できるからです。この形式は unshar [ファイル 名].shar コマンドで展開できます。その他の点では "tarball" と同じよ うに扱います。 o 一部のソースアーカイブは、DOS や Mac, ことによっては Amiga の標準で ない圧縮ユーティリティで処理されていることがあります。これには zip, arc, lha, arj, zoo, rar, and shk 等があります。幸い、 Sunsite 等のサイトには Linux 用の圧縮ユーティリ ティが置いてあり、これらのほとんど全てを扱えます。 時として、元のソースファイルからの変更点を記してある パッチファイルや diff ファイルを使って、展開したソースファイルを更新したり、バグ修正を 取り込んだりすることが必要な場合があります。こういった場合にすべきこと は、ドキュメントファイルや README ファイルにのっています。Larry Wall が開発した強力な patch ユーティリティの普通の使い方は patch < [パッチ ファイル]です。 さて、それでは、構築の段階へと進みましょう。 3. Make の使用 Makefile は構築の段階で鍵となるファイルです。Makefile の最も単純な使い 方は、「バイナリ」つまりパッケージの実行部分のコンパイルや構築を行うス クリプトとしてのものです。 Makefile を使えば、ソフトウェアパッケージの 更新をする際に全部のファイルをいちいち再コンパイルしないで済ませること もできるのですが、この使い方はここでは関係ないのでまた別の話になりま す。 いくつかのタイミングで Makefile は cc や gcc を実行します。正確には、 プリプロセッサ、C (や C++) のコンパイラ、リンカを順に実行します。 普通、make を実行するには make とタイプするだけです。 make を実行する と、普通はパッケージに必要な全ての実行可能ファイルが構築されます。しか し、make にできることはこれだけではありません。例えば、ファイルを適切 なディレクトリにインストールしたり(make install)、古いオブジェクトファ イルを消去できます(make clean)。make -n を実行すると、make が呼び出す 全ての命令を実際の処理を行わずに表示だけさせることにより、構築のプロセ スをあらかじめ確認できます。 一般的な Makefile を使うのは非常に単純なソフトだけです。もっと複雑なイ ンストール作業では、あなたのマシンのライブラリやインクルードファイル、 リソースに合わせて Makefile の設定を必要があります。このことはインス トールに X11 のライブラリが必要なときによく起こります。 X11 では Imake と xmkmf がこの作業をしてくれます。 man ページからの引用によると、Imakefile は Makefile の「テンプレート」 です。 imake ユーティリティは Imakefile を元にしてシステムに合った Makefile を作ります。しかし、ほとんどの場合は、imake を直接使うのでは なく xmkmf を実行することになるでしょう。 xmkmf は imake を実行するた めのシェルスクリプトであり、フロントエンドです。個別のインストールの際 の具体的な作業については、ソフトウェアアーカイブに入っている README や INSTALL という名前のファイルをチェックしてください。(ソースファイルを 展開した後に、メインのディレクトリに Imakefile ができていれば、xmkmf を使うはずだという動かぬ証拠になります。) imake と xmkmf の細かい動作 については man ページを読んでください。 xmkmf や make は root で実行することが必要な場合があることに注意してく ださい。特に、make install を実行して /usr/bin や /usr/local/bin ディ レクトリにバイナリファイルを移動させる場合はそうです。root 権限を持た ない普通のユーザにはシステムディレクトリへの書き込み権限がないの で、make を使用するとおそらく書き込み拒否のエラー(write access denied) が出るでしょう。また、バイナリファイルの実行許可が適切なユーザに与えら れているかどうかも確認してください。 xmkmf は Imakefile を使って、システムに合った Makefile を新しく作りま す。通常は -a オプションを付けて xmkmf を実行し、 make Makefiles, make includes, make depend を自動的に行わせます。これにより変数の設定や、コ ンパイラやリンカに与えるライブラリの位置の定義が行われます。場合によっ ては、Imakefile がなく、その代わりに同様の設定を行うための INSTALL ス クリプトや configure スクリプトが付いていることもあります。この際の注 意ですが、configure を実行する場合には、確実にカレントディレクトリの configure スクリプトを実行するために ./configure として実行すべきで す。大抵の場合、インストールの手順を説明した READMEファイルがパッケー ジに入っています。 xmkmf や何らかのインストールスクリプトが作成した Makefile を実際に見て 詳しく点検するとよいでしょう。 Makefile は通常、あなたのシステムに合わ せて正しく設定されているはずですが、時として手作業で Makefile を「い じったり」、間違いを直す必要に迫られることがあります。 できたてのバイナリを適切なシステムディレクトリにインストールするには、 普通は root になって make install します。最近のディストリビューション では、システム全体で使うバイナリを置くための一般的なディレクトリは /usr/bin, /usr/X11R6/bin, /usr/local/bin です。新しいパッケージを入れ るのに適切なディレクトリは /usr/local/bin で、そうしておけば新しく入れ た部分と元々 Linux にインストールされていた部分を分けておけます。 もともと商用 UNIX 用を対象にしていたパッケージは、/opt 等の見慣れない ディレクトリにインストールしようとするかもしれません。もちろん、インス トール先のディレクトリが存在していなければ、エラーになります。これを回 避する最も簡単な方法は、root になって /opt ディレクトリを作って、そこ にパッケージをインストールし、PATH 環境変数にそのディレクトリを追加す ることです。別のやり方としては、 /usr/local/bin にシンボリックリンクを 張ってもかまいません。 したがって、一般的なインストールの手順は以下のようになります: o README ファイルや他の適当なドキュメントを読みます。 o xmkmf -a または INSTALL や configure といったスクリプトを実行しま す。 o Makefile をチェックします。 o 必要に応じて、make clean, make Makefiles, make includes, make depend を実行します。 o make を実行します。 o ファイルのパーミッションを確認します。 o 必要なら make install を実行します。 注意: o 普通は、パッケージを root ユーザでコンパイルしてはいけません。 su して root する必要があるのは、コンパイルが終わったバイナリをシステ ムディレクトリにインストールするときだけです。 o makeとその使い方に慣れたら、インストールしようとしているパッケージ に含まれている、あるいはパッケージが自動的に生成する標準の Makefile に手を入れて、gcc に渡す最適化オプションを追加するといいでしょう。 こういったオプションでよく使われるのは、 -O2, -fomit-frame-pointer, -funroll-loops, -mpentium(Pentium を使っている場合)です。Makefile をいじる時は、用心と常識を忘れないように! o make でバイナリを作った後は、バイナリに対して strip を実行するとよ いでしょう。strip コマンドはバイナリからデバッグ用のシンボル情報を 取り除いてサイズを小さくします。劇的に小さくなることもよくありま す。これを実行すると、当然ながらデバッグには使えなくなります。 o Pack Distribution Project は、先程ま での説明とは別のアプローチでソフトウェアパッケージのアーカイブを作 れるようにしようとしています。このアプローチは、ばらばらのコレク ションディレクトリにインストールされたファイルへのシンボリックリン クを Python スクリプト群を使って管理するというものです。このアプ ローチでもアーカイブは tarball ですが、これらは /coll ディレクトリ や /pack ディレクトリにインストールされます。これらのディストリ ビューションのどれかをちょっと試してみるにも、パックコレクショ ン(Pack-Collection)を上記のサイトから入手する必要があるでしょう。 4. コンパイル済バイナリパッケージ 4.1. RPM の悪いところ 自分の手でパッケージをソースファイルから作ってインストールするのはおっ くうな作業だからといって、人気のある rpm 形式や deb 形式のパッケージ や、新しい Stampede slp 形式のパッケージを利用する Linuxユーザがいま す。通常は rpm を使うと例の悪名高いオペレーティングシステムと同じくら い簡単かつ速くパッケージをインストールできるのは確かでしょうが、勝手に インストールされるコンパイル済みのバイナリパッケージには間違いなく欠点 もいくつかあります。 まず、ソフトウェアのパッケージは普通、"tarball" のソースファイルが最初 にリリースされ、コンパイル済みのバイナリパッケージはそれより数日、数週 間、場合によっては数ヵ月遅れてリリースされる点に注意してください。最新 の rpm パッケージでも、最新の "tarball" よりマイナーバージョンが 1 つ か 2 つ遅れているのが普通です。ですから、常に「最先端」のソフトウェア を追いかけ続けたいのであれば、 rpm や deb が出るのを待つのは得策ではな いでしょう。あまり人気のないパッケージについては、rpm 化されないことも あるかもしれません。 2 番目に、"tarball" パッケージの方がより完全であり、オプションも多く、 カスタマイズしたりいじったりする余地も多くあります。バイナリ rpm 版で は、完全リリース版の一部の機能が消えていることもあります。ソース rpm には完全なソースコードが入っているので、対応する "tarball" と同等で す。したがって、rpm --recompile packagename.rpm か rpm --rebuild packagename.rpm のどちらかのオプションを使って構築とインストールを行う 必要があるでしょう。 2 番目に、コンパイル済みのパッケージの一部には正しくインストールできな いものがあります。あるいはインストールしたとしても、クラッシュしてコア を吐くかもしれません。これはシステムに入っているライブラリのバージョン の違いに依存するかもしれないし、rpm パッケージの用意がうまくできていな いのかもしれませんし、単にパッケージが壊れているのかもしれません。いず れの場合にせよ、rpm や deb をインストールする時には、パッケージを作っ た人の技術を信じるしかありません。 最後に、ソースコードを持っていればいじったり、勉強する時の役に立ちま す。ソースコードはバイナリを作成した元々のアーカイブで持つ方が、それと は別のソース rpm の形で持っているよりもずっと分かりやすいでしょう。 rpm パッケージのインストールは、必ずしもバカなわけではありません。も し、依存関係で競合があれば、rpm のインストールは失敗するでしょう。同様 に、現在のシステム上で動作しているライブラリとバージョンが違うライブラ リを rpm が要求しているならば、たとえ足りないライブラリの名前で既存の ライブラリにシンボリックリンクを張ってもインストールは実行されません。 便利であるにもかかわらず、 rpm でのインストールは "tarball" のインス トールと同じ理由で失敗してしまいます。 書き込みに必要なパーミッションを得るためには、rpm や deb パッケージは root になってインストールする必要がありますが、これは重大なセキュリ ティホールの可能性をもたらします。というのも、うっかりとシステムのバイ ナリやライブラリを壊してしまうかもしれないし、システムに大損害をもたら すトロイの木馬をインストールしてしまうことさえあるかもしれません。した がって、「信頼できる所」から rpm や deb のパッケージを入手するというの は重要なことです。いずれにせよ、インストールの前には rpm --checksig [ パッケージ名].rpm を実行し、「(MD5 チェックサムに対する)署名の確認」を パッケージに対して行うべきです。同様に強くお勧めするのは、 rpm -K --nopgp [パッケージ名].rpm の実行です。 deb パッケージでこれに対応する コマンドは dpkg -I | --info [パッケージ名].deb と dpkg -e | --control [パッケージ名].deb です。 o rpm --checksig gnucash-1.1.23-4.i386.rpm gnucash-1.1.23-4.i386.rpm: size md5 OK o rpm -K --nopgp gnucash-1.1.23-4.i386.rpm gnucash-1.1.23-4.i386.rpm: size md5 OK 本当に細かいことが気になる人のために(そして、こういった場合はよく偏執 病と言われます)、パッケージの個々の要素を展開してチェックするための unrpm や rpmunpack というユーティリティがあります。これは Sunsite の ユーティリティ/パッケージ用ディレクトリ にあります。 Klee Diene は、インストールされた .deb ファイ ルが改変されていないことを MD5 チェックサムで調べるための実験的な dpkgcert パッケージを作りました。このパッケージは Debian の ftp アーカ イブ から入手で きます。現在のパッケージ名とバージョンは dpkgcert_0.2-4.1_all.deb で す。 Jim Pick Software のサイトで は、Debian の通常のインストール対象となっているパッケージに対して dpkgcert 証明書を提供するための実験的なサーバデータベースが動かされて います。 最も単純な形では、rpm -i [ファイル名] や dpkg --install [ファイル名] コマンドでソフトウェアの展開とインストールが自動的に行われます。しかし 注意してください。これらのコマンドをむやみに使うと、システムが不安定に なる恐れがあります! ここで注意ですが、上記の警告は (被害の範囲こそ少ないものの) Slackware のインストールユーティリティである pkgtool にも当てはまります。ソフト ウェアの「自動的な」インストールはどんなものであっても注意が必要です。 martian プログ ラムと alien プログラムを使う と、rpm, deb, Stampede の slp, tar.gz 形式の各ファイルを互いに変換でき ます。これにより、これらのパッケージがどの Linux ディストリビューショ ンでも使えるようになります。 rpm コマンドや dpkg コマンドの man ページはじっくり読んでください。ま た、詳しい情報については RPM HOWTO や TFUG の Quick Guide to Red Hat's Package Manager 、 The Debian Package Management Tools を見てください。 4.2. RPM で起こる問題の例 Jan Hubicka は、 xaos というとっても良い 感じのフラクタル表示パッケージを作っています。彼のホームページ には、.tar.gz 形式と rpm 形式の パッケージが両方あります。ここは便利さをとって、"tarball" ではなく rpm 版を試しましょう。 残念なことに、xaos の rpm パッケージはインストールできません。おかしな 動作をするバージョンは 2 つあります。 rpm -i --test XaoS-3.0-1.i386.rpm 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 rpm -i --test xaos-3.0-8.i386.rpm error: failed dependencies: libaa.so.1 is needed by xaos-3.0-8 ここでおかしいのは、libslang.so.0, libpng.so.0, libaa.so.1 は全部、テ ストを行ったマシンの /usr/lib にあることです。ライブラリのリリース番号 は同じであっても、 xaos はちょっとバージョンが違うライブラリを使ってい るに違いありません。 テストとして、--nodeps オプションを使って xaos-3.0-8.i386.rpm を強制的 にインストールしてみましょう。ところが、試しに xaos を実行してもクラッ シュしてしまいます。 xaos: error in loading shared libraries: xaos: undefined symbol: __fabsl ここでくじけないで真相を追求してみましょう。xaos のバイナリに対して ldd を実行してライブラリの依存関係を調べると、必要な全ての共有ライブラ リが表示されます。/usr/lib/libaa.so.1 ライブラリに対して nm を実行して シンボル参照を表示させると、本当に __fabsl がないことが分かります。も ちろん、足りない参照が他のライブラリのどれかから抜けている可能性はあり ます…。この問題、つまりライブラリの入れ換えにより足りないものが出てく ることについては、対処の方法はありません。 でも大丈夫! "tarball" の XaoS-3.0.tar.gz を FTP サイト から入手しましょう。 ホームページからも入手できます。これを構築してみましょう。./configure, make を実行し、最後に(root になって) make install を実行すれば問題なく インストールできます。 これはパッケージ済みのバイナリで起こる、便利というよりも問題が先に立つ ようなたくさんの例のうちのひとつです。 5. Termcap と Terminfo の問題 man ページには「terminfo は画面指向のプログラムが使う、端末を記述する データベースで…」 とあります。terminfo は端末にテキストを表示するため に使う制御シーケンス(エスケープコード)の一般的な集合を定義し、特殊なド ライバを使う必要なしにさまざまな端末ハードウェアに対応できるようにしま す。最近のほとんどの Linux ディストリビューションでは、 terminfo ライ ブラリは /usr/share/terminfo にあります。 terminfo は比較的古めの termcap にほとんどとって代わり、termlib を完全 に過去のものにしました。 termcap を必要とするパッケージを扱う時を除い て、普通はプログラムのインストールをする際に端末ライブラリに気を使う必 要はありません。 ほとんどの Linux のディストリビューションは現在 terminfo を使用してい ます。しかし、昔ながらのアプリケーションとの互換性のためにいまだに古い termcap が残っています(/etc/termcap を参照)。場合によっては、termcap をリンクしたバイナリを楽に使うためにインストールする必要がある互換性維 持のための特別なパッケージがあります。よくあるケースとして、ソースファ イルの #define termcap という行をコメントアウトする必要がある場合があ ります。こういった事情の確かな情報については、お使いのディストリビュー ションの関連ドキュメントを調べてください。 6. a.out 形式のバイナリの後方互換性 まれにしかないことなのですが、ソースコードが入手できなかったり、さまざ まな要因でソースコードから ELF バイナリが作れないといった理由で a.out バイナリを使う必要に迫られることがあります。 こういうことも起こるので、ELF で組んであるシステムでも大抵は a.out の ライブラリを全部用意しています。これは /usr/i486-linuxaout/lib ディレ クトリに置かれます。 a.out ライブラリの番号付けの規則は ELF の場合の規 則と違うので、問題を起こしかねないような衝突はうまく避けられます。した がって、a.out バイナリは実行時に正しいライブラリを見つけられるのです が、これが常に正しいわけでもありません。 カーネルには a.out のサポートを組み込む必要があるので注意してくださ い。これは直接組み込んでもかまいませんし、ローダブルモジュールにしても かまいません。これを有効にするにはカーネルを再構築する必要があるかもし れません。さらに、Linux ディストリビューションによっては互換性保持のた めの特殊なライブラリをインストールする必要があります。例えば、Debian には a.out の X アプリケーションを実行するための xcompat があります。 6.1. 事例 何年か前に Jerry Smith がとても便利な rolodex というプログラムを書きま した。このプログラムは Motif ライブラリ(訳注: フリーで手に入らない)を 使っていますが、好運なことに a.out のライブラリを静的リンクしてあるバ イナリが入手できます。残念なことに、lesstif ライブラリを使ってソースを 再構築するには大幅に手を入れる必要があります。さらに残念なことに、ELF システム上では a.out のバイナリは次のようなエラーメッセージを出力して ふっ飛んでしまいます。 xrolodex: can't load library '//lib/libX11.so.3' No such library このようなことがあるために、この手のライブラリが /usr/i486-linuxaout/lib に置かれているのですが、xrolodex は実行時にラ イブラリの位置を見つけることができません。単純な解決法はシンボリックリ ンクを /lib ディレクトリに作ることです。 ln -s /usr/i486-linuxaout/lib/X11.so.3.1.0 libX11.so.3 同様のリンクを libXt.so.3 と libc.so.4 ライブラリについて作る必要があ ることもわかります。この作業はもちろん root で行う必要があります。ここ で注意ですが、既に入っているライブラリを上書きしたり、バージョン番号の 衝突が絶対に起こらないように確かめてください。幸い、こういった問題が起 こらないようにするため、新しい ELF ライブラリのバージョン番号は古い a.out ライブラリよりも大きくされています。 上記 3 つのリンクを張れば、xrolodex はうまく動きます。 xrolodex パッケージは元々 Spectro に投稿され ていましたが、今はここから消えてしまったようです。現在は Sunsite から tar.Z 形式で入手できます(サイズは 512K バイトです)。 7. トラブルシューティング xmkmf や make がエラーを出さずに正常終了したら、 ``次の節''に進んでく ださい。しかし「実際」には一発でうまく行くことはほとんどありません。こ こで、あなたの知恵が問われるのです。 7.1. リンクエラー o xmkmf を実行していたのに Link error: -lX11: No such file or directory というエラーで make が失敗する場合。これは Imakefile が適 切に設定されていないということかもしれません。 Makefile の最初あた りで以下のような行を確認してください: LIB= -L/usr/X11/lib INCLUDE= -I/usr/X11/include/X11 LIBS= -lX11 -lc -lm -L オプションはライブラリを探す場所をリンカに対して指定し、-I オプショ ンはインクルードファイルを探す場所をコンパイラに対して指定します。この 例の場合、 X11のライブラリは /usr/X11/lib ディレクトリにあり、 X11 の インクルードファイルは /usr/X11/include/X11 ディレクトリでなければなり ません。もし、これがあなたのマシンのディレクトリ構成と違っていたら、 Makefile に適当な変更を加えてから、もう一度 make を実行してください。 o 下のように計算のライブラリで関数の参照先が定義されていないというエ ラーが出る場合: /tmp/cca011551.o(.text+0x11): undefined reference to `cos' この問題を解決するには、Makefile の LIB と LIBS に -lm を加えて、明示 的に計算ライブラリにリンクさせてください(前の例を参照してください)。 o xmkmf が失敗するときには、下記のスクリプトを実行してみるのもいいで しょう。 make -DUseInstalled -I/usr/X386/lib/X11/config これは、機能をそぎ落として骨と皮だけにした xmkmf と同じ働きをします。 o ごく稀にですが、root になって ldconfig を実行すると問題が解決するこ とがあります: # ldconfig を実行すると、共有ライブラリへのシンボリックリンクが張り直 されます。これは必要でないかもしれません。 o Makefiles によっては、あなたのシステムにあるライブラリを、識別でき ないエイリアスで使っていることがあります。例えば、構築に libX11.so.6 が必要なのに、/usr/X11R6/lib にはそのようなファイルやリ ンクが存在しない場合です。しかし libX11.so.6.1 はあるとします。この 場合の解決方法は、 ln -s /usr/X11R6/lib/libX11.so.6.1 /usr/X11R6/lib/libX11.so.6 を root になって実行することです。リンク を張った後には ldconfig が必要かもしれません。 o たまに、ソースコードを構築するのに古い X11R5 のライブラリが必要なこ とがあります。もし、/usr/X11R6/lib の中に R5 のライブラリがある (最 初に Linux をインストールするときにオプションとしてインストールする かどうか聞かれます)場合には、ソフトウェアの構築に必要なライブラリに リンクを張るだけで大丈夫です。R5 のライブラリの名前は、 libX11.so.3.1.0, libXaw.so.3.1.0, libXt.so.3.1.0 です。通常 は、libX11.so.3 -> libX11.so.3.1.0 といったリンクが必要です。このソ フトウェアにはさらに libX11.so -> libX11.so.3.1.0 のようなリンクも 必要でしょう。もちろん、「足りない」リンクを作るには、root になって コマンド ln -s libX11.so.3.1.0 libX11.so を使います。 o パッケージによっては一つまたは複数のライブラリを更新する必要がある でしょう。例えば、StarDivision 社の StarOffice というオフィススイー トのバージョン 4.x は、バージョン 5.4.4 以上の libc が必要なことで 悪評が高かったです。もっと新しい StarOffice 5.0 でさえ、新しい glibc 2.1 ライブラリのシステムにインストールすると動作しません。幸 いなことに、さらに新しい StarOffice 5.1 では、こういった問題は解決 しています。古いバージョンの StarOffice を使っているなら、root に なって、いくつかのライブラリを適切なディレクトリにコピーし、古いラ イブラリを削除し、それからシンボリックリンクを再設定する必要がある でしょう(この作業に関する詳しい情報については、StarOffice miniHOWTO の最新版を見てください)。 注意: もし、失敗するとシステムが動作しなくなってしまうので、この作 業は十分注意して行ってください。 通常、最新のライブラリは Sunsite で入手できます。 7.2. その他の問題 o Perl やシェルスクリプトがインストールされているのに No such file or directory といったエラーメッセージが出る場合。この場合は、そのファ イルが実行可能かどうかパーミッションを確認してください。また、スク リプトの最初の行を確認して、スクリプトが呼び出すシェルやプログラム が正しく指定されているかどうかを確かめてください。例えば、スクリプ トは次のように始まると思います: #!/usr/local/bin/perl もし Perl が /usr/local/bin ではなく /usr/bin にインストールされていた らスクリプトは動作しないでしょう。これを動作させるには 2 つの方法があ ります。スクリプトファイルの最初の行を #!/usr/bin/perl と書き換える か、 ln -s /usr/bin/perl /usr/local/bin/perl を実行して、適切なディレ クトリへシンボリックリンクを張ってください。 o X11 のソフトウェアの中には、構築するのに Motif のライブラリが必要な ものがあります。普通の Linux ディストリビューションには Motif のラ イブラリは入っておらず、現在は Motif を使うには別途 $100〜$200 のお 金を出さなければなりません(ただし、フリーウェアの Lesstif でも多くの場合は動作します)。あるパッケー ジを構築するのに Motif が必要なのに Motif ライブラリがない場合で も、静的にリンクされたバイナリファイルが入手できるかもしれません。 静的なリンクとはライブラリルーチンをバイナリ自身の中に組み込んだも のです。その結果、バイナリファイルは巨大になりますが、ライブラリの 入っていないシステム上でもバイナリを動かすことができます。 あるパッケージの構築を行うためにシステムに入っていないライブラリが必要 な場合にはリンクエラーが起こります(undefined reference エラー)。ライブ ラリは高価な上に中身が秘密になっているかもしれませんし、何か別の理由で 見つけるのが困難なこともあります。こういった場合には、静的にリンクした バイナリをパッケージの作者から入手するか、 Linux のユーザグループから 入手するのがもっとも簡単な対処です。 o configure を実行するとおかしな Makefile、つまり構築しようとしている パッケージに関係がないように見える Makefile ができることがありま す。これは間違った configure、つまりパス中のどこか別のディレクトリ にある configure が実行されたということです。こんなことにならないよ うに、configure を実行するときは必ず ./configure という指定で呼び出 してください。 o ほとんどの Linux ディストリビューションは、古い libc 5 ライブラリか ら libc 6 / glibc 2 ライブラリに移行しました。古いライブラリで動い ていたコンパイル済みバイナリは、ライブラリをアップグレードすると動 かなくなるかもしれません。この問題に対処するには、アプリケーション をソースからコンパイルしなおすか、新しいライブラリに対応したコンパ イル済みバイナリを入手してください。システムを libc 6 にアップグ レードしようとしていて問題に遭ったなら Eric Green の Glibc 2 HOWTO を見るとよいでしょう。 glibc にはバージョン間の互換性のない部分が少しあるので、 glibc 2.1 で 作ったバイナリは glibc 2.0 では動かないかもしれませんし、その逆も起こ るかもしれません。 o Makefile のコンパイルオプションから -ansi オプションを外さなければ ならないことが時々あります。これを行うと、gcc の非 ANSI 拡張機能が 使えるようになり、その拡張機能を必要とするパッケージを構築できるよ うになります。(この点について指摘してくれた Sebastien Blondeel に感 謝します。) o プログラムによっては root 権限で動作させるために setuid root する必 要があります。この設定を行うには root になってから chmod u+s [ファ イル名] を実行します。(プログラムの所有者はあらかじめ root にしてお かなければならないので注意してください。)こうすることで、ファイルの パーミッションの setuid ビットが立ちます。setuid root しなければな らないという問題は、プログラムがモデムや CD-ROM ドライブのようなシ ステムのハードウェアにアクセスするときや、とある有名エミュレータの ように SVGAlib(SVGA操作ライブラリ)をコンソールモードから呼び出すと きに起こります。 root ならプログラムが動作するけれど一般ユーザだと access denied エラーが起こる場合には、この問題を疑いましょう。 警告: root に setuid したプログラムはシステムのセキュリティ上の危険 を伴います。root に setuid したプログラムは root 権限で動作するの で、致命的な被害を与える可能性があります。setuid ビットを立てる前に は、可能であればソースコードを読んでて、プログラムが何をするのかを 確かめてください。 7.3. 改善と最適化 Makefile を調べて、あなたのシステムに最適なオプションが設定されている かどうかを確かめるといいでしょう。例えば、-O2 オプションは最高レベルの 最適化を行い、-fomit-frame-pointer オプションは小さいバイナリを作成し ます(ただし、デバッグはできなくなります)。自分が何をやっているか分から ない場合や、どんな場合であれうまく構築できることが確かめられる前にはこ れらのオプションをいじらないようにしてください。 7.4. さらなる情報の入手先 私の経験によると、アプリケーションの 25% くらいは「何もしなくても」う まく構築できます。50% かそこらは、ちょっとしたことから大変な苦労までの 違いはありますが「何とか」構築できます。ということは、頑張ってもインス トールできないようなパッケージがかなりあるということです。それでももし かすると Sunsite や TSX-11 アーカイブで ELF や a.out のバイナリが見つ かるかもしれません。 Red Hat や Debian には、Linux でよく使われるソフトウェアのパッ ケージ化済みのバイナリを大量にアーカイブしています。もしかすると、ソフ トウェアの作者がちょうどあなたのマシンで使えるようなコンパイル済みのバ イナリを用意しているかもしれません。 コンパイル済みのバイナリを入手したら、お使いのシステムとの互換性を確認 する必要がある点に注意してください: o バイナリがあなたのハードウェア(例えば Intel x86 系マシン)で動作する か。 o バイナリはお使いのカーネルとの互換性があるか(つまり a.out 形式なの か ELF 形式なのか)。 o 最新のライブラリを必要とするかどうか。 o (rpm や deb)のような適切なユーティリティが必要かどうか。 これ以外の原因でだめだったら、 comp.os.linux.x や comp.os.linux.development といったニュースグループで助けてもらえるかも しれません。 [訳注: 日本語のニュースグループなら fj.os.linux、jlug.ml.users があり ます。しかし、これらのニュースグループで答えてくれる人は皆自分の空いた 時間を使ってボランティアで答えてくれています。決してメーカーのサポート ではないので、失礼な態度を取らないようにしてください。また、質問すると きには、わかりやすく、具体的に質問しましょう。また、問題が解決したな ら、解決したことの報告、解決の要因を忘れずに報告しましょう。] それでもダメだとしても、少なくとも最善を尽くし、たくさんのことを学んだ のだから、それはそれでいいのではないでしょうか。 8. 最後の仕上げ パッケージのドキュメントを読んで、(.bashrc や .cshrc で)環境変数の設定 が必要かどうか、あるいは .Xdefaults や .Xresources のカスタマイズが必 要かどうかを確認してください。 アプリケーションのパッケージにはデフォルトの設定ファイルがついているこ とがあります。普通、パッケージの名前が Xfoo なら、 Xfoo.ad という名前 になっています。もし設定ファイルがあれば、 Xfoo.ad をマシンに合わせて カスタマイズしてから、(mv を使って)名前を Xfoo に変 え、/usr/lib/X11/app-defaults ディレクトリにインストールしてください。 インストールは root になってやってください。この作業に失敗すると、ソフ トウェアの挙動がおかしくなったり、最悪、動作さえしなくなることがありま す。 ほとんどのソフトウェアには、整形済みの man ページが付属しています。 root になって Xfoo.man というファイルを /usr/man や /usr/local/man や /usr/X11R6/man の適切なディレクトリ (man1 - man9)にコピーして、適切な 名前に変えてください。例えば Xfoo.man を /usr/man/man4 に置く場合、(mv Xfoo.man Xfoo.4 を実行して) Xfoo.4 という名前に変えてください。リネー ムしてください。慣例では、ユーザコマンドは man1 に、ゲームは man6 に、 システム管理のコマンドは man8 に入れることになっています(詳しくは man docs コマンドを実行してください)。もちろん、そうしたければ、この慣習を 守らなくてもかまいません。 パッケージによっては、適切なシステムディレクトリにバイナリファイルをイ ンストールしてくれないものがあります。つまり、Makefile の install オプ ションの設定がないのです。このような場合は、バイナリを手動で適切なシス テムディレクトリ(/usr/bin, /usr/local/bin, /usr/X11R6/bin)にコピーして インストールしてください。もちろん作業はroot になって行います。 Linux ディストリビューションの基本コマンドでないようなバイナリは、 /usr/local/bin ディレクトリに入れるのが好ましいことも覚えておいてくだ さい。 大抵の場合、上記の一部あるいは全ての手順は make install や make install.man, make install_man 等で自動的に処理されます。そうなっている のであれば、README や INSTALL といったドキュメントファイルに明記されて いるはずです。 9. 最初の例: Xscrabble 私は ScrabbleTM にハマっているので、Matt Chapman の Xscrabble がとても 面白そうなプログラムに思えました。私は、これをダウンロードして、展開し た後、README ファイルに書かれている手順に沿って構築しました。 xmkmf make Makefiles make includes make もちろん動作しませんでした…。 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... 私は、この問題についてニュースグループの comp.os.linux.x で尋ねてみま した。すると、どうもリンクの段階で Xt, Xaw, Xmu, X11 のライブラリが見 つけられていないようだと親切な方が指摘してくれました。うーむ…。 Makefile は 2 つありますが、私は src ディレクトリにある方の Makefile に注目しました。Makefile の中で「LOCAL_LIBS = $(XAWLIB) $(XMULIB) $(XTOOLLIB) $(XLIB)」のように LOCAL_LIBS を定義している部分がありまし た。これらは、はリンカが見つけられ損ねているライブラリを参照していま す。 次に LOCAL_LIBS を参照している部分を探すと、 Makefile の 495 行目が以 下のようになっていました: $(CCLINK) -o $@ $(LDOPTIONS) $(OBJS) $(LOCAL_LIBS) $(LDLIBS) $(EXTRA_LOAD_FLAGS) この LDLIBS とは何なのでしょう? LDLIBS = $(LDPOSTLIB) $(THREADS_LIBS) $(SYS_LIBRARIES) $(EXTRA_LIBRARIES) SYS_LIBRARIES は以下の通りです: SYS_LIBRARIES = -lXpm -L../Xc -lXc これだ! 見つからなかったライブラリがありました。 もしかすると、リンカは LOCAL_LIBS よりも前に LDLIBS を見に行く必要があ るのかもしれません…。そこで、最初に試したのは Makefile の 495行目の $(LOCAL_LIBS) と $(LDLIBS) を入れ換えることでした。そうすればライブラ リを読みに行ってくれるでしょう: $(CCLINK) -o $@ $(LDOPTIONS) $(OBJS) $(LDLIBS) $(LOCAL_LIBS) $(EXTRA_LOAD_FLAGS) ^^^^^^^^^^^^^^^^^^^^^^^ 上記の変更を加えてから再び make を実行すると――まあ見てくださいよ―― 今回はうまくいきました。もちろん、 Xscrabble にはまだ微調整したり手を 加えたりする必要があり、ディレクトリの名前を変えたり、ソースファイルの 一つで宣言されている文をコメントアウトするといった事をしなければなりま せんでした。でもこれ以降の作業は、私に数時間の楽しい時間を与えてくれま した。 [現在、新しいバージョンの Xscrabble は rpm 形式で入手できます。また、 新しいバージョンは問題なくインストールできます。] 作者のメールでの連絡先は Matt Chapman であり、Xscrabble は彼のホームペー ジ からダウン ロードできます。 Scrabble は the Milton Bradley Co., Inc の登録商標です。 10. 2 番目の例: Xloadimage この例の問題は割と簡単です。xloadimage は私のグラフィックツール集に加 えると便利なプログラムのようです。私は Mui と Quercia が書いた素晴らし い本である ``X User Tools'' の付属 CD-ROM のソースディレクトリから xloadi41.gz を コピーしました。もちろん tar xzvf でファイルを展開しま した。しかし、make するとタチの悪そうなエラーが出て終了してしまいま す。 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 このエラーメッセージには重要な手がかりが含まれています。 image.h の 23 行目を見ると…。 #include なるほど、xloadimage のソースファイルのどこかで、 wchar_t が標準のイン クルードファイルである stdlib.h の定義から再定義されていました。まずは image.h の 23 行目をコメントアウトしてみましょう。同様に、たぶん stdlib.h もインクルードする必要はないだろうと見当をつけ、実際そのとお りでした。 この時点で、致命的なエラーも起こらずに構築できました。そして今でも、 xloadimage プログラムはちゃんと動いています。 11. 3 番目の例: Fortune この例は C 言語のプログラミングの知識をある程度必要とします。UNIX や Linux のソフトウェアのほとんどは C 言語で書かれているので、ソフトウェ アのインストールをまじめにやろうとするなら多少でも C 言語を覚えておけ ばきっと役に立つでしょう。 有名な fortune プログラムはユーモアのあることわざ、いわゆる "fortune cookie" を Linux がブートするたびに表示します。不運なことに(ここは unfortune にかけたシャレのつもり)、カーネルのバージョンが 2.0.30 の RedHat ディストリビューションでは致命的なエラーが発生します。 ~/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 fortune.c を見てみると、エラーの起こっている部分は以下の場所です。 if (dirent->d_namlen == 0) continue; name = copy(dirent->d_name, dirent->d_namlen); dirent 構造体を見付ける必要がありますが、fortune.c では定義されていま せんし、grep dirent で探してみても他のソースファイルで宣言されているわ けでもありません。しかし fortune.c の最初に次のような行があります。 #include これはシステムライブラリのインクルードファイルのようです。したがって、 必然的に dirent.h を探しに行く場所は /usr/include となります。実を言う と、/usr/include に dirent.h はあるのですが、dirent.h には dirent 構造 体の宣言はありません。しかし、他の dirent.h ファイルを参照するように なっています。 #include やっと /usr/include/linux/dirent.h までくれば、探している構造体の宣言 が見つかります。 struct dirent { long d_ino; __kernel_off_t d_off; unsigned short d_reclen; char d_name[256]; /* We must not include limits.h! */ }; やっぱり、構造体の宣言に d_namelen が入っていませんでした。しかし、そ れに相当しそうな「候補」が 2 つあります。そのうちもっともそれらしいの は d_reclen です。というのも、この構造体メンバは何かの長さを表している ようですし、short 型の整数だからです。もう一つの方は d_ino ですが、こ れは名前と型から考えると inode 番号のようです。実をいうと、ここでは 「ディレクトリエントリ」構造体を扱っていて、各要素はファイルの属性、 ファイル名、inode 番号、(ブロック単位での)長さを表しています。この事実 と突き合わせると推測が確実になるでしょう。 fortune.c を編集して、551 行目と 553 行目にある d_namelen への参照を d_reclen に書き換えてみましょう。それから make all をもう一度試しま しょう。成功しました。エラーもなしに構築できました。これで fortune を 使って「ちょっとどきどき」できますね。 12. 4 番目の例: Hearts とても古い Hearts というゲームがあります。これは 1980 年代のどこかで Bob Ankeney が UNIX 用に作成し、1992 年に Mike Yang が改訂し、現在は Jonathan Badger がメンテナンスして います。その前身は、Oregon Software の Don Backus が書いたもっと古い Pascal のプログラムであり、後に Jeff Hemmerling が更新しています。もと もとは複数の人間で遊ぶことを想定したゲームですが、コンピュータを相手に して一人で遊ぶこともできます。グラフィックスはいい感じですが、このゲー ムには凝った機能はありませんし、コンピュータと対戦してもあまり強くあり ません。それにもかかわらず、現在においても UNIX マシンや Linux マシン で生き残っているゲームはこの Hearts だけのようです。 古いため、また歴史的な経緯のため、このパッケージを Linux システム上で 構築するのは特に困難です。この作業では長くて複雑なパズルを解く必要があ ります。忍耐と決断力の訓練になるでしょう。 作業を始める前には、必ず motif または lesstif ライブラリをインストール しておいてください。 o xmkmf make 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 client.c ファイル中の問題を起こした部分を以下に示します: #ifndef SYSV (buf[2] != _tty.sg_erase) && (buf[2] != _tty.sg_kill)) { #else (buf[2] != CERASE) && (buf[2] != CKILL)) { #endif o client.c の 30 行目に #define SYSV を追加してください。これにより _tty への参照が回避されます。 make client.c:41: sys/termio.h: No such file or directory make: *** [client.o] Error 1 o インクルードファイル termio.h は Linux システムでは /usr/include ディ レクトリにあります。比較的古い UNIX マシンの場合のような /usr/include/sys ではありません。したがって、 client.c の 41行目を #include から #include に変更してください。 make 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 o 最近の Linux ディストリビューションは、時代遅れの termlib データベース ではなく terminfoデータベース や termcap データベースを使っています。 したがって Makefile を編集します。 655 行目の CURSES_LIBRARIES = -lcurses -ltermlib を CURSES_LIBRARIES = -lcurses -ltermcap に変更します。 make 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 o メインの lesstif ライブラリは libXm_s ではなく libXm です。したがっ て、Makefile を編集して、 653 行目の XMLIB = -lXm_s $(XTOOLLIB) $(XLIB) -lPW を XMLIB = -lXm $(XTOOLLIB) $(XLIB) -lPW にします。 make 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 o ここではいつもの容疑者を逮捕しましょう。 PW というライブラリはありません。Makefile を編集して、 653 行目を XMLIB = -lXm $(XTOOLLIB) $(XLIB) -lPW から XMLIB = -lXm $(XTOOLLIB) $(XLIB) -lPEX5 make 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 make がやっとうまくいきました(ばんざーい!)。 o インストール: root になって以下を実行します。 [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 o 実行テスト: rehash (tcsh を使っているものとします。) xmhearts localhost:~/% xmhearts Can't invoke distributor! o hearts 付属の README を見ると以下のように書いてあります: heartsd, hearts_dist, hearts.instr ファイルを local.h で定義され ている HEARTSLIB ディレクトリに置き、誰でもアクセスできるようにし てください。 local.h には以下のように書いてあります: /* where the distributor, dealer and instructions live */ #define HEARTSLIB "/usr/local/lib/hearts" これは「マニュアルをちゃんと読め!」の典型例ですね。 root になって以下の作業を行います。 cd /usr/local/lib mkdir hearts cd !$ それから、distributor ファイルをこのディレクトリにコピーします。 cp /home/username/hearts/heartsd . cp /home/username/hearts/hearts_dist . cp /home/username/hearts/hearts.instr . o もう一度実行テストをしてみましょう。 xmhearts これは動くことも時々ありますが、大抵の場合は dealer died! というメッ セージを出して止まってしまうでしょう。 o "distributor" と "dealer" はハードウェアのポートを叩きます。したがっ て、これらのプログラムが root 権限が必要としていることを疑うべきです。 root になって以下の作業をしてみましょう。 chmod u+s /usr/local/lib/heartsd chmod u+s /usr/local/lib/hearts_dist (前にも述べましたが、suid したバイナリはセキュリティホールになるかもし れないので注意してください。) xmhearts これでやっと動くようになりました! Hearts は Sunsite から入手できます。 13. 5 番目の例: XmDipmon ブルウィンクル: やあ、ロッキー。帽子からウサギを出すから見ててくれよ。 ロッキー: でも、うまくいったことなんかないじゃん。 ブルウィンクル: 今度こそうまくいくよ。 それっ! うーん、あとちょっとだね。 ロッキー: ということはそろそろ別の特殊機能を用意しなきゃね。 --- 「ロッキーとその仲間たち」より XmDipmon はインターネット接続の状態を表示するボタンを画面に出す気の利 いた小さなプログラムです。このプログラムは接続が切れると光ってビープ音 を出します。こういった事態は田舎の電話システムではとてもよく起こりま す。残念ながら、XmDipmon は dip と組み合わせてしか使えないので、接続に chat を使っている人達(こちらが多数派なのですが)の役には立ちません。 XmDipmon の構築は難しくありません。XmDipmon は Motif ライブラリをリン クしますが、Lesstif をリンクしてもうまく構築できます。難しいのは chat を使っている時にもこのパッケージが動作するように変えることです。これは 実際のソースコードの改造を含むので、プログラミングの知識がある程度必要 です。 「xmdipmon は起動時に /etc/dip.pid というファイルをチェックし ます(コマンドラインオプション -pidfile を使うと、別のファイ ルを参照させることもできます)。このファイルには dip デーモン のプロセス ID が入っています(dip はいったん接続が確立すると、 自分自身をデーモンモードに切り替えます)」 --- XmDipmon の README ファイルより -pidfile オプションを使うと、起動時に別のファイルをチェックするように プログラムに指示できます。このファイルは、chat ログインが正常にできて いる間だけ存在するものでなければなりません。すぐ思い付く候補としてはモ デムのロックファイルがあります。したがって、 xmdipmon -pidfile /var/lock/LCK..ttyS3 としてプログラムを起動すればよいかもしれません(こ の例ではモデムは COM ポート 4 番、ttyS3 にあるものとしています)。しか し、この方法で解決するのは問題の一部分だけです。プログラムは dip デー モンを連続的に監視するので、このプロセスではなく chat や ppp に対応す るプロセスをポーリングするように動作を変えてやる必要があります。 ソースファイルは 1 つだけですし、幸いなことに詳しいコメントが付けられ ています。xmdipmon.c を眺めてみると getProcFile という関数があります が、その先頭には以下のように書いてあります。 /***** * Name: getProcFile * Return Type: Boolean * Description: dip の pid ファイルから読み出した /proc エントリのオープンを試みる *****/ ここは頑張って調べるところです。関数の中身を読んでみましょう…。 /* we watch the status of the real dip daemon */ sprintf(buf, "/proc/%i/status", pid); procfile = (String)XtMalloc(strlen(buf)*sizeof(char)+1); strcpy(procfile, buf); procfile[strlen(buf)] = '\0'; 問題になるのは 2383 行目です: sprintf(buf, "/proc/%i/status", pid); ^^^^^^^^^^^^^^^^^^^^^ このコードは dip デーモンのプロセスが動作中かどうかを調べています。こ こで、どうすれば dip でなく pppd デーモンを監視するように変更できるで しょうか? pppd の man ページを読んでみましょう: FILES /var/run/pppn.pid (BSD または Linux), /etc/ppp/pppn.pid (others) ppp インタフェースユニット n の pppd プロセスのプロセス ID そこで、xmdipmon.c の 2383 行目を以下のように変更します: sprintf(buf, "/var/run/ppp0.pid" ); 修正したパッケージを再構築します。構築は問題ないはずです。次に、新しい コマンドライン引数をテストします。これは見事に動作します。ISP への ppp 接続が確立すると小さな青いボタンがそれを示し、接続が切れるとボタンが光 り、ビープ音がします。これで chat を完璧に監視できるツールができまし た。 XmDipmon は Ripley Linux Tools から入手できます。 14. ソースアーカイブの入手先 この文書で新しく覚えた知識を使って、ユーティリティや素晴らしいソフトを システムに追加したいと思ったら、ネットワーク上では Linux Applications and Utilities Page で見つかるでしょうし、 Red Hat , InfoMagic , Linux Systems Labs , Cheap Bytes 等からはとてもお買い得な CD-ROM アーカイブ が売られています。 ソースコードがたくさん置いてある場所としては、 comp sources UNIX archive があります。 たくさんの UNIX のソースコードがニュースグループの alt.sources にポス トされています。もし、特定のソースコードのパッケージを探しているのな ら、 alt.sources.wanted 以下の関連ニュースグループに投稿して聞いてみる とよいでしょう。チェックするとよい別の場所としては、 comp.os.linux.announce ニュースグループがあります。 Unix sources メー リングリストに入るには、本文に subscribe と書いたメールをこのメーリン グリスト宛に送ってください。 alt.sources ニュースグループのアーカイブは以下の FTP サイトにありま す。 o ftp.sterling.com/usenet/alt.sources/ o wuarchive.wustl.edu/usenet/alt.sources/articles o src.doc.ic.ac.uk/usenet/alt.sources/articles 15. 最後に まとめると、とにかく粘り強さが問題になります(また、フラストレーション への耐性があると役に立つでしょう)。努力することと同じく、間違いから学 ぶことも非常に大切です。それぞれの誤りや失敗により知識が豊富になり、ソ フトウェアの構築の技術を究めることができるでしょう。 16. 参考文献 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) [これらの HOWTO は、お使いのシステムの /usr/doc/HOWTO ディレクトリか /usr/doc/HOWTO/mini ディレクトリにあるはずです。最新版は LDP のサイト からテキスト、HTMO, SGML 形式で入手 できます。また、普通はそれぞれの著者のホームページからも入手できます] 17. クレジット 本 HOWTO の著者は、有益な提案、訂正、応援をしてくださった以下の方々に 感謝します。 o R. Brock Lynn o Michael Jenner o Fabrizio Stefani この HOWTO をイタリア語・日本語に翻訳してくれた人々にも称賛を捧げま す。 そして、もちろん Linux Documentation Project の Greg Hankins と Tim Bynum にお礼と称 賛、感謝、熱い賛辞を送ります。 LDP のおかげで全てができたのですから。 18. 日本語訳について 日本語訳は Linux Japanese FAQ Project が行いました。翻訳に関するご意見 は JF プロジェクト 宛に連絡してください。 改訂履歴を以下に示します。 v1.10, 8 September 1998 翻訳: 井田 司 v1.91j, 18 January 2000 更新: 藤原 輝嘉 校正: o 中野 武雄 o 武井 伸光