ここに記載されている情報は、 GNUシステムまたはUNIXシステム上にGNU CCをインストールするための手順です。 VMSシステム上でのインストールに関しては、 VMSへのGNU CCのインストールを参照してください。 このセクションでは、 ソース・ファイルの置かれているディレクトリにおいてコンパイルをすることを想定しています。 UNIXシステム上において これとは異なるディレクトリにおいてコンパイルする方法については、 別ディレクトリにおけるコンパイルを参照してください。
MSDOS上では、 GNU Cを単独でインストールすることはできません。 GNU C以外のどのようなMSDOS上のコンパイラを使っても、 GNU Cをコンパイルすることはできません。 完全なコンパイラ・パッケージであるDJGPPを入手する必要があります。 DJGPPには、 ソースだけではなくバイナリも含まれていて、 かつ、 必要なコンパイル・ツールとライブラリがすべて備わっています。
PATHの中において、
`/usr/bin'が`/usr/ucb'よりも前にあることを確認します。
`/usr/ucb'にあるccコマンドは、
バグのあるライブラリを使います。
PATHの値を使って、
これ以降のコンパイル処理を実行することもできます。
./configure --host=sparc-sun-sunos4.1コンフィギュレーション名は、 正規名でも構いませんし、 多少省略しても構いません。 正規のコンフィギュレーション名は、 3つの部分から構成され、 各部分はダッシュによって区切られます。 `cpu-company-system' のようになります （3つの構成要素の中にダッシュが含まれることもあります。 `configure'は、 どのダッシュがどのような目的で使われているかを判別することができます）。 例えば、 `m68k-sun-sunos4.1'はSun 3を指定します。 また、 コンフィギュレーションの構成要素を、 ニックネームや別名で置き換えることもできます。 例えば、 `sun3'は`m68k-sun'を表わします。 したがって、 `sun3-sunos4.1'は、 Sun 3を指定する別の方法です。 あるいは単に、 `sun3-sunos'を使うこともできます。 SunOSのバージョンは、 デフォルトでバージョン4と想定されているからです。 バージョン番号は、 任意のシステム種別の後ろに指定することができます。 また、 いくつかのCPU種別の後ろにも指定することができます。 ほとんどの場合、 バージョンは無関係であり、 無視されます。 したがって、 バージョンは、 分かっている場合に指定すれば良いのです。 サポートされているコンフィギュレーション名と、 多くのコンフィギュレーションに関する留意点については、 GNU CCのサポートするコンフィギュレーションを参照してください。 GNU CCのインストールにこれ以上進む前に、 そのセクションに記載されている留意点をチェックするべきです。
configureを実行する際には、
ハードウェアやソフトウェアのさまざまなコンフィギュレーションを指定するオプションを
追加して指定する必要があるかもしれません。
`--with-gnu-as'、
`--with-gnu-ld'、
`--with-stabs'、
`--nfp'がそうしたオプションです。
asという名前のプログラムをさまざまなディレクトリにおいて探します。
見つかったプログラムがGASであれば、
GNU CCはGASを実行します。
GNU CCが使っているアセンブラがどのディレクトリにあるものか定かではない場合は、
GNU CCの実行時に`-v'オプションを指定してみてください。
GASを使うか使わないかによって違いの出るシステムは、configureは、
Haifaスケジューラが有効化されているかどうかを、
実行時に表示します。
configureによってセットアップされるすべてのファイルを示します。
通常は、
これらのファイルのことをユーザが気にする必要はありません。
gettextライブラリを使うことを試みます。
ホストのライブラリが十分でない場合に限り、
GCCの持っているGNU gettextライブラリのコピーを使います。
`--with-included-gettext'オプションが指定されると、
ビルド・プロシージャは、
GNU gettextのコピーを優先して使います。
gettextが存在せず、
機能的に劣るcatgetsインターフェイスは存在する場合、
GCCのビルド・プロシージャは通常、
catgetsを無視して、
GCCの持っているGNU gettextライブラリのコピーを使います。
`--with-catgets'オプションが指定されると、
ビルド・プロシージャはこのような状況において、
ホストのcatgetsを使います。
configureを実行する際に、
他の特定のオプションを指定する必要があります。
--with-local-prefixオプションを使います。
直接指定したディレクトリは存在する必要はありませんが、
その親ディレクトリは必ず存在しなければなりません。
fixincludesスクリプトによるヘッダ・ファイルの修正が無視され、
無効になってしまうからです。
どうやら、
このオプションを使う人々は、
このオプションの目的を誤解していて、
その誤解にもとづいてこのオプションを使っているようです。
このオプションは、
あたかもGNU CCの構成要素をインストールするディレクトリを指定するもののように
使われています。
おそらく、
GNU CCをインストールするとこのディレクトリが作成されるので、
人々はそうした想定をしてしまうのでしょう。
make stage1ファイルは、 `stage1'という名前のサブディレクトリに移動されます。 インストールが完了した後には、
rm -r stage1によってこれらのファイルを削除すると良いでしょう。
PATH環境変数の値を使って、
必要なGNUツールがシステム標準のツールよりも優先されるようにすることもできます。
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2"これは、 ステージ2・コンパイラの作成と呼ばれます。 上記のコマンドは、 サポートされるすべての言語用のコンパイラをビルドします。 これらすべてが必要ではない場合、 コンパイラをビルドする言語を 引数`LANGUAGES="list"'によって指定することができます。 listには、 `c'、 `c++'、 `objective-c'、 `proto'の中の1つ以上が指定されていなければなりません。 複数指定する場合は、 空白類で区切ります。 `proto'は、
protoizeプログラムとunprotoizeプログラムを表わしています。
これらは言語ではありませんが、
そのインストールは、
LANGUAGESを使って有効または無効にします。
ステージ3・コンパイラをビルドするのであれば、
ステージ2ではC言語用のコンパイラだけをビルドするのが良いでしょう。
ステージ2・コンパイラのビルドが終了した後に
ディスク・スペースが不足しているようであれば、
`stage1'サブディレクトリを削除しても問題ありません。
浮動小数点ハードウェアを持たない68000システムまたは68020システムでは、
そのようなハードウェアがないことをデフォルトで想定している
`tm.h'を選択したのでない限り、
以下のように実行します。
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2 -msoft-float"
make stage2 make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2"これは、 ステージ3・コンパイラの作成と呼ばれます。 `-B'オプション以外のコンパイラ・オプションは、 ステージ2・コンパイラを作成した際と同一でなければなりません。 しかし、
LANGUAGESオプションは同一である必要はありません。
上記のコマンドは、
サポートされているすべての言語を扱えるコンパイラをビルドします。
サポートされているすべての言語が必要ではない場合、
上で説明したように、
`LANGUAGES="list"'引数を入力することによって、
ビルドされるサポート言語を指定することができます。
GNUツールを追加でインストールする必要がないのであれば、
`stage1'、
`stage2'の各ディレクトリを作成して、
コンパイラのビルドを2回実行する代わりに、
make bootstrap LANGUAGES=language-list BOOT_CFLAGS=option-listというコマンドを使うこともできます。
make compareこれにより、 ステージ2とステージ3の間で相違のあるオブジェクト・ファイルがあれば、 そのことが報告されます。 いかに無害なものであっても相違があるということは、 ステージ2・コンパイラがGNU CCを正しくコンパイルしなかったということであり、 したがって、 ユーザが調査して報告するべき重大なバグである可能性があります （バグ報告を参照）。 オブジェクト・ファイルの中にタイム・スタンプを組み込まないシステムの場合、 以下のようにすればより高速に比較を行なうことができます （Bourneシェルを使った例）。
for file in *.o; do cmp $file stage2/$file doneMIPSマシン上において `-mno-mips-tfile'オプションを指定してコンパイラをビルドした場合は、 オブジェクト・ファイルの比較を行なうことはできません。
CC、
CFLAGS、
LANGUAGESについては、
インストールされるファイルをコンパイルする際に使ったのと同一の値を使います。
これが必要となる理由の1つは、
いくつかのバージョンのmakeにバグがあって、
このステップを実行する際に、
必要もないのに再コンパイルを実行することがあるからです。
同一の変数値を使っていれば、
ファイルが再コンパイルされても問題はありません。
例えば、
ステージ2・コンパイラをビルドしたのであれば、
以下のコマンドを使うことができます。
make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="list"これにより、 ファイル`cc1'、 `cpp'、 `libgcc.a'が、 ディレクトリ`/usr/local/lib/gcc-lib/target/version'に、 `cc1'、 `cpp'、 `libgcc.a'としてコピーされます。 このディレクトリは、 コンパイラ・ドライバがこれらのファイルを探す場所です。 ここでtargetは、 `configure'を実行した際に指定されたターゲット・マシン種別を 正規化したもの（canonicalized form）です。 またversionは、 GNU CCのバージョン番号です。 このような名前付けによって、 異なるバージョンのコンパイラやクロス・コンパイラの共存が可能になります。 また、 他の言語用のコンパイラの実行ファイル （例えば、 C++用の`cc1plus'）が、 同一のディレクトリにコピーされます。 さらに、 ドライバ・プログラム`xgcc'が、 典型的な実行サーチ・パスの中に存在するよう、 `/usr/local/bin/gcc'としてコピーされます。 また、 `gcc.1'が`/usr/local/man/man1'に、 infoページが`/usr/local/info'に、 それぞれコピーされます。 システムによっては、 このコマンドによっていくつかのファイルが再コンパイルされることがあります。 これは通常は、
makeのバグによるものです。
この問題は無視するか、
さもなくば、
GNU makeを使ってください。
警告： Sunのライブラリに含まれているallocaにはバグがあります。
このバグを回避するには、
GNU CCによってコンパイルされたGNU CCの実行ファイルをインストールしてください。
（ステージ1の実行ファイルではなく、
ステージ2またはステージ3の実行ファイルです。）
この実行ファイルは、
allocaを組み込み関数として扱い、
ライブラリの中のallocaを使いません。
（通常は、
ステージ2またはステージ3のGNU CC実行ファイルをインストールするほうが
良いでしょう。
というのは、
これらのほうが、
他のコンパイラによってコンパイルされたものよりも高速だからです。）
$ CXX=gcc ./configure configure-options $ make $ make install
make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2" OBJC_THREAD_FILE=thr-single以下に、 現在利用可能なバックエンドの一覧を示します。
configureによって生成されるファイル
以下に、
configureによってセットアップされるファイルを順を追って説明します。
通常、
これらのファイルのことを気にする必要はありません。
以下に、 指定可能なCPU種別を示します。
1750a, a29k, alpha, arm, cn, clipper, dsp16xx, elxsi, h8300, hppa1.0, hppa1.1, i370, i386, i486, i586, i860, i960, m32r, m68000, m68k, m88k, mips, mipsel, mips64, mips64el, ns32k, powerpc, powerpcle, pyramid, romp, rs6000, sh, sparc, sparclite, sparc64, vax, we32k.
以下に、 認識される企業名を示します。 これを見て分かるように、 より長い正式名よりはむしろ慣例的に使われている省略名となっています。
acorn, alliant, altos, apollo, apple, att, bull, cbm, convergent, convex, crds, dec, dg, dolphin, elxsi, encore, harris, hitachi, hp, ibm, intergraph, isi, mips, motorola, ncr, next, ns, omron, plexus, sequent, sgi, sony, sun, tti, unicom, wrs.
企業名は、 指定されたその他の情報だけでは不十分な場合に、 曖昧さを取り除くという点においてのみ意味を持ちます。 必要なければ、 単に`cpu-system'のように書いて省略することができます。 例えば、 `vax-ultrix4.2'は、 `vax-dec-ultrix4.2'と同等です。
以下に、 システム種別の一覧を示します。
386bsd, aix, acis, amigaos, aos, aout, aux, bosx, bsd, clix, coff, ctix, cxux, dgux, dynix, ebmon, ecoff, elf, esix, freebsd, hms, genix, gnu, linux-gnu, hiux, hpux, iris, irix, isc, luna, lynxos, mach, minix, msdos, mvs, netbsd, newsos, nindy, ns, osf, osfrose, ptx, riscix, riscos, rtu, sco, sim, solaris, sunos, sym, sysv, udi, ultrix, unicos, uniplus, unos, vms, vsta, vxworks, winnt, xenix.
システム種別は省略可能です。 省略すると、 `configure'は、 CPU種別と企業名からオペレーティング・システムを推測します。
システム種別にバージョン番号を付加することができます。 これは、 違いをもたらす場合ともたらさない場合があります。 例えば、 BSDのバージョンを区別するのに、 `bsd4.3'や`bsd4.4'のように指定することができます。 実際のところバージョン番号は、 多くの場合異なるものとして扱われる、 `sysv3'と`sysv4'について最も必要となります。
`i860-dg-vms'のようなあり得ない組み合わせを指定すると、 `configure'がエラー・メッセージを出力するかもしれません。 あるいは、 `configure'が、 情報の一部を無視して、 それ以外の部分を頼りに最善の努力を払うかもしれません。 `configure'は常に、 代わりに使った組み合わせの正規名を表示します。 GNU CCは、 すべての可能な組み合わせをサポートしているわけではありません。
多くの場合、 特定のマシン・モデルには名前があります。 多くのマシン名が、 CPU種別と企業名の組み合わせの別名として認識されます。 上で示した`sun3'というマシン名は、 `m68k-sun'の別名です。 企業名が特定のマシンの名前として一般に使われている場合には、 その企業名をマシン名として受け入れることもあります。 以下に、 既知のマシン名の一覧を示します。
3300, 3b1, 3bn, 7300, altos3068, altos, apollo68, att-7300, balance, convex-cn, crds, decstation-3100, decstation, delta, encore, fx2800, gmicro, hp7nn, hp8nn, hp9k2nn, hp9k3nn, hp9k7nn, hp9k8nn, iris4d, iris, isi68, m3230, magnum, merlin, miniframe, mmax, news-3600, news800, news, next, pbd, pc532, pmax, powerpc, powerpcle, ps2, risc-news, rtpc, sun2, sun386i, sun386, sun3, sun4, symmetry, tower-32, tower.
マシン名が、 CPU種別と企業名の両方を指定していることを覚えていてください。 ユーザ独自に作成したコンフィギュレーション・ファイルをインストールしたい場合は、 それにアクセスするための企業名として`local'を使うことができます。 `cpu-local'というパターンのコンフィギュレーションを使うと、 CPU種別を示す接頭辞を除いた名前が コンフィギュレーション・ファイル名の構成要素として使われます。
したがって、 `m68k-local'を指定すると、 `config/m68k'ディレクトリにあるファイル `m68k.md'、 `local.h'、 `m68k.c'、 `xm-local.h'、 `t-local'、 `x-local' がコンフィギュレーションにおいて使われます。
以下に、 ユーザが知っておくべき、 特殊な取り扱いを受けるコンフィギュレーション、 あるいは、 特殊な事情を持つコンフィギュレーションの一覧を示します。
as1750用の出力を生成します。
as1750は、
ftp://ftp.fta-berlin.de/pub/crossgcc/1750gals/から入手できます。
同じアドレスから、
同様のライセンスにもとづく1750A用シミュレータも入手できます。
libgccをビルドしている過程において出る致命的エラーは無視するべきです
（libgccは、
まだ1750A用には実装されていません）。
as1750アセンブラは、
`ms1750.inc'というファイルを必要とします。
このファイルは、
`config/1750a'ディレクトリにあります。
GNU CCは、
Fairchild F9450 Cコンパイラと同一のセクションを生成します。
具体的には、
以下に示すセクションです。
Normal
Static
Konst
Init
CFLAGSに`-save-temps'を追加しないと、
make compareによる比較結果は不一致となるかもしれません。
これらのシステムでは、
オブジェクト・ファイルの中にアセンブラ入力ファイルの名前が含まれていて、
stage1とstage2のそれぞれのコンパイルにおいてこの名前が異なると、
オブジェクト・ファイルの比較は不一致という結果になります。
オプション`-save-temps'は、
アセンブラ入力ファイルに対して、
`/tmp'において無作為に選択された名前の代わりに、
ある固定した名前が使われるよう強制します。
`-save-temps'は、
これを指定しないと比較の結果が不一致となる場合以外は追加しないでください。
`-save-temps'を追加すると、
一連のコンパイルのたびに
`.i'ファイルと`.s'ファイルを手作業で削除しなければならなくなります。
GNU CCは現在、
DBXとGDBにより使われるネイティブ（ECOFF）・デバッグ・フォーマットと
GDBのみにより使われるカプセル化された（encapsulated）STABSフォーマットの
両方をサポートしています。
これらのフォーマットに関するさらに詳しい情報とその選択方法については、
上に示した`configure'の`--with-stabs'オプションの議論を参照してください。
DECのアセンブラには、
`.align'指示子が使われると、
ECOFFフォーマットにおいて正しくない行番号を出力するというバグがあります。
この問題を回避するために、
GNU CCは、
最適化が実行されている場合でも、
ECOFFフォーマットのデバッグ情報を生成する際に、
このような境界整列指示子を出力しません。
不幸なことに、
この回避策には、
`-O'が指定された際のコード・アドレスが、
`-g'の指定の有無によって変わってしまうという
非常に好ましくない副作用があります。
この振る舞いを回避するには、
`-gstabs+'を指定して、
DBXではなくGDBを使ってください。
DECは、
アセンブラにこの問題があることを既に知っており、
近いうちに修正を提供したいと考えています。
CCを上書きしてMIPSコンパイラを使う場合は、
`-Wf,-XNg1500 -Olimit 3000'を追加する必要があるかもしれません。
mrs@cygnus.comに連絡してください。
/bin、
/usr/bin、
/usr/ccs/bin
よりも前にあるディレクトリにインストールする必要があります。
また、
GASのインストールは、
GNU CCをビルドする前に行なわなければなりません。
デバッグ情報を有効にするには、
ビルドをする前に、
`--with-gnu-as'オプションを指定してGNU CCを構成（configureを実行）しなければなりません。
configure winntとして起動します。
`configure.bat'は、
`Makefile.in'から実際に使える`Makefile'を生成するのに使われるUNIX風の`sed'プログラムが、
既にインストール済みでパスの中に存在することを想定しています。
`Makefile'は、
GNU CCをビルドするのに、
メンテナンス・ユーティリティMicrosoft NmakeプログラムとVisual C/C++ V8.00コンパイラを使います。
コンパイラ自身を自動的にビルドするだけであるこのインストール方法を使うには、
`sed'ユーティリティと`touch'ユーティリティだけがあれば十分です。
その後に、
`fixinc.winnt'の処理内容を調べて、
ヘッダ・ファイルを手作業で編集して、
`libgcc.a'を手作業でビルドしなければなりません。
law@cygnus.comに連絡してください。
configureに対する
`--with-gnu-as'オプションと`--with-gnu-ld'オプション
によって有効にします。
このシステムに付属しているCコンパイラはGNU CCをコンパイルすることができませんので、
注意してください。
ブートストラップ用のGNU CCのバイナリは、
jagubox.gsfc.nasa.govにあります。
また、
オリジナル版にある
いくつかの恣意的な上限を大きくした、
`/bin/ld'のパッチ版もあります。
obstack_freeを、
_obstack_freeに置き換えます。
makeを実行します。
F.Pierresteguy@frcl.bull.frに連絡してください。
asではなくcasmです。
何らかの奇妙な理由により、
`/bin/as'を`/bin/casm'にリンクすると振る舞いが変わってしまって、
動作しなくなってしまいます。
したがって、
GNU CCをインストールする際に、
GCCの各パスのファイルがインストールされているサブディレクトリに、
以下のスクリプトを`as'という名前でインストールしなければなりません。
#!/bin/sh casm $*Unosのデフォルトのライブラリの名前は、 `libc.a'ではなく`libunos.a'です。 GNU CCが機能できるようにするためには、 `gcc.c'の中で`-lc'を指定しているすべての部分を `-lunos'に変更するか、 `/lib/libc.a'を`/lib/libunos.a'にリンクします。 標準のコンパイラを使ってGNU CCをコンパイルする際には、
allocaのサポートに関するバグを克服するために、
ステージ2をビルドしているときには`-O'を指定しないでください。
その後に、
ステージ2・コンパイラに`-O'を指定してステージ3・コンパイラをビルドします。
このコンパイラが、
他のシステム上における通常のステージ2・コンパイラと同一の性格を持ちます。
これを使ってステージ4・コンパイラをビルドします。
正しくコンパイルできたことを検証するには、
このステージ4をステージ3と比較します。
（コメントの中に記述されているように、
`x-crds'の中においてALLOCAを定義するだけで、
上のパラグラフの記載はおそらく不必要になるでしょう。
この方法でうまくいくかどうか、
情報を提供してください。）
Unosでは、
デマンド・ページングの代わりにメモリ・セグメンテーションを利用しています。
したがって、
大量のメモリが必要になります。
他のタスクがまったく動作していないのであれば、
5MBあればかろうじて足りるでしょう。
`cc1'のリンクに失敗するのであれば、
オブジェクト・ファイルをライブラリの中に入れて、
そのライブラリからリンクすることを試みてください。
memcpy、
memcmp、
memset
が欠けている可能性があります。
システムにこれらの関数がない場合は、
`mips-bsd.h'の中のTARGET_MEM_FUNCTIONSの定義を削除するか取り消すことをしなければなりません。
MIPSのCコンパイラを使って`cp/parse.c'をコンパイルするためには、
`-Wf,-XNg1500'オプションによって、
switch文用のテーブル・サイズを大きくするよう指示する必要があります。
最適化オプション`-O2'を指定するのであれば、
`-Olimit 3000'も指定する必要があります。
これらのオプションはいずれも、
シェル・スクリプト`configure'がビルドする`Makefile'の中に自動的に記述されます。
make変数CCを無効にしてMIPSコンパイラを使うのであれば、
`-Wf,-XNg1500 -Olimit 3000'を追加する必要があるかもしれません。
CCを無効にしてMIPSコンパイラを使うのであれば、
`-Wf,-XNg1500 -Olimit 3000'を追加する必要があるかもしれません。
RISC-OSを動作させるMIPSマシンは、
4つの異なるパーソナリティをサポートすることができます。
デフォルト、
BSD 4.3、
System V.3、
System V.4です
（古いバージョンのRISC-OSは、
System V.4をサポートしていません）。
これらのプラットフォーム用にGCCを構成（configureを実行）するには、
以下のコンフィギュレーションを使います。
rev'
revのデフォルトのコンフィギュレーション。
revbsd'
revのBSD 4.3コンフィギュレーション。
revsysv4'
revのSystem V.4コンフィギュレーション。
revsysv'
revのSystem V.3コンフィギュレーション。
revは、
使用されるRISC-OSのリビジョンです。
RISC-OSのリビジョン4からリビジョン5へ移行する際には、
GCCの再構成（configureの実行）を行なわなければなりません。
これは、
リンカのバグを回避する効果を持ちます
（詳細については、
インストールの問題を参照）。
CFLAGSに`-save-temps'を追加しないと、
make compareによる比較結果は不一致となるかもしれません。
これらのシステムでは、
オブジェクト・ファイルの中にアセンブラ入力ファイルの名前が含まれていて、
stage1とstage2のそれぞれのコンパイルにおいてこの名前が異なると、
オブジェクト・ファイルの比較は不一致という結果になります。
オプション`-save-temps'は、
アセンブラ入力ファイルに対して、
`/tmp'において無作為に選択された名前の代わりに、
ある固定した名前が使われるよう強制します。
`-save-temps'は、
これを指定しないと比較の結果が不一致となる場合以外は追加しないでください。
`-save-temps'を追加すると、
一連のコンパイルのたびに
`.i'ファイルと`.s'ファイルを手作業で削除しなければならなくなります。
MIPS Cコンパイラを使って`cp/parse.c'をコンパイルするためには、
`-Wf,-XNg1500'オプションによって、
switch文用のテーブル・サイズを大きくするよう指示する必要があります。
最適化オプション`-O2'を指定するのであれば、
`-Olimit 3000'も指定する必要があります。
これらのオプションはいずれも、
シェル・スクリプト`configure'がビルドする`Makefile'の中に自動的に記述されます。
make変数CCを無効にしてMIPSコンパイラを使うのであれば、
`-Wf,-XNg1500 -Olimit 3000'を追加する必要があるかもしれません。
Irixのバージョン4.0.5Fには、
命令の順序変更が正しく行なわれないというアセンブラのバグがあります。
より古いバージョンのいくつかにも、
おそらくこのバグがあるでしょう。
このバグを回避するには、
`mips-sgi-irix4loser'というターゲット・コンフィギュレーションを指定してください。
このコンフィギュレーションは、
アセンブラの最適化を禁止します。
ターゲット`mips-sgi-irix4'によって構成（configureを実行）されたコンパイラでは、
`-noasmopt'オプションを使うことによってアセンブラの最適化を無効にすることができます。
このコンパイラ・オプションを指定すると、
命令の順序変更を禁止するために、
アセンブラに対してオプション`-O0'が渡されます。
`-noasmopt'オプションは、
問題の原因がアセンブラによる誤った命令の順序変更にあるのかどうかテストするのに役に立ちます。
`-noasmopt'オプションによって問題が解消されないとしても、
アセンブラによる命令の順序変更が原因である可能性はあります。
おそらく、
命令の順序変更のために、
GNU CC自身が正しくコンパイルされなかった可能性があるのです。
Irix 5でのデバッグを可能にするためには、
GNU as 2.5以降を使い、
gccの構成（configureの実行）を行なう際に
configureオプション`--with-gnu-as'を指定しなければなりません。
GNU asは、
binutilsパッケージの一部として配布されています。
allocaとmallocにバグがあります。
GNU Emacsから、
これらのコンパイル済みのバージョンを入手しなければなりません。
hcを使ってGNU CCをコンパイルすることもできますが、
ステージ2・コンパイラとステージ3・コンパイラの比較において、
さまざまなファイルが不一致となるでしょう。
これらのエラーは、
いくつかの浮動小数点定数における重要ではない相違であって、
無視しても安全です。
ステージ3・コンパイラは適正です。
vcc）を使ってコンパイルを試みてはいけません。
いくつかのケース
（例えば、
allocaが使われた場合）
において、
正しくないコードが生成されます。
その一方で、
pccの内部的なテーブル・サイズの制限のために
このコンパイラ（pcc）によって`cp/parse.c'をコンパイルすることはできません。
この問題を回避するためには、
最初にGNU Cコンパイラだけをコンパイルして、
それを使って再コンパイルすることによって、
動作させたいすべての言語用のコンパイラをビルドします。
mv /lib/cpp /lib/cpp.att
cp cpp /lib/cpp.gnu
echo '/lib/cpp.gnu -traditional ${1+"$@"}' > /lib/cpp
chmod +x /lib/cpp
システムのコンパイラは、
GNU CCの最適化ファイルのいくつかに対して正しくないコードを生成します。
したがって、
ステージ2・コンパイラは最適化せずにビルドしなければなりません。
その後に、
ステージ3・コンパイラを最適化してビルドしてください。
その結果生成される実行ファイルは正しく機能するはずです。
以下に必要なコマンドを示します。
make LANGUAGES=c CC=stage1/xgcc CFLAGS="-Bstage1/ -g" make stage2 make CC=stage2/xgcc CFLAGS="-Bstage2/ -g -O"ファイル`cc1plus'のサイズは1メガバイトを超えるので、 C++コンパイラをビルドするためには、 ULIMITの設定値を大きくする必要があるかもしれません。
ソース・ファイルのディレクトリ以外のディレクトリにおいて オブジェクト・ファイルと実行可能ファイルをビルドしたい場合、 通常の手順とは異なる、 以下のことをしなければなりません。
VPATH機能をサポートするMakeを使っていることを確認してください。
（GNU Makeはこの機能をサポートしています。
ほとんどのBSDシステム上のMakeも同様です。）
make distclean
mkdir gcc-sun3 cd gcc-sun3シンボリック・リンクをサポートしていないシステムでは、 このディレクトリは、 ソース・コードのディレクトリと同一のファイル・システム上に存在しなければなりません。
../gcc/configure ...これにより、 コンパイラ・ソースの存在場所も
configureに対して示されます。
configureは、
その起動に使われたファイル名からディレクトリ部分を抽出します。
しかし、
ソースの存在場所の指定を確実にしたければ、
以下のようにして、
ソース・ディレクトリを`--srcdir'オプションで指定することもできます。
../gcc/configure --srcdir=../gcc other options`--srcdir'によって指定するディレクトリは、
configureの存在するディレクトリと同一である必要はありません。
ここまでくれば、
そのディレクトリにおいてmakeを実行することができます。
普通のソース・ファイルが変更されただけであれば、
上記のコンフィギュレーション手順を繰り返す必要はありません。
しかし、
コンフィギュレーション・ファイルが変更された場合、
システムがシンボリック・リンクをサポートしていないのであれば、
configureを再実行しなければなりません。
GNU CCは、 すべてのマシンに対してというわけにはいきませんが、 多くのマシンに対してクロス・コンパイラとして機能することができます。
GNU CCはアセンブラ・コードを生成するため、 オブジェクト・ファイルを作成するためには、 GNU CCが実行することのできるクロス・アセンブラがおそらく必要になるでしょう。 ターゲット・マシン以外のマシンでリンクしたいのであれば、 クロス・リンカも必要になります。 また、 ホスト・マシン上にインストールすることのできる、 ターゲット・マシンに適合するヘッダ・ファイルとライブラリも必要になります。
クロス・コンパイラを使ってプログラムをコンパイルして実行することは、 いくつかの手順を伴います。
これらすべての手順を同一のホスト・マシン上で実行するのが最も便利です。 GNU CCを一度起動するだけですべての手順を実行できるからです。 そのためには、 適切なクロス・アセンブラとクロス・リンカが必要となります。 ターゲットによっては、 GNUアセンブラとGNUリンカが利用可能です。
GNU CCをクロス・コンパイラとしてビルドするためには、 まず`configure'を実行することから始めます。 ターゲット種別を指定するには`--target=target'を使います。 実行中のシステムを`configure'が正しく識別できなかった場合は、 `--build=build'オプションも指定します。 以下に例として、 `configure'が正しく識別することのできるシステム上において、 BSDを動作させるHP 68030システム用のコードを生成するクロス・コンパイラを 構成（configureを実行）する方法を示します。
./configure --target=m68k-hp-bsd4.3
クロス・アセンブラとクロス・リンカが利用可能であれば、 それらをインストールしなければなりません。 これらは、 ディレクトリ`/usr/local/target/bin'に置きます。 このディレクトリに置くべきツールの一覧を以下に示します。
GNU CCをインストールすると、 このディレクトリの中のこれらのプログラムが見つけられ、 後にクロス・コンパイラが実行されたときにクロス・コンパイラが見つけるのに適した場所に、 コピーまたはリンクされます。
これらのファイルを提供する最も簡単な方法は、 BinutilsパッケージとGASをビルドすることです。 GNU CCを構成（configureを実行）した際に指定したのと同一の値を `--host'オプションおよび`--target'オプションに指定して、 構成（configureの実行）を行ないます。 その後、 ビルドとインストールを行ないます。 実行可能ファイルは、 適切なディレクトリに自動的にインストールされます。 残念ながら、 BinutilsとGASは、 GNU CCがサポートしているターゲットすべてをサポートしてはいません。
標準Cライブラリのような、 クロス・コンパイラとともに使うライブラリをインストールしたいのであれば、 ディレクトリ`/usr/local/target/lib'に置きます。 GNU CCをインストールすると、 このサブディレクトリにあるすべてのファイルは、 GNU CCが見つけてリンクをするのに適した場所にコピーされます。 以下に、 ターゲット・マシンからいくつかのライブラリをコピーする手順の例を示します。
ftp target-machine lcd /usr/local/target/lib cd /lib get libc.a cd /usr/lib get libg.a get libm.a quit
必要となるライブラリ群の正確な一覧とそのターゲット・マシン上の位置は オペレーティング・システムによって異なります。
多くのターゲットでは、
個々の実行可能ファイルにリンクして組み込まれる、
`crt0.o'や`crtn.o'のような「起動ファイル（start files）」が必要となります。
これらもまた
`/usr/local/target/lib'に置かれなければなりません。
`crt0.o'については、
プロファイル処理用や他のコンパイル・オプション用として、
いくつかの代替ファイルが存在するかもしれません。
使われている起動ファイルを調べるには、
ターゲットのSTARTFILE_SPECの定義をチェックします。
以下に、
ターゲット・マシンからこれらのファイルをコピーする手順の例を示します。
ftp target-machine lcd /usr/local/target/lib prompt cd /lib mget *crt*.o cd /usr/lib mget *crt*.o quit
GNU CCによりコンパイルされたコードは、 いくつかのランタイム・サポート関数群を暗黙のうちに使います。 これらの関数群のいくつかはGNU CC自身によって問題なくコンパイルすることができますが、 コンパイルできないものも少数ですがあります。 これら問題のある関数群は、 ソース・ファイル`libgcc1.c'の中にあります。 これらから作られたライブラリは`libgcc1.a'という名前です。
ネイティブ・コンパイラをビルドする際には、 これらの関数群は別のコンパイラ、 すなわち、 GNU CCをブートストラップするのに使われたコンパイラによってコンパイルされます。 おそらく、 そのコンパイラは、 これらの演算をオープン・コードする（open code）方法を知っているか、 さもなければ、 マシンに付属するランタイム・エミュレーション機能を呼び出す方法を知っているのでしょう。 しかし、 このアプローチは、 クロス・コンパイラをビルドする際には通用しません。 ビルドに使うコンパイラはホスト・システムのことは知っていますが、 ターゲット・システムのことは知りません。
したがって、 クロス・コンパイラをビルドする際には、 期待されている仕事をこなす適切なライブラリ`libgcc1.a'を提供しなければなりません。
クロス・コンパイラ自身によって`libgcc1.c'をコンパイルするのはうまくいきません。 このファイルの中の関数群は、 算術オペレーションを実装することになっていますが、 これらの演算をターゲット・マシン用にオープン・コードする（open code）方法を、 GNU CCは知りません。 これらの関数群をGNU CC自身によってコンパイルすると、 無限再帰に陥ってしまいます。
どのターゲットにおいても、 これらの関数群のほとんどは必要ではありません。 GNU CCは、 ある算術演算をオープン・コードする（open code）ことができる場合、 その演算を実行するためにこれらの関数群を呼び出すことはしません。 使っているターゲット・マシンにおいて、 これらの関数群がまったく必要ではないということもありえます。 その場合は、 空のライブラリを`libgcc1.a'として提供することもできます。
多くのターゲットは、
乗算と除算についてのみライブラリのサポートを必要とします。
乗算と除算の関数を含むライブラリとリンクしているのであれば、
マクロMULSI3_LIBCALLとそれに類するものを定義することによって、
これを直接呼び出すようGNU CCに指示することができます。
これらのマクロは、
ターゲット記述マクロ・ファイルに定義されている必要があります。
ターゲットによっては、
それはあらかじめ定義されています。
libgcc1.aが必要とされないようにするにはこれだけでも十分かもしれません。
そうであれば、
空のライブラリを供給することができます。
ターゲットによっては、 浮動小数命令を持たないものもあります。 このようなターゲットは、 `libgcc1.a'の中の別の関数群を必要とします。 浮動小数演算を行なう関数群です。 GNU CCの最近のバージョンには、 浮動小数をエミュレートするファイルが含まれています。 ある程度作業をすれば、 `libgcc1.a'として使うことのできる浮動小数エミュレータが作れるはずです。 おそらく将来のバージョンには、 これを自動的かつ便利に行なうコードが含まれるでしょう。 これは、 そのようなコードを実装したい人の有無にかかっています。
組み込みシステムによっては、 Cまたはアセンブラで記述された、 すべての必要な`libgcc1.a'ルーチンが付属しているものもあります。 これらのターゲットは自動的に`libgcc1.a'をビルドするので、 このファイルのために特別なことをする必要はまったくありません。 他の組み込みシステムには、 必要なすべての演算がハードウェアによってサポートされているので、 `libgcc1.a'のルーチンがまったく必要ないものもあります。
使っているターゲット・システムに別のCコンパイラがあれば、 そのマシンのネイティブ・コンパイラとしてGNU CCを構成（configureを実行）し、 そのマシン上で`make libgcc1.a'を実行することによって`libgcc1.a'だけをビルドして、 結果として生成されたファイルをクロス・コンパイラとともに使うことができます。 このようにするには、 ターゲット・マシン上において以下のとおり実行します。
cd target-build-dir ./configure --host=sparc --target=sun3 make libgcc1.a
次に、 ホスト・マシン上において以下を実行します。
ftp target-machine binary cd target-build-dir get libgcc1.a quit
`libgcc1.a'の中に必要となる関数群を提供するまた別の方法として、
これらの関数群に対して適切なperform_...マクロを定義するという方法があります。
これらの定義が、
それら関数群が本来実装するべきCの算術演算を使わないかぎり、
ビルドしたクロス・コンパイラを使ってコンパイルすることができるはずです。
（ターゲット・ファイルにおいてこれらの定義が既に存在するのであれば、
準備万端ととのっています。）
performマクロを使って`libgcc1.a'をビルドするためには、
コンパイラをビルドする際に`LIBGCC1=libgcc1.a OLDCC=./xgcc'を使います。
さもなければ、
makeを実行する前に、
クロス・コンパイラをビルドするディレクトリの中に、
`libgcc1.a'という名前の代替ライブラリを置かなければなりません。
スタンドアロン・プログラムや組み込みシステム用のプログラムをクロス・コンパイルする場合は、 GNU CCの構成要素であるごく少数のヘッダ・ファイル （および、 ユーザ・プログラムのヘッダ・ファイル） を除いて、 ヘッダ・ファイルは必要ないかもしれません。 しかし、 `libc.a'のような標準Cライブラリをユーザ・プログラムとリンクするつもりであれば、 使用するライブラリに関連するヘッダ・ファイルを使ってコンパイルする必要がおそらくあるでしょう。
GNU Cコンパイラには、 これらのファイルは付属していません。 その理由は、 (1)これらのファイルはシステム固有であること、 (2)これらのファイルはCライブラリに属するものであり、 コンパイラに属するものではないこと、 の2点です。
GNU Cライブラリがターゲット・マシンをサポートしている場合は、 （プログラムをリンクする際に、 GNUライブラリを実際に使うものと想定すれば） そこからヘッダ・ファイルを入手することができます。
ターゲット・マシンにCコンパイラが付属していれば、 おそらく適切なヘッダ・ファイルもまた付属しているでしょう。 これらのファイルをホスト・マシンからアクセスできるようにすれば、 クロス・コンパイラもそれを使うことができます。
上記以外の場合は、 クロス・コンパイルを行なう際に使うヘッダ・ファイルを、 独力で見つけなければなりません。
適切なヘッダ・ファイルが見つかれば、 クロス・コンパイラをビルドする前に、 それらをディレクトリ`/usr/local/target/include'に置きます。 この後、 インストールの過程においてfixincludesが正しく実行され、 コンパイラが使う場所に、 修正済みのヘッダ・ファイルがインストールされます。
クロス・コンパイラをビルドする前にヘッダ・ファイルを提供します。 これは、 ビルドの段階において、 `libgcc.a'の一部を作成するために、 実際にクロス・コンパイラが実行されるからです。 （これは、 GNU CCによってコンパイルすることが可能な部分です。） この中には、 適切なヘッダ・ファイルを必要とするものがあります。
以下は、 ターゲット・マシンからヘッダ・ファイルをコピーする方法を示す例です。 ターゲット・マシンでは以下を実行します。
(cd /usr/include; tar cf - .) > tarfile
次に、 ホスト・マシンにおいて、 以下を実行します。
ftp target-machine lcd /usr/local/target/include get tarfile quit tar xf tarfile
ここまでくれば、 単一マシン上のコンパイラをコンパイルするのとまったく同様に、 ステージ1をビルドするステップを実行することができます。 何らかの`libgcc1.a'を提供していないのであれば、 そのファイルが必要となるところでコンパイルは中断し、 適切なエラー・メッセージが表示されます。 `libgcc1.a'を提供すれば、 コンパイラのビルドの過程で、 自動的に`libgcc1-test'という名前のテスト・プログラムがコンパイルされ、 リンクされます。 リンクにおいてエラーが出るようであれば、 `libgcc1.a'の中に必要とされるすべてのルーチンが利用できるようになっていないということを意味しています。
ヘッダ・ファイル`float.h'を提供しなければなりません。 そうするための1つの方法は、 `enquire'をコンパイルして、 ターゲット・マシン上でそれを実行することです。 `enquire'の仕事は、 ターゲット・マシン上で動作して、 実験によって、 ターゲット・マシンの浮動小数表現の性質を理解することです。 `enquire'は、 発見したことをヘッダ・ファイル`float.h'に記録します。 ターゲット・マシン上において`enquire'を実行することによって このファイルを作成することができないのであれば、 何か別の方法によって適切な`float.h'を作り出す必要があります （あるいは、 プログラムの中で`float.h'を使うことを避けるという手もあります）。
クロス・コンパイラのステージ2をビルドすることを試みないでください。 クロス・コンパイラを使って、 GNU CCをクロス・コンパイラとして再ビルドしてもうまくいきません。 これでは、 ホスト・マシンではなく、 ターゲット・マシン上で動作するプログラムが作成されてしまいます。 例えば、 386上で68030のコードを生成するクロス・コンパイラを、 それ自身を使ってコンパイルすると、 結果として生成されるものは、 （68030コードにコンパイルされたのですから） 386用としては適切ではなく、 （386をホストとして構成されたのですから） 68030用としても適切ではありません。 GNU CCを68030コードにコンパイルしたいのであれば、 68030上でコンパイルするにせよ、 386上でクロス・コンパイラを使ってコンパイルするにせよ、 構成（configureを実行）する際には、 68030をホストとして指定しなければなりません。
クロス・コンパイラをインストールするには、 通常どおり、 `make install'を実行します。
Solarisでは、
GNU CCをビルドするのに、
`/usr/ucb'にあるリンカやその他のツールを使わないでください。
/usr/ccs/binのほうを使ってください。
ブートストラップの際にアセンブラが`Error: misaligned data'を報告するようであれば、
おそらく古くなってしまったバージョンのGNUアセンブラを使っているのでしょう。
GNU binutilsの最新版にアップグレードするか、
または、
Solarisのアセンブラを使ってください。
`libgcc.a'をコンパイルするときには、
環境変数FLOAT_OPTIONがセットされていないことを確認してください。
`libgcc.a'のコンパイル時にこのオプションがf68881にセットされていると、
結果として生成されるコードは特殊なスタートアップ・ファイルとリンクすることを要求され、
正しくリンクするためには特別な苦労が必要になるでしょう。
Sunのライブラリのいくつかのバージョンには、
allocaにバグがあります。
このバグを回避するには、
GNU CCによってコンパイルされたGNU CCバイナリをインストールしてください。
これは、
allocaを組み込み関数として使います。
ライブラリの中の関数を使うことはありません。
Sunコンパイラのいくつかのバージョンは、 GNU CCをコンパイルする際にクラッシュします。 問題になるのは、 cppにおけるセグメンテーション・フォルトです。 この問題の原因は、 環境変数に大量のデータが存在することにあるように思われます。 Sun CCを使ってGNU CCをコンパイルするのに以下のコマンドを使うことによって、 この問題を回避することができるかもしれません。
make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc"
SunOS 4.1.3と4.1.3_U1には、 GNU CCをコンパイルする際に断続的なコア・ダンプを引き起こすバグがあります。 共通する現象は、 再度コンパイラを実行しても再現しないコンパイラの内部エラーです。 この問題を修正するには、 Sunの推奨パッチ100726（SunOS 4.1.3の場合）、 あるいは、 101508（SunOS 4.1.3_U1の場合）をインストールするか、 より新しいSunOSリリースにアップグレードしてください。
GNU CCのVMSバージョンは、 ソース・コードとコンパイル済みのバイナリを含む バックアップ・セーブセット（backup saveset）に入れて配布されています。
VMS Cコンパイラを使うのと同様の方法で簡単にコンパイラが使えるように`gcc'コマンドをインストールするには、 以下のようにして、 GNU CC用のVMS CLDファイルをインストールしなければなりません。
$ assign /system /translation=concealed - disk:[gcc.] gnu_cc $ assign /system /translation=concealed - disk:[gcc.include.] gnu_cc_includeこれらのコマンドは、 マシンが起動するたびに実行されるよう、 システムのスタートアップ・ファイルの中に置くこともできます。 これは、 そうしたければ、 `[GCC]'ディレクトリの中の`GCC_INSTALL.COM'スクリプトを使って実現することもできます。
$ set command /table=sys$common:[syslib]dcltables - /output=sys$common:[syslib]dcltables gnu_cc:[000000]gcc $ install replace sys$common:[syslib]dcltables
$ library/help sys$library:helplib.hlb gcc.hlpここまでくれば、 `gcc /verbose file.c'のようなコマンドを実行することによって、 コンパイラを起動することができます。 これは、 UNIXにおいて`gcc -v -c file.c'というコマンドを実行するのと同等です。
GNU C++を使いたい場合は、 最初にGNU CCをインストールしなければなりません。 その後に、 以下の手順を実行します。
$ assign /system /translation=concealed - disk:[gcc.gxx_include.] gnu_gxx_includeC++ランタイム・ライブラリを使うのであれば、 そのインストール・プロシージャがヘッダ・ファイルをインストールするディレクトリがここです。
私たちは、 対応関係のあるバイナリとソースをVMSディストリビューション・テープ上に収録するよう努力しています。 しかし、 常にアップデートする時間があるわけではないので、 ときにはバイナリのバージョンがソースよりも古いことがあります （バイナリのバージョン番号を知るには`/version'オプションを使います。 バイナリのバージョンが古いかどうかを知るには、 その結果をソース・ファイル`version.c'と比較します）。 この場合、 そのバイナリを使ってソースを再コンパイルするべきです。 再コンパイルしなければならない場合、 その手順は以下のとおりです。
$ @vmsconfig.com
$ assign /system /translation=concealed - disk:[bison.] gnu_bisonそうしたいのであれば、 `[BISON]'ディレクトリにある`INSTALL_BISON.COM'スクリプトを使うこともできます。
$ set command /table=sys$common:[syslib]dcltables - /output=sys$common:[syslib]dcltables - gnu_bison:[000000]bison $ install replace sys$common:[syslib]dcltables
$ library gnu_cc:[000000]gcclib/delete=(new,eprintf) $ library gnu_cc:[000000]gcclib/delete=L_* $ library libgcc2/extract=*/output=libgcc2.obj $ library gnu_cc:[000000]gcclib libgcc2.obj最初のコマンドは単に、 異なるモジュール名を持つ`libgcc2'のモジュールによって置き換えられる、 古いモジュールを削除しているだけです。 モジュール
newとeprintfは、
実際には`gcclib.olb'の中に存在しないかもしれません。
VMSライブラリアン（librarian）が、
これらのモジュールが存在しないことを訴えてきたとしても、
単にそのメッセージを無視して次のコマンドに進んでください。
2番目のコマンドは、
古いバージョンのライブラリ`libgcc2.c'のモジュールを削除します。
システム上のコンパイラをアップデートしたときには常に、
上記のプロシージャによってライブラリもアップデートするべきです。
$ assign dua0:[gcc.build_dir.]/translation=concealed, -
dua1:[gcc.source_dir.]/translation=concealed gcc_build
$ set default gcc_build:[000000]
ここで、
ディレクトリ`dua1:[gcc.source_dir]'は、
ソース・コードが存在するディレクトリです。
また、
ディレクトリ`dua0:[gcc.build_dir]'は、
すべての生成されたオブジェクト・ファイルと実行可能ファイルを置くためのものです。
これを実行した後では、
上で説明したとおりGCCのビルドを進めることができます。
（`gcc_build'はルート化された（rooted）論理名であり、
したがって、
サーチ・リストの個々の要素の中のデバイス名は、
別のルート化された論理名ではなく、
実際の物理デバイス名でなければならないことを忘れないでください）。
extern const変数のread-onlyビットはセットされず、
リンカが、
これらの変数のpsect属性が一致しないことに関する警告メッセージを出力するでしょう。
これらの警告メッセージは迷惑なだけで、
無視しても安全です。
1.33よりも古いバージョンのGNU CCを使ってコンパイルをしているのであれば、
コンパイルするときには常に`/DEFINE=("inline=")'をオプションとして指定してください。
こうするためには、
`make-cc1.com'の中のすべてのgccコマンドを編集する必要があります。
（古いバージョンでは、
inlineのサポートに問題がありました。）
正しく動作する1.33以降のGNU CCが手に入れば、
このファイルを元に戻すことができます。
CC、
CFLAGS、
LIBS
の別の定義を選択するために、
`make-cccp.com'と`make-cc1.com'の内部を若干変更する必要があります。
これらのファイルの中のコメントを参照してください。
さらに、
正しく動作する
（GNU as、
あるいは、
GASとしても知られる）
GNUアセンブラを手に入れなければなりません。
これは、
バイナリ・オブジェクト・モジュールを作成するための、
GNU CCのバックエンドとして使われますが、
GNU CCのソースの中には含まれていないからです。
GASはまた、
`gcclib'をビルドするために`libgcc2'をコンパイルするためにも必要です
（上記参照）。
`make-l2.com'は、
`gnu_cc:[000000]gnu-as.exe'にGASが動作できる状態で存在することを期待しています。
VMS上でGNU CCを使うためには、
VMSドライバ・プログラム
`gcc.exe'、
`gcc.com'、
`gcc.cld'
が必要です。
これらは、
GNU CCのソースの中にはなく、
VMSバイナリ（`gcc-vms'）とともに配布されています。
GASもまた`gcc-vms'に含まれており、
Bisonも同様です。
VAX Cを使ったGNU CCのビルドに成功したら、
GNU CCの再ビルドを行なうのに、
結果として生成されたコンパイラを使わなければなりません。
その前に、
`make-cccp.com'と`make-cc1.com'の中の
CC、
CFLAGS、
LIBS
の定義を元に戻すことを忘れないでください。
2回目に生成されるコンパイラは、
他のコンパイラを使ったビルドの際には抑止されるべき多くの最適化を利用することができます。
以前のバージョンのGNU CCでは、 共用ライブラリ`VAXCRTL'とリンクされると、 生成されたコードが奇妙な結果をもたらすことがたまにありました。 現在のバージョンでは、 問題なく動作するはずです。
しかし、
現在のバージョンでも、
GNU CC自身は共用ライブラリ`VAXCRTL'とリンクされてはなりません。
`VAXCRTL'の中のqsortには
（VMSのバージョンV4.6からV5.5まで存在することが知られている）
バグがあり、
このためにコンパイラが正しく動作できません。
`make-cc1.com'と`make-cccp.com'により生成される実行可能ファイルは、
`gcclib.olb'の中のqsortルーチンを利用するために、
オブジェクト・ライブラリ版の`VAXCRTL'を使います。
コンパイラの実行可能ファイルを共用イメージ版の`VAXCRTL'とリンクしたい場合は、
（マクロQSORT_WORKAROUNDを定義するために`vmsconfig.com'により生成される）
ファイル`tm.h'を編集しなければなりません。
QSORT_WORKAROUNDは、
`gcclib.olb'が利用可能ではない場合の問題を回避するために、
VAX CによってGNU CCがコンパイルされるときには常に定義されています。
collect2
GNU CCは、
起動時にさまざまな初期化関数を呼び出すよう調整するために、
collect2という名前のユーティリティを、
ほとんどすべてのシステム上で使います。
プログラムcollect2は、
プログラムを一度リンクして、
リンカの出力ファイルの中から、
生成関数であることを示す特定の名前を持つシンボルを探し出すことによって機能します。
そのようなシンボルを見つけると、
それらのテーブルを含む新しい`.c'テンポラリ・ファイルを作成し、
それをコンパイルして、
そのファイルも含めて再度プログラムをリンクします。
生成関数の実際の呼び出しは、
__mainという名前のサブルーチンによって実行されます。
このサブルーチンは、
（GNU CCによってmainがコンパイルされたものとして）
main本体の先頭において
（自動的に）
呼び出されます。
__mainの呼び出しは、
Cのオブジェクト・コードとC++のオブジェクト・コードのリンクを可能にするために、
Cのコードをコンパイルしている場合であっても必要です。
（`-nostdlib'を指定すると、
__mainへの参照が未解決となります。
__mainが、
標準GCCライブラリの中で定義されているからです。
この参照を解決するためには、
コンパイラを起動するコマンドラインの末尾に`-lgcc'を入れます。）
プログラムcollect2はldと同様、
コンパイラの各パスのファイルがインストールされるディレクトリにインストールされます。
collect2が本当のldを見つける必要があるときには、
以下のファイル名の使用が試みられます。
PATHの一覧の中のディレクトリにおける`real-ld'。
REAL_LD_FILE_NAMEコンフィギュレーション・マクロが指定されている場合、
それによって指定されるファイル。
collect2は自分自身を再帰的に呼び出すことはしません。
PATHの中の`ld'。
「コンパイラのサーチ・ディレクトリ」は、
gccがコンパイラの各パスのファイルを探すディレクトリすべてを意味しています。
この中には、
`-B'によって指定されたディレクトリが含まれます。
クロス・コンパイラは、 若干異なるものを探します。
PATHの中の`target-real-ld'。
REAL_LD_FILE_NAMEコンフィギュレーション・マクロが指定されている場合、
それによって指定されるファイル。
PATHの中の`target-ld'。
collect2は、
collect2自身の起動に使われたファイル名によるldの呼び出しを回避します。
実際にcollect2は、
あるcollect2が、
サーチ・パスの中の別の場所にldという名前でインストールされた
別の
（別のバージョンの）
collect2を見つける場合に備えて、
そのような名前の一覧を記憶しています
collect2は、
上記のldの場合と同一のアルゴリズムを使って、
ユーティリティnmおよびstripを探します。
GCC_INCLUDE_DIRは、
ネイティブ・コンパイラ、
クロス・コンパイラのどちらにとっても同じことを意味します。
それは、
GNU CCが自分専用のインクルード・ファイルを置く場所であり、
また、
GNU CCが修正版のインクルード・ファイルを置く場所でもあります。
クロス・コンパイル用のGNU CCは、
`$(tooldir)/include'にあるヘッダ・ファイルに対して
fixincludesを実行します。
（クロス・コンパイル用のヘッダ・ファイルを修正する必要があれば、
GNU CCをビルドする前にインストールしておかなければなりません。
クロス・コンパイル用のヘッダ・ファイルが、
ANSI CおよびGNU CCにとって既に適切なものであれば、
特別なことは何もする必要はありません。）
GPLUSPLUS_INCLUDE_DIRは、
ネイティブ・コンパイラ、
クロス・コンパイラのどちらにとっても同じことを意味します。
それは、
g++が最初にヘッダ・ファイルを探す場所です。
C++ライブラリは、
ターゲットに依存しないヘッダ・ファイルだけをこのディレクトリにインストールします。
LOCAL_INCLUDE_DIRは、
ネイティブ・コンパイラに対してのみ使われます。
それは通常は`/usr/local/include'です。
ユーザがヘッダ・ファイルを`/usr/local/include'にインストールできるよう、
GNU CCはこのディレクトリを探索します。
CROSS_INCLUDE_DIRは、
クロス・コンパイラに対してのみ使われます。
GNU CCは、
ここには何もインストールしません。
TOOL_INCLUDE_DIRは、
ネイティブ・コンパイラ、
クロス・コンパイラの両方に対して使われます。
それは、
他のパッケージが、
GNU CCの使うヘッダ・ファイルをインストールする場所です。
クロス・コンパイラにとっては、
これは`/usr/include'と同等です。
クロス・コンパイラをビルドする際に、
このディレクトリにあるヘッダ・ファイルはすべてfixincludesによって処理されます。