7.2 GCC のインストール時の問題

以下に、GCC のインストール過程で発生する問題(それに実際には何も 間違いではない見かけ上の問題)の一覧を示す。

• システムによっては、CC のような環境変数を定義すると、 make の機能と干渉を起こすことがある。
• ソースディレクトリとは別のディレクトリでコンパイルしたときに 変なエラーが出たら、それは、以前にソースディレクトリでコンフィギュレーション を行なったせいだろう。必要な準備が全部終わっているか確認して欲しい。 See section 別ディレクトリでのコンパイル方法.
• BSD 系の Unix で GCC を構築するとき、System V のファイルシステム上の ディレクトリを使うと、その System V のファイルシステムがシンボリック リンクをサポートしていないと、 fixincludes を実行中に 問題が発生する可能性がある。 この問題により結果的に、‘sys/types.h’ の中の size_t の 宣言の修正に失敗する。size_t が符号付きの型になっていて そのために型の不一致のエラーが起こったら、これが原因である。

  この問題を回避するには、GCC を構築するのに、 System V のファイルシステム上のディレクトリを使わないことである。

• GCC の古いバージョンでは、ドライバプログラム gcc は、 as や ld を色々な場所から探した。 例えば、‘/usr/local/lib/gcc-’ で始まるファイル等から。 GCC のバージョン 2 では、 ‘/usr/local/lib/gcc-lib/target/version’ という ディレクトリを探すようになっている。

  つまり、システムのデフォルト以外のバージョンの as や ld、 例えば gas や GNU ld を使いたければ、それを 上記のディレクトリに置いておく必要がある。(あるいは、リンクを張っておく。)

• コンパイラを作成するときに実行されるコマンドの中には失敗する (ゼロでない終了ステータスを返す)コマンドがあるが、make が その失敗を無視することがある。 こういう失敗は、ファイルが見つからない場合に良く起こり、予想されている ことなので、無視しても大丈夫である。
• GCC のソースファイルの幾つかは、コンパイル時に、到達不能コードや 列挙型の衝突について警告が出ることがあるが、これは問題ない。 問題が出るファイルは名前が ‘insn-’ で始まるものである。 また、‘real.c’ でも警告が出ることがあるが、これも無視しても問題ない。
• コンパイラをインストールするとき、make がコンパイラの一部を 再コンパイルすることが時々ある。 ある場合には、make のバグに起因することがある。 その場合は、この問題を無視するか GNU Make を使うようにすれば良い。
• purify というプログラムをインストールしてある場合、enquire を リンクするときにエラーが起きるかもしれない。 enquire のリンクは、GCC の構築過程の一部である。 これを避けるには、purify がインストールする real-ld というファイル を取り除くことである。そうすれば、GCC は purify を使おうとしない。
• GNU/Linux SLS 1.01 では、‘libc.a’ に問題がある。 これには obstack の関数群が含まれていない。 だが、GCC は ‘libc.a’ が GNU C ライブラリである場合には obstack 関数が含まれていることを想定している。 この問題を回避するには、31 行目付近の __GNU_LIBRARY__ の条件を ‘#if 1’ に変えれば良い。
• 386 システムの中には、コンパイラの構築が絶対終わらないものがある。 これは、enquire が、マザーボードのハードウェア障害のために ハングしてしまうからである。ハードウェア障害というのは、 浮動小数点例外をカーネルに不正確に伝えるというものである。 enquire を実行するコマンドを取り除くことで、‘float.h’ なしで GCC をインストールすることもできる。 本当に問題を解決したのなら、マザーボードを取り替えるのが良いだろう。 この問題は、Micronics のマザーボードの Revision E で見つかっており、 Revision F では修正されている。 また、MYLEX MAX-33 のマザーボードでも見つかっている。

  この問題に出会ったら、コンパイルを実行している間、ソケットから FPU を取り外しておくことも考えても良いだろう。 あるいは、SCO Unix を使っているなら、リブートして強制的に FPU を 無視するようにすることもできる。それには、‘hd(40)unix auto ignorefpu’ と入力する。

• 386 システムの中には、‘enquire.c’ をコンパイル使用とすると、 GCC が落ちてしまうものがある。 これは、387 FPU チップのないマシンで発生する。 386 システムでは、387 が無いときはシステムカーネルが 387 をエミュレート すると想定している。GCC が落ちるのは、エミュレータのバグに寄るものである。

  こういうシステムの一つは、Interactive Systems の Unix である 386/ix である。 このシステムには、別のエミュレータも提供されており、そちらは正しく動作する。 それを使うためには、以下のコマンドをスーパーユーザで実行する。

  ln /etc/emulator.rel1 /etc/emulator

  次にシステムをリブートする。 (デフォルトのエミュレータファイルは、‘emulator.dflt’ という名前で 残っている。)

  この問題が SCO のシステムで起きたときは、 ‘/etc/emulator.att’ を使ってみて欲しい。

  この問題のあるもう一つ別のシステムは、Esix である。 正しく動作するエミュレータが別にあるかどうか我々は知らない。

  NetBSD 0.8 では、同様の問題により以下のようなエラーメッセージが出る。

  enquire.c: In function `fprop': enquire.c:2328: floating overflow

• SCO のシステムで、GCC をコンパイルするにシステムコンパイラを 使うときは、‘-O’ を指定してはならない。システムコンパイラの バージョンによっては、‘-O’ を付けると、正しくないコンパイルが 行なわれることがあるためである。
• Sun4 では、ときどき GCC を構築する際に genflags や genoutput と言ったプログラムが落ちることがある。 これは、sh のバグのせいだと言われている。 おそらく、genflags や genoutput を手動で実行して、 もう一度 make を実行することで回避できると思われる。
• Solaris 2 では、GCC のバージョン 2.0.2 の実行形式が広く利用可能である。 だが、このバージョンには GCC の現行バージョンをコンパイルする際に 現れるバグがある。‘-g’ を指定すると、アセンブリ時に 未定義シンボルのエラーが発生する。

  解決策は、GCC の現行バージョンは ‘-g’ なしでコンパイルする ことである。こうすると正しく動作するコンパイラができるので、 それを使って ‘-g’ を付けて再コンパイルすれば良い。

• Solaris 2 は、たくさんのオプションの OS パッケージが付いてくる。 これらのパッケージの中には、GCC を充分に使うためには必要となるものが ある。Solaris をインストールする際にオプションパッケージを全部は インストールしなかった場合は、GCC が必要とするパッケージを インストールしてあるかどうかを確かめる必要がある。

  あるオプションのパッケージがインストールされているかどうかを 確かめるには、pkginfo コマンドを使う。あるオプションパッケージを 追加するには、pkgadd コマンドを使う。さらに詳しいことについては Solaris のドキュメントを参照のこと。

  Solaris 2.0 と 2.1 の場合は、GCC は次の 6 個のパッケージが必要である。 ‘SUNWarc’、‘SUNWbtool’、‘SUNWesu’、‘SUNWhea’, ‘SUNWlibm’、‘SUNWtoo’。

  Solaris 2.2 の場合は、さらに 7 番目のパッケージ ‘SUNWsprot’ が ひつようになる。

• Solaris 2 では、GCC をインストールするのの、‘/usr/ucb’ に あるリンカやその他のツールを使おうとすると問題になることが知られている。 例えば、リンカは永久にハングしてしまう。 回避するには、PATH から ‘/usr/ucb’ を取り除く。
• MIPS のアセンブラのバージョン 1.31(例えば、Ultrix 3.1 に付いてくる)を 使っているなら、浮動小数点コードを最適化するときには ‘-fno-delayed-branch’ オプションを使う必要がある。 そうしないと、GCC が遅延分岐スロットを add.d のような、 浮動小数点命令で埋めたといってアセンブラが文句を言ってくる。
• MIPS のシステムで、“does not have gp sections for all it's [sic] sections [sic]” というエラーメッセージが出ても気にしなくて良い。 これは、GAS と MIPS のリンカを組み合わせて使うと必ず出るが、 実際には何も間違いはないし、その出力ファイルを使っても問題ない。 この警告を止めるには、GNU リンカをインストールすれば良い。

  GAS が gp テーブルを生成するようにすれば良いのだろうが、これは 無くても良いものなので、無いからと言って警告を出すべきではないのである。

• MIPS 上の Ultrix 4.0 では、‘stdio.h’ は、fixincludes で 修正しないうちは、GCC では全く使えない。これは、GCC を構築するときに 問題になり、GCC を一旦インストールしてしまえば問題はなくなる。

  この問題を回避するには、ステージ 1 コンパイラを作るときに、make に 以下のオプションを指定する。

  GCC_FOR_TARGET="./xgcc -B./ -I./include"

  ステージ 2 と 3 を作るときには、以下のように指定する。

  CFLAGS="-g -I./include"

• Ultrix 4.1 と共に出荷された MIPS のバージョン 2.0 の コンパイラツールには幾つか問題があるとの報告がユーザから上がっている。 Ultrix 4.2 付属のバージョン2.10 は正しく動作するようである。

  RISC/os 4.x と共に出荷された MIPS のバージョン 2.20 の コンパイラツールには幾つか問題があるとの報告もユーザから上がっている。 バージョン 2.11 以前なら正しく動作するようである。

• MIPS のリンカの幾つかのバージョンは、alloca を使っているコードを RISC/OS 5.0 と DEC の OSF/1 の共有ライブラリとリンクするときに アサーションに失敗する。これはリンカのバグであり、将来のバージョンでは 修正されるものと思われる。これを避けるために、ユーザが明示的に ‘-shared’ や ‘-call_shared’ を指定しない限り、GCC は リンカに ‘-non_shared’ を渡す。
• System V release 3 では、リンク時に以下のようなエラーメッセージを が出るかもしれない。

  ld fatal: failed to write symbol name something in strings table for file whatever

  これは恐らく、ディスクが一杯になってしまったか、ULIMIT の設定のために 必要な大きさのファイルが作れないということを示している。

  この問題は、カーネルのパラメータ MAXUMEM が小さすぎても 起こる。その場合、カーネルを作り直して、この値をもっと大きくしなければ ならない。デフォルト値は 1024 であるという報告が来ている。 32768 だと動作するようだ。これより小さくても動くかもしれない。

• System V では、

  /usr/local/lib/bison.simple: In function `yyparse': /usr/local/lib/bison.simple:625: virtual memory exhausted

  というエラーが出たら、ディスク容量、ULIMIT あるいは MAXUMEM の 問題であることを表している。

• 現在のバージョンの GCC は、NeXT のオペレーティングシステムのバージョン 2 では恐らく動作しないだろう。
• NeXTStep 3.0 では Objective C コンパイラは動作しない。 カーネルのバグによるものである。3.1 ではこの問題はない。
• Tower のモデル 4n0 と 6n0 では、デフォルトでは 一個のプロセスは 1 メガバイトを越えるメモリを持つことができない。 GCC は、‘-O’ をそれだけのメモリでは自分自身(あるいは他の多くの プログラムも)をコンパイルすることができない。

  これを回避するには、カーネルを再構成して、構成ファイルに以下の行を 追加する。

  MAXUMEM = 4096

• HP9000 シリーズの 300 や 400 で HP-UX release 8.0 を動かしている場合、 アセンブラのバグがあり、GCC を構築する前に修正しなければならない。 このバグは、ステージ1 のコンパイルの、‘libgcc2.a’ を 構築している時に現れる。

  _floatdisf cc1: warning: `-g' option not supported on this version of GCC cc1: warning: `-g1' option not supported on this version of GCC ./xgcc: Internal compiler error: program as got fatal signal 11

  修正済みのアセンブラは、altdorf.ai.mit.edu の ‘archive/cph/hpux-8.0-assembler’ にあり、匿名 ftp で 入手できる。HP のソフトウェアサポートを受けているなら、 パッチを HP から、以下の注意書きにあるように直接入手できる。

  This is the patched assembler, to patch SR#1653-010439, where the assembler aborts on floating point constants.

  The bug is not really in the assembler, but in the shared library version of the function “cvtnum(3c)”. The bug on “cvtnum(3c)” is SR#4701-078451. Anyway, the attached assembler uses the archive library version of “cvtnum(3c)” and thus does not exhibit the bug.

  このパッチは PHCO_4484 としても知られている。

• HP-UX のバージョン 8.05 では、シェルスクリプト fixproto を 実行すると、システムのシェルのバグを引き出す。 これは、8.07 以降のバージョンでは発生しない。 この問題に出会ったら、OS をアップグレードするか、fixproto を 実行するのに BASH (GNU のシェル)を使えば良い。
• Pyramid の C コンパイラは、バージョンによって、 GCC をコンパイル出来ないという報告が上がっている。 古いバージョンの GCC を使ってブートストラップする必要がある。 この問題に出くわしたかどうかは、‘libgcc2.c’ の中の 関数 muldi3 をコンパイルするときに GCC が落ちるかどうかで 判る。

  GCC のバージョン 1 を入手、インストールして、それを使って GCC のバージョン 2 をコンパイルするとうまく行くはずである。 この、Pyramid の C コンパイラのバグは、GCC のバージョン 1 には 影響しないようなので。

• 386 システム上の System V Release 3.1 にも似た問題が存在する。
• Intel Paragon(i860 を使っている機種である)では、 バージョン 1.0 の OS だと、GCC の構築の際に、 va_arg を 二重定義しているという警告かエラーが出る。

  そうなった場合、ほとんどのプログラムは、ライブラリ ‘iclib.a’ を リンクする必要がある。また、‘stdio.h’ を以下のように 修正しなければならない。

  #if defined(__i860__) && !defined(_VA_LIST) #include <va_list.h>

  という行の前に以下の行を挿入する。

  #if __PGC__

  そして、

  extern int vprintf(const char *, va_list ); extern int vsprintf(char *, const char *, va_list ); #endif

  という行の後に

  #endif /* __PGC__ */

  という行を追加する。 この問題は、OS のバージョン 1.1 には存在しない。

• Altos 3068 では、GCC でコンパイルしたプログラムは、 カーネルのバグを修正しない限り、動かない。 このバグは、バージョン V.2.2 1.0gT1 や V.2.2 1.0e、それにおそらく それ以降のバージョンのシステムに存在する。‘README.ALTOS’ という ファイルを参照のこと。
• we32k の場合、特別な手順を取らない限り、コンパイル時やリンク時に 色々な種類のエラーが出る。See section GNU CC でサポートしているコンフィギュレーション.
• HP-UX 8.05 (とそれ以前のバージョン)ではシェルのバグのために、 fixproto プログラムが以下のようなエラーを出す。

  ./fixproto: sh internal 1K buffer overflow

  これを回避するには、シェルスクリプト fixproto の先頭の行を 以下のように変えれば良い。

  #!/bin/ksh

This document was generated using texi2html 1.78.