GCC 4.9のビルド手順です。
1. MinGW環境について
GCCを自前でビルドしようという意気込みの方は、MinGW環境もすでにあるという前提で、細かい説明は省略します。
MinGW環境については、こちらもお読みいただくと参考になると思います。
MinGW環境のアップデート (2013/10/14)
MSYS環境のアップデート (2011/04/12)
MinGWのmingwrtとw32apiの代わりに、MinGW-w64を使います。
MinGW環境に、MinGW-w64を上書きインストールします。
MinGW-w64 for win32 のインストール
MinGW-w64も自分でビルドする場合は、こちらの記事も参考にしてください。
MinGW-w64のビルド (v3.1.0以降)
GCC 4.9のビルド手順は、gcc-4.8.1、mingw-w64-v3.1.0、winpthreadsの組み合わせで確認しました。
2014/10/31 追記
mingw-w64の最新版は、mingw-w64-v3.3.0 です。
追加で、FlexとTexinfoをインストールします。
インストール済みの場合は、あらためてインストールする必要はありません。
以下のファイルを、
C:\msys\1.0\
に、解凍します。
MinGWとMSYSを mingw-get-setup.exe などでインストールした場合、MSYSの場所は、
C:\MinGW\msys\1.0\
になっているかもしれませんので、以下、読み替えてください。
・flex-2.5.35-2
http://sourceforge.net/projects/mingw/files/MSYS/Extension/flex/flex-2.5.35-2/
flex-2.5.35-2-msys-1.0.13-bin.tar.lzma
・texinfo-4.13a-2
http://sourceforge.net/projects/mingw/files/MSYS/Base/texinfo/texinfo-4.13a-2/
texinfo-4.13a-2-msys-1.0.13-bin.tar.lzma
・regex-1.20090805-2
http://sourceforge.net/projects/mingw/files/MSYS/Base/regex/regex-1.20090805-2/
libregex-1.20090805-2-msys-1.0.13-dll-1.tar.lzma
Git for Windowsがインストール済みで、MSYSから使用できるようにパスを通していると、GCCのconfigureの時にGit for Windowsのbisonが応答しなくなって、固まる場合があります。
その場合は、MSYSにbisonをインストールしてください。
・bison-2.4.2-1
http://sourceforge.net/projects/mingw/files/MSYS/Extension/bison/bison-2.4.2-1/
bison-2.4.2-1-msys-1.0.13-bin.tar.lzma
2. ライブラリのインストール
以下のライブラリは、あらかじめインストールしておいてください。
最新版は、各ライブラリのページで確認してください。
winpthreads ※MinGW-w64を自分でビルドして、winpthreadsもインストール済みの場合は不要です。
zlib-1.2.8
libiconv-1.14
gmp-6.0.0a
mpfr-3.1.2
mpc-1.0.2
cloog-0.18.1、isl-0.12.2
必要なライブラリなどについては、こちらも参照してください。
Prerequisites for GCC
http://gcc.gnu.org/install/prerequisites.html
3. ソースコードの準備
GCC 4.9のソースコードは、このページから適当なサーバを選んでダウンロードしてください。
http://gcc.gnu.org/mirrors.html
この辺りから、
http://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-4.9.2/
gcc-4.9.2.tar.bz2
を、ダウンロードします。
ファイルを適当な場所に保存して、解凍します。
ソースコードとビルド用のディレクトリは、分けておいた方が良いと思います。
私の場合は、こんな感じにしています。
/usr/local/src/gcc-4.9.2/
/usr/local/src/build/
(/usr/local/src/ は、Windows上では、C:\msys\1.0\local\src\ です。)
MSYSでは、
/usr/local/
と
/local/
は同じディレクトリなので、どちらでも良いです。
$ cd /usr/local/src/
$ tar xjf gcc-4.9.2.tar.bz2
次に、
make-temp-fileパッチ
make-temp-file.diff
を適用します。
gcc-4.5.0用のパッチですが、そのまま使用します。
その他、
libstdc++-v3/configure
の20082行目辺りで、Sleep関数をチェックしている所の条件が、
if test x"$ac_has_nanosleep$ac_has_sleep" = x"nono"; then
になっていて、正しく判定されません。
「nono」を「no」に修正します。
$ cd gcc-4.9.2
$ patch -p1 < ../make-temp-file.diff
$ sed -i.orig 's/nono/no/g' libstdc++-v3/configure
4. GCC 4.9のビルド
ここまで準備ができましたら、GCC 4.9をビルドします。
ビルド用のディレクトリ(/usr/local/src/build/)で、configureを実行します。
--enable-threads
は、何も設定しない場合「Thread model: win32」になります。
MinGW-w64とwinpthreadsをインストールすると、
--enable-threads=posix
という設定でGCCをビルドできるようになり、「Thread model: posix」になります。
$ ../gcc-4.9.2/configure --prefix=/mingw --build=mingw32 --with-arch=i686 --with-tune=generic --enable-threads=posix --enable-languages=c,c++,objc,obj-c++ --enable-libgomp --disable-sjlj-exceptions --with-dwarf2 --enable-version-specific-runtime-libs --disable-win32-registry --disable-werror --disable-nls --enable-lto --with-system-zlib --enable-libstdcxx-debug --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --disable-libstdcxx-pch --disable-bootstrap
configureオプションについては、こちらを参照してください。
Installing GCC: Configuration
http://gcc.gnu.org/install/configure.html
--with-arch=i686 --with-tune=generic
のところは、完成したGCCの-marchと-mtuneのデフォルト値が
-march=i686 -mtune=generic
になるので、自分の環境に合わせて、
--with-arch=core2 --with-tune=core2
とか、
--with-arch=athlon64 --with-tune=athlon64
などとすると良いかもしれません。
自分の環境でしか使用しない場合は、
--with-arch=native --with-tune=native
でも良いかもしれません。
--with-arch、--with-tuneオプション無しの場合は、--build=mingw32 が指定されていると、
-march=i386 -mtune=i386
がデフォルト値になります。
configureが終了したら、makeします。
$ make -j3 CFLAGS="-O2 -D__USE_MINGW_ACCESS" CFLAGS_FOR_TARGET="-O2 -D__USE_MINGW_ACCESS -DIN_WINPTHREAD" CXXFLAGS="-mthreads -O2" CXXFLAGS_FOR_TARGET="-mthreads -O2" OPTIMIZE_CXXFLAGS="-DIN_WINPTHREAD" LDFLAGS="-s" 2>err.log 1>out.log
そのままmakeだけすると、デバッグシンボル入りの巨大なバイナリになってしまうため、フラグを変えています。
メッセージをログに保存して、何か問題があった時に参照できるようにしています。
5. インストール
そのままmake installするのはちょっと危険です。
私の場合、TDMさんだったか誰かのインストールスクリプトを参考に、以下のように、実行環境とは別のディレクトリにインストールしています。
$ make DESTDIR=/develop/sandpit/dw2 install
MSYSから見ると、
/develop/sandpit/dw2/mingw/
実際のディレクトリは、
C:\msys\1.0\develop\sandpit\dw2\mingw\
に、インストールされます。
あとは、ディレクトリ構造を変えずに、そのままMinGW環境に上書きすれば完了です。
$ cp -rp /develop/sandpit/dw2/mingw /c/.
configureからmake installまでの流れは、けっこう時間がかかりますので、私はスクリプトで流しています。
参考までに、こちらに置いておきます。
gcc-4.9.2-build-dw2-generic-posix.sh
【補足】
とりあえず上記の手順で完成なのですが、出来上がったGCC 4.9で、個別ライブラリを全部コンパイル&インストールし直して、またGCC 4.9をビルドし直せば完璧です。
makeのコンパイルフラグについての補足です。
libgompやlibstdc++で、winpthreadsのスタティックライブラリをリンクすると、こんなエラーが出ます。
.libs/critical.o:critical.c:(.text+0xc): undefined reference to `_imp__pthread_mutex_lock'
.libs/critical.o:critical.c:(.text+0x2c): undefined reference to `_imp__pthread_mutex_unlock'
(以下略)
winpthreadsのヘッダファイル「pthread.h」に以下の記述があります。
#if defined DLL_EXPORT
#ifdef IN_WINPTHREAD
#define WINPTHREAD_API __declspec(dllexport)
#else
#define WINPTHREAD_API __declspec(dllimport)
#endif
#else
#define WINPTHREAD_API
#endif
libgompをコンパイルする時のフラグに「-DDLL_EXPORT」が付いているせいで、winpthreadsの関数に「__declspec(dllimport)」が付けられるのがエラーの原因です。
とりあえず、CFLAGS_FOR_TARGETに「-DIN_WINPTHREAD」を追加して、「__declspec(dllexport)」が選択されるようにしました。
gcc-4.8.1から、libstdc++でもlibgompと同じようなエラーが出るようになったので、OPTIMIZE_CXXFLAGS="-DIN_WINPTHREAD" を追加しました。
【更新履歴】を見る
2014年07月19日
この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/101815433
※言及リンクのないトラックバックは受信されません。
この記事へのトラックバック
http://blog.sakura.ne.jp/tb/101815433
※言及リンクのないトラックバックは受信されません。
この記事へのトラックバック
のABIが変更になり、これまでのg++でビルドされたライブラリ
が一部使えなくなるらしいです。
対策としては、面倒ですがライブラリをビルドしなおすしかな
さそうです。詳しくはurlを参照してみて下さい。
c言語で書かれたライブラリも、4.9ではビルドできたけど5で
は失敗するって物があるらしいです。
まだデベロッパレベルの段階ですので今後改善されるかもしれ
ませんが、もうstage4にまで突入しています。
5の導入は慎重に行った方がよろしいかと思われます、余計な
お世話ですがご一報まで。
開発版gccは
svn co svn://gcc.gnu.org/svn/gcc/trunk
で取得できます。
ちなみにmingw-w64もgitから取得したものを使う必要がありま
す。多分gcc5がリリースされたらmingw-w64も更新すると思いま
すけど、具体的にはftw.hが必要になります。
別トピックの話になりますが、ここで。
libresslですが、試しにビルド->インストールしてみました。
ライブラリやパッケージ名インクルードファイルまでopensslと
同じです。しかし、opensslに実装されていた擬似乱数のいくつ
かが削除されています。
ですので、opensslライブラリに依存したいくつかのソフトはビ
ルドに失敗します。野良patchも出ていますが、その多くはコメ
ントアウトによる対応ですのでよろしくないです。
私もw3mでそのような処理をしたら、やはり動作がおかしくなり
ました。
開発者が正式に対応しない限りは、sslの乗り換えは.exeだけに
とどめておいた方が良いような気がします。
gcc5が出たら早速乗り換えようかと思っていたのですが、少し様子を見たほうが良さそうですね。
opensslかgnutlsの代わりに、サイズが小さくて簡単に置き換えられるライブラリはないかなと調べていて、wolfssl(旧cyassl)なども候補に考えています。
libresslも難しそうですね。
情報ありがとうございました。