!!!今更MinGW 2009.06(3) MinGW MinGWは、C言語の初心者が作成するような単純なmakeレベルの環境は、MSYSとは独立に動作することができる。その構築方法と注意点をここで述べる。 !!ベース環境(binutils, mingwrt, w32api, mingw-utils, gdb, mingw32-make) コンパイラ本体であるgccの前に、ベースとなる環境を作成する。コンパイラ本体を同時に入れてしまっても良いのだが、猫科研究所では''gcc3とgcc4を切り替えられるようにする''ことも命題の1つであるので、ここでは共通であるベース環境を先に準備する。 [MinGWのダウンロードページ|http://sourceforge.net/project/showfiles.php?group_id=2435]で、以下のファイルを取得してこよう。 *[GNU Binutils|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=11290] / [Current Release: GNU binutils-2.19.1|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=11290&release_id=19055] **[binutils-2.19.1-mingw32-bin.tar.gz|http://sourceforge.net/project/downloading.php?group_id=2435&filename=binutils-2.19.1-mingw32-bin.tar.gz] *[GNU Make|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=23918] / [Current Release: mingw32-make-3.81-20080326|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=23918&release_id=587379] **[mingw32-make-3.81-20080326-3.tar.gz|http://sourceforge.net/project/downloading.php?group_id=2435&filename=mingw32-make-3.81-20080326-3.tar.gz] *[MinGW API for MS-Windows|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=11550] / [Current Release: w32api-3.13|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=11550&release_id=645278] **[w32api-3.13-mingw32-dev.tar.gz|http://sourceforge.net/project/downloading.php?group_id=2435&filename=w32api-3.13-mingw32-dev.tar.gz] *[MinGW Runtime|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=11598] / [Current Release: mingwrt-3.15.2|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=11598&release_id=16692] **[mingwrt-3.15.2-mingw32-dev.tar.gz|http://sourceforge.net/project/downloading.php?group_id=2435&filename=mingwrt-3.15.2-mingw32-dev.tar.gz] *[MinGW Utilities|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=61599] / [Current Release: mingw-utils-0.3|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=61599&release_id=126568] **[mingw-utils-0.3.tar.gz|http://sourceforge.net/project/downloading.php?group_id=2435&filename=mingw-utils-0.3.tar.gz] *[GNU Source-Level Debugger|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=20507] / [Release Candidate: GDB 6.8-3|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=20507&release_id=594520] **[gdb-6.8-mingw-3.tar.bz2|http://sourceforge.net/project/downloading.php?group_id=2435&filename=gdb-6.8-mingw-3.tar.bz2] これらのファイルは全て/mingw以下（C:\msys\mingw以下）に展開する。 !各パッケージの説明 簡単に説明する。 ::binutils :::ldやstripなどのリンカやバイナリを操作するツール群 ::mingw32-make :::Makefileに従いビルドをある程度自動化するツール ::w32api :::Win32APIをMinGWから使用可能にするファイル群 ::mingwrt :::ランタイムライブラリにglibcではなくmsvcrtを使用可能にするファイル群 ::mingw-utils :::reimpやa2dll等の主にbinutilsを補佐するツール群 ::gdb :::主にGCC向けのコマンドラインデバッガ binutilsが無ければリンカがないので.exeや.dllが作成できず、w32apiが無ければWindows固有のプログラミングができない。そしてmingwrtが無ければランタイムがない状態となるのでprintfさえ使用できない。よって、この3つは特に重要だ。 !makeに関する注意 ''makeは、MSYS側でも導入するため重複する''ことになる。ただし、mingw32-makeは名前の通り''"mingw32-"というプレフィックスが付く''ために、使い分けることは可能である。 makeがコンパイラ環境の一環であるのかUnixライクな環境の一部であるかの判断は難しいところだが、同じくビルドに使用するconfigureはシェルスクリプトであるためにMSYSが無ければ動作しない。また、makeの中でシェルスクリプトを使用することはかなり多いことから、実情としてはMSYS側に近い存在であるように思う。ただし、MSYS側に新しいバージョンがない等の理由でMinGW側のものをメインに使用する（プレフィックス無しのmake.exeにする）方がよい場合もある。 今回の記事で取り上げるmakeでは、バージョンは両者とも3.81で相違はないが、''MSYS側のmakeの方が安定している''ようだ。猫科研究所で試した限りでは、mingw32-makeは不正終了することがあった。 !!コンパイラ(gcc) MinGWの核であるコンパイラを導入する。以前の猫研パックではMinGWのページからそれぞれバージョン3系と4系のGCCを導入していたが、a003からは4系のコンパイラに[Twilight Dragon Media|http://www.tdragon.net/recentgcc/]で配布されている、通称TDM版のGCCを導入した。また、3系と4系の混在や、未だに公式ではSJLJ方式版がメインであるため、Dwarf-2方式版は利用しない。 !TDM版GCC-4に関して TDM版のGCCには以下の特徴がある。 *より''最新のGCC-4系バイナリ''が用意されている。 *MinGW環境向けにビルドされている。 *バグが独自に修正されていることがある。 *pthreadやiconv等がサポートされている。 MinGW公式のGCC-4は長くTechnology PreviewやAlphaの状態で、これら''MinGW公式版は必ずしも安定していない''ため、オリジナルのGCCのバグフィックスが取り込まれた最新版を使用できることには特に意味がある。TDM版も最近まで「試験目的(experimentation purposes only)」とされていたが、有名になり多く使用されるようになったことで実用に耐えると判断され、''非公式である''こと、''無保証である''ことの警告付きではあるが''「非クリティカルな用途に使用できる」''と銘打たれた。そもそもGCCは元から無保証であるし、MinGW公式のGCC-4も不安定なのであるから、GCC-4が必要であるユーザには特段の制約ではないだろう。 TDM版の2009年6月現在の最新版であるGCC-4.4.0は[オリジナルのGCCプロジェクト|http://gcc.gnu.org/]でも2009年4月21日にリリースされたばかりのまさに''最新''だ。 !GCC-3 GCC-3に関しては、MinGW公式のGCC-3.4.5で特段の問題が無く、非常に安定しているため、これを使用する。[オリジナルのGCCプロジェクト|http://gcc.gnu.org/]によるGCC-3系の最新は3.4.6だが、[changesのページ|http://gcc.gnu.org/gcc-3.4/changes.html#3.4.6]でも変更内容が明記されていないくらいで、GCC-3.4.5は安定バージョンと言ってよい。 !SJLJ版とDwarf-2版に関して [[2008年春版の今更MinGW(5)|今更MinGW(5)]]で書いているが、例外の取り扱い方式に関する違いである。Dwarf2の方が性能的には勝っているが、現在の安定版としては''SJLJ版を使用すべき''だ。MinGW公式のGCCがSJLJ方式になっているため、Dwarf-2方式のGCCを導入してしまうと、GCC付属ではなく、かつバイナリで導入したライブラリ群は、その他のバイナリ（GCC付属やソースからビルドしたもの）と互換性がないことになる。 SJLJとはSetJump-LongJumpの略で、例外発生時の飛び先をsetjumpで設定する方式だ。これは予め飛び先を設定する必要があるため、try-catch構文がある度に、setjumpが実行されることになる。''例外が発生しない場合、このsetjumpは単なる無駄''でしかない。 一方、Dwarf2はデバッグ機能を利用して例外の飛び先を決める方式で、余計な処理を行わないために''高速で動作''する。しかしWindows上では、Dwarf2方式でコンパイルされていない関数のスタックフレームをクリアする必要がないと分かっている場合にしか使用できない。これはWindowsAPIのコールバック等を利用する場合に例外を発生させられないということで、''コーディングに余計な注意を必要とする''、ということだ。何かのライブラリをリンクする場合には、その中でも問題行動が行われていないか把握していなければならないため、''現実的ではない''。 このため、通常は速度を犠牲にしてSJLJ版を使用するのである。 !導入 下記のファイルをそれぞれ取得しよう。 *[GCC Version 3|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82723] / [Current Release: gcc-3.4.5-20060117-3|http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82723&release_id=428244] **[gcc-core-3.4.5-20060117-3.tar.gz|http://sourceforge.net/project/downloading.php?group_id=2435&filename=gcc-core-3.4.5-20060117-3.tar.gz] **[gcc-g++-3.4.5-20060117-3.tar.gz|http://sourceforge.net/project/downloading.php?group_id=2435&filename=gcc-g++-3.4.5-20060117-3.tar.gz] *[TDM's GCC/mingw32 Builds|http://www.tdragon.net/recentgcc/] / (GCC Current Series) 4.4.0-tdm-1 (r2) Released 2009-05-02 **[gcc-4.4.0-tdm-1-core-2.tar.gz|http://downloads.sourceforge.net/tdm-gcc/gcc-4.4.0-tdm-1-core-2.tar.gz] **[gcc-4.4.0-tdm-1-g++-2.tar.gz|http://downloads.sourceforge.net/tdm-gcc/gcc-4.4.0-tdm-1-g++-2.tar.gz] もしAdaコンパイラやGNU製のJavaコンパイラが必要であれば、追加して構わない。 猫研パックではこれらを/_felidlabo/gccにバージョンごとにディレクトリを分けて展開し、その後.7zに再アーカイブしている。後で''上書きコピーによるGCCの切り替えを可能にする''ため、/mingwには直接展開しない。 なお、TDM版ではない、MinGW公式のGCC4も、下記pthreadの対応が不要なだけで、同様に導入できる。 !TDM版の導入に際する注意 TDM版はlibpthreadを含んでいる。pthreadとは''POSIXで規定されるスレッド機能''だが、WindowsはPOSIX準拠ではないので、POSIXと同様のインターフェース（関数形式）でスレッドを制御できるようにするのがlibpthreadだ。 しかし、OSでネイティブにサポートされる機能ではないために、ライブラリで''吸収しきれない差異''が発生する。これはlibpthreadでもGCCでもどうしようもない制限としてユーザに降りかかる。具体的には今更MinGWの2008年春版を書いたときに併せて書いたMinGW+ffmpegの[[MinGW＋ffmpeg(A)pthreadは複雑]]を読んで戴きたいが、ここではかいつまんで述べよう。 まずWindows上でlibpthreadをstaticにリンクする場合には、プロセスやスレッドの開始・終了時に、POSIXの規定にはない''特別な関数を呼び出す必要がある''。つまり、ソースコードレベルの互換性が無く、#ifdef等で切り分ける必要がある。この制限を避けるためにはダイナミックリンク（DLLで使用）にすればよいが、それはつまり''pthread*.dllを.exeと共に配布しなければならない''ことを意味する。 これ自体は精神衛生的なことを除けば大きな制限ではないが、問題はconfigure等がpthreadの存在を自動的に検出し、''勝手にリンクされることがある''ことだ。Windows環境を想定していないソフトウェアでは、staticリンク時に特別な関数を呼び出していないケースもあるため、''ビルドは通るが動作時にクラッシュする''事態となる。また一方、DLLをリンクするケースでは、pthreadを使用していることをユーザが把握せず、.exeのみを配布して動作しない事態に陥る。 このため猫研版では以下のファイルをリネームし、TDM版のpthreadを無効にしている。 *include/pthread.h *include/sched.h *include/semaphore.h *lib/libpthread.a *lib/libpthreadGC2-static.a *lib/libpthreadGCE2.a 上記の注意点を承知していれば、pthreadを有効のままにしていても問題はない。