ついにGtkmm3のHelloWorldに成功した。 今回は取り急ぎ、事前準備(環境変数)のことだけ。
証拠の画像。
前回まで
MinGW環境を新たに構築し、GTKmm3をソースコードからコンパイルした。
今回
今回はコンパイルで生成されたGTKmm3のDLLを使ってHelloWorldしてみた。 しかし、失敗した時と同様のエラーダイアログが発生した。 libstdc++-6.dllの競合が原因だった。環境変数のPathを調整して解決した。
libstdc++-6.dllの競合
ググってみたら同じ境遇の方がおられる様子。
"g++ libstdc++-6.dll"で検索。
"g++ libstdc++-6.dll rpath"で検索。
どうやらlibstdc++-6.dllの競合によって起こっている場合があるらしい。 以前、考えたとおり。
試してみた
-Wl,-rpath C:/MinGW_GET/bin
-Wl,-rpath C:/MinGW_GET/bin
を付与してHelloWorldのソースコードをコンパイルしてみる。
しかし、exeを実行しても同様のエラーダイアログが表示されて実行できない。
msysから実行する
hello.exe
をmsysから起動すると実行できた。
C:\MinGW_GET\msys\1.0\msys.bat
を実行。hello.exe
コマンドを打って実行。- hello.exeが起動できた。
今まではファイラから直接exeをダブルクリックして実行していてエラーダイアログが出ていた。 でも、msysから実行すればイケるらしい。
なんじゃそりゃ。
原因の予想
おそらく、環境変数のPathの中に、libstdc++-6.dll
が配置してあるパスが2つ以上あるのだろう。
今回参照させたいのはC:/MinGW_GET/bin
。それ以外のどれかのパスにlibstdc++-6.dll
が配置してあるパスがあるはず。
たぶんそいつが参照されてしまうせいで、例のエラーダイアログが出たのだろう。
ようするにGTKmm3をコンパイルした時に使用したlibstdc++-6.dll
を参照すれば成功するはず。
でも今はべつのlibstdc++-6.dll
を参照してしまっているせいでエラーになっていると予想した。
環境変数の確認
早速、環境変数のPathを確認する。
面倒すぎるが、1つずつ確認するしかない。
libstdc++-6.dll
があるなら○
。ないなら×
。パス自体が存在しないなら‐
。
ユーザ環境変数のPATH
結果 | パス |
---|---|
‐ | C:\HaxeToolkit\haxe\ |
‐ | C:\HaxeToolkit\neko |
× | C:\Program Files\Gtk+\bin |
× | C:\Documents and Settings\Administrator\Application Data\npm |
‐ | C:\Documents and Settings\All Users\Application Data\chocolatey\lib\msys2 |
問題なし。
システム環境変数のPath
結果 | パス |
---|---|
× | C:\Ruby193\bin |
× | C:\gtkmm\bin |
× | C:\Program Files\Windows Resource Kits\Tools\ |
× | %SystemRoot%\system32 |
× | %SystemRoot% |
× | %SystemRoot%\System32\Wbem |
× | C:\Python27\Scripts |
‐ | D:\tools\Xml\libxml\libxslt-1.1.26.win32\bin |
‐ | D:\tools\Xml\libxml\libxml2-2.7.8.win32\bin |
‐ | D:\tools\Xml\libxml\iconv-1.9.2.win32\bin |
‐ | D:\tools\Xml\libxml\zlib-1.2.5\bin |
‐ | D:\tools\Compiler\PortablePython2.7.3.2\App |
‐ | D:\tools\Server\Node\nvmw |
× | C:\WINDOWS\system32\WindowsPowerShell\v1.0 |
× | C:\Program Files\Microsoft\Web Platform Installer\ |
× | C:\root\tool\System |
× | C:\Program Files\Mono-3.2.3\bin |
○ | C:\Program Files\GtkSharp\2.12\bin |
× | c:\Program Files\Microsoft SQL Server\100\Tools\Binn\ |
× | c:\Program Files\Microsoft SQL Server\100\DTS\Binn\ |
× | C:\Python27 |
× | C:\Program Files\Git\cmd |
× | C:\Program Files\Pandoc\ |
× | C:\Program Files\nodejs\ |
× | C:\Documents and Settings\All Users\Application Data\chocolatey\bin |
× | C:/MinGW_GET/msys/1.0/bin |
× | C:/MinGW_GET/msys/1.0/gtk3/bin |
× | C:/MinGW_GET/msys/1.0/home/m4-1.4.14-1-bin/bin |
○ | C:/MinGW_GET/bin |
調整
システム環境変数のPath
を以下のように調整した。
C:/MinGW_GET/bin
を先頭にした(C:\Program Files\GtkSharp\2.12\bin
よりも前)
今回のエラーとは関係ないが、GTKmm3のDLL参照パスを追加しておいた。
C:/MinGW_GET/msys/1.0/gtkmm3/bin
を追加
結果的に、以下のようにした。
C:/MinGW_GET/bin;
C:/MinGW_GET/msys/1.0/bin;
C:/MinGW_GET/msys/1.0/gtk3/bin;
C:/MinGW_GET/msys/1.0/gtkmm3/bin;
C:/MinGW_GET/msys/1.0/home/m4-1.4.14-1-bin/bin;
C:\Ruby193\bin;
C:\gtkmm\bin;
C:\Program Files\Windows Resource Kits\Tools\;
%SystemRoot%\system32;
%SystemRoot%;
%SystemRoot%\System32\Wbem;
C:\Python27\Scripts;
D:\tools\Xml\libxml\libxslt-1.1.26.win32\bin;
D:\tools\Xml\libxml\libxml2-2.7.8.win32\bin;
D:\tools\Xml\libxml\iconv-1.9.2.win32\bin;
D:\tools\Xml\libxml\zlib-1.2.5\bin;
D:\tools\Compiler\PortablePython2.7.3.2\App;
D:\tools\Server\Node\nvmw;
C:\WINDOWS\system32\WindowsPowerShell\v1.0;
C:\Program Files\Microsoft\Web Platform Installer\;
C:\root\tool\System;
C:\Program Files\Mono-3.2.3\bin;
C:\Program Files\GtkSharp\2.12\bin;
c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;
c:\Program Files\Microsoft SQL Server\100\DTS\Binn\;
C:\Python27;
C:\Program Files\Git\cmd;
C:\Program Files\Pandoc\;
C:\Program Files\nodejs\;
C:\Documents and Settings\All Users\Application Data\chocolatey\bin;
競合を発見した
C:\Program Files\GtkSharp\2.12\bin;
にあった。
だいぶ昔、GtkSharpをインストールした記憶があるような無いような…。
汚染されすぎな環境変数
ほかにも、昔インストールしただろうけど記憶にないものが多数ある。 パスが存在しないものまである。
優先順位
Pathに書く順序を変えた。C:/MinGW_GET/bin
を先頭にし、C:\Program Files\GtkSharp\2.12\bin
よりも前にした。
その後、exeをダブルクリックで実行すると、実行できた!
どうやら先頭のパスが優先されるらしい。
GtkSharp
GtkSharpはインストールしたことすら忘れていた。 使っていないから削除してもいいのだが、使うかも知れないので念のためとっておく。 ただ、もしかするとGtkSharpのほうで不都合が出るかもしれない。
異なるMinGWのバージョンは共存できない?
異なるMinGWのバージョンは共存できないのだろうか。
MinGWのファイル自体は配置できる。
でも、異なるMinGWのバージョンでコンパイルしたexeは、そのバージョンのlibstdc++-6.dll
ファイルを必要とするらしい。
exeファイル実行時に困る。
exeは特定バージョンのlibstdc++-6.dll
に依存する
MinGWでコンパイルしてできたexeファイルは、libstdc++-6.dll
に依存する。
しかもlibstdc++-6.dll
は、MinGWのバージョンによって異なる。
よって、exeごとに適切なバージョンのlibstdc++-6.dll
を参照させてやらねば実行時にエラーダイアログが出る。
今回の場合を考えてみる
ファイラからダブルクリックで実行すると失敗したのは、環境変数のPathにあったlibstdc++-6.dll
が、exeが必要とするバージョンのlibstdc++-6.dll
と違ったからだろう。
msysから実行すると起動できたのは、そのmsysが参照するlibstdc++-6.dll
が、exeが必要とするバージョンのlibstdc++-6.dll
と一致したからだろう。
今、環境変数のPathにあるMinGWのバージョンは5.3.0。
だからファイラからダブルクリックでexeを実行したとき、5.3.0のlibstdc++-6.dll
を参照する。
ファイラからダブルクリックで実行したときは、5.3.0でコンパイルされたexeでないと、例のようなエラーダイアログが出て実行できないかもしれない。ようするにバージョンの差異による問題が生じうる。
たとえば、MinGW4.6.2でコンパイルしたexeを実行するときは、4.6.2のlibstdc++-6.dll
を参照すべき。
そのためには、MinGW4.6.2と一緒にインストールしたmsysから、exeを呼び出して実行すればいいらしい。
ファイラからダブルクリックで実行したら、環境変数のPathに通した5.3.0のlibstdc++-6.dll
を参照してしまう。
複雑な依存関係
MinGWとコンパイルしたexeの依存関係…なんて面倒なんだ。 絶対こんなこと忘れる。 依存関係に翻弄されるのは嫌だ。勘弁してくれ。よしなにやってくれ。
実行時は何も考えず、ダブルクリックしたら起動するようにしてくれ。 あのエラーダイアログから、こんな背後やら事実関係を推測する過程がとても大変で面倒。
おわり
とにかく、今はMinGW5.3.0だけでいい。 これでGTKmm3開発環境が整った。