疎行列直接解法ライブラリMUMPSをWin32/MinGW gfortranでビルドする

2016/06/26 （2019/06/08 編集上修正・一部追記）

疎行列計算ライブラリ MUMPS : MUltifrontal Massively Parallel sparse direct Solver (http://mumps.enseeiht.fr/) を MS-Windows 上でビルドする事例記載は海外のサイトを含めても極めて少なく、あっても Intel XE Composer (Intel Fortran) が必須と書いてあります。もちろん、Intel Fortran に付属する Math Kernel Library は HPC（High Performance Computing）に重要な存在で、それなくして MUMPS のような数値計算ライブラリの性能を引き出すことはできません。しかし、MUMPS を評価目的でちょっとだけ使ってみたい程度の需要に対して Windows 用の Intel Fortran を購入することもまた無理があります。

試してみると、様々な制約事項に目をつぶれば Windows 上で GNU Fortran (gfortran) でも MUMPS をビルドできることが判りました。64bit でのビルドも可能です。また、基本的にはビルドしたライブラリを GCC（gfortran, gcc, g++）で利用することが前提となりますが、制約は多いものの Microsoft Visual C++ (MS-VC++) で利用することも一応可能です。このような事例紹介がまったく見当たらないので、ここにレポートします。

（2019/06/08 GCC も MSVC も進化し、このページの記載もかなり古くなってきています。このため、いくつか編集上の修正や追記をしましたが、最新環境でのテストは一切行っていません。あしからず。）

制約事項

一般

ビルドしたライブラリを MS-VC++ で利用する場合の制約

目次

用意するもの

手順 BLAS ライブラリ／バリエーションAとBに共通

32bit/64bitとも（コンパイラのターゲットを i386 と x86-64 のどちらにするかの設定手順を除き）手順は同じです。

Netlib の Reference BLAS 公式サイトから書庫を得ます。ここでは Version 3.6.0 を使っています。書庫をディレクトリ付きで展開したあと、以下の作業を行います。

blas-3.6.0\make.inc 修正

行オリジナル修正後備考 
10

PLAT = _LINUX

# PLAT =
成果物ファイル名にアーキテクチャを含める設定は、とりあえずコメントアウト。（ファイルを置く場所で区別する） 
34
 
BLASLIB      = blas$(PLAT).a
 
BLASLIB  = libblas$(PLAT).a
 GCCの慣例では、ライブラリのファイル名を lib から始めるようである。
$(PLAT) は未定義なので消滅。
結果として、成果物ファイル名は libblas.a となる。
こうすると、GCCのリンカーオプション -lblas でライブラリを認識するようになる。

なお、オリジナルの make.inc であらかじめ指定されているFortranコンパイラは gfortran、最適化は -O3 となっている。このままでよい。

blas-3.6.0 ビルド

以上で、必要環境が正しく用意されていれば、単に make と打ち込むだけでビルドできる。libblas.a が成果物（ライブラリファイル）である。これを、MUMPS の配布書庫を展開してできる MUMPS_5.0.1\ フォルダにコピーしておく。

手順 MUMPS 本体／バリエーションA：MinGW-GCC のみでのビルド（GCC 用ライブラリの生成）

MUMPS を MinGW-GCC で利用したい場合はこのセクションの記述によります。

MinGW-GCC は unix 系 OS の GCC との差異があまり大きくないので、MinGW-GCC を使いこなしてさえいれば、ビルド作業自体はそれほど難しくないことが利点です。

32bit/64bitとも（コンパイラのターゲットを i386 と x86-64 のどちらにするかの設定手順を除き）手順は同じです。

MUMPS : a parallel sparse direct solver 本家から得たソースコード一式をディレクトリ付きで展開したあと、以下の作業を行います。

(0) BLASライブラリ

BLASライブラリは前記の gfortran でビルドしたものをそのまま使い、libblas.a を MUMPS の配布書庫を展開してできる MUMPS_5.0.1\ フォルダ（以下ではこれをトップディレクトリという）にコピーしておく。

(1) MUMPS_5.0.1\Makefile.inc 作成と修正

MUMPS_5.0.1\Make.inc\Makefile.inc.generic.SEQ をコピーして MUMPS_5.0.1\Makefile.inc を用意する。（サフィックスが .WIN.MS-G95 とか .G95.SEQ とか興味をそそられるものがいくつかあるが、あえて無視。）

この MUMPS_5.0.1\Makefile.inc を以下のように修正する。

行オリジナル修正後備考 
79

ORDERINGSF  = -Dpord

ORDERINGSF  = -Dpord -DWITHOUT_PTHREAD
pthread.h (POSIX thread) を要求しないようにする（それ以外にも作用があるらしい）
これにより、GCCがpthreadバージョンでなくても（Thread model: win32であっても）コンパイルは通るようになる。
本来ここに書くのが適当とはいえないが、他に適当な場所が見当たらないので妥協 
101
102
103
104
105
106

# CC : C compiler
CC      = cc
# FC : Fortran 90 compiler
FC      = f90
# FL : Fortran linker
FL      = f90

# CC : C compiler
CC      = gcc
# FC : Fortran 90 compiler
FC      = gfortran
# FL : Fortran linker
FL      = gfortran
コンパイラコマンド名の修正 
125
126

# DEFINE HERE YOUR PTHREAD LIBRARY
LIBOTHERS = -lpthread

# DEFINE HERE YOUR PTHREAD LIBRARY
# LIBOTHERS = -lpthread
コメントアウトして、リンク時に libpthread.a を要求しないようにする。
残っていると、このライブラリが無いwin32スレッドバージョンのgccではリンクが失敗してしまう。 -DWITHOUT_PTHREAD を指定しているので機能上の変化はない。 
143
144
145

OPTF    = -O
OPTC    = -O -I.
OPTL    = -O

OPTF    = -O3
OPTC    = -O3 -I.
OPTL    = -O3
最適化オプションを -O（ -O1 相当）から -O3 に格上げ（試していない。次項目のMS-VC++併用ビルドでは、問題は無いように見える）。 
150

LIBS = $(LIBSEQ)

LIBS = $(LIBSEQ) -L$(topdir)
トップディレクトリ MUMPS_5.0.1\ に libblas.a をコピーしておく手順上、リンカのライブラリ指定にトップディレクトリを追加する。

(2) MUMPS_5.0.1 ビルド

以上で、必要環境が正しく用意されていれば、単に make と打ち込むだけでビルドできる。成果物は

であり、これら一式と libblas.a を一緒に使う。

また、MUMPS_5.0.1\examples\ フォルダ内にはテスト用実行ファイルが出来上がっているはずである。 そのフォルダ内で

dsimpletest.exe < input_simpletest_real

とすると、テストが走る。これは double 型のFortran90によるテストである。他の型のFortran90によるテストは、examples フォルダ内でMakefileにターゲットを別途指定して生成する。

C言語からの呼び出しテスト c_example.exe もできているはずである。examples フォルダ内で引数無しで実行する。

MinGW-GCC のみでビルドしたライブラリの MS-VC++2013 からの利用（きわめて限定的）

MinGW-GCC のみでビルドしたライブラリを MS-VC++ から利用するには、かなりの制限が伴います。どうやら32bitのみ、MinGW 本家の GCC-4.9.3 でビルドしたライブラリと MS-VC++2013 の組み合わせに限って可能なようです。

ただし、MinGW-GCC でコンパイルしたものである以上 MinGW ランタイムライブラリの呪縛からは自由になれません。上記で構築（GCC-4.9.3）したMUMPSの examples フォルダ内における例を示します。MUMPS と BLAS のほか、GNU のライブラリ libgfortran.dll.a libquadmath.dll.a libgcc.a libmingwex.a と、これらおよびMUMPSのヘッダファイルが MS-VC++ から正しく見えるような環境変数設定、実行時に MinGW の DLL が必要です。

set INCLUDE=%INCLUDE%;..\libseq;..\include;
set LIB=%LIB%;C:\mingw\lib;C:\MinGW\lib\gcc\mingw32\4.9.3;
cl /MD c_example.c -link ..\lib\libdmumps.a ..\lib\libmumps_common.a ..\lib\libpord.a ..\libseq\libmpiseq.a ..\libblas.a libgfortran.dll.a libquadmath.dll.a libgcc.a libmingwex.a
ja.Wikipedia ar (UNIX)によると、Microsoft の Win32 系の LIB コマンドで作るライブラリ（*.lib）は、内部的に GNU の ar とフォーマットが同じ…らしく、それが、MS-VC++ でも *.a をそのまま使える理由らしい。

この設定では、MS-VC++ のランタイムライブラリはDLL版（MSVCR120.dll、コンパイルオプション /MD）の指定しか受け付けません。静的リンク（LIBCMT.lib）にするとシンボルの衝突や未解決参照が生じます。

MinGW-W64 GCC-5.3.0 32bit（sjlj、dwarf共）でビルドしたライブラリの場合は更に libmingw32.a も必要となる。かつ、これがために、MS-VC++2013との併用は純粋C言語の範囲内でしか使えないようです（C++ではビルドは通るが実行するとクラッシュする）。MinGW-W64の libmingwex.a と libmingw32.a の中に、MicrosoftのC++ランタイムと衝突するものが何かあるようです。https://www.mail-archive.com/mingw-w64-public@lists.sourceforge.net/msg05104.html

MinGW-W64 GCC-5.3.0 64bitとMS-VC++2013との組み合わせ、並びに、32bitでもMS-VC++2010との組み合わせでは、純粋C言語範囲であっても、ビルドは通っても動作しない（クラッシュする）バイナリになってしまうようです。

かなりきわどい状況ですので、計算結果についても細心のチェックが必要と思われます。

以上より、GCCのみでコンパイルしたライブラリは、GCCで使用するのがよさそうです。

MS-VC++での利用は、次項の手順バリエーションBによる併用コンパイルの方が、良い結果が得られると思います。

手順 MUMPS 本体／バリエーションB：MS-VC++ と gfortran の併用ビルド（MS-VC++ 用ライブラリの生成）

疎行列計算以外のプログラムコードとの相互運用性の関係などの事情で、MS-VC++ 主体でのプログラミングを行いたい場合は、MUMPS を MinGW-GCC と MS-VC++ を併用してビルドする必要があります。ただし、系譜がまったく違うコンパイラが出したオブジェクトファイルを混ぜてリンクすることになり、技術的に、いささかきわどい領域にあります。いまいち気分がよくないですが、とにかくやってみましょう。

なお、冒頭に記したように、ここでは逐次求解 (sequential) 用ライブラリのビルドに限定しています。MS-VC++ は、かなり以前から MPI に対応しているそうです（→参照 Visual Studio 2013におけるMS-MPI v6の利用）が、MPI が異なるコンパイラを跨いで使えるのか否かは未知です。これは、詳しい方による追試を待ちたいと思います。

32bit/64bit とも基本手順は同じです。なお、gfortran ではターゲットを i686 と x86-64 のどちらにするかの選択はコンパイラオプションでの設定だが、MS-VC++ は vcvarsall.bat や環境変数等で切り替えることになります。

make は MSYS に入っている GNU make を使います。Microsoft の NMake はこの目的には使えません。

（2016年当時）この節を書いた後、MUMPS のメーリングリストのアーカイブが誰でも閲覧可能であることが判り (https://listes.ens-lyon.fr/sympa/arc/mumps-users) 、簡単に検索してみましたが、近年のエントリにはこの節に書いた内容の試行事例は無いようでした。

(0) BLASライブラリ

BLASライブラリは前記の gfortran でビルドしたものをそのまま使い、libblas.a を MUMPS の配布書庫を展開してできる MUMPS_5.0.1\ フォルダ（以下ではこれをトップディレクトリという）にコピーしておく。

(1) MUMPS_5.0.1\Makefile.inc 作成

MUMPS_5.0.1\Make.inc\Makefile.WIN.MS-G95.SEQ をコピーして MUMPS_5.0.1\Makefile.inc を用意する。

この MUMPS_5.0.1\Makefile.inc を以下のように修正する。なお、GNU makeでは（MSYS版であっても）スラッシュが常にパス区切りの意味を持ってしまうため、Makefile内の記述では、MS-VC++のコマンドラインコンパイラのオプションデリミタをマイナスで書く。実はMS-VC++はマイナスも（ファイル名と混同しない限り）オプションデリミタとして使える。

一部、表の横幅が収まりきらないため、折り返し可で書いています。表示が折り返されていても実際には行番号あたり1行なので、ご注意願います。

行オリジナル修正後備考 
57

ORDERINGSF  = -Dpord

ORDERINGSF  = -Dpord -DWITHOUT_PTHREAD
MS-VC++には pthread.h (POSIX thread) が存在しないので、それを要求しないようにする（それ以外にも作用があるらしい） 
77
78
79
80

CC      = cl
FC = g95
FL = cl
AR = lib -out:

CC = cl -MD
FC = gfortran
FL = cl -MD
AR = lib -out:
コンパイラコマンド名の修正
オプション /MD を加え「MSVCRT.LIB でリンクする」設定にする（実行時に MSVCR120.dll を使う）。本来ここに書くのは変だが、いくつかの子Makefileを直さないで済む方法は、これしかない。
リンカ（ここでは FL ）として、冗談みたいな話だが cl をあてがう。オプション /MD については同上。 
88

LIBBLAS = mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib

LIBBLAS = libblas.a
Intel MKL の参照をやめ、前述の MinGW-gfortran でビルドした Reference BLAS で代替する。 
90

LIBOTHERS = libf95.lib libgcc.lib -link $(PATHORDERINGS)

LIBOTHERS = libgfortran.dll.a libquadmath.dll.a libgcc.a
インポートライブラリ類の g95 から gfortran への変更。別途、環境変数 LIB の設定が必要。
この場所にリンカーパスを記述すると正しく認識しないので、削除。 
92

CDEFS   = -DAdd__

CDEFS   = -DAdd_
MinGW-gfortran のオブジェクトファイル内シンボルのデフォルト命名規則は「下線1個追加」。 
95
96
97

OPTF   = -O -i4 -fno-underscoring -fcase-upper
OPTL   =
OPTC   = -O2 -MD

OPTF   = -O3
OPTL   = -link $(PATHORDERINGS) -LIBPATH:$(topdir)
OPTC   = -O2 -MD
オプションを gfortran のものに合わせる。ここで、-fno-underscoring -fcase-upper の削除はソースコードとオブジェクトファイル内シンボルに影響する。
gfortran の最適化を -O（ -O1 相当）から -O3 としてみた。
リンカーパスの記述はこの場所にするのが正しい。
トップディレクトリに blaslib.a をコピーする手順上、リンカーのライブラリ指定にトップディレクトリを追加する。
Microsoft Cコンパイラの設定を、実行速度の最適化、MSVCRT.LIBリンクに設定する。
※OPTC の指定において、-Ox と -O2 のどちらが良いのかはよくわからない。テストした2016年当時は -Ox としていたが、色々な事例を見ると -O2 のほうが適切なようなので、 -O2 に変更した。

(2) MUMPS_5.0.1\examples\Makefile 修正

盛りだくさんなので、ここだけ表の書式が違いますが、ご勘弁を。

まず、テストプログラムの関連。これは頑張って修正してもどうせ動かない実行ファイルしかできない（後述）のだが、この修正を施しておかないと make が途中で止まってしまうので、やむなく行う。

表の横幅が収まりきらないため、折り返し可で書いています。表示が折り返されていても実際には行番号あたり1行なので、ご注意願います。

行修正箇所 
29
オリジナル 
	$(FL) -o $@ $(OPTL) ssimpletest.o  $(LIBSMUMPS) $(LORDERINGS) $(LIBS) $(LIBBLAS) $(LIBOTHERS)
修正後 
	$(FL) -Fe$@ $@.o $(OPTL) $(LIBSMUMPS) $(LORDERINGS) $(LIBS) $(LIBBLAS) $(LIBOTHERS)

35
オリジナル 
	$(FL) -o $@ $(OPTL) dsimpletest.o  $(LIBSMUMPS) $(LORDERINGS) $(LIBS) $(LIBBLAS) $(LIBOTHERS)
修正後 
	$(FL) -Fe$@ $@.o $(OPTL) $(LIBSMUMPS) $(LORDERINGS) $(LIBS) $(LIBBLAS) $(LIBOTHERS)

41
オリジナル 
	$(FL) -o $@ $(OPTL) csimpletest.o  $(LIBSMUMPS) $(LORDERINGS) $(LIBS) $(LIBBLAS) $(LIBOTHERS)
修正後 
	$(FL) -Fe$@ $@.o $(OPTL) $(LIBSMUMPS) $(LORDERINGS) $(LIBS) $(LIBBLAS) $(LIBOTHERS)

47
オリジナル 
	$(FL) -o $@ $(OPTL) zsimpletest.o  $(LIBSMUMPS) $(LORDERINGS) $(LIBS) $(LIBBLAS) $(LIBOTHERS)
修正後 
	$(FL) -Fe$@ $@.o $(OPTL) $(LIBSMUMPS) $(LORDERINGS) $(LIBS) $(LIBBLAS) $(LIBOTHERS)

次に、C言語ソースに対してわざわざ中間オブジェクトを作らず cl でまとめて一発でつくってしまうように変更。cleanは、出てくる成果物の実情に合わせる。

行修正箇所 
50
51
オリジナル 
c_example:	$(LIBDMUMPS) $$@.o
	$(FL) -o $@ $(OPTL) $@.o $(LIBDMUMPS) $(LORDERINGS) $(LIBS) $(LIBBLAS) $(LIBOTHERS)
修正後 
c_example:	$$@.c $(LIBDMUMPS)
	$(CC) $(OPTC) $(INCS) $(CDEFS) -I$(topdir)/include $< $(OPTL) $(LIBDMUMPS) $(LORDERINGS) $(LIBS) $(LIBBLAS) $(LIBOTHERS)

54
55
56
57
58
オリジナル 
.SUFFIXES: .c .F .o
.F.o:
	$(FC) $(OPTF) $(INCS) -I. -I$(topdir)/include -c $*.F $(OUTF)$*.o
.c.o:
	$(CC) $(OPTC) $(INCS) $(CDEFS) -I. -I$(topdir)/include -I$(topdir)/src -c $*.c $(OUTC)$*.o
修正後 
.SUFFIXES: .F .o
.F.o:
	$(FC) $(OPTF) $(INCS) -I. -I$(topdir)/include -c $*.F $(OUTF)$*.o



81
82
オリジナル 
clean:
	$(RM) *.o [sdcz]simpletest c_example
修正後 
clean:
	$(RM) *.o *.obj *.exe [sdcz]simpletest c_example

(3) MUMPS_5.0.1\PORD\lib\Makefile 修正

行オリジナル修正後備考 
31
32

clean:
	rm -f *.o

clean:
	rm -f *.o libpord$(LIBEXT)
他のものと同様になるように、ただの clean でもライブラリアーカイブ（ .a ）を消すようにする。これは趣味の問題であり、元のままでも構わない。 
34
35

realclean:
	rm -f *.o libpord.a

realclean:
	rm -f *.o libpord$(LIBEXT)
ここだけ拡張子が .a 固定になっているという凡ミスの修正。

(4) MUMPS_5.0.1\src\mumps_c.c 修正

行オリジナル修正後備考 
45
55
65
75
の各行

# if defined(UPPER) || defined(MUMPS_WIN32)

#if defined(UPPER)
mumps_compat.h に 
#if defined(_WIN32) && ! defined(__MINGW32__)
# define MUMPS_WIN32 1
#endif
という記述があり、この #if が成立すると、C言語ラッパー関数内において、対応するFortran関数の呼び出しのシンボルが大文字で定義される。
これは、Intel FortranのWindows版がオブジェクトファイル内シンボルを大文字で出力するという仕様に適合させるためらしい。
gfortranは関数シンボルを全部小文字で記録する仕様であり、かつ、g95 時代の -fcase-upper のように大文字で記録するように変更するオプションは廃止済みのため、この変換マクロは邪魔である。
Windows版Intel Fortranの仕様がイレギュラーなのであるから、それを使う場合に限り UPPER を定義するべきという立場のほうがリーズナブルである。
なお MUMPS_WIN32 は他箇所で別目的にも使われているマクロなので、いじらないこと。

(5) MUMPS_5.0.1\src\mumps_common.h 修正

行オリジナル修正後備考 
30

#if defined(UPPER) || defined(MUMPS_WIN32)

#if defined(UPPER)
mumps_c.c の修正と同じ。

(6) MUMPS_5.0.1 ビルド

Visual Studio 2013 のセットアップ時に Windows SDK を入れておく必要がある。インストール時のオプションによっては SDK が入っていない場合があるようだが、ここではその解決方法については触れないので、別途解決しておくこと。

ビルドを行う環境整備は、MS-VC++をインストールしたときにスタートメニュー内に追加されている筈の「Visual Studio 2013→Visual Studio ツール」の中にあるショートカットを使用する。
32bitの場合は「VS2013 x86 Native Tools コマンド プロンプト」、64bitの場合は「VS2013 x64 Native Tools コマンド プロンプト」または「VS2013 x64 Cross Tools コマンド プロンプト」である。基本的にはこれを動かすだけでMS-VC++の環境は整うはずである。
必要な方のコマンドプロンプトを起動したうえで、MinGW GCC および MSYS に必要な PATH を設定する。以下は一例にすぎないので、各々の環境に合わせる。例えば今風に MSYS2 を使う場合は、C:\MinGW\msys\1.0\bin を変更する必要がある。MinGW に必要な設定は、PATH を設定すれば他も自動でなされる。なお、この PATH の設定はテストの実行の時にも役立つ。

MinGW-W64 GCC-5.3.0 for 32bitの場合

path C:\mingw32\bin;C:\MinGW\msys\1.0\bin;%path%

MinGW-W64 GCC-5.3.0 for 64bitの場合

path C:\mingw64\bin;C:\MinGW\msys\1.0\bin;%path%

更に、MS-VC++ から gcc 並びに gfortran のライブラリを参照する必要があるため、環境変数を設定する。設定すべき環境変数は MS-VC++ と GCC のインストール状況に依存する。以下は例にすぎない。

MinGW-W64 GCC-5.3.0 for 32bitの場合

set LIB=%LIB%;C:\mingw32\lib\gcc\i686-w64-mingw32\5.3.0;C:\mingw32\lib\gcc\i686-w64-mingw32\lib;C:\mingw32\i686-w64-mingw32\lib

MinGW-W64 GCC-5.3.0 for 64bitの場合

set LIB=%LIB%;C:\mingw64\lib;C:\mingw64\x86_64-w64-mingw32\lib;C:\mingw64\lib\gcc\x86_64-w64-mingw32\5.3.0;C:\mingw64\lib\gcc\x86_64-w64-mingw32\lib;

以上で、make と打ち込めばビルドできる。成果物は

であり、これら一式と libblas.a を一緒に使う。

また、MUMPS_5.0.1\examples\ フォルダ内にはテスト用実行ファイルが出来上がっているはずである。ただし、動作可能なのはC言語のサンプル c_example.exe だけである。FORTRAN のサンプルは、例えば double 型（FORTRAN では real*8）の dsimpletest.exe であればソースコード中の CALL DMUMPS(mumps_par) にてクラッシュしてしまう。理由はわからない。他の型のものも同様に落ちてしまうようである。詳しい方の追試を待ちたい。

テストの実行時は、gcc並びにgfortranのランタイムDLLが必要なため、PATH設定が必要（上述のとおり）。gfortranのランタイムDLLに関するPATH設定をしない場合、ランタイムDLLを同じフォルダにコピーする。

c_example.exe のコンパイル時コマンドラインを抜き出すと以下のようになっている。こちらのケースにおいては libmingwex.a が含まれていないことに注意。含めると、動かない実行ファイルになってしまう。

cl -MD -Ox -I../libseq -DAdd_ -I. -I../include c_example.c -link -LIBPATH:../PORD/lib/ -LIBPATH:.. ../lib/libdmumps.lib ../lib/libmumps_common.lib libpord.lib ../libseq/libmpiseq.lib libblas.a libgfortran.dll.a libquadmath.dll.a libgcc.a
※-Ox と -O2 のどちらが良いのかはよくわからない。テストした2016年当時は -Ox としていたが、色々な事例を見ると -O2 のほうが適切なのかもしれない。

このMS-VC++/GCC併用ビルドによるライブラリは、MS-VC++の呼び出し側のソースコードがC++であっても（すなわち、上記で例えば c_example.c が c_example.cpp であっても）使用できる。

雑感

安定してビルドできるようになるまでには様々な試行錯誤が必要でした。

Windows 向けビルドのためにソースコードや Makefile に施された対応箇所は、どうやらかなり以前、g95 の時代に外部からの貢献があったものの残骸であったようです。そもそも MUMPS は HPC（High Performance Computing）のためのライブラリですから、開発元は Windows にあまり興味が無い（ファイル INSTALL にその旨明記）のは仕方のないことでしょう。いきおい、Windows 上でこういった物を使いたいユーザー、ましてや GCC と MS-VC++ を両方同時に使う必要に迫られる人は、世の中に殆ど居ない。結局、「しょうがないから Linux マシンを用意するか」ということになり、Windows でのビルドの努力をするのは時間の無駄と見られ、長く忘れ去られてしまっていたのでしょう。

しかし、限定的ながらも、僅かこれだけの修正で移植可能であること、後は、その修正をやる気になるかどうかだけが問題だったということも、また事実です。周囲の動きから取り残されていた部分を今風に修正するだけで済んだということは、おおもとのソースコードが注意深く記述され的確に抽象化されていることを示しています。

ただし、Windows との互換性に本当に問題がないかどうかの詳細調査はしていないことを、ご了承ください（今後も調査する予定はありません）。開発元が Windows に興味が無いと公言している以上、特に LLP64 データモデルに関する問題の内在は否定できません。SuperLU での問題事例 を参照してください。

この文書が誰か・何かの役に立てば幸いです。さらに願わくば、この文書の公開（並びに Eigen / Lis / SuperLU の事例も）が、日本における数値計算ライブラリ利用裾野を広げ、日本全体の底上げにつながることを、静かに期待します。

略歴

トップページ / 計算機関係の雑多なこと / 疎行列直接解法ライブラリMUMPSをMinGW gfortranでビルドする
このサイトについて・著者連絡先