| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ここでは、GNU CC を GNU システム、あるいは Unix システムに インストールするための手順を説明する。 VMS の場合は、GNU CC を VMS にインストール を参照のこと。 この節では、ソースの置かれているディレクトリでコンパイルを行なうことを 仮定する。ソースディレクトリとは別のディレクトリでコンパイルする方法に ついては、別ディレクトリでのコンパイル方法 を参照のこと。
MSDOS では、GNU C 自身をインストールすることはできない。 GNU C 自身以外の MSDOS のコンパイラではコンパイルできないからである。 このため、完全な DJGPP パッケージを入手する必要がある。 DJGPP は、ソースだけでなくバイナリを含んでおり、さらに他に必要な ツールやライブラリを全て含んでいる。
PATH で、必ず ‘/usr/bin’ が
‘/usr/ucb’の前に来るようにすること。
‘/usr/ucb’ にある cc は、バグがあるライブラリを使って
しまうので。
"Sept 8, 1998" より古いバージョンの Bison は、‘c-parse.c’ を 正しく生成できない。
システム標準のツールよりも先に来るように設定したうえで、引き続く コンパイルを行なうこともできる。
ビルドマシンとは、読者が使っているシステムであり、 ホストマシンとは、できたコンパイラを実行させたいシステム (普通はビルドマシン)であり、ターゲットマシンとは それ向けにコンパイラにコードを生成させたいシステムのことである。
コンパイラ自身が動作するマシン向けのコードを生成するコンパイラ (ネイティブコンパイラ)を構築する場合は、普通は ‘configure’ に 何も引数を指定する必要はない。 機種を推測し、それを構築マシンおよびホストマシン、ターゲットマシンとして 使う。このため、‘configure’ が今フィギュレーションを推測できなかったり、 推測が間違っていない限り、ネイティブコンパイラを構築するときには コンフィギュレーションを指定する必要がない。
推測がうまくいかない場合は、構築マシンの コンフィギュレーション名 を ‘--host’ オプションで指定する。 ホストとターゲットはデフォルトでホストマシンと同じになる。 (クロスコンパイラを構築する場合は、クロスコンパイラの構築とインストールの方法。)
以下に例を示す。
./configure --host=sparc-sun-sunos4.1 |
コンフィギュレーション名は、正規名でも省略形でも良い。
コンフィギュレーションの正規名は三つの部分をダッシュで区切ったものからなる。 ‘cpu-company-system’ という形式になる。 (三つの部分はさらにその中にダッシュを含んでも良い。‘configure’ は、どのダッシュがどの役割を果たすかを区別できる。) 例えば、‘m68k-sun-sunos4.1’ は Sun 3 を指定する。
コンフィギュレーションの一部をニックネームまたは別名で置き換えることも できる。例えば、‘sun3’ は ‘m68k-sun’ を表すので、 ‘sun3-sunos4.1’ としても Sun 3 を指定したことになる。 これをさらに簡単にして ‘sun3-sunos’ としても良い。 なぜなら、SunOS のバージョンはデフォルトがバージョン 4 であると 仮定されているからである。
システムタイプのどれにでも、そして CPU タイプの幾つかには その後にバージョン番号を指定することができる。 大部分の場合は、バージョンは関係なく、無視される。 このため、知っている場合にはバージョンを指定しても良い。
サポートされているコンフィギュレーション名の一覧と 多くのコンフィギュレーションについての注意書きについては、 GNU CC でサポートしているコンフィギュレーション を参照のこと。
configure を実行するとき、ハードウェアとソフトウェアを
記述する特定のオプションを追加で指定する必要があるかもしれない。
コンフィギュレーションの一部を独立に指定できるようになっている。
それは、‘--with-gnu-as’、‘--with-gnu-ld’、
‘--with-stabs’、‘--nfp’ である。
GNU CC を GNU アセンブラ(GAS) と共に使うなら, ‘configure’ の実行時に ‘--with-gnu-as’ を指定することで その旨を宣言する必要がある。
このオプションを指定しても、GAS のインストールは行なわない。 GNU CC の出力を GAS で処理できるように修正するだけである。 GAS の構築とインストールは読者の責任である。
逆に、GAS を使うことを希望せず、構築時に ‘--with-gnu-as’ を
指定しないのであれば、GAS がインストールされていないことを
確認するのは読者の責任である。
GNU CC は、as という名前のプログラムを色々なディレクトリから
探す。もし見つけたプログラムが GAS であれば、GAS が実行されることに
なる。GNU CC が使っているアセンブラがどこにあるのかわからない場合は、
‘-v’ を指定して実行してみよう。
GAS を使うかどうかによって違いが生じるシステムは以下の通りである。
‘hppa1.0-any-any’、 ‘hppa1.1-any-any’、
‘i386-any-sysv’、 ‘i386-any-isc’、
‘i860-any-bsd’、 ‘m68k-bull-sysv’、 ‘m68k-hp-hpux’、
‘m68k-sony-bsd’、
‘m68k-altos-sysv’、 ‘m68000-hp-hpux’、 ‘m68000-att-sysv’、
‘any-lynx-lynxos’、‘mips-any’)。
これら以外のシステムでは、‘--with-gnu-as’ は何の効果もない。
上に列挙したシステムでは(HP-PA, i386 上の ISC、‘mips-sgi-irix5.*’ を 除く)、GAS を使う場合には GNU リンカも使うべきである (‘--with-gnu-ld’ を指定する)。
GNU CC と一緒に GNU リンカを使う予定なら、‘--with-gnu-ld’ オプションを 指定する。
このオプションでは、GNU リンカをインストールしようとはしない。 単に、GNU CC の振るまいを GNU リンカと協調して動作するように修正する だけである。
MIPS ベースのシステムと Alpha では、GNU CC が通常の ECOFF 形式の デバッグ情報を作るか、BSD形式の stabs を ECOFF のシンボルテーブルを 通して使うかのどちらかを指定しなければならない。 通常の ECOFF デバッグ情報形式は、C 以外の言語を完全には取り扱うことが できない。BSD stabs 形式は、他の言語も扱えるが、 GNU デバッガ GDB でしか使えない。
通常、GNU CC は、ECOFF 形式のデバッグ情報をデフォルトで使う。 BSD stabs の方が良ければ、GNU CC をコンフィギュレーションする際に ‘--with-stabs’ を指定する。
GNU CC をコンフィギュレーションするさいに、どちらをデフォルトとして 選んだかに関わらず、ユーザは ‘-gcoff’ オプションと ‘-gstabs+’ オプションを使って、特定のコンパイル毎にデバッグ情報形式を 明示的に指定することができる。
‘--with-stabs’ は、i386 上の ISC システムでは、‘--with-gas’ も 指定されたときに有効になる。このオプションにより、COFF 出力の 中に埋め込む形の stabs デバッグ情報を使うことを選択する。 この種類のデバッグ情報は C++ もサポートする。通常の COFF デバッグ情報は サポートしていない。
‘--with-stabs’ は、i386 上の SVR4 でも有効である。 このオプションにより、ELF 出力の 中に埋め込む形の stabs デバッグ情報を使うことを選択する。 C++ コンパイラは現在(2.6.0)、i386 上の SVR4 プラットフォームで 通常使われている DWARF デバッグ情報をサポートしていない。 このため、stabs を動作する選択肢となる。 このオプションは、gas と gdb を必要とする。 通常の SVR4 のツールでは、stabs を生成したり、解釈できないからである。
ある種のシステムでは、マシンに浮動小数点ユニットがあるかどうかを 指定しなければならない。そういうシステムには、 ‘m68k-sun-sunosn’ や ‘m68k-isi-bsd’ がある。 他のシステムでは、今のところ ‘--nfp’ は何の効果もないが、 それを使って違いを出すと便利なシステムがおそらく他にもあるだろう。
‘--enable-haifa’ を指定すると、ある実験的な命令スケジューラ
(IBM Haifa 提供)を使うようにする。これにより生成されるコードが
良くなることもあれば、良くならないこともある。
良くなることが分かっているいくつかの機種ではデフォルトでこの機能が有効に
なっている。その場合、無効にするには ‘--disable-haifa’ オプションを
使えば良い。configure を実行すると、Haifa スケジューラが
有効になっているかどうかを表示する。
ある種のシステム、特に Linux ベース GNU システムは、 Objective C の実行時にスレッド機能を提供するには信頼が置けないので、 デフォルトでシングルスレッド実行時になる。だが、これらのシステムに スレッドの実装が利用可能なライブラリがあるかもしれない。その場合、 スレッド機能は、このオプションに適切な type、おそらく ‘posix’ を 指定することで有効になる。type の可能な値は、 ‘single’、‘posix’、‘win32’、‘solaris’、 ‘irix’、‘mach’ である。
このオプションを指定すると、GCC は、ツリー・ノード型の検査を、そのノードの フィールドを参照したときに、実行するように構築される。 これは生成されるコードを変えることはしないが、GCC 内部のエラー検査を 追加する。これにより、コンパイル速度は遅くなり、GCC を構築するのに GCC を使ったときにしか正しく動作しないだろう。
‘configure’ スクリプトは、GNU CC に統合される他のコンパイラを、 ソースディレクトリのサブディレクトリから探す。 例えば、C++ 向けの GNU コンパイラは、G++ と呼ばれており、‘cp’ という サブディレクトリにある。‘configure’ は ‘Makefile’ に ルールを挿入して、これらのコンパイラを全て構築するようにする。
以下に、configure が設定するファイルについて残らず
説明する。普通は、以下のファイルに注意を払う必要はない。
最上位レベルのコンフィギュレーションファイルはサブディレクトリ ‘config’ に置かれている。その名前は常に ‘xm-something.h’ である。普通は ‘xm-machine.h’ であるが、幾つか例外がある。
シンボリックリンクのないシステムでは、‘config.h’ を適切なファイルを 参照している ‘#include’ 制御子を含むように設定する必要があるだろう。
‘--enable-nls’ オプションを指定すると母国語サポート(Native Language Support, NLS)を有効にする。NLS を使うと、GCC は、合衆国で使われている 英語以外の言語で診断メッセージを出力する。メッセージを翻訳したものは まだ利用可能ではないので、このオプションの主なユーザは、 GCC の診断メッセージを翻訳している人々であり、翻訳作業結果の 確認に使っている。一度翻訳が揃えば、母国語サポートをデフォルトで 有効にする予定である。‘--disable-nls’ オプションで NLS を 無効にできる。
NLS が有効になっていると、GCC の構築手順では普通、ホストマシンにある
gettext ライブラリを使うことをまず試み、それが充分なもので
ない場合にだけ、GCC に含まれている GNU gettext ライブラリを
使う。‘--with-included-gettext’ オプションを指定すると、
付属の GNU gettext を優先させる。
NLS が有効になっていると、ホストに gettext はないが、
やや劣る catgets インターフェースならあるという場合、
GCC の構築手順では普通、catgets は無視して、代わりに GCC に付属の
GNU gettext ライブラリを使う。‘--with-catgets’ オプションを
指定すると、その場合にホストの catgets を使う。
configure を実行するときに他の特定のオプションを
指定する必要がある。
--with-local-prefix オプションを使う。
ここで指定したディレクトリが存在する必要はないが、その親ディレクトリは
存在しなくてはならない。
‘--with-local-prefix’ を指定するのは、 読者のサイトが、サイト固有のファイルを置く場所について別の規約 (‘/usr/local’ 以外)にしている場合にだけすべきである。
‘--with-local-prefix’ のデフォルト値は ‘--prefix’ の値に よらずに ‘/usr/local’ である。‘--prefix’ を指定しても、 GNU CC がローカルのヘッダファイルを探しに行くディレクトリには影響がない。 これは直観に反するようだが、論理に適っている。
‘--prefix’ の目的は GNU CC をインストールする場所を 指定することにある。‘/usr/local/include’ にある ローカルのヘッダファイルは—読者がそこに何か置いた場合–GNU CC の 一部ではないのである。そこにあるものは他のプログラム—多分たくさんの プログラムの一部である。(GNU CC は自分自分のヘッダファイルは ‘--prefix’ の値に基づく別のディレクトリにインストールする。)
‘--with-local-prefix’ のデフォルト値は、‘--prefix’ の値に 関わらず ‘/usr/local’ である。‘--prefix’ を 指定しても、GNU CC がローカルのヘッダファイルを検索するディレクトリには 影響しない。これは一見すると変に思えるかもしれないが、実際には 論理的な帰結である。
‘--with-local-prefix’ として ‘/usr’ を指定してはならない。
‘--with-local-prefix’ で指定するディレクトリは、
システムの標準ヘッダファイルを一切含んでいてはならないのである。
もし含んでいると、ある種のプログラムは正しくコンパイルされない
(あるターゲットでの GNU Emacs を含む)。これは、fixincludes スクリプト
により修正がなされるヘッダファイルを上書きし、中身を消してしまうからである。
このオプションを使う人達は、何のためのオプションかを誤解して使っている という徴候がある。人々は、このオプションを、まるで GNU CC の一部を インストールする場所を指定するものであるかのように使っている。 人々がそう考えるのは、おそらく、GNU CC をインストールするときに このオプションで指定したディレクトリが実際に作られるからだろう。
‘LANGUAGES=c’ は、C コンパイラのみコンパイルすることを指定する。 特に指定しなければ通常は、サポートされている言語全てのコンパイラを 構築する。現在サポートされているのは、C、C++、Objective C である。 しかし、GNU C コンパイラ以外の他のコンパイラを使って構築する場合に、 正しく動作することが保証されるのは C だけである。 さらに付け加えるなら、C 以外のものをこのステージで構築するのは 時間の無駄である。
一般に、構築したい言語を指定するには、引数 ‘LANGUAGES="list"’ を 追加する。ここで list は、‘c’、‘c++’、‘objective-c’ の うちから一つ以上選んで並べたものである。 GNU CC のソースディレクトリのサブディレクトリに何か追加言語 の GNU コンパイラのソースを持っているなら、その名前をリストに指定しても 良い。
‘insn-emit.c’ で “statement not reached” という警告が出るかも しれないが、無視して良い。それで問題はない。 それから、‘genopinit.c’ や、もしかするとそれ以外の ファイルでも出るかも知れないが、“unknown escape sequence” という警告も 問題がない。同様に、‘insn-emit.c’ と ‘insn-recog.’ の “constant is so large that it is unsigned”、 ‘enquire.o’ の 比較が常に 0 になる旨の警告、それに ‘cexp.y’ での シフト回数が型の大きさを越えているというも無視して良い。 それ以外のコンパイルエラーは問題の起きるマシンや OS への移植の バグの可能性があるので、 調べて報告すべきである(see section バグレポート)。
コンパイラの中には、バグや制限のために GNU CC をコンパイルできない ものがある。例えば、Microsoft のコンパイラはマクロスペースを 使い切ってしまうと言われている。いくつかの Ultrix のコンパイラは、 式空間を使い切ってしまい、問題が起きたところで文をいくつかに 分割しなければならない。
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’
のどれか一つ以上の名前を指定する。名前は空白で区切る。
‘proto’ は、protoize と unprototize プログラムを
表す。これらは独立した言語ではないが、インストールするかどうかを
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’を作って、コンパイラを二回構築する 代わりに、以下のコマンド行を使うことができる。
make bootstrap LANGUAGES=language-list BOOT_CFLAGS=option-list |
機種によっては、オブジェクトファイルの意味のある比較が不可能な場合がある。 常に「異なってしまう」ように見える。 これは、今のところ、Solaris と ELF オブジェクトファイル形式を使用している 幾つかのシステムが当てはまる。 SGI の Irix の幾つかのバージョンと、Alpha システム上の DEC Unix(OSF/1) では、 ‘-save-temps’ を指定しないとオブジェクトファイルを比較できないだろう。 比較に失敗したなら、これらの個々のシステムの説明を見て欲しい。 他のシステムでも同じような問題が起きるかもしれない。
ファイルの比較を行なうには次のコマンドを使う。
make compare |
これは、ステージ2 とステージ3で異なるオブジェクトファイルについて 知らせてくれる。 何か違いがあれば、それが無害かどうかに関わらず、 ステージ 2 のコンパイラが GNU CC を正しくコンパイルしなかったということを 意味し、それゆえ潜在的に重大で、調査したうえで 報告(see section バグレポート)を 行なうべきバグが存在する可能性がある。
オブジェクトファイルにタイムスタンプを挿入しないシステムでは、 以下のコマンドが比較を行なう速い方法である(Bourne シェルを使っている)。
for file in *.o; do cmp $file stage2/$file done |
MIPS のマシンで ‘-mno-mips-tfile’ オプションを指定して コンパイラを構築した場合は、ファイルを比較することはできない。
CC と CFLAGS、LANGUAGES に対して使うようにする。
同じ値にする理由の一つは、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’ を実行したときに指定した ターゲット機種のタイプの正規形であり、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 の実行形式を
インストールするよう注意すること。(すなわち、stage1 ではなくて、
stage2 か 3 で出来た実行形式をインストールする。)
GNU CC は、組み込み関数の alloca を使い、ライブラリにあるものは
決して使わない。
(通常でも、stage2 また 3 の GNU CC の実行形式をインストールしたほうが 良い。というのは、他のコンパイラでコンパイルしたものよりも高速に 動作するからである。)
GNU CC 用の標準C++実行時ライブラリは ‘libstdc++’ というものである。 旧版の ‘libg++’ も利用可能であるが、変換が済んでいない 古いソフトウェアにしか必要のないものである。読者が ‘libg++’ を 必要とするかどうかわからない場合は、おそらく必要としないだろう。
以下に GNU CC 用に ‘libstdc++’ を構築し、インストールする方法の 一つを示す。
まとめると、GNU CC を構築・インストールしたあと、以下のシェルコマンドを C++ ライブラリの配布物の最上位ディレクトリで実行することになる。 configure-options には、GNU CC のコンフィギュレーションで 使用したのと同じオプションを指定する。
$ CXX=gcc ./configure configure-options $ make $ make install |
‘configure’ を実行すると、ターゲットのプラットフォームに適した Objective-C のスレッド実装ファイルを選び出す。 場合によっては、複数のスレッド実装をサポートしているプラットフォームが あったり、スレッドサポートを完全に無効にしたいなどの理由により、 異なるバックエンドを選びたいこともあるだろう。それには、make の 実行時に、コマンド行で Makefile 変数のOBJC_THREAD_FILE に 値を指定すれば良い。例えば以下のようにする。
make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2" OBJC_THREAD_FILE=thr-single |
以下に現在利用可能なバックエンドの一覧を示す。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated
using texi2html 1.78.