MSYS対応のmake v3.82を作ってみた
暫くupdateがなかったのは、ちょっと忙しかっただけではなく、make v3.82をwindows(MinGW/MSYS)上で動かそうとすると、バグだらけで泣いていたからです。自分のソースなら如何様にも弄れますが、他人様のソースなので、どのようにあるべきか？を考えてると、中々先に進まない…
ともあれ、取りあえず動く物が出来たので、ご紹介しておきます。ただし、こいつも、gccに対してパラレルmakeを実施するとハングするので、使うのは趣味の世界です。テストは問題なく通るんですけどね〜何故か。しかし、ここまで出来が微妙だと、MSYSライブラリだけではなく、make自体にも何か不具合が潜んでそうで、ちょっと怖いですよ、正直言って。
※2013/7/15追記/修正: バッチを使用したとき、firestorageからパッチを正しくダウンロードできないことが判明しましたので、バッチを修正しました(直リンクを使っていたのですが、そのURLは永続的ではないことが分かりました)。
続きを読むmake on MSYS ? (その２)
ix86-pc-msysがconfigureを通るように、config周りを弄って、再チャレンジ。ん〜ようやく、提供されている物と同じ物ができたよ〜。
ついでに、その辺のことを調べていくと、どうも自爆していたらしい。MSYS上に切り替えたときに実行されるautoconf(autoreconf)は、MSYS用にアレンジされたものが動作する。で、こいつがconfig周りにix68-pc-msysを、植え付けていく作りになっていた。今回ちょっとした理由で、/usr/local/binにMinGW用のautoconfを置いていたため、こっちが走ってしまい、config周りにix68-pc-msysが入らず、ビルド失敗となっていた様だ。
むーこれだから/usr/local(/bin|/sbin)が優先される脆弱なシステムは嫌いなんだよ〜。
この辺りだと安心する
makeと戯れている間に、ドル円が100円半ばに突入してましたよ。この辺りに居てくれると、安心出来るんですけどね(本音は、もう少し上だと良いなぁ)。
make on MSYS ?
パラレルmakeが失敗する根本原因の調査はひとまず置いておいて、取りあえずlinux上ではどうなるかを調べてみた。
残念ながら今回の問題となったmake v3.81の入った環境は見つからなかったが(再インストールしてmake v3.81の環境を探すのが面倒なだけ)、make v3.82の環境があったので、デバッグレベルを上げて流れを見てみる。すると、古いMSYS v1.0.17+make v3.81の動作と同じように、プロセスを乗り換えながらmakeツリーとコマンド実行を熟(こな)していることが分かった(32bit/64bit共に)。
となると、MSYS v1.0.18がかなり臭いのだが、make v3.81のバグも排除仕切れていないので、MSYS+make v3.82の検討を始めて見る。
パラレルmakeがハングする理由を調べてみる…そして挫折へ
mingw-get-inst-20120426.exeの内蔵カタログと最新カタログで、make -j4がハングしない／ハングする理由を調べてみた。
makeは、どちらも同じものが取得される…いきなり挫折したくなってくる。
デバッグレベルを上げて、何をしているのか調べてみる…stage1-bubbleから入ったall-stage1のmakeで、ハングアップしていることが分かった。更にデバッグレベルを上げて調べると、makeツリーの探索をしただけでジョブ数の上限に達してしまい、ジョブの終了待ちをしていた。これが表層上の原因。しかし、なぜか内蔵カタログのmakeでは、プロセスを渡り歩きながら、makeツリーを探索している様だ。このため、ある時点ではジョブ数の上限に達するものの、探索中にプロセスが終了してジョブの空きが発生し、その隙間を縫うようにして、makeツリーの探索とコマンドの実行をうまく処理している様に見える。あれ??同じものなのに、なんで動きがこんなに違うんだ??
……思案中……
のろのろとgcc 4.8.1を作ってみる(その６) 本編
まずは、お詫びを。「のろのろとgcc 4.8.1を作ってみる(その４)」で、環境の把握が出来ておらず、誤った情報を元に記事を書いていたことを謝罪したします。
また、そのせいで無駄な時間を過ごした方がいらっしゃいましたら、ご容赦願います。
どうにも、明確な答えが書いてある場所を見つけられませんでしたが、動作から判断すると、gcc 4.8.1をコンパイルするときにgcc 4.6.x(恐らく、これ以前のverも)を使用するとビルトイン関数(ffsなど)が無条件に使用されるため、gcc 4.8.1は先日紹介した手順でコンパイルすることが出来ます。
一方gcc 4.7.x/gcc 4.8.xを使用した場合、ビルトイン関数は明示的に__builtin_ffs()のように記述する必要があり、先頭に__builtin_を付けずに使用すると、その関数は標準ライブラリに存在するものとして動作します。ただし、MinGW環境においては、gccのビルトイン関数とされているものには、標準ライブラリに存在していないものがあり、これによってコンパイルが失敗します。今回これに該当するのは、ffs関数です。基本的には、これらの関数はlibibertyライブラリによって救済されているのですが、あまりにも標準的な関数のためか、一部モジュールで見逃されているようです。
今回、見逃しのあるモジュール群に対して、libibertyライブラリを参照するようにパッチを加えていますが、願わくばgcc開発メンバーの方々が気づかれますよう期待します。本来はポストすべきところですが、なにぶん英語はRead Onlyなもので…。
以降が、gcc 4.7.x/gcc 4.8.xでもできるgcc 4.8.1のコンパイル方法の紹介です。
続きを読むのろのろとgcc 4.8.1を作ってみる(その６) パッチ編
本文書くのは後回しにして、まずは差分パッチ情報だけ。一応、このパッチは、gcc v4.8.1＋前提のソースに対して当てるもので、2013/6/27のパッチを当てた後の環境に当てるものではないので、注意されたし。
続きを読む