wmakerconf (libjpeg差し替えで大騒ぎ)

長らくβだったのだが、つい先日、wmconfig 1.0がリリースされたようなので、早速もらってきてパッケージ化することにした。すると、wmakerconfのホームページにリンクが置いてあって、すでにwmakerconf-1.0-1.i386.rpmなどとすっかりパッケージ化されているでわないか。なぁんだ、ぢゃもらってきて入れるべ、と思ったオレはアサハカだった(笑)

とりあえず、wmakerconfのパッケージをソース、バイナリとも念のため持ってきてインストールしてみると、ライブラリとかがぜぇんぜん足りなくて、入りゃしねぇ。オレの環境なんて必要条件にかすりもしなかった。

だって、依存関係を見てみると

imlib >= 1.7
gtk+ >= 1.0.5
WindowMaker >= 0.19.0

なんてなってんだもん(-_-#) imlibなんてハナッから入れてもいないし、gtk+もWindowMaker自体もオレのは古いらしい。おいおい… しかし、ここで引き下がってはコンダラ引きの名がすたるってもんだ。なんとかツジツマを合わせよう。バータリー指向でがんばるのだ。

wmakerconfのホームページによると、gtk+は1.0.2以降、WindowMakerは0.15.0なら実はよいらしい。てことは、imlib 1.7というヤツを持ってきて入れてやれば、バイナリのパッケージをそのまま使うことはできないまでも、自前でmakeすればなんとかなるハズだ。うむ。

てなワケで、RedHatのimlibのページからimlib-1.7-1.i386.rpmをもらってきて入れてみることにした。

だがダメだった…

このimlibってヤツ、なにしてくれるライブラリなのかよく知りもしないで突っ込もうとしたオレがバカなのだが、ほとんど全てのグラフィクス関係のライブラリに依存しているのだった。GTK+は言うに及ばす、ImageMagickだのなんだの、必要なライブラリがワンサカあるのよ。もう泣きそう。

結局、もう一度RedHatのimlibのページに行き、必要なライブラリを全部落してきた。えれ〜時間かかったぜ。だが、落してきたなかで本当に必要なのは、少ししかなかった。内訳は以下のとおりね。

結局、自分でmakeしていれる必要があったのは、libungifだけだった。これって実は、imlibのページのチョンボじゃないかと思うんだけど、置いてあるバイナリはlibungif-3.0-3.i386.rpmで、リビジョンが3なのに、ソースのほうはlibungif-3.0-4.src.rpmと、リビジョンが4なんだよね。まぁほとんど差はないんだろうけど、やっぱ同じページにより新しいソースがあるのに、わざわざ古いバイナリ持ってくるのってなんか気分わるいぢゃん。そらまぁ他のサイトを当たればもっと新しいimlibがあんぞ、とかあるのかも知れないけどさ。

しかもこのlibungifってちょっと変わってて、実はlibgif.soも含まれてたりする。同じimlibのページにgiflib-3.0.2-3.i386.rpmなんてのもあるが、これってお互いに同じlibgif.soを含んでいるから思いっきりコンフリクトするのだ(笑) なんだかなぁ。makeするときに中身を見たら、libungifのパッケージはgiflibパッケージへの依存関係も満たすようだったので、結局libungifだけを入れることにした。とりあえず問題はないようだ。

次に、ImageMagick関係はRedHatのCD-ROMに入っているヤツよりもimlibのページのほうが新しかったんで、持ってきた入れようとしたんだが、コイツがなんとlibjpeg-6b-5に依存していて、インストールできないし。しょうがないからlibjpeg-6b-5にアップデートするのを先にすることにした。

だがダメだった…

もともと、jpegのライブラリなんて当然だがインストールされていて、libjpeg-6b-3.i386.rpmというパッケージなんだけど、コレをlibjpeg-6b-5.i386.rpmで上書きしてアップデートすることができないのだ。見た目はリビジョン番号が3から5になっているだけなのに…

中見たらすぐに理由はわかった。どういう方針でバージョン番号を付けているのかは知らんけど、もともと入っていたjpegのライブラリはlibjpeg.so.6.0.0で、そのシンボリックリンクのlibjpeg.so.6の方を他のプログラムからリンクして使うようになっている。が、libjpeg-6b-5.i386.rpmに入っているライブラリはlibjpeg.so.62.0.0で、そのシンボリックリンクは当然libjpeg.so.62だ。メジャー番号自体が違うから、置き換えにはならんのよ。

しっかし、メジャー番号が6からいきなり62になるなんて絶対おかしいよなぁ。一度に56もバージョン上がっちゃうの？そんなのMicrosoftだっていまだかつてしたことないぜ(笑) libjpeg.so.6.2.0の間違いなんじゃねぇのか？？？

半信半疑でAltaVistaでlibjpeg.so.62で検索してみると、実はたくさんヒットして、libjpeg.so.62に依存するパッケージもたくさんあったし、libjpeg.so.62がロードできないよ、と言われて起動できないよ〜、などという話も見付かった。どうやらそういう名前らしい。あきらめて入れ換えることにしよう。

単純にrpm -Uvhなどとしてもアップデートできない以上、rpm -ivh --forceなどで強制的に叩き込むか、またはまずは古いjpegライブラリを削除して、それからインストールするという丁寧な手順を踏むか。古い方のlibjpeg.so.6.0.0に依存しているのは、オレの環境では幸いXEmacs-20.4とxv-3.10だけだったので、この2つのパッケージは後でmakeしなおすことにして、libjpegはヘッダファイルも含めて丁寧に差し替えることにした。

libjpeg-6b-5.i386.rpmとlibjpeg-devel-6b-5.i386.rpmをインストールすると、これでやっとImageMagick関連のライブラリをインストールすることができたぜ。やっとimlib 1.7もインストールできそう。はぁ、手間食ったぜ。

だが必要な作業はまだまだこんなもんじゃなかったのだ。

グラフィクス系のライブラリを片っ端から突っ込んで、ツジツマが合ってきたかに見えたコンダラ環境だったが、imlibのヤツ、さらにglibというパッケージが足りないなどと文句をたれてくださる。いったいglibってのはなに？

探してみると、たしかにglibというパッケージは入ってはいなかった。だけど、/usr/lib/libglib.so.1.0.4というライブラリそのものは入ってるんだよね。こいつはGTK+-1.0.4jpが提供するライブラリなんだが… で、しかたがないので、いつもrpmを漁りにいくftpサイトに行き、日本語化などの手の入っていない、もっとも素に近そうなgtk+-1.0.4.src.rpmというヤツを落してきて中を見てみると…

なんのことはない、gtk+-1.0.4.src.rpmからmakeすると、gtk+-1.0.4.i386.rpmとgtk+-devel-1.0.4.i386.rpmの他に、ちゃあんとglib-1.0.4.i386.rpmというパッケージを作ってくれるでわないか。ひょっとしてこれはgtk+-1.0.4.jpのパッケージミスか、それともなにか歴史的な経緯でもあって、glibパッケージを生成しないようにしてあるのだろうか？？

なんだか事情は良くわからんが、glib-1.0.4.i386.rpmの中身って、libglib.so.1.0.4と、そのシンボリックリンクのlibglib.so.1の2つが入っているだけで、これは今までもgtk+-1.0.4jp.i386.rpmに入っていたものだ。specファイルをちょっと書き換えるくらいで、大した作業は必要なさそうなんで、もう一度GTK+-1.0.4jpをmakeしなおすことにしたよ。めんどくさいからGTK+のリビジョン番号を1つ上げて、サクッとアップデートできるようにしとこう。

作り直したgtk+をインストールし終ると、rpm -ql glibなどとすると確かに元通りlibglib.so.1.0.4が入っているのが確認できた。この状態まできて、やっとimlib 1.7がインストールできた。はぁ。やっと下ごしらえが終ったぜ。

さぁ、いよいよwmakerconfのmakeか？

と思ったら、実はwmakerconfって、WindowMakerに含まれているlibPropListに依存しているのだった。今の段階ではWindowMaker 0.17.5という、安定しているバージョンが入っているのでこのままでもmakeできそうだが… 聞くところによると、すでにWindowMakerは0.19.0というバージョンが出ていて、そのバージョンだと、かねてから問題視されていたWINGsというwidgetセットが国際化され、従来は日本語が表示できなかったダイアログボックスなんかでも日本語の表示ができるようになっているらしい。う〜む、もらってくるか。

WindowMakerのホーム・ページに行ってみると、すでに0.19.1が出ているではないか。すかさずもらってきてパッケージにしてみた(とか言って、コレを書いている時点ですでに0.19.2が出てるよ…ついてけん)。WindowMakerのページからたどれるftpサイトにも、コンパイル済みのバイナリがあるんだけど、どういうワケだかいまだにlibc5版しかないんだよね。だから、glibcでwcsmbsなコンダラ環境だと、もはや自分でパッケージを作るしかないのだ。

以前に0.17.5はパッケージ化してあったんで、それをちょこちょこモディファイして新しいパッケージ自体はすぐに作ることができた。メッセージ関係がGNUのgettext対応になってるんだけど、日本語のpoファイルの文字コードがiso-2022-jpなうえ、さらに1箇所間違いがあったんで、それを直した上でEUCにコード変換する必要があったが、その他には特に何も問題はなかった。

wmaker.instを実行して環境設定ファイルを生成させ、さらに馬目さん作のsetlinguasというscriptで日本語な設定ファイルを整える。オレのパッケージでは/usr/doc/WindowMaker-0.19.1/setlinguasというのがインストールされているのでそれを使うのだ。さらに新しく追加になった ~/GNUstep/Defaults/WMGLOBAL というファイルにちょっと手を入れることにする。

{
  SystemFont = "-*-helvetica-medium-r-normal-*-%d-*-*-*-*-*-*-*";
  BoldSystemFont = "-*-helvetica-bold-r-normal-*-%d-*-*-*-*-*-*-*";
  DoubleClickTime = 250;
}

インストール直後だと上記のようになっているが、オレはX-TTなXサーバを使っていて、DynaLABのフォント集を入れてあるので今回は丸ゴシックを日本語フォントとして使うことにして見た。

{
  SystemFont = "-*-helvetica-medium-r-normal-*-%d-*-*-*-*-*-*-*,-dynalab-dfmarugothic-*-r-normal-*-%d-*-*-*-*-*-jisx0208.1983-0";
  BoldSystemFont = "-*-helvetica-bold-r-normal-*-%d-*-*-*-*-*-*-*,-dynalab-dfmarugothic-*-r-normal-*-%d-*-*-*-*-*-jisx0208.1983-0";
  DoubleClickTime = 250;
}

TrueTypeなフォントを使えない人も、日本語フォントを適切に選んでカンマで続けて書くだけなので苦労はしないと思う。

立ち上げて早速ダイアログボックスなどを見てみると… こんな感じになる。終了時のダイアログボックスはこんな感じだ。いいでしょ(笑)

大事な設定として、上記のとおり、setlinguas jaとして設定ファイルを日本語向けにし、WMGLOBALに変更を加えたあと、export LINGUAS=ja とするのがキモだ。絶対に忘れないようにしよう。

やれやれ、やっとwmakerconfのパッケージを作れるよ。ひろってきたバイナリはGTK 1.0.5以降が指定されてるから、そのままぢゃ使えない。makeしなおすしかないんだよな。クソ。

で、wmakerconfのソース・パッケージをインストールして、specファイルをちょっと書き換えてGTKのバージョンチェックを1.0.4jp以降に変え、rpm -ba でまずはサクッと一通りmakeしてみることにする。

だがダメだった…

誰だよこれをパッケージしたヤツわ。なになに、Michael Hart？ ダメだよMichaelよ〜。configureを動かしたいなら、./configureって書いてくれよ。あんたひょっとしてカレントパスをPATHに含めてる人？DOSぢゃないんだからさぁ。やめといたほうがいいと思うぜ、そういう設定。危ねぇしさ。

もとい、そうそう、specファイルの記述がタコで、一発じゃmakeできなかったのよ、とにかく。で、気を取り直してspecファイルを修正し、今度はうまくいった。いったんだが、どうも様子が変なんだよね。日本語なんか一切使っていないのに、なんつ〜か、テキストというテキストがうまくエコーバックされないのだ。英数字でさえも。なぜだ…

結局、一番クサそうなのは、gtk_init()を呼び出す前に、LOCALEをセットしていないからじゃないか？と気がついたので、その辺のパッチをバータリー指向で作り、もう一度makeしてみた。今度はどうだ？

おぉ！イケてるか？ が、一見ちゃんと動いているようなのだが、いろいろといじくり回していると、なにやら標準エラー出力にgtkかららしいメッセージが出力されて、ブチ落ちる時がある。うむ〜。

これはどうも、gtkconvと相性が悪いみたいだ。結局のところ、gtkconvって、gimpで使うメニューやらメッセージを別ファイルとして持っておき、表示するときに差し替えて日本語メニューを出す、という仕組みらしいけど、放っとくとgimpだけじゃなくて、gtkを使うアプリ全部に適用されちゃうみたいなんだよね。だけどメッセージの中身なんて汎用じゃないから、あったりなかったりするのは当然だ。やっぱり、本来はgettextで実装するべき機能なんじゃなかろうか。常々思ってはいたけれど…

同じような現象が、同様にgtk+を使うgladeでも起きていたんで、もうここまで来たらやっちまえ。gtk+はもう一度makeしなおしだ(笑) gtkconvを外しちゃえ。どうせオレはgimpをスキャナのフロントエンドとしてしか使ってないし、英語メニューで充分だぜ。

ついでに、gimpもmakeしなおしだ(ビルド・ハイな状態)。plug-inのほとんど全部が、gtk_initの前にLOCALEをセットするってのをやってないもんね。不都合がでるまえに、全部直しちゃえ。もしも赤帽でwcsmbsな環境の人で、gimpのscript-fu、特にconsoleなどがうまく動かない人は、まずまちがいなくこのLOCALEのセット忘れが原因だとおもう。

てなワケで、ド根性で関連するパッケージもみな作りなおしたよ。ったく、wmakerconfひとつ入れるのに、えらい騒ぎだぜ。でもまぁ確実に環境は進歩しているハズだ。よしとしよう。

で、もう一度wmakerconfを動かし、いろいろいじくり回してみる。おぉ… 安定している… しかもカッコイイぜ！こ、こんなのがソースからフリーでいいワケ？ ちょっと見てごらんよ。

はぁ〜、苦労したぜ。