gcc on Windows 9x 1998,March,18 　β19が出たのは良いけど、あれ？と思うこと多く、結局こうしました、という 　顛末の記録です。 ====== 内容： 1. gcc-b19 2. gccが一杯 3. My gcc ======= gcc-b19 at Mar.3.1998 - Mar.5 ふらっと見たら、遂にβ19がリリースされていた！！以下はそれの(例によって) 日記風のインストール履歴である。 1. まずダウンロードだ！ 　で、と？ 　ftp: 　　見ると次の2つがある。latestの方を落とす方が幸せだろう。 gnu-win32-b19.html latest.html 　　＃Mar.4.1998ではどっちも同じのようだが... 　Directory of /pub/ftp.cygnus.com/gnu-win32/latest 　Current directory is /pub/ftp.cygnus.com/gnu-win32/latest 　Welcome to go. The files we make available are in the pub directory. 　Please read the file README.txt 　 it was last modified on Fri Feb 27 06:29:00 1998 - 4 days ago 　Up to higher level directory 　 README.txt 14 Kb Fri Feb 27 14:29:00 1998 　 ash-linux-0.2.tar.gz 106 Kb Mon Mar 2 06:32:00 1998 　 cdk-man.tar.gz 2096 Kb Fri Feb 27 14:17:00 1998 　 cdk-split/ Fri Feb 27 11:18:00 1998 Directory 　 cdk-src.tar.gz 26817 Kb Fri Feb 27 14:01:00 1998 　 cdk-src/ Fri Feb 27 09:46:00 1998 Directory 　 cdk.exe 12393 Kb Fri Feb 27 14:01:00 1998 　 faq.txt 130 Kb Fri Feb 27 14:01:00 1998 　 md5sums 1 Kb Fri Feb 27 14:17:00 1998 　 usertools-man.tar.gz 677 Kb Fri Feb 27 14:17:00 1998 　usertools-split/ Fri Feb 27 08:21:00 1998 Directory 　 usertools-src.tar.gz 8897 Kb Fri Feb 27 14:02:00 1998 　 usertools-src/ Fri Feb 27 08:11:00 1998 Directory 　 usertools.exe 3138 Kb Fri Feb 27 14:02:00 1998 　う？どれがどれやねん(@_@!) 　独断と偏見な解釈： 　　ash-linux-*　は、その名の通り、linux対応なのだろう 　　*-split　　　は、見ると単に分割してあるだけだ 　　md5sums　　　は、チェックサムのリストだ。PGPではないけど、似たような 　　　　　　　　 用途に使われるものだろう(多分) 　　*-src*　　　 は、どう考えてもソースだ。当面関係ない 　　だ、もんで以下を落とした： cdk.exe 12,394KB cdk-man_tar.gz 2,097KB faq.txt 134KB README.txt 15KB usertools.exe 3,139KB usertools-man_tar.gz 678KB 　　が、usertools*はどうもcdk*のサブセットらしい。よって必要なのは上から4つ。 　　都合、14,640KBとなる。 　　前のCDKにもコンパイルとは関係ないツールが山と入っていたのでusertoolsは 　　不要ではないかと思いながらダウンしたのだが案の定であった。 　　usertools.exeはcdk.exeのサブセット。つまり、cdk.exeを展開すればusertools.exe 　　にある全てのファイルもあるのだ。 　README.txtの大意： 　　・以前のバージョンと.dllに互換性がないので、cygwinb19.dllとした 　　・MS製品との互換性を向上させたので、以前の*.o、*.aは使えない 　　・windresという新しいリソースコンパイラがある 　　・その他付属ツール類もアップデートした 　　・i386でも動作はするが、Pentium向けの最適化をした 　　・makeは環境変数MAKE_MODEにUNIXと指定しない限り、cmd.exe/command.comを使う 　　　ようになった(道理でβ18ではmake cleanがうまく動作せぇへんかったんやな) 　　・その他の雑多な改良をしている 2. Install 　このバージョンでは、Startメニューにgccに必要な環境変数を設定した上で、 　DOS窓でbashを起動するショートカットが設定される。 　で、「環境変数が足りないのぉ」と言われたら： 　　shell=c:\command.com /e:4096 /p 　を、config.sysに追記せよとある。ま、場合によりけりね。うちはndos.comだし、 　そもそもc:\にcommand.comなんざ存在してないし、command.comのような情けない 　Shellは使っていない。 　　後、C:\tmpやC:\binを作り、C:\binにはsh.exeを入れろとかうるさい指示もある。 　指示通りやらなくとも大丈夫みたいだが。 　　で、ちょいちょいとAutoexec.batをいじり、copy con hello.cで...OKOK。 　ちゃんとa.exeができたと。でも……。 3. ちょっと待て 　β19は確か純粋なWin32アプリもサポートするはずではなかったか？ 　しかるにそのような記述はどこにもない！ 　私はUNIXアプリのポーティング(移植)には関心がないのだ。 　純Win32なアプリをgccで作ることをサポートしているサイトに飛ぶ。しかし、 　そこの情報は未だβ19の発表日時以前のものだった。しかし： 　Mingw32のサイトからリンクを辿ると……。げ。gccが一杯あるんでないかい？。 ★「GCCが一杯」に続く 　　　　　　　　　　　　　　　　　　　　　　　　　　　− 以上 − ========= GCCが一杯 at March.11, 1988 - 12 　最初に謝罪： 　　元情報が示せません。元URLは不明です。あちこちをサーフィンして集めて得た 　　情報を適当に訳して理解できた範囲でまとめてます。　　 　　とんでもない誤解がある可能性もあります。 　　そもそも自分用のメモと思って書いているものを何も考えずに載せてます。 　さて： 　1.Cygwin32、これが元々gccをWindowsに移植するものであった。目的としては 　　unixのソースを最小限の変更でWindows 95/NTに移植するためである。 　　従って、unixのAPIをWindowsのAPIに変換する.dllが必須。 　　shellもbashをデフォルトで使うし、TCL/TKその他もてんこ盛り。 　2.これに対してMingw32は、純粋なWin32アプリを作成するのが目的。ただし、 　　コンパイラ自体はCygwin32のものを使う。出来た物は純粋なWindows環境で 　　動作するが、gcc自体はCygwin32環境下でないと動作しない。 　3.egcsは、基本的に先進的機能の先取りを目的とする、Cygwin32から派生した 　　 ものである。Mingw32版(つまりunix互換レイヤ用.dllを必要としない物)もある。 　4.これらとは別に、Mingw32を使ってunix互換APIレイヤが不要なgccを作成した人が 　　いる。こっちはgcc 2.8.1ベース。 　5.gccの動きとは別にCコンパイラを作った人もいる。これがlcc-Win32 　で： 　　gcc-Win32 β18 gcc 2.7.2がベース 　　gcc-Win32 β19 これもgcc 2.7.2ベースみたい 　　gcc 2.8.1 堅実で安定したコンパイラの供給を目的とする 改良点： 　・例外処理のバグfix。従って以前のバージョンで作成した共有ライブラリは 　　なんとかせよ、とある(「なんとか」の内容はパス) 　・デバッガ、プロファイラ機能の増強 　　でもELFシステムとかDwarfデバッグフォーマットバージョン1とか言わ 　　れてもあっしには分からない。妖精やドワーフ？う〜む(笑) 　・メモリチェックツールサポート 　　何だろう？バウンズチェッカのgcc版？ 　・-fstack-checkによるスタックオーバーフローチェック。でもABIって何？ 　　勘で訳すと、スタック溢れもチェックしねぇよーなシステム用に新設 　　したオプション、ってか？(きっと間違ってるな) 　・-Wundef、-Wno-undef。#ifで未定義な識別子を評価したら警告。 　　…と書いてあるけど、前者は未定義なやつのundef、後者はundefしない 　　ままdefineした場合、でないかな？defineが同じならCかC++のどっちか 　　は再定義の警告が出ないってのが言語仕様のはずだから 　・-Wall、-Wimplicitは暗黙のint変数定義に対する警告。 　　例として`register i;'これはCの標準化委員会が、次バージョンでそういう 　　定義が許されないように決定したかららしい。 　　-Wimplicit-function-declarations、-Wimplicit-intはこのオプションの 　　サブセットとか 　・-Wsign-compareは、符号付き数と符号無し数の比較に警告を出す。 　　ってまんまやんけ 　・cxrefのためにcccpのオプションとして-dl追加。 　　って何の事やらさっぱり分からない(;_;) 　・コンパイル環境設定もオプション追加。どうやら95/NTでは必要な環境変数 　　が1つに減ったらしい(これは嬉しいぞ) 　・g++も拡張。内容は殆どパス。下を除いて 　　(void *)0 はNULLポインタへの定数とは見なされない。NULLは__nullと 　　いうマジック定数と見なされる。これは(void *)であるが、-ansiが指定 　　された場合は(size_t)である 　・Objective-Cやx86以外のCPUに関する話は全部パス 　　　付記：C++ライブラリに付いて libg++ これは旧来のg++ユーザのためにあるが、今後は、 libstdc++ こっちを使うことをお勧めする 　　　とも書いてあった。 　　egcs 将来gccに盛り込まれるかもしれない実験的な機能を先取りする (だからつまりgcc 2.8.xより先進的なはず) 　　lcc-win32 Oh! no!!。届かない。リンク先がない！！あれ？ (どうもサーバが気まぐれらしい。つながる時にはつながる……) 　う〜む： 　 C++の場合、私のコンパイラの選択考察は次のようになる： 1. gcc 2.8.1ベースな新しいプロジェクトに乗る 利点：自分にとって意味不明で用法不明でもある多数の*.exeを 　　　捨てられる 　　　gcc 2.8.xなので、それなりに最新環境ではないかい？ 欠点：tarとか、必要なツールが未だ移植されてない 2. 従来通り、Cygwin32 + Mingw32に乗る 利点：とにかくunix-likeなツールは殆ど使える。manがないけど 欠点：使えもしないツールを多数抱えるのはHDDの無駄 3. egcs 欠点：あたし、C++は落ちこぼれです。とてもこんなコンセプトの 　　　代物を使いこなすことはできまっせん(;_;) 4. 商業品 利点：情報が豊富。多分gccでVxDを作るというのは苦しいと 　　　思われるので、デバドラ作るならM$製品しかない気がする 欠点：有料(^^; 　　　M$製品をフォローする覚悟なら、バージョンアップの度に 　　　H/W (と、もしかしたらOSまで)を買い換える覚悟が必要。 　　　情け容赦なく重くなる。M$が軽くなるゆーて実際に軽く 　　　なった試しは記憶にないもんな 　 Cの場合： 1. LSI-C86 (これはGNUとは無関係。かの有名な試食版の話) 16 bit版のFreeなCコンパイラはこれしか知らない。が、パス。 あたし、DOSなアプリならアセンブラで作るしぃ(^^;; (とゆーか、Cに馴染まないようなモンしか作らないのだった) ＃作れない、思い付かない、のかも知れない(-_-; 2. lcc-win32 コンパイルが高速だったし、SDKとの互換性もgccより良かったのだが、 ホームページはどこさいっただ？(一時的な現象のようだ) ★「My-GCC」に続く 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　− 以上 − ====== My GCC at March, 12-22, 1998 1. 方針 　gccをWindowsマシンで動かすにあたり、色々と選択肢が出てきたが、結局 　当方は次のように方針を定めた。 　・unix互換APIは捨て、Win32に限定。これは自分の仕事柄、Win32を選ぶしか 　　ないからである 　・ベースはMingw32を使ってgcc 2.8.1を移植し、unix互換を捨てた新プロジェクト 　　に乗る(egcsはパス) 　・ただし足りないツール類はgcc-Win32 β19から持ってくるものとする。 　　先ずtarは必要だしね 　・ヘッダファイルの類はgccを尊重する。あたしゃSDKとDDKのCD-ROMはほぼ正当に 　　個人所持してますから、MS純正ヘッダを使うことに何の問題もないんですけど、 　　何となくgccのヘッダファイルを使いたい気分なので 　…自分独自なカスタマイズも、やりすぎると自分の首を絞める。だからgcc-Win32 　β18はほぼデフォルト環境だったのだが、HDD不足もあり、覚悟を決める。 　幸い、デフォルトで各gccパッケージを展開すると何がどうなるかは例によって 　Libretto君が犠牲になって確認済みなので、後は実行あるのみ！ 　(我がLibretto君は、「何でも実験機」扱い。変になったら即、再インストール 　 できる体勢なので、思い切った実験とか妖しいアプリのインストールはみんな 　 Libretto君が一手に引き受けています。レジストリがぐちゃぐちゃになって 　 起動もしない状況になっても、CD-ROMからあっさり初期状態に戻りますから) 2. 必須ファイル(と、私が判断したもの) 　単位：[KB] gcc-Win32 β19より： usertools.exe 3,139 　＃実際、tarが欲しかっただけなのだが……xx.tar.gzというファイルの 　　展開が必要なければこの3Mなファイルは不要かも gcc 2.8.1を移植したサイトより： gas-980119.zip 1,903 gcc-2_8_1.zip 2,807 libstdc++-2_8_1.zip 352 mingw32-980105.zip 182 windows32api-980118.zip 390 make-3_76_1.zip 233 どこから落としたのか忘れた： res2coff_tar.gz 20 WinHelp形式のヘルプ：(なけりゃないで何とかなる気もする) ManPages.zip 4,360 ＃ちなみにManPagesDir.zipはManPages.zip内に含まれるので落とすのは無意味 ＃res2coffが必要なのは、新しいリソースコンパイラ、windres.exeでも 　.rcの"#include "処理中にSyntax Errorを起こすため。 　相変わらず、リソースのコンパイルはMSのrc.exeを使う方が良いようである？ 　(リソース作成にMS SDK付属の16 bitなResEditを使っているせいかもしれない) 3. 統合 　酔っぱらった勢いで統合。C:\gcc以下に全て集結。不要ファイルは削除し、 　Hello, World!を実現した直後で25.5MBだ。 　(この容量は過大である。bashを消したのに、bash経由でないと恐らく意味のない 　 コマンドやファイルがまだ残っているのは明らかな状態での話なので) 　WinHelp形式のドキュメントを展開しちまったこともある。gccディレクトリ以下には 　　bin、hlp、include、lib、samples 　のフォルダがある(それ以外のフォルダは全て粛正した)。 　bin下のコマンドにはcygwinb19.dllが必要な奴と、そうでないものが混在してるが、 　実用上、問題ない(実はndosのdescribeコマンドで区別が付くようにしている)。 　ごちゃごちゃとautoexec.batを修正し(インストールマニュアルに全部書いてあるので 　再掲はしない)、再起動。 　gcc -v 　Reading specs from C:\gcc\lib\gcc-lib\i386-mingw32\2.8.1\specs gcc version 2.8.1 ふ。完璧。 4. え゛？ 　makeできないのだ。以前のアプリが。WindResに付いては警戒していたので、ちょっと 　テストしたら分かったが、gcc β18対応の我がmkmf.batで作ったmakefileが全く動作 　しないとは何事？結局、 　make -f makefile 　で解決はしたが、なんだかなぁ。β19のmakeなら-fしなくても通ったで！？ 　make.exeはだから結局β19のものと入れ替え。 　で、これだけでは解決しない。__argcとかを使ったアプリがリンクでけへん！！ 　specsも見比べて見たがわからん。grepしてようやく判明。gcc 2.8.1では__argcでは 　なくて、_argcなのだった。 　M$非互換である。困ったものだ。勝手にOS KernelをバージョンアップするM$にも 　腹立たしいが、β18では通ったのだが……。 　通常、M$が人知れず仕様を改変するのが、他社アプリの致命傷となるのだが、今回は 　M$に責務はない。で、freeなソフトに文句を言うとは天に向かって唾を吐くが 　ごとき不毛な行為であるとも理解している。 　でも、あの。これってバグでは？と、とっても小さい声で言ってみたりする……。 5. う゛？ 　　*.cなアプリは何とかできるようになった。が、またまた問題発生！ #include int main(void) { cout << "Hello, world"; return 0; } 　　こいつのコンパイルに(正確にはリンクだが)失敗するのだ！！ 　C:\NET\TST> gcc cpp.cpp 　c:\win95\temp\cc7916931.o(.text+0x1e):cpp.cc: undefined reference to `cout' 　c:\win95\temp\cc7916931.o(.text+0x23):cpp.cc: undefined reference to `ostream::operator<<(char const *)' 　　へ？げ？お？症状からしてライブラリをリンクできてないってことにはすぐ気付いた 　のだが、解決にはすったもんだした。 　C:\NET\TST> gcc cpp.cpp -lstdc++ 　　これが正解。って書くと何でもないんだけど、そりゃーもう、苦労しました(T_T)。 　β18ならこんなことしなくても問題ないんですが……。 　　…って、ありゃ？mkmf.batを修正しようとしたら、c++の時にはリンク時に-lstdc++ 　を追加するようになってるやんけ？あたしの一人相撲ってか？(大泣) 　　後、-windowsを受け付けない、とか、-lgdi32しないとダメとか、β19のmakeは 　'\'をディレクトリのセパレータとして正常に扱う(β18のmakeは'\\'としないと 　だめだった。これは、β18のmakeがunix色を色濃く残していたのに対し、β19は 　DOSにより歩み寄ったため)とか色々……。 　う〜む。こうも細部が違うとは。 　　りゃっ？makeした時にエラーしてもエラーメッセージが出ないぞ。手動でやれば 　出るけど、これはやっかい。う〜む。う〜むむ。 　　↑ 　　手動でやればよろしい、という後ろ向きな方法で妥協してしまった。昔なら力で 　ねじ伏せていたのだが、年取ると人格が丸くなるとゆーか、覇気がなくなったと 　言うか(;_;)。help!。誰か〜 ＃あう。相変わらずZeroMemory()がリンクでけんぞ。こんな関数、自前で作るのは 　簡単なのだが……。←だもんで自作して何事もなかったようにしてたりする(-_-; 　　　　　　　　　　　　　　　− 以上 −