小学館版 学習まんが人物館 藤子・Ｆ・不二雄

藤子・Ｆ・不二雄大全集は、まだぜんぜん読めてませんが、全集の最初の3冊を買った帰り道、なんとなく立ち寄った某古書店で、見つけました。

小学館版　学習まんが人物館
藤子・Ｆ・不二雄
こどもの夢をえがき続けた　「ドラえもん」の作者
監修／藤子プロ
まんが／さいとう　はるお
シナリオ／黒沢哲哉

この本は、藤本弘先生が亡くなった後に出た本で、当時、書店で見かけたとき、なんだこれ？と思って、見向きもしていなかったんですけど、数年前から、もしも見つけたら、手に入れておこう、と思ってました。偶然にも、全集を買ったその日に、お手ごろ価格で入手できちゃいました。

2001年4月10日 第5刷と、増刷を重ねているようでして、実は人気のある書籍だったり？！

私は珍本だと思ってたんですが、amazonでも、在庫ありますね。

学習まんが人物館というシリーズは、けっしてまんが家を取り上げた本ではなくて、藤本先生以外には、手塚治虫もあるようですが、キュリー夫人とかエジソンとか豊臣秀吉とか、歴史に名を残す偉人を取り上げるもの・・・らしいです。

前半は、安孫子先生の「まんが道」のanother side storyって感じです。おおむね、まんが道と同じですが、藤本先生が就職して辞めた話、上京するときの藤本先生が描かれています。

あと、まんが道で謎の伏線か？！と思われている、「藤本先生、咳こんで、重病なのか！」のシーンも、詳しく描かれているのには驚きました。

まあ、読んでからのおたのしみ、ということで。

・・・この本の内容、どこまでが真実？　どこからフィクション？　

あれ？そうだったの！？と思ったのが、ペンネームを藤子不二雄を変更したのは、実は、東京に出てきてすぐだった、ということ。まんが道では、原稿を落としまくった後にペンネーム変更をしているので、まんが道の方が真実だと思い込んでました。

それと、原稿落としまくり事件の後、藤本先生が単身で上京してきて一人でお詫びの電話をかけたりしてた描写。藤本先生は社交的なことは苦手、といった話を聞いていたので、今回この本を読んで、えーそうだったの？と思ったんですけど。

後半は、「まんが道」にも、「愛しりそめし頃に」にも、描かれていない内容です。トキワ荘を出る話、少年サンデーの創刊、スタジオ・ゼロの設立～解散、オバケのＱ太郎の大ヒット、ドラえもん誕生、藤子不二雄コンビ解散、藤本先生の最期のとき、・・・などなど。

まあ、これらの話は、個々に、いろんなところで語られていたりしますし、これは子供向けの本ですしページ数も限られているので、あまり深くは描写されていません。

巻末には、「学習資料館　藤子・Ｆ・不二雄…ひとと時代」という資料編がついてまして、写真とか、代表的な作品の紹介、年表なんかが掲載されています。

そういえば、「未来の想い出」を、まだ読んだことがなかった。

(Solaris) SUN_LENがundefined

先日、Solaris8で見たこと。

pkgsrcで、xrandrをxrandr-1.3.0へアップデートしようとしたら、pkgsrc/math/nickleというのもついでにビルドされるようになったんですが、途中で、こんなエラー

In file included from lex.l:16:
/work/pkgsrc.work/math/nickle/work/.buildlink/include/readline/readline.h:379: warning: function declaration isn't a prototype
lex.c:2680: warning: 'yyunput' defined but not used
gcc -Wall -Wpointer-arith -Wstrict-prototypes  -Wmissing-prototypes -Wmissing-declarations  -Wnested-externs -fno-strict-aliasing -fwrapv -O -I/usr/pkg/include -I/usr/include -I/usr/pkg/gcc34/include  -L/usr/pkg/gcc34/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.6 -Wl,-R/usr/pkg/gcc34/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.6 -L/usr/pkg/gcc34/bin/../lib -Wl,-R/usr/pkg/gcc34/bin/../lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -L/usr/pkg/gcc34/lib -o nickle  alarm.o array.o atom.o  box.o compile.o debug.o  divide.o edit.o error.o  execute.o expr.o file.o  float.o foreign.o frame.o  func.o gcd.o hash.o int.o  integer.o io.o main.o mem.o  natural.o pretty.o profile.o  rational.o ref.o refer.o  sched.o scope.o stack.o  string.o struct.o symbol.o  sync.o type.o union.o util.o  value.o builtin-command.o  builtin-debug.o builtin-environ.o  builtin-file.o builtin-math.o  builtin-semaphore.o builtin-sockets.o  builtin-string.o builtin-thread.o  builtin-toplevel.o builtin-pid.o  builtin.o builtin-foreign.o gram.o  lex.o  -ldl -lresolv -lsocket -lnsl -lm  -lreadline -lncurses
Undefined                       first referenced
symbol                             in file
SUN_LEN                             builtin-sockets.o
ld: fatal: Symbol referencing errors. No output written to nickle
collect2: ld returned 1 exit status
*** Error code 1

nm builtin-sockets.oしてみると、ああなるほど、未定義だね、と。

[42]    |         0|       0|NOTY |GLOB |0    |UNDEF  |Reduce
[27]    |         0|       0|NOTY |GLOB |0    |UNDEF  |SUN_LEN
[47]    |         4|       4|OBJT |GLOB |0    |COMMON |SocketNamespace
[35]    |         0|       0|NOTY |GLOB |0    |UNDEF  |StackPush
[54]    |         0|       0|NOTY |GLOB |0    |UNDEF  |StackReset

とりあえずソースコードを、grep SUN_LEN * してみると、

builtin-sockets.c:    *len = SUN_LEN (addr);

・・・と、これしかない。マクロっぽい名前なので

ggrep -R SUN_LEN /usr/include/ とかやってみますと、なにもない。そりゃぁ未定義になるわけです。

FreeBSDで同じくgrepしてみますと、すぐ見つかりました。

% grep -R SUN_LEN /usr/include/
/usr/include/sys/un.h:#define SUN_LEN(su) \

↓　こんなのです。

#define SUN_LEN(su) \
        (sizeof(*(su)) - sizeof((su)->sun_path) + strlen((su)->sun_path))

というわけで、上記の２行を、builtin-sockets.cの中にコピー＆ペーストして、解決させました。

☆

ネット検索してみると、SUN_LENがSolarisには無い、というのはどうもFAQっぽいですね。

大体１５年くらい昔は、インターネット上で配布されているソフトウェアは（あのころは、オープンソースなんて用語はなかった）、SunOSでビルドできるのが当然、というくらいにSunOSの地位は高かったんですが、Linux等の台頭につれて、それもなくなりました。

ちなみに、SUNってのは会社名のことじゃなくて（誰もそんなことは思わないか）、UNIX domain Socketのことですね。

それにしても、このマクロSUN_LENの中身、低レベルなことやってて、いかにもＣ言語っぽいなぁ。

でも、こういうのができるからこそ、Ｃ言語だ、という気がします。

どっちかというと、sockaddr_un構造体の定義自体が、なんだかなぁ、という気がします。

FreeBSDの場合、こんなの。

/*
* Definitions for UNIX IPC domain.
*/
struct sockaddr_un {
        unsigned char   sun_len;        /* sockaddr len including null */
        sa_family_t     sun_family;     /* AF_UNIX */
        char    sun_path[104];          /* path name (gag) */
};

まあ、今どきの考え方に照らし合わせてみると、気持ち悪い、ってことですが。
なんだよ、104って何？みたいな。

(FreeBSD) panic get_pv_entry: increase vm.pmap.shpgperproc

いろいろと忙しく仕事している、（５月ころbuildworldした）FreeBSD 7.2-STABLEなマシンで、先日、kernel panicが発生しました。

get_pv_entry: increase vm.pmap.shpgperproc

というメッセージが残されていました。

しかも、このkernel panic、立て続けに、数回発生。

けっこう安定して動作していたのに、突然の連続kernel panicで、ちょっと嫌な気分。

ネット検索してみると、この辺に、似たような話を発見。7.0-RELEASE-p5の場合で、ちょっと違いもありますが。

kernel: Approaching the limit on PV entries...
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2052953+0+archive/2008/freebsd-questions/20081012.freebsd-questions

kernel panicするという話も、こちらに出てます。
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2082943+0+archive/2008/freebsd-questions/20081012.freebsd-questions

pv_entryについて、少し解説がされてました。
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2094590+0+archive/2008/freebsd-questions/20081012.freebsd-questions

☆

このpanicを発生させているのは、src/sys/i386/i386/pmap.cです。

7.2-STABLEは、RELENG_7ブランチなので、ソースコードはこれ（i386版なので）。
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/pmap.c?rev=1.594.2.18;content-type=text%2Fplain

get_pv_entryという関数の中ですね。

私が見たケースでは、

Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.

というメッセージは残っていませんでした。ディスプレイを接続していなのでわかりませんが、コンソール画面には出ていたかもしれないですけど。

さてさて、

get_pv_entry: increase vm.pmap.shpgperproc

でkernel panicしてるのは、ここですが・・・

/*
* Access to the ptelist "pv_vafree" is synchronized by the page
* queues lock.  If "pv_vafree" is currently non-empty, it will
* remain non-empty until pmap_ptelist_alloc() completes.
*/
if (pv_vafree == 0 || (m = vm_page_alloc(NULL, colour, (pq ==
    &vm_page_queues[PQ_ACTIVE] ? VM_ALLOC_SYSTEM : VM_ALLOC_NORMAL) |
    VM_ALLOC_NOOBJ | VM_ALLOC_WIRED)) == NULL) {
    if (try) {
        pv_entry_count--;
        PV_STAT(pc_chunk_tryfail++);
        return (NULL);
    }
    /*
     * Reclaim pv entries: At first, destroy mappings to
     * inactive pages.  After that, if a pv chunk entry
     * is still needed, destroy mappings to active pages.
     */
    if (pq == NULL) {
        PV_STAT(pmap_collect_inactive++);
        pq = &vm_page_queues[PQ_INACTIVE];
    } else if (pq == &vm_page_queues[PQ_INACTIVE]) {
        PV_STAT(pmap_collect_active++);
        pq = &vm_page_queues[PQ_ACTIVE];
    } else
        panic("get_pv_entry: increase vm.pmap.shpgperproc");
    pmap_collect(pmap, pq);
    goto retry;
}

よくわからないっす。

panicするんじゃなくて、システムコール（？）を失敗させるとか、もしくは、processをkillしちゃうとか（どうも、ここで必要なメモリ量は、process数と関係しているっぽいので）、何かもう少しましな方法があるんじゃないかと思うのですが・・・

swap不足になったとき、processがどんどこkillされたりしますねよ。あんな感じでいいので、とりあえず、OSとしては運用を継続して欲しいところです。

panicされちゃうと、file systemがdirtyのままになるので、fsckに時間がかかってたまらないし、なによりも、ファイル内容の破壊が怖いです。

☆

とりあえずの解決方法。

vm.pmap.shpgperprocを増やせ、といってるので、増やしてみました。

これ、OSが立ち上がった後では変更できないパラメータなので、/boot/loader.confで指定しなければなりません。

ですが・・・、どんだけ増やせばいいのか？　よくわかんないです。

デフォルトが200で、とりあえず50増やしてみて、やっぱりpanic。また50増やして・・・とやっていって、400でどうやらpanicしなくなったようです。

何をしたとき、pv_entryが不足するのか？・・・それが気になって、こんなシェルスクリプトを走らせておいて、いろいろ負荷をかけて観察してみました。

#! /bin/sh

( while [ /bin/true ] ; do
    sysctl vm.pmap
    sleep 0.5
  done ) | awk '
/pg_ps_enabled/ { printf("\n"); }
{ printf("%d ", $2); }
'

実行すると、こんな感じで、sysctl vm.pmapで表示される値を、表示しつづける、というもの。一部のパラメータは（ひたすらカウントアップしていくらしい）、signed intのために、負の値へ突入しちゃってますね。

0 0 0 68464 -2143457166 -2144110094 0 8838034 8840181 2147 652928 0 0 0 0 400 3362352
0 0 0 68797 -2143455008 -2144107939 0 8838043 8840191 2148 652931 0 0 0 0 400 3362352
0 0 0 68922 -2143449222 -2144106732 0 8838049 8840211 2162 657510 0 0 0 0 400 3362352

ところで、このスクリプト、改行位置が１列分、ずれてるみたい。awkで実行する2行を入れ替えればいいのかな。

で、観察してみたんですが、panicしなくなっちゃって、結局よくわからなかったです。
けっこうたくさんのプロセスが起動していても、手計算してみると、８０％くらい、余裕で空きがあるように見えたんですが。

よくわかんないですねぇ・・・

% sysctl vm.pmap
vm.pmap.pmap_collect_active: 0
vm.pmap.pmap_collect_inactive: 0
vm.pmap.pv_entry_spare: 68508
vm.pmap.pv_entry_allocs: -2142835831
vm.pmap.pv_entry_frees: -2143492075
vm.pmap.pc_chunk_tryfail: 0
vm.pmap.pc_chunk_frees: 8840296
vm.pmap.pc_chunk_allocs: 8842453
vm.pmap.pc_chunk_count: 2157
vm.pmap.pv_entry_count: 656244
vm.pmap.pde.promotions: 0
vm.pmap.pde.p_failures: 0
vm.pmap.pde.mappings: 0
vm.pmap.pde.demotions: 0
vm.pmap.shpgperproc: 400
vm.pmap.pv_entry_max: 3362352
vm.pmap.pg_ps_enabled: 0

しかも、これって、一般ユーザー権限でkernel panicを発生させられちゃうので、local user exploitableなDoSじゃん？　と思うわけで・・・

赤い雲

藤子・Ｆ・不二雄の全集の３冊は、後日じっくりと読むことにして、先に読み始めていたこっちの本。

西岸良平名作集
赤い雲

猫のワニ丸が、途中から、かわいい絵になっていくように見えたんですが、「この猫、いいキャラだ、使えるぞ」なんて思って、路線変更したんでしょうかね。

さて、最近は少なくなりましたが、一昔前は、「兄と妹」という設定は、アニメでよくありました。

その兄と妹モノを西岸良平に描かせると、こうなるぞ！って感じでしょうか

といってもこんな↑作品じゃないです、この本は。このコマだけ。

 

07月28日のココロ日記(BlogPet)

今週のブログ妖精界でのヒットソングは「在庫のラブソング」みたいです。

*このエントリは、ブログペットのココロが書いてます♪

藤子・Ｆ・不二雄大全集

最初に、藤子・Ｆ・不二雄の全集が出ると聞いたとき、正直なところ、一瞬ひるみました。

いったい、何冊でるんだ。価格はいくらになるんだ。全集とはいえ、収録されない作品もあるんじゃないか・・・などなど。

というわけで、あんまりノリ気ではなかったんです。そろそろ発売なんだっけ？あれ、７月２４日に発売されてたんだ！そんな感じ。

それが昨日、７月２５日の土曜日の夜のこと。全集のウェブサイトで情報収集して、とりあえず、最初だけ買ってみて、それで考えようかな、そういう気分になってきました。

で、amazonをチェックしたら（amazonで本を買ったことないけど）、おっと、在庫切れ。あれ？何、意外と評判よかったりするの？

なんてことになり、日曜日の昼、自転車で、駅にある本屋に行ったら・・・、売ってねー。ポスターは貼ってあるけど。当書店で全巻予約受け付けてますよ～というポスター。その書店は、先ごろ出た「ＴＰぼん」の３巻を発売日直後には売ってたくらいの規模だから（よくわからない例えだな）、そんな小規模ではないんです。

日曜日の昼間。カンカン照りの真夏状態。ひょっとして、自転車であちこち書店めぐりしないとまずいっすかね？なんて予感がしつつ、隣の駅の近くの書店に行ったら、幸運にも、めぐりあうことができました。平積みで。あーよかった。

• パーマン
• オバケのＱ太郎
• ドラえもん

オバケのＱ太郎は、大人の事情なのかよくわかりませんが、事実上の廃刊状態というか、新品の本は流通しておりませんでして、近年、入手難が続いてました。しばらく前の「コロコロ伝説」で、ちょっと風向き変わったかな、という状況になってきていたところへ、今回の全集の刊行。これはとてもうれしいですね。

さてさて、予想以上に、分厚いです、この本。持って帰るのが、ちょっと苦労しました。

そして、寝転んで読むには、腕が疲れます。

買ってきてすぐに、とりあえず、３冊の中で、一番薄い「パーマン」を読み始めたんですが、まだ5分の1くらい。

感想を書こうにも、まだそんなじゃ書けません。

１つだけ。

私が持っている文庫版では、たしか「超人」ってなっていたところが、今回の全集では、「スーパーマン」になっていて（初出に戻った！）、なかなか好感をもてます。

こんなの誤検出だよね！ と思ってた ～ AVGでiTunesが「トロイの木馬Small.BOG」

AVG Avti-Virus Free Editionがをインストールしてかれこれ何年、役にたってるのかどうかまったくわかりませんでしたが、昨日、初めて、なにやら感染してるぞ～！とか言い出して・・・「トロイの木馬Small.BOG」って。

iTunesが起動しなくなったなぁ・・・まぁいっかぁ

こんなの、どうせ誤検出にきまってる！！と決め付けて無視しておりました

案の定、さっきAVGのアップデートを実行したら、AVGは文句を言わなくなりました。

Googleで検索してみると、これは誤検出だと言うブログ記事がたくさん見つかりますが、AVGのウェブサイトでは、見つけられなかった　・・・無料版だからっすか？

燻製のようなもの

先週、ひさしぶりに、段ボール箱で、燻製（のようなもの）を作りました。
すぐに火が消えてしまって、けっこう手間取りました。

やっぱりチーズは、燻製にすると、すごくおいしくなります。

パインマンゴー

ベトナム式ミックス飲料
パインマンゴー

あまりマンゴーな風味は全面には出てなかったです・・・

そういえば、今年は、マンゴーな飲み物・食べ物をあまりみかけないなぁ。ブームは終わった、ということかな。

☆

ローソンでも今おにぎりが１００円というので行ってみたら、もともと１０５円のおにぎりばっかりだった。なんだかなぁ・・・

瞬殺で売り切れていたのか、もともと数が少ないのか、それとも、今だけ数が少なくされているのか。

別のコンビニで１００円のときは、いつも、ちゃんとそろってるけどな。全部売り切れのときもあったけど。

■ 過去記事

• コッペパン　マンゴー＆ホイップ
• マンゴー＆オレンジ メロンパン
• 帰ってきた「アルフォンソマンゴー水」
• すっきりマンゴー
• ショコライフ　アルフォンソマンゴー
• のむ豆乳ヨーグルト仕立　まろやかマンゴー
• マンゴー＆オレンジ サワー
• 頭脳パン　アップルマンゴー＆クリーム
• タカナシ　夏季限定　マンゴー
• 午後の紅茶　マンゴー＆オレンジティー
• マンゴーメロンパン　　チーズホイップ
• アルフォンソマンゴーティー
• アルフォンソマンゴー水
• ガリガリ君　マンゴー
• 夏らしい？　～　マンゴーメロンパン　／　チーズ＋9種の野菜カレー
• マンゴープリンパン

(FreeBSD) portsのdevel/gettextは、textproc/libcrocoに依存していないようで、実は依存してる

FreeBSDでportsでインストールしたソフトウェアのうち、不要なものをどんどこアンインストールしていったら、gettext関係のコマンドが動かなくなりました。

% ldd /usr/local/bin/msgfmt
/usr/local/bin/msgfmt:
        libgettextsrc-0.17.so => /usr/local/lib/libgettextsrc-0.17.so (0x48085000)
        libgettextlib-0.17.so => /usr/local/lib/libgettextlib-0.17.so (0x480b7000)
        libcroco-0.6.so.3 => /usr/local/lib/libcroco-0.6.so.3 (0x4818a000)
        libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x481bb000)
        libz.so.3 => /lib/libz.so.3 (0x482d3000)
        libm.so.4 => /lib/libm.so.4 (0x482e4000)
        libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x482fa000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x4839e000)
        libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x483a7000)
        libncurses.so.6 => /lib/libncurses.so.6 (0x483d6000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x48413000)
        libc.so.6 => /lib/libc.so.6 (0x4850a000)

ということになっているので、gettextはlibcrocoに依存しているのでした。libcrocoをアンインストールしちゃったので、ダメになった、と。

しかし、portsのdevel/gettextを見ても、libcrocoへの依存関係はどこにも指定されていませんし、pkg_infoで見ても

% pkg_info -r gettext-0.17_1
Information for gettext-0.17_1:

Depends on:
Dependency: libiconv-1.13.1

ということなので、ports的には依存関係はない、とされています。そのため、libcrocoをあっさりとpkg_deleteできてしまうのです。ところが、gettextが共有ライブラリlibcrocoをリンクしている！

gettextのconfigureスクリプトをながめていると

• libcrocoがインストール済みだった場合は、そのインストール済みのlibcrocoを使う
• libcrocoがインストールされていない場合は、gettextの配布パッケージ内にあるlibcrocoを使う

という挙動になっているようです。

gettextのconfigureは、このへんのファイルがあるかどうかで、判断しているようです。

% ls -l /usr/local/include/libcroco-0.6/libcroco/libcroco-config.h
-r--r--r--  1 root  wheel  258  2 16 13:20 /usr/local/include/libcroco-0.6/libcroco/libcroco-config.h

gettextのconfig.logでは、こんな感じ。

configure:30907: result: yes
configure:30795: checking libcroco-0.6/libcroco/libcroco-config.h usability
configure:30812: cc -std=gnu99 -c -O2 -fno-strict-aliasing -pipe -I/usr/local/in
clude conftest.c >&5
configure:30818: $? = 0
configure:30832: result: yes
configure:30836: checking libcroco-0.6/libcroco/libcroco-config.h presence
configure:30851: cc -E -I/usr/local/include conftest.c
configure:30857: $? = 0
configure:30871: result: yes
configure:30899: checking for libcroco-0.6/libcroco/libcroco-config.h
configure:30907: result: yes

生成されたMakefileをgrepしてみました。

% grep croco Makefile
        $(top_srcdir)/gnulib-m4/libcroco.m4 \
INCCROCO = -I///usr/local/include/libcroco-0.6/libcroco
LIBCROCO = /usr/local/lib/libcroco-0.6.so /usr/local/lib/libglib-2.0.so /usr/local/lib/libintl.so /usr/local/lib/libpcre.so /usr/local/lib/libxml2.so -lz /usr/local/lib/libiconv.so -lm -Wl,-rpath -Wl,/usr/local/lib
LTLIBCROCO = -L/usr/local/lib -lcroco-0.6 -L/usr/local/lib -lglib-2.0 -L/usr/local/lib -lintl -L/usr/local/lib -lpcre -L/usr/local/lib -lxml2 -lz -L/usr/local/lib -liconv -lm -R/usr/local/lib

というわけで、

ports/devel/gettext/Makefileに、libcrocoへの依存関係を追加したほうがいいんじゃない？

と思ったのですが

% pkg_info -r libcroco-0.6.2
Information for libcroco-0.6.2:

Depends on:
Dependency: python25-2.5.2_3
Dependency: perl-5.8.9_3
Dependency: pkg-config-0.23_1
Dependency: pcre-7.9
Dependency: libiconv-1.13.1
Dependency: libxml2-2.7.3
Dependency: gettext-0.17_1
Dependency: glib-2.20.4
Dependency: gamin-0.1.10_3
Dependency: gio-fam-backend-2.20.4

というように、libcroroがgettextに依存しているため、依存関係のループができてしまいます。

gettextの配布パッケージ内のファイルを適当にgrepしてみますと

configure:  --with-included-libcroco  use the libcroco included here

なんてのが出てくるので、gettextをconfigureするときに、--with-included-libcroco を追加すればよさそうです。

ほかにも方法があるかもしれませんが、/usr/ports/devel/gettext/Makefile の中の

CONFIGURE_ARGS= --disable-csharp --disable-threads --disable-openmp

を

CONFIGURE_ARGS= --disable-csharp --disable-threads --disable-openmp --with-included-libcroco

にすると、うまいこといきました。

% ldd /usr/local/bin/msgfmt
/usr/local/bin/msgfmt:
        libgettextsrc-0.17.so => /usr/local/lib/libgettextsrc-0.17.so (0x48085000)
        libgettextlib-0.17.so => /usr/local/lib/libgettextlib-0.17.so (0x480b7000)
        libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x481b8000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x4825c000)
        libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x48265000)
        libncurses.so.6 => /lib/libncurses.so.6 (0x4829d000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x482da000)
        libc.so.6 => /lib/libc.so.6 (0x483d1000)

/usr/local/lib/libcroco.soのほうは、libxml2とかもリンクしているのに、gettextに付属のlibcrocoではlibxml2は出てこないので、何か違いが生じるのかもしれませんが・・・

☆

Makefileを書き換えずに

make CONFIGURE_ARGS+="--with-included-libcroco"

でもうまくいくんじゃないかと思ったんですが、infoファイルをインストールする最中に、エラーが出てしまいました。

どうやら、configureのオプションに、「--infodir=/usr/local/info/」など、いろいろ追加されなければいけないのに、make CONFIGURE_ARGS+=～で実行してしまうと、そういったportsが裏でコッソリ追加してるオプションが付かなくなってしまい、それでエラーになるようです。

え～？そうなの？？
なんか勘違いしてるかも。