[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.2 GNU CC でサポートしているコンフィギュレーション

以下はサポートしている 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 と企業名からオペレーティングシステムを推測する。

システム名にバージョン番号を付け足すこともできる。 これにより、違いが生じる場合もあるし、違いはない場合もある。 例えば、‘bsd4.3’ や ‘bsd4.4’ と書いて、BSD のバージョンを 区別することができる。‘sysv3’ と ‘sysv4’ の 場合にはバージョン番号を必要とし、異なった扱いを受ける。

i860-dg-vms’ のようにありえない組合せを指定すると、 ‘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’ と指定したとすると、このコンフィギュレーションは ‘m68k.md’、‘local.h’、‘m68k.c’、‘xm-local.h’、 ‘t-local’、‘x-local’ といったファイルを使う。 これらは全てディレクトリ ‘config/m68k’ に置かれる。

以下のリストは、知っていなければならない、特別な取扱いや特別な事項のある コンフィギュレーションである。

1750a-*-*

MIL-STD-1750A プロセッサ。

MIL-STD-1750A のクロス・コンフィギュレーションは GNU Public License の元で利用可能な 1750A 向けアセンブラ/リンカである as1750 用のコードを生成する。 ‘as1750’ は、ftp://ftp.fta-berlin.de/pub/crossgcc/1750gals/ から入手可能である。同様のライセンスを持つ、1750A 向けシミュレータ も同じ所から入手可能である。

libcc を構築中に出る致命的エラーは無視して良い(1750A 向けのlibgcc は まだ実装されていない。)

as1750 アセンブラは ‘ms1750.inc’ というファイルを 必要とする。このファイルはディレクトリ ‘ms1750.inc’ にある。

GNU CC は、Fairchild F9450 C Compiler と同じセクションを生成する。 すなわち、以下のものである。

Normal

プログラムのコード・セクション。

Static

読み書き(RAM)データ・セクション。

Konst

読み込み専用(ROM)定数セクション。

Init

初期化セクション(KREL を SREL にコピーするためのコード)。

アドレス可能な最小単位は 16 ビット(BITS_PER_UNIT が 16)である。 これは、`char' 型が、一文字につき 16 ビットの語で表現されるという ことを意味する。1750A の "Load/Store Upper/Lower Byte" 命令は GNU CC では使われない。

alpha-*-osf1

DEC Alpha アーキテクチャを実装したプロセッサを使い、DEC Unix (OSF/1) が 走るシステムである。例えば、DEC Alpha AXP システム等である。

クロスコンパイラとして構築されない限り、GNU CC は ‘.verstamp’ 疑似命令をアセンブラ出力ファイルに書き出す。 これには、システムヘッダファイル ‘/usr/include/stamp.h’ から 取ったバージョンが入っている。 DEC Unix の新しいバージョンをインストールするときには、 GCC を再構築して、新しいバージョンスタンプを取り出すようにしないといけない。

Alpha は 64 ビットアーキテクチャなので、32ビットの機種で動作する Alpha をターゲットとするクロスコンパイラは、64ビットの機種で 動作するコンパイラが生成するコードと同程度に効率の良いコードを 生成することはできない。これは、多くの最適化が、ターゲットの ワードをホスト上での整数値として表せるということに依存しており、 32ビットの機種上では実行できないからである。 Alpha 上で動作する、ターゲットを 32 ビット機種とするクロスコンパイラを 構築するのは、ほんの2,3の場合しかテストされておらず、多分 正しく動かないだろう。

古いバージョンの DEC Unix では、CFLAGS に ‘-save-temps’ を 追加しないと、make compare に失敗する。これらのシステムでは、 アセンブラへの入力ファイル名がオブジェクトファイル内に収められているので、 そのファイル名が stage1stage2 で異なると、 比較に失敗してしまうのである。オプション ‘-save-temps’ を 指定すると、アセンブラへの入力ファイル名として、‘/tmp’ に置かれる、 ランダムに選ばれた名前の代わりに、固定したファイル名を使う。 ‘-save-temps’ オプションは、これを指定しないと比較に失敗するので ない限り、追加しないこと。‘-save-temps’ を指定すると、 各コンパイルの段階で、‘.i’ と ‘.s’ で終わるファイルを 自分で消さないといけない。

GNU CC は現在、DBX と GDB が使うネイティブ(ECOFF)デバッグ情報形式と GDB だけが使う埋め込み STABS 形式の両方をサポートしている。 これらのデバッグ情報形式と選択方法についての詳細は、既出の ‘configure’ の ‘--with-stabs’ オプションの説明を 参照のこと。

DEC のアセンブラにはバグがあり、‘.align’ 疑似命令を使ったときに ECOFF 形式用の行番号情報が正しくないものを生成する。 この問題を回避するために、GNU CC は、最適化を実行する場合でも ECOFF 形式のデバッグ情報を書き出すときに、この疑似命令をださないように している。ただし、残念なことに、これには非常に困る副作用があり、 ‘-O’ を指定したときのコードのアドレスが、‘-g’ を合わせて 指定するかどうかによって違ってきてしまう。

これを避けるには、‘-gstabs+’ を指定して、DBX の代わりに GDB を 使えば良い。DEC も今ではアセンブラのこの問題に気付いていて、 早急に修正版を提供しようとしている。

arc-*-elf

Argonaut の ARC プロセッサである。 このコンフィギュレーションは組み込みシステム向けである。

arm-*-aout

Advanced RISC Machines 社の ARM 一族のプロセッサである。 埋め込みアプリケーションで良く使われている。 標準の Unix 用コンフィギュレーションは存在しない。 このコンフィギュレーションは基本的な命令列に対応し、‘a.out’ 形式の オブジェクトモジュールを生成する。

読者自身の特定のコンフィギュレーション向けには、‘arm.h’ の 修正版を作る必要がある。

arm-*-linuxaout

a.out’ バイナリ形式を使う Linux ベース GNU システムの動作する ARM プロセッサ(ELF はまだサポートされていない)。GNU/Linux binutils の 2.8.1.0.7 以降を使わなければならない。これは ‘sunsite.unc.edu:/pub/Linux/GCC’ や Linux ベース GNU システム向けの 他のミラーサイトから入手することができる。

arm-*-riscix

ARM2 または ARM3 で動作する RISC iX。 RISC iX は、Acorn による BSD Unix の移植である。 バージョン 1.2 以前の RISC iX を使っている場合は、コンフィギュレーションの 際にバージョン番号を明示的に指定しなければならない。 RISC iX 付属のアセンブラは、stabs 形式のデバッグ情報をサポートしていない ことに注意が必要である。現在、stabs 形式のサポートが入った新しいバージョンの アセンブラが Acorn から入手できる。ftp では ‘ftp.acorn.com:/pub/riscix/as+xterm.tar.Z’ から入手できる。stabs デバッグ情報を有効にするには configure に ‘--with-gnu-as’ を指定する。

configure を実行する前に GNU ‘sed’ をインストールする必要がある。

a29k

AMD の Am29k シリーズのプロセッサである。通常、組み込みアプリケーションで 使われる。標準のUNIX 向けのコンフィギュレーションは存在しない。 このコンフィギュレーションは、AMD 標準の呼び出しシーケンスと バイナリインターフェースに対応しており、他の 29k 用のツールと 互換性がある。

読者自身の特定のコンフィギュレーション向けには、‘a29k.h’ の 修正版を作る必要がある。

a29k-*-bsd

BSD Unix のある版が動作するシステムで使われている場合の AMD Am29050 である。

decstation-*

MIPS ベースの DECstation は三つの異なるコンフィギュレーションを サポートしている。(Alpha ベースの DECstation 製品のコンフィギュレーション 名は ‘alpha-dec’ で始まる。) Ultrix、DEC OSF/1、OSF/rose である。これらのプラットフォーム向けには 以下のようなコンフィギュレーションを使う。

decstation-ultrix

Ultrix のコンフィギュレーション

decstation-osf1

OSF/1 の DEC版。

decstation-osfrose

OSF/1 の Open Software Foundation の参照ポート。 これは、オブジェクトファイル形式として、ECOFF の代わりに OSF/rose を使っている。普通、このコンフィギュレーションを 選択することはないだろう。

MIPS の C コンパイラに対しては、‘cp/parse.c’ をコンパイルするために、 オプション ‘-Wf,-XNg1500’ を指定して、スイッチ文のテーブルの大きさを 大きくしておく必要がある。最適化オプションとして ‘-O2’ を使う場合は、 ‘-Olimit 3000’ も使う必要がある。 この二つのオプションはどちらも、‘configure’ が構築する ‘Makefile’ には自動的に追加される。 make の変数 CC を上書きして MIPS のコンパイラを使うには、 ‘-Wf,-XNg1500 -Olimit 3000’ を追加する必要がある。

elxsi-elxsi-bsd

Elxsi の C コンパイラには、GNU C のコンパイルを妨げる制限があることが 知られている。詳細については mrs@cygnus.com に連絡して欲しい。

dsp16xx

AT&T の DSP1610 シリーズのプロセッサへの移植である。

h8300-*-*

日立の H8/300 シリーズのプロセッサである。

呼びだし規約と構造体のレイアウトがリリース2.6 で変更された。 全てのコードを再コンパイルする必要がある。 新しい呼びだし規約では、関数の引数の最初の三つをレジスタで渡す。 構造体は、大きさがもはや 2 の倍数のバイト数ではない。

hppa*-*-*

HP-PA プロセッサには色々な種類があり、色々な OS が動作する。 GNU CC が正しいプロセッサ型とOSを使うようにコンフィギュレーション をしなければならない。正しくコンフィギュレーションあれていないと、 GNU CC は正しく機能しない。 この問題に対処する一番簡単な方法は GNU CC のコンフィギュレーションを 行なう時にターゲットを指定しないことである。そうすると、‘configure’ スクリプトが自動的に正しいプロセッサ型とOSを決定してくれる。

HP-UX では ‘-g’ は使えない。GNU CC の知らない、独特のデバッグ情報 形式を使っているからである。だが、GCC に GAS と GDB を組み合わせて 使うなら ‘-g’ を使うことができる。 全ての HP-PA のコンフィギュレーションで GAS を使うことを強くお勧めする。

その場合、GAS-2.6 以降と GDB_4.16 以降を使わなくてはならない。 これらは、全ての伝統的 GNU ftp アーカイブサイトから取り寄せることができる。

HP-UX のいくつかのバージョンでは、GNU ‘sed’ をインストールする 必要がある。

コマンド検索パスに、/bin/usr/bin/usr/ccs/bin の現れる前に、GAS をインストールするディレクトリを置く必要がある。 GNU CC を作る前に GAS をインストールしておく必要がある。

デバッグを可能にするには、構築を行なう前に ‘--with-gnu-as’ オプションを つけて GNU CC のコンフィギュレーションを行なう。

i370-*-*

この移植はまだまだ予備的であり、たくさんバグがあることがわかっている。 この機種向けの品質の良い移植を早急に求めている。

i386-*-linux-gnuoldld

gas/binutils のバージョン 2.5.2 以降をインストール済みでない場合に、 Linux ベースの GNU システム上で a.out 形式のバイナリを生成するには、 このコンフィギュレーションを使う。 これは廃れたコンフィギュレーションである。

i386-*-linux-gnuaout

Linux ベースの GNU システム上でa.out 形式のバイナリを生成するには、 このコンフィギュレーションを使う。 このコンフィギュレーションは置き換えの途上にある。 gas/binutils のバージョン 2.5.2 以降を使う必要がある。

i386-*-linux-gnu

Linux ベースの GNU システム上で ELF 形式のバイナリを生成するには、 このコンフィギュレーションを使って。gas/binutils のバージョン 2.5.2 以降を 使う必要がある。

i386-*-sco

RCC でコンパイルするのがお勧めである。また、システムに付いてくる malloc ではなく GNU malloc をリンクするのが良いだろう。

i386-*-sco3.2v4

SCO のリリース 3.2 バージョン4 にはこのコンフィギュレーションを 使う。

i386-*-sco3.2v5*

SCO OpenServe Release シリーズの 5.0.0、5.0.2、5.0.4、5.0.5、 Internet FastStart 1.0、Internet FastStart 1.1 用である。

GNU CC は ‘-mcoff’ を指定すると COFF バイナリを生成可能である。 デフォルトは ELF バイナリである。ELF を構築する ELF コンパイラが 生成されるように完全な ‘make bootstrap’ を行うことをお勧めする。

TLS597 を ftp://ftp.sco.com/TLS から入手してインストールし、 ELF C++ バイナリが 5.0.4 以前のリリースで正しく動作するように しなければならない。

OS に無料で付いてくる SCO のネイティブ・アセンブラが普通は必要である。 だが、GNU アセンブラも使えなくてはならないだろうから (読者が複雑な asm 文を使っているかもしれないから)、このパッケージを ‘--with-gnu-as’ を指定してコンフィグレーションしなければならない。 このためには、gcc/as として GNU アセンブラをインストール(cp か symlink) しておく。新しめの GNU binutils を使わなければならない。 バージョン 2.9.1 はうまく動作するようだ。このオプションを選択した場合は、 COFF イメージを構築するのは不可能になる。そうしようとすると、 はっきりとした形で見えずに失敗に終わるだろう。一般に、"–with-gnu-as" オプションは、ネイティブのアセンブラ程良くはテストされていない。

注意: C++ を構築する場合は、‘make bootstrap’ を起動する 手順を取る必要がある。ネイティブの OpenServer のコンパイラは、 たくさんの正しい C プログラムを正しく構文解析できない ‘cc1plus’ を 作ってしまう可能性があるからである。ネイティブコンパイラで構築を 行うときは、‘make bootstrap’ しなければならない。

i386-*-isc

システムに付いてくる malloc ではなく GNU malloc をリンクするのが良いだろう。

ISC バージョン 4.1 では、‘duduced.h’ を作るときに ‘sed’ がコアダンプする。バージョン 4.0 の ‘sed’ を使うこと。

i386-*-esix

システムに付いてくる malloc ではなく GNU malloc をリンクするのが良いだろう。

i386-ibm-aix

GAS のバージョン 2.1 かそれ以降、それに GNU LD の GNU binutils バージョン 2.2 かそれ以降を使う必要がある。

i386-sequent-bsd

コンパイルする前に Berkeley 宇宙に行く。

i386-sequent-ptx1*
i386-sequent-ptx2*

configure’ を実行する前に GNU ‘sed’ をインストール する必要がある。

i386-sun-sunos4

ブートストラップするには GNU CC の別のバージョンが必要である。 これは、現在のバージョンをシステム標準のコンパイラで構築すると、 ‘libgcc2.c’ の一部をコンパイルするときに無限ループに陥るからである。 GNU CC の任意のバージョンでコンパイルした GNU CC バージョン 2 には この問題はないようだ。

Sun のシステムに GNU CC をインストールする場合の情報については、 GNU CC を Sun にインストール を参照のこと。

i[345]86-*-winnt3.5

このバージョンは、まだリリースされていない GAS を必要とする。 それがリリースされるまでの間、前もって構築済みのバイナリ版を ftp://cs.washington.edu/pub/gnat/ か ‘cs.nyu.edu:pub/gnat’ から 匿名 ftp で入手することができる。また、Windows NT 3.5 SDK の Microsoft の ヘッダファイルを使わなければならない。 9/4/94 付の CDROM の ‘/mstools/h’ というディレクトリにこれらが 置かれている。NT 3.5 用に特別に作られた、Microsoft リンカの修正版を 使わなければならない。これもまた、NT 3.5 SDK CDROM に入っている。 このリンカがないときは、Visual C/C++ 1.0 または 2.0 のリンカを 使っても良い。

NT に GNU CC をインストールすると、ラッパーとしてのリンカが作られる。 これは ‘ld.exe’ という名前で、ライブラリの指定方法の点で (‘-L’ と ‘-l’) Unix の ‘ld’ の動作のまねをする。 ‘ld.exe’ はライブラリの Unix 名と Microsoft 名の両方を探す。 例えば、‘-lfoo’ と指定すると、‘ld.exe’ は最初に ‘libfoo.a’ を探し、次に ‘foo.lib’ を探す。

GNU CC を Windows にインストールするには二つの方法がある。 どちらを取るかは、Unix 的なシェルと色々な Unix 的なツールが 手元にあるかどうかによる。

  1. Unix にあるようなシェルやユーティリティーがないときは、 DOS のバッチスクリプト ‘configure.bat’ を使う。 これを、MSDOS のコンソールウィンドウかプログラムマネージャのダイアログ ボックスから configure winnt として起動する。 ‘configure.bat’ は、Unix にあるような ‘sed’ プログラムが インストール済みであり、コマンド検索パスに入っていることを想定している。 ‘sed’ を使って、‘Makefile.in’ から ‘Makefile’ を 作るのである。

    こうしてできる ‘Makefile’ では、Microsoft の Nmake 保守ユーティリティ と Visual C/C++ V8.00 コンパイラを使って GNU CC を構築する。 この方法を使う場合には、必要なユーティリティは ‘sed’ と ‘touch’ だけであり、コンパイラ自体の構築までしか自動的に行なわない。 この後、‘fixinc.winnt’ が何をしているのかを眺めて、 ヘッダフィアルを編集し、‘libgcc.a’ を主動で作らなければならない。

  2. 二番目のインストール方法では、Unix にあるようなシェルが使えて、 Unix にあるようなユーティリティが充分揃っていてコマンド検索パスに 入っていて、かつ GNU CC の以前のバージョンがインストール済みである ことを想定している。GNU CC の古いバージョンは、上記の方法で インストールしたものでも構わないし、事前に構築されたバイナリを 使っても構わない。この場合は、ふつうと同じく ‘configure’ スクリプトを 使えば良い。
i860-intel-osf1

これは Paragon 用である。

バージョン 1.0 のオペレーティングシステムを使っている場合は、 システムの癖に対処するために特別な手順が必要なので、 GCC のインストール時の問題 を参照のこと。

*-lynx-lynxos

LynxOS 2.2 およびそれ以前。 これらは、GNU CC 1.x が ‘/bin/gcc’ としてインストールされてくる。 ‘/bin/cc’ ではなく ‘/bin/gcc’ を使ってコンパイルすべきである。 GNU CC に GNU アセンブラと GNU リンカを使うように指示するには、 コンフィギュレーション時に ‘--with-gnu-as --with-gnu-ld’ を 指定すれば良い。これらは、COFF 形式のオブジェクトファイルと実行形式 ファイルを生成する。GNU アセンブラとリンカを使わない場合は、 GNU CC はインストールされているツールを使い、‘a.out’ 形式の 実行形式ファイルを生成する。

m32r-*-elf

三菱 M32R プロセッサ。 このコンフィギュレーションは組み込みシステム用である。

m68000-hp-bsd

BSD Unix が動作する HP 9000 シリーズ 200 である。 このシステム付属の C コンパイラでは GNU CC をコンパイルできないことに 注意。ブートストラップ用の GNU CC のバイナリを入手するには law@cygnus.com に連絡して欲しい。

m68k-altos

Altos 3068 である。GNU アセンブラ、GNU リンカ、GNU デバッガを 使わなければならない。詳細は、‘README.ALTOS’ というファイルを 参照すること。

m68k-apple-aux

A/UX が稼働する Apple の Macintosh である。 GCC をコンフィギュレーションするのに、システムのアセンブラとリンカを 使っても良いし、GNU のアセンブラとリンカを使っても良い。 出来れば GNU のものを使うべきである。特に GNU C++ も使いたい場合は。 GNU のアセンブラとリンカを使うコンフィギュレーションにするには、 configure にオプション ‘--with-gnu-as’ と ‘--with-gnu-ld’ を追加すれば良い。

システムに付属の C コンパイラでは GNU CC をコンパイルできないことに注意 して欲しい。GNU CC をブートストラップするには jagubox.gsfc.nasa.gov にあるバイナリを使うことができる。 また、同じところにあるパッチを当てたバージョンの ‘/bin/ld’ を 使うと、もともとのバージョンにある手前勝手な制限値をいくらか 上げることができる。

m68k-att-sysv

AT&T 3b1、別名 7300 PC である。この機種で、標準の C コンパイラを使って GNU CC をコンパイルするには特別な手順が必要である。これは標準の コンパイラのバグのせいである。GNU CC の以前のバージョンをインストール してあるなら、もっと簡単にブートストラップできる。

GNU CC を 3b1 にインストールするのは、既に動作する GNU CC がないと 困難である。これは、インストール済みの C コンパイラにバグがあるためである。 しかし、以下のような手順でおそらくうまく行くだろう。 我々には、この手順はテスト不可能である。

  1. cccp.c’ の先頭付近の ‘#include "config.h"’ を コメントアウトして、‘make cpp’ を行なう。 これで、GNU cpp の準備版を作る。
  2. 古い ‘/lib/cpp’ を退避し、GNU cpp の準備版をこのファイル名で コピーする。
  3. cccp.c’ の変更を取り消すか、オリジナル版を再インストールし、 もう一度 ‘make cpp’ を行なう。
  4. こうしてできた GNU cpp の最終版を ‘/lib/cpp’ にコピーする。
  5. ファイル ‘tree.c’ に現れる obstack_free を全て _obstack_free に置き換える。
  6. make を実行して、GNU CC のファーストステージを作る。
  7. /lib/cpp’ をオリジナルのものに戻す。
  8. これで、普通の手順で、GNU CC をそれ自身でコンパイルしたり、インストールする ことが可能になった。
m68k-bull-sysv

Bull DPX/2 のシリーズ 200 と 300 で、BOS-2.00.45 から BOS-2.01 を 使っているもの。GNU CC は、システム付属のアセンブラとでも GNU アセンブラとでも使うことができる。configure スクリプトに 対し ‘--with-gnu-as’ を指定することで GNU アセンブラとシステムの COFF 形式の組合せで使うこともできるし、 ‘--with-gnu-as --stabs’ を指定することで GNU アセンブラと DBX 形式を COFF 形式に包み込んだ形との組合せで使うこともできる。 システムアセンブラの問題や DPX/2 用の GAS の入手方法については、 F.Pierresteguy@frcl.bull.fr に問い合わせて欲しい。

m68k-crds-unox

Unos で構築するには ‘configure unos’ とする。

Unos のアセンブラは、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’ を使わないようにすること。そうしておいて、 ステージ 3 のコンパイラは、ステージ 2 コンパイラに ‘-O’ を指定して 作る。こうして出来るステージ 3 のコンパイラは、 他のシステムでの通常のステージ 2 のコンパイラと同じ性格を持つものである。 これを使って、ステージ 4 のコンパイラを作り、ステージ 3 のコンパイラと 比較して、コンパイルが正しく行なわれたかどうかを検査すること。

(恐らく、‘x-crds’ にあるコメントにあるように、単に ‘x-crds’ で ALLOCA を定義すれば、上のパラグラフの話は不要になると 思われる。うまく行った人がいたら、是非とも教えて欲しい。)

Unos は、要求時ページングではなくてメモリセグメンテーションを 使っているので、メモリがたくさん必要になる。他のタスクが走っていなければ、 5Mb でぎりぎり足りる。‘cc1’ をリンクするのに失把したら、 オブジェクトファイルをライブラリに入れたうえで、そのライブラリと リンクしてみて欲しい。

m68k-hp-hpux

HP-UX が動作する HP 9000 シリーズの 300 か 400 である。 HP-UX バージョン 8.0 のアセンブラにはバグがあり、GNU CC を コンパイルできない。このバグを修正するには、HP からパッチ PHCO_4484 を 入手して欲しい。

また、‘--with-gnu-as’ を指定して GAS を使いたい場合には、 GAS のバージョン 2.1 以降と GNU リンカのバージョン 2.1 を使わなければ ならない。初期のバージョンの GAS は、GAS の出力を HP-UX のネイティブ形式に 変換するプログラムに依存していた。だが、そのプログラムが更新されていない のである。GDB は HP-UX のネイティブ形式を理解しないので、GDB を 使いたい場合も GAS を使う必要がある。

m68k-sun

Sun 3 である。デフォルトでは Sun FPA を使うコンフィギュレーションファイル は提供していない。浮動小数点トラップ向けのシグナルハンドラを設定する プログラムは、本質的に FPA と一緒には動作不可能だからである。

Sun のシステムでの GNU CC のインストールに関する情報については、 GNU CC を Sun にインストール を参照のこと。

m88k-*-svr3

AT&T/Unisoft/Motorola V.3 のリファレンスポートが動作する、 モトローラ m88k である。これらのシステムでは、標準の C コンパイラとして Green Hills C リビジョン 1.8.5 が使われることが多い。 このコンパイラには明らかにバグがあり、そのため、ステージ 2 とステージ 3 のオブジェクトファイルが異なるものになってしまう。 そうなった場合、ステージ 4 のコンパイラを作って、ステージ 3 と 比較するようにして欲しい。その結果、ステージ 3 とステージ 4 の オブジェクトファイルが同じであったら、標準の C コンパイラの バグに遭遇した可能性が高い。こうして出来たステージ 3 と ステージ 4 のコンパイラは使えると思う。

だがしかし、ブートストラップするのに一番良いのは、もしあるなら 古いバージョンの GNU CC を使うことである。

m88k-*-dgux

DG/UX の動作するモトローラの m88k である。 DG/UX 上 の 88open BCS のネイティブコンパイラまたはクロスコンパイラを 構築するには、コンフィギュレーション名として ‘m88k-*-dguxbcs’ を 指定し、88open BCS のソフトウェア開発環境で構築を行なう。 DG/UX 上の ELF のネイティブコンパイラまたはクロスコンパイラを 構築するには、‘mm8k-*-dgux’ を指定し、DG/UX ELF 開発環境で 構築を行なう。ソフトウェア開発環境を設定するには、 ‘sde-target’ コマンドを使い、引数として ‘m88kbcs’ か ‘m88kdguxelf’ を指定する。

コンフィギュレーション名を指定しないと、 ‘configure’ が、現在のソフトウェア開発環境に基づいた コンフィギュレーションを推測する。

m88k-tektronix-sysv3

UTekV 3.2e の動作する Tektronix XD88 である。 バグの多い Green Hills のコンパイラでブートストラップを 行なうときは、ステージ 1 を作るとき最適化を行なわないこと。 また、付属の LAI System V NFS もバグが多いので、NFS マウント されたディレクトリで構築する場合は、一回リブートしてから 行なうこと。あるいは、NFS は全く使わないほうが良いだろう。 さもないと、ステージ間の比較で問題が起きる可能性がある。

mips-mips-bsd

MIPS のオペレーティングシステムを BSD モードで実行している MIPS のマシンである。このシステムの古いバージョンには、 memcpymemcmpmemset といった関数が ないものがある。読者のシステムにこれらの関数がない場合は、 ‘mips-bsd.h’ 中の TARGET_MEM_FUNCTIONS の定義を 削除するか未定義にする必要がある。

MIPS の C コンパイラは、switch 文用の表の大きさを ‘-Wf,-XNg1500’ オプションで増加させておかないと、 ‘cp/parse.c’ をコンパイルできないと言われている。 最適化オプション ‘-O2’ を使うには、‘-Olimit 3000’ も 必要である。この二つのオプションは両方とも、‘configure’ が 作る ‘Makefile’ には自動的に追加される。 make の変数 CC を上書きして MIPS のコンパイラを使うには、 ‘-Wf,-XNg1500 -Olimit 3000’ を追加する必要がある。

mips-mips-riscos*

MIPS の C コンパイラは、switch 文用の表の大きさを ‘-Wf,-XNg1500’ オプションで増加させておかないと、 ‘cp/parse.c’ をコンパイルできないと言われている。 最適化オプション ‘-O2’ を使うには、‘-Olimit 3000’ も 必要である。この二つのオプションは両方とも、‘configure’ が 作る ‘Makefile’ には自動的に追加される。 make の変数 CC を上書きして MIPS のコンパイラを使うには、 ‘-Wf,-XNg1500 -Olimit 3000’ を追加する必要がある。

RISC-OS の動作する MIPS のマシンでは、4つの異なる個性を サポートする。デフォルトと BSD 4.3、System V.3、System V.4 である。 (RISC-OS の古いバージョンでは V.4 はサポートしていない)。 これらのプラットフォーム用に GCC をコンフィギュレーションするには、 次のコンフィギュレーションを使う。

mips-mips-riscosrev

リビジョン rev の RISC-OS 用のデフォルトのコンフィギュレーション。

mips-mips-riscosrevbsd

リビジョン rev の RISC-OS 用の BSD 4.3 のコンフィギュレーション。

mips-mips-riscosrevsysv4

リビジョン rev の RISC-OS 用の System V.4 のコンフィギュレーション。

mips-mips-riscosrevsysv

リビジョン rev の RISC-OS 用の System V.3 のコンフィギュレーション。

ここでリビジョン rev は、RISC-OS のリビジョンである。 RISC-OS のリビジョン 4 から リビジョン 5 に移るときは GCC を再コンフィギュレーションしなければならない。 これは、リンカの バグ(詳細については GCC のインストール時の問題) を回避する効果がある。

mips-sgi-*

SGI IRIX 4 で GCC をコンパイルするには、Silicon Graphics 提供の CD-ROM から "c.hdr.lib" というオプションをインストールする必要がある。 これは、リリース 4.0.1 の二枚目の CD に入っている。

SGI IRIX 5 で GCC をコンパイルするには、Silicon Graphics 提供の IDO CD-ROM から "compiler_dev.hdr" というサブシステを インストールする必要がある。

IRIX 5 では、CFLAGS に ‘-save-temps’ を追加しないと、 make compare に失敗する。このシステムでは、アセンブラに対する 入力ファイル名がオブジェクトファイルに格納されるので、 そのファイル名が stage1stage2 で違っていると オブジェクトファイルの比較に失敗する。オプション ‘-save-temps’ を 指定すると、アセンブラに対する入力ファイル名として、 ‘/tmp’ に置かれるランダムに選ばれた名前ではなくて、決まった名前を 使う。‘-save-temps’ は、これなしでは比較に失敗するのでない限り、 指定しないこと。これを指定してしまうと、各コンパイル段階の後で ‘.i’ ファイルと ‘.s’ ファイルを自分で削除しなければ ならなくなる。

MIPS の C コンパイラの場合は、switch 文用の表の大きさを ‘-Wf,-XNg1500’ というオプションを指定することで大きくしておかないと ‘cp/parse.c’ がコンパイルできないと報告されている。 最適化オプション ‘-O2’ を指定するときは、 ‘-Olimit 3000’ も指定する必要がある。 このどちらのオプションも、シェルスクリプト ‘configure’ が作る ‘Makefile’ では自動的に生成される。 make の変数 CC を 上書きして、MIPS のコンパイラを使うときは、‘-Wf,-XNg1500 -Olimit 3000’ というオプションを指定する必要がある。

Irix のバージョン 4.0.5F、それに多分その他のバージョンでも同じだが、 アセンブラにバグがあり、命令の並べ替えが正しく行なわれない。 これを回避するには、ターゲットのコニフィギュレーションを ‘mips-sgi-irix4loser’ と指定する。このコンフィギュレーションは、 アセンブラによる最適化を抑止する。

ターゲット ‘mips-sgi-irix4’ でコンフィギュレーションした場合は、 アセンブラの最適化は ‘-noasmopt’ オプションで抑止できる。 このオプションはアセンブラには ‘-O0’ として渡り、命令の 並べ替えを行なわない。

-noasmopt’ オプションを使うと、問題がアセンブラによる命令並べ替えに 間違っているために起きるかどうかを調べることができる。 ‘-noasmopt’ を指定しても問題がなくならない場合でも、 なおアセンブラによる命令並べ替えの問題のせいである可能性がある。 この問題のために、GNU CC 自体が正しくコンパイルされていない 恐れがある。

Irix 5 でデバッグを出来るようにするためには、GNU as の 2.5 以降を 使わなければならず、gcc をコンフィギュレーションするときに configure の オプションに ‘--with-gnu-as’ を指定しなければならない。 GNU as は、binutils パッケージの一部として配布されている。

mips-sony-sysv

Sony MIPS NEWS である。これは NEWSOS 5.0.1 ではうまくいくが、 5.0.2 ではうまくいかない(5.0.2 では COFF ではなく ELF が使われている)。 5.0.2 は恐らくボランティアの手ですぐにサポートされるだろう。 特に、共有ライブラリをリンクするときに GCC で生成されたコードを リンカが嫌う。

ns32k-encore

Encore ns32000 システムである。Encore システムは BSD の場合のみサポート されている。

ns32k-*-genix

National Semiconductor の ns32000 システムである。 Genix の allocamalloc にはバグがあるので、 GNU Emacs からコンパイル済みの版を取ってきて使う必要がある。

ns32k-sequent

コンパイルを行なう前に Berkley 宇宙に移行する。

ns32k-utek

UTEX の ns32000 システム(“merlin”) である。 システム付属の C コンパイラでは GNU CC をコンパイルできない。 ‘tektronix!reed!mason’ に連絡を取って、 ブートストラップに必要な GNU CC のバイナリを入手して欲しい。

romp-*-aos
romp-*-mach

IBM RT PC をサポートしている OS は、AOS と MACH だけである。 GNU CC は RT 上の AIX をサポートしていない。 GNU CC をコンパイルするには、GNU CC 自体の古いバージョンlを使うことを お勧めする。Metaware のコンパイラである hc でコンパイルするのは、 一応動作するが、ステージ 2 とステージ 3 のオブジェクトの比較で、 色々なファイルが一致しないだろう。これらの問題は、幾つかの浮動小数点 定数のわずかな差異によるもので、安心して無視できるものである。 ステージ 3 のコンパイラが正しいものである。

rs6000-*-aix
powerpc-*-aix

IBM XLC コンパイラの各リリースの色々な初期バージョンでは、GNU CC の ブートストラップができない。症状としては、stage2 と stage3 の オブジェクトファイルの差異と、‘libgcc.a’ あるいは ‘enquire’ を コンパイルするときのエラーがある。問題があることが判明している リリースは以下の通り。xlc-1.2.1.8、xlc-1.3.0.0 (AIX3.2.5 と共に配布されている)、xlc-1.3.0.19 である。 xlc-1.2.1.28 と xlc-1.3.0.24 (PTF 432238) はどちらも正しく動作する GNU CC を生成できることがわかっているが、より最近のリリースの方が GNU CC を正しくブートストラップできる。

リリース 4.3.0 の AIX と AIX 3.2.4 以前のリリースに含まれる IBM の アセンブラは、 デバッグ情報疑似命令を受け付けない。このアセンブラに対する修正は PTF として入手可能である。 さらに、AIX 3.2.5 以降および GNU アセンブラを使う場合は、 GNU C コンパイラを構築するためには、1995年10月16日以降に修正された バージョンの GNU アセンブラが必要である。 以上の問題の詳細については ‘README.RS6000’ というファイルを参照のこと。

GNU CC は、まだ 64ビットの PowerPC 命令をサポートしていない。

このアーキテクチャでは Objective C は動作しない。 呼び出し規約と互換性のない仮定をしているからである。

RS/6000 上の AIX では、合衆国以外の環境をサポートしている(NLS)。 コンパイラとアセンブラは NLS を使って、浮動小数点数(浮動小数「点」として 「.」と「,」のどちらを使うか)を含む様々なオブジェクトのロケール固有の 表現をサポートしている。GNU CC でリンクしたライブラリが、 アセンブラが受け付けるのと同じ浮動小数点形式を生成しないという 問題が報告されている。この問題に出会ったら、環境変数 LANG を "C" か "En_US" に設定してみて欲しい。

AIX 4.1 用では、GNU CC がバインダ(リンカ)を起動する方法が変わったので、 リンク時に、以前は出なかった、シンボルが二重定義されているという警告が でるかもしれない。AIX 用の GNU CC で生成されたアセンブリファイルは、 元のプログラムに存在する、ある種のグローバル変数と関数の宣言について、 シンボルの複数定義を含んでいる。警告が出ても、リンカは 正しいライブラリや実行可能な実行形式を生成するはずである。

デフォルトでは、AIX 4.1 は Power でも PowerPC でも使えるコードを 生成する。

-mcpu=cpu_type オプションに対するデフォルトを configure のオプション ‘--with-cpu-cpu_type オプションで 指定することができる。

powerpc-*-elf
powerpc-*-sysv4

System V.4 の動作する、ビッグエンディアンモードのPowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトを configure のオプション ‘--with-cpu-cpu_type オプションで 指定することができる。

powerpc-*-linux-gnu

Linux ベースの GNU システムの動作する、ビッグエンディアンモードの PowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトを configure のオプション ‘--with-cpu-cpu_type オプションで 指定することができる。

powerpc-*-eabiaix

-mcall-aix がデフォルトで選択された、ビッグエンディアンモードの 組み込み PowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトを configure のオプション ‘--with-cpu-cpu_type オプションで 指定することができる。

powerpc-*-eabisim

PSIM シミュレータの下で動作させるのに使われる、ビッグエンディアンモードの 組み込み PowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトを configure のオプション ‘--with-cpu-cpu_type オプションで 指定することができる。

powerpc-*-eabi

ビッグエンディアンモードの組み込み PowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトを configure のオプション ‘--with-cpu-cpu_type オプションで 指定することができる。

powerpcle-*-elf
powerpcle-*-sysv4

System V.4 の動作する、リトルエンディアンモードのPowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトを configure のオプション ‘--with-cpu-cpu_type オプションで 指定することができる。

powerpcle-*-solaris2*

Solaris 2.5.1 以降の動作する、リトルエンディアンモードの PowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトを configure のオプション ‘--with-cpu-cpu_type オプションで 指定することができる。 Sun 4.0 コンパイラのベータ版では GNU CC を正しく構築できないようだ。 また、ホストアセンブラとリンカにも問題がある。この問題は GNU 版でこれらのツールを置き換えることで対処できる。

powerpcle-*-eabisim

PSIM シミュレータの下で動作させるのに使われる、リトルエンディアンモードの 組み込み PowerPC システム。

powerpcle-*-eabi

リトルエンディアンモードの組み込み PowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトを configure のオプション ‘--with-cpu-cpu_type オプションで 指定することができる。

powerpcle-*-winnt
powerpcle-*-pe

Windows NT の動作する、リトルエンディアンモードの PowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトを configure のオプション ‘--with-cpu-cpu_type オプションで 指定することができる。

vax-dec-ultrix

Vax C(vcc) でコンパイルしてはいけない。 (例えば、alloca が使われた場合に)正しくないコードを 生成することがある。

一方、pcc で ‘cp/parse.c’ をコンパイルするのは、pcc の内部 テーブルの大きさの制限のため、うまくいかない。 この問題を避けるには、GNU C コンパイラだけをまずコンパイルし、 それを使って、必要な全ての言語フロントエンドを再コンパイルするのが良い。

sparc-sun-*

Sun のシステムでの GNU CC のインストールに関する情報については、 GNU CC を Sun にインストール を参照のこと。

vax-dec-vms

VMS への GNU CC のインストール方法の詳細については、 GNU CC を VMS にインストール を参照のこと。

we32k-*-*

この計算機は、3b2、3b5、3b20、その他類似の名前でも知られている。 (ただし、3b1 は実際には 68000 である。GNU CC でサポートしているコンフィギュレーション 参照。)

システムのコンパイラでコンパイルするときは ‘-g’ を使わないこと。 システムのリンカが、デバッグ情報がついた、このような大きなプログラム 扱えないようである。

システムのコンパイラは、GNU CC の ‘stmt.c’ をコンパイルするときに、 能力を越えてしまう。これを回避するには、GNU CC にある ‘cpp’ を まず構築し、システムのプリプロセッサの代わりに、システムの C コンパイラ と組み合わせて ‘stmt.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"

C++ コンパイラを構築するには ULIMIT の設定を上げる必要が あるかもしれない。出来上がった ‘cc1puls’ は、1メガバイトを 越えるので。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated using texi2html 1.78.