Gcc-Win32 (その2) - 1997 Sep.21 - 1. Abstruct 　　GCC for Win32の導入記録、その2であります。β18を入れてみました。 2. Introduction 　　ふと、GNU-Win32のページを見るとβ18がアナウンスされていた。場所は： http://www.cygnus.com/misc/gnu-win32/ 　　当方としてはunixアプリのポーティングに興味はない(というか、DOSな人 　なんで、unixのアプリ自体に縁がない)のでそこからMinimalist GNU-Win32の 　リンクに飛ぶ。 　　で、β18用に新しくReadmeが書き直されているようなので読む。すると 　最初にcdk.exe, 15MB (実際は13,730KB)を落とせ、とある。(@_@;) !! 　　い、以前は全部合わせても5MBだったのに、15MBだとぉ!? 　　どうもcdkの方はunixアプリの移植をメインとするフルセットであり、 　Minimalistの方は純粋なWin32アプリのためのサブセット。しかし、cdkの 　ファイルと一部を共用するから先ずcdkが必要、ということらしい。 　　ここでう〜む。となってしまい、長らく放置していたのだが、ようやく 　今回やってみた、という次第。明日見てβ19があったりしたらショック 　でかいかもね(^^;; 　　落としたもの： cdk.exe 13,730KB GNU C and many many files mingw32_014_tar.gz 56KB Minimalist本体 3. Extraction 　　cdk.exeはInstall Shildによる自己展開ファイルなので簡単。実行すればそれで 　終わり。後々を考えるとデフォルトのディレクトリは変更しない方が吉。 　　…という後知恵めいたことが言えるのは実は自分のメインマシンに導入 　する前にLibrettoに入れたから。モバイルな人からは絶対に敵視されかねない 　極悪な使い方をしてたりする。Librettoは小さい。邪魔にならない。リカバリ 　CDさえあればどんなに環境を破壊しても汚しても元通り。故に先ずLibretto君に 　生贄の子羊になってもらう、というやり方で運用してたりする。 　　メインマシンがこけるとえらい騒ぎだが、Libretto君が死んでもしばらく 　目に見えない場所でリカバリしてやれば元通りなんで、重宝する。その代わり 　環境設定が大変になるんで自分の最低環境設定用のFDは作ってある。 　　バッチでごりごりとやってしまう奴だが、便利。 　　で、minimalistのreadmeに従って(これ、具体的にどれなのかは不明。 　GCCのWWWから「名前を付けて保存」したのです)先ずcygwin32をセットアップ。 　cygwin.batはないから、readmeからCut&Pasteしてバッチを作成。 　　何かする前に以前のバージョンのdll、systemの下のcygwin.dllをリネームして 　しまう。β18ではPATH内にdllがあれば良いそうなのだから、新バージョンの 　cygwin.dllは移動しない。 　　早速テストプロをコンパイルしようとしたらgccが動かない。PATHにLFN 　(Long file name)があるため。Command.comならひょっとしてそのまま動くのかも 　しれないが、こっちは往年のNdos.comがシェルなのでPathを修正。OK。 　　unixのプログラムを移植するにはここまででOKなのだが、こっちは純Windows95 　プログラムを作るのが目的。unixのAPIは知らない、分からない、資料なし、 　なのだから先に進む。 　　あ、この時点でgdbを起動するとTcl/Tkも起動する。おぉ！unixのGUIだぁぁ！！ 　(どのGUIだよ、という突っ込みはなしね。DOSなあたしには特定できるだけの 　知識がないのさ)ちょっと感動する(wish42も起動するぞ。使い方分からないけど)。 　　さて。cdk.exeはC:\gnuwin32をデフォルトとした。Minimalistの方はと言えば 　どうやらC:\mingw32がデフォルトのようだ。 　　ディレクトリ(フォルダだろ？という突っ込みは却下)を掘り、展開。 　tar -xvf mingw~1.gz 　　前回とは違い、GNUのtarを動かす。こいつはdos版のtarと違い、LFNをサポート 　しているはずだ。が、展開されたファイルにLFNはないみたい。あらら？ 　わざわざcygwin.batをreadmeから生成したのは何の為？＞私 　　まぁ良い。これで準備は(ほぼ)整った。 　　Readmeの指示通り、テストプロをコンパイル。問題なし。 　　…どうでも良いが、"Hello world!"をprintfするテストプロですらcygwin.dllが 　ないと動かないのね。きっとランタイムで初期化時に呼ぶんだろうなぁ。 4. Settings 　　move-win32.batを実行...ってmove-win.batしかないやんけ？構わずやると 　エラー。ndos.comではだめか？で、command.comを使う(もちろんだが、この 　バッチを動かす為には引数が必要。readmeを参照してね)。 　　move-win32.bat実行後、gccがwin32のファイルを見付けられるようにする 　ためにはwin32-ap.batを実行すれば良いらしい。 　　win32-ap.batと先のcygwin.batを統合したバッチを新たに書くことにする。 　最終的にはautoexec.batでこれらの設定を全てするつもりなので、そうする。 　　しかし。unix系って何でまたこんなに環境変数の浪費に無頓着なんでしょうね。 　出自ゆえの所業なのだとは思うけど、1 byteを開放するのに必死になった経験がある 　組み込みソフト経験者たる私にとっては神経逆撫でされる思いよ。 call foo ret 　　てなのがあれば間違いなく、 jmp foo ; call and return 　としてしまう性癖が染み付いてるものね。 ＃あう。move-win.batしかない理由が判明。tarが、だな。DOS版だった。何の為に 　gnuwin32をインストールしたのだ？pathの設定でc:\dosが先にあったらしゃれに 　ならんやんか！！＞あたし 　PATHを再設定し、gungip、tarとやって再展開。…しかしそうするとGNUのgrepが 　DOS版grepより先に動くぞ。GNU版のgrepってば、ファイル名の大文字／小文字を 　区別しやがる。何てこったい！ 　　foo_tar.gzをバラす手順としては： gunzip -d foo_tar.gz 　　ここで期待としては： foo.tar 　　が、できて欲しいんだけど、 foo 　　となるんだな。でも気にしなくて tar -xvf foo 　　で、問題なく展開されるから、ま、良いんだけど……。 5. Test 　　すったもんだがちょっとあった。readmeにspecsファイルを移動せよ、とあるの 　だが、そのディレクトリが存在しないのだ。 　　結局、specsをサーチしてもっともらしい操作をした。つまり： 　move \GNUWIN32\B18\H-I386~1\LIB\GCC-LIB\I386-C~1\CYGNUS~1.2-9\SPECS 　　　　\GNUWIN32\B18\H-I386~1\LIB 　　という訳。gcc -vで確認するとよさそう。早速： 　　gcc -o test.exe test.c -windows 　　成功。念のためcygwin.dllが存在しない別マシンからできたtest.exeを実行して 　みたが問題なし。 　　ちなみにautoexec.batに追加した内容は次の通り。 　SET C_INCLUDE_PATH=C:\mingw32\include;C:\mingw32\win32\include; 　SET CPLUS_INCLUDE_PATH=C:\mingw32\win32\include; 　PATH=C:\WIN95;C:\WIN95\COMMAND;C:\gnuwin32\b18\H-i386~1\bin;C:\gnuwin32\b18\tcl\bin;C:\DOS;C:\WIN95\JAVA\BIN 　SET TCL_LIBRARY=C:/gnuwin32/b18/tcl/lib/tcl7.6 　SET GDBTK_LIBRARY=C:/gnuwin32/b18/share/gdbtcl 　SET GCC_EXEC_PREFIX=C:\gnuwin32\b18\H-i386-cygwin32\lib\gcc-lib\ 　SET LIBRARY_PATH=C:\mingw32\lib;C:\mingw32\win32\lib; 　PATHに余計な指定も入っているけど気にしないように＞all 6. Compile 　　で、以前のようにSDKサンプルをコンパイルしようとした。前のはmake -f MAKEFILE 　とやらないとだめだったのだが、今回のはmakeだけでちゃんとmakefileを読み込んで 　くれる。くれるのだが、MAKEFILE:7: *** missing separator. Stop.だとさ。 　　う〜む。7行目は!include なんだけど... 　　結局、gcc専用のmakefileを作ってしまったりする(^^;; 　　まぁ、それで問題なくOKOK。できた*.exeの比較は別途書くとして、ヘッダの誤りも 　修正されてる(気付いたのはZeroMemory()。以前のgccのヘッダには入ってなかった。 　あれ？とか思っているうちにβ18が出てたんで、レポートは出さなかったけど)。 　　ま、とにかくgccはInstallできたと。さてと。何作るべぇ(笑) 7. C++ 　　更に調子に乗ってC++をコンパイルできるようにしてみる。 追加で落としたもの： 　　stdcpp_tar.gz 153KB C++ include, lib 　　stdcppsrc_tar.gz 256KB そのソース 　　samples_tar.gz 3KB サンプル 　　必要なのは最初の奴だけで後の2つは不要なのだけど、毒を喰らわば皿までも... 　　展開し、ライブラリlibstdc++.aはc:\mingw32\libへ、インクルードc++\*.*は 　c:\mingw32\include\c++\*.*へ。 　　さっそく： #include int main(int argc, char **argv) { cout << "hello world!\n"; return 0; } 　　で、またテストコンパイルですったもんだがあった。基本的には gcc pp.cpp -lstdc++ 　　これでOKなのだが、ソースの拡張子が問題。ざっとはまった結果によれば： gcc pp.c ; ソースはCである gcc pp.C ; ソースはC++である gcc pp.cpp ; ソースはC++である gcc pp.cc ; ソースはC++である gcc pp.CPP ; ソースは正体不明 gcc pp.CC ; ソースは正体不明 　　うぅ。大文字・小文字をしっかり区別してる...Windowsではファイル名の大文字・ 　小文字は無視して欲しいなぁ(泣) 　　ちなみに環境変数もさっきのではまずくて： CPLUS_INCLUDE_PATH=C:\mingw32\include\c__~1;c:\mingw32\include\nonansi;c:\mingw32\include;C:\mingw32\win32\include; 　　ここまで必要だった。いや、ここまであれば少なくとも先のソースはa.exeになる。 　　nonansiまで必要だったのはiostream.hがio.hを必要とするためで、このio.hは実は 　nonansiの下の他にc:\gnuwin32のずっと下のディレクトリにもある。 　　どっちが正解なのか迷ったのだが、結果オーライという訳で(^^;; 　　う〜ん。ディレクトリが深過ぎるというか、環境変数の使い過ぎだよぉ(泣) 　specsファイルで指定できたって良さそうなものなのだが……。 　　さてと。比較の意味で... #include int main (int argc, char **argv) { printf("hello world!\n"); return 0; } 　　できた結果をstripすると： CPP.EXE 51,200 byte ; C++ C.EXE 2,560 byte ; C 　　うぅ。20倍。CのランタイムがOS付属なのに対してC++のランタイムがそうでは 　ないから？それとも使っていないクラスライブラリが軒並みリンクされた？ 　　閑話休題： 　　C++のソースも展開してみた。docsというディレクトリになにやらマニュアルらしい 　ファイルが...。う〜む。読んだ方が良いのだろうか？ 　　includeというディレクトリもまた出来る。が、このinclude下の*.hは既にコピーした 　include\C++の下にもあるようだ。 　　で、ソースを展開してできたincludeと、バイナリリリースを展開してできたinclude 　では構成がちと違う。ソース側にはstlというディレクトリができた。 　　これはもしかしてあのstlかい？ここに含まれる*.hはバイナリリリースのinclude下に 　も含まれるようだけど。 　　…どうもそうらしい。そんな気がする。間違ってるかもしれない。が、当面はどうでも 　良いこと。何故なら私、templateって知らないのぉ(号泣) ＃情けねぇ(-_-; 　　ここまでやって気付いたが、HDDの空きも随分寂しくなってしまった。いっそのこと 　C:\GCCにでも固めてしまおうかと思う今日この頃。しかし後が恐そう。 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　− 以上 −