| エンタープライズ：特集 | 2003/09/26 18:00:00 更新 |
特集：第2回 RPM活用のステップアップ−SRPMリビルドとコンパイルマスター (5/6)
エラー解決のコツ
ここからが正念場だ。コンパイルは成功するとは限らない。失敗する原因はさまざまであり、時としてソースファイルに触れなければならないこともある。ここではSPECファイルの問題やファイルの有無など、解決が比較的容易な例をいくつか挙げてみよう。
ex.1 「パッケージ依存」。サンプルにしているbalsaを一般的な構成のRed Hat Linux 9でコンパイルすると、途中で以下のようなメッセージが表示されストップしてしまう。
|
〜前略〜 checking for libgnomeprint-2.2 >= 2.1.4 libgnomeprintui-2.2 >= 2.1.4 ... Package libgnomeprintui-2.2 was not found in the pkg-config search path. Perhaps you should add the directory containing `libgnomeprintui-2.2.pc' to the PKG_CONFIG_PATH environment variable No package 'libgnomeprintui-2.2' found configure: error: Library requirements ( libgnomeprint-2.2 >= 2.1.4 libgnomeprintui-2.2 >= 2.1.4 ) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. エラー: Bad exit status from /var/tmp/rpm-tmp.21713 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.21713 (%build) |
これは依存関係と同じであり、使用するライブラリ、libgnomeprint、libgnomeprituiのバージョンが低いというエラーだ。パッケージチェックの段階で検出されたのでパッケージ名が分かるだろう。rpmfind.netなどで該当するパッケージを探し、随時インストールしながら回避していく。
ex.2 「必要なファイルの存在」。「/usr/lib/libgthread.la」というファイルがなく、エラーになったとする。その場合には、エラー表示ストップした個所から上に少しスクロールさせていけば、メッセージに「Not find」などと表示されているはずだ。
しかし「libgthread.la」という単独のファイル名では、それがどのパッケージに含まれるのかは分からない。手掛かりを得るには、同じファイル名の既存ファイル名からクエリーをかけることだ。ライブラリやヘッダ系のファイルであれば「.la」はなくとも、同じ名前の「.so」（共有ライブラリ）や「.a」（a.out形式のライブラリ）、「.o」（オブジェクトモジュール）というサフィックスのついたファイル名がある。通常、これらは同一のdevel系パッケージに含まれている。そこで次のように入力する。
|
# rpm -qf /usr/lib/libgthread.a glib-devel-1.2.10-10 |
これでファイルを供給しているパッケージ名が分かる。もしも「glib-devel」パッケージはインストール済みであり、「libgthread.aがあるのにlibgthread.laがない」という場合には、glib-develをsrc.rpmからリビルドし、インストールし直す。rpmのバイナリパッケージは使用頻度の低いファイルが間引かれていることもあるからだ。
|
%makeinstall # Remove files that should not be packaged rm $RPM_BUILD_ROOT%{_libdir}/*.la |
SPECファイル中にこのような記述があれば「.la」ファイルはパッケージから除外される。この部分をコメントアウトしてリビルドしなおせばよい。
ex.3 「SPECファイルのマクロ定義」。自ディストリビューション向けのsrc.rpmがなく、他ディストリビューション向けのものを利用したとする。rpmfind.netなどで比較的新しいバージョンが揃うのはMandrakeだが、MandrakeのSPECファイルを使うと書式や設定される環境変数の違いから、しばしばエラーが起きる。次のような例だ。
|
〜前略〜 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.1148 + umask 022 + cd /usr/src/redhat/BUILD + cd libgnomeprintui-2.2.1.3 + LANG=C + export LANG + %configure2_5x /var/tmp/rpm-tmp.1148: line 29: fg: no job control エラー: Bad exit status from /var/tmp/rpm-tmp.1148 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.1148 (%build) |
これは「%configure2_5x」というマクロが理解できずにストップしていることを意味する。SPECファイルを覗いてみると、以下のようになっている。
|
# less libgnomeprintui.spec 〜中略〜 %build %define __libtoolize /bin/true %configure2_5x %make 〜以下略〜 |
こうした特定のディストリビューションを前提としたマクロ名、環境変数が理解できない場合には、余計なオプションや環境変数を取り除いてやるとエラー回避できることがある。上記の例であれば、
|
%configure2_5x ↓ %configure |
と修正するとエラー回避されることがある。
ex.4 「src.rpmが存在しない」。最新のライブラリになると、src.rpmもなく、tarボールのソースファイルのみ提供されているという場合がある。しかし、そのままmake、make installしてしまってはRPMで管理する意味がない。どうすればよいのだろうか。
このような場合には、「sh ./configure; make」としていちどコンパイルする。ただし、「make install」を実行しない。どのファイルが必要であるのかは、たいていエラーメッセージの中に含まれているので、コンパイルしたビルドツリーから手作業でファイルを該当ディレクトリへ配置する（なお、tarballからRPMを作成する方法については次回説明する）。
| One Point： |
| 「./configure」実行時に「--prefix」オプションでインストールの配置ディレクトリを指定する方法もある。ただし、RPMの管理下にはなくなるのでお勧めはしない。 |
[渡辺裕一，ITmedia]
