パラレルmakeがハングする理由を調べてみる…そして挫折へ

mingw-get-inst-20120426.exeの内蔵カタログと最新カタログで、make -j4がハングしない／ハングする理由を調べてみた。
makeは、どちらも同じものが取得される…いきなり挫折したくなってくる。
デバッグレベルを上げて、何をしているのか調べてみる…stage1-bubbleから入ったall-stage1のmakeで、ハングアップしていることが分かった。更にデバッグレベルを上げて調べると、makeツリーの探索をしただけでジョブ数の上限に達してしまい、ジョブの終了待ちをしていた。これが表層上の原因。しかし、なぜか内蔵カタログのmakeでは、プロセスを渡り歩きながら、makeツリーを探索している様だ。このため、ある時点ではジョブ数の上限に達するものの、探索中にプロセスが終了してジョブの空きが発生し、その隙間を縫うようにして、makeツリーの探索とコマンドの実行をうまく処理している様に見える。あれ??同じものなのに、なんで動きがこんなに違うんだ??
……思案中……
プロセス管理に差があるのか??って観点で調べたら差分がいました。msysCORE-1.0.xx-1-msys-*-binが、内蔵カタログはv1.0.17、最新カタログはv1.0.18。この中にmsys-1.0.dllが入っていて、makeはこれで提供されるシステムコールを使っている。このシステムコールはエミュレータなので、ここの動きが変わってくれば、プロセス管理が変わっている様に見えるハズ。
v1.0.17からmsys-1.0.dllを取り出して、最新環境にコピーして、パラレルmakeを実行してみる…おぉ動くぞ！ソースも取り出して念のために見てみると、確かにwait周りとか微妙に差がある。…コメントにon 64bit環境はvistaしか見てなかったので、それ以降のOSも正しく確認して処理出来るようにした…って、え？
やばいmakeがバグっているのか、msysがデグレってるのか分からん。makeも、msysCore*msys*binも、これ以上新しいのないよ〜。gnu makeは、確かにもう一個先がある。あとコンパイルする気にはならないけど、ベータ版にはスレッド化されたmakeがあるには、あるが…どー考えても茨の道だな。普通のlinux上でも、まともに動くかどうか分からん様なものをMSYSに持ってきても…。
ダメ元でMSYS用のリリース版gnu make作るかなぁ〜でも、on MSYSのコンパイル方法ってイマイチ良く分からんのだ…