クロスコンパイラ環境を構築する一番やさしい方法は、バイナリをダウンロードしてくることです。 Linux/i386 用のビッグエンディアンターゲット向けのパッケージは次のものです。
binutils-mips-linux-2.8.1-1.i386.rpm egcs-c++-mips-linux-1.1.2-2.i386.rpm egcs-g77-mips-linux-1.1.2-2.i386.rpm egcs-libstdc++-mips-linux-2.9.0-2.i386.rpm egcs-mips-linux-1.1.2-2.i386.rpm egcs-objc-mips-linux-1.1.2-2.i386.rpm
そして、次がリトルエンディアン向けのパッケージのリストです。
binutils-mipsel-linux-2.8.1-1.i386.rpm egcs-c++-mipsel-linux-1.1.2-2.i386.rpm egcs-g77-mipsel-linux-1.1.2-2.i386.rpm egcs-libstdc++-mipsel-linux-2.9.0-2.i386.rpm egcs-mipsel-linux-1.1.2-2.i386.rpm egcs-objc-mipsel-linux-1.1.2-2.i386.rpm
64-bit MIPS カーネル向けには、現在一つのパッケージのみが入手できます。
egcs-mips64-linux-1.1.2-2.i386.rpmこのコンパイラはビッグエンディアン向けです。これは現在 64-bit カーネルをサポートしたリトルエンディアンのマシンがないためです。 リトルエンディアン向けのコンパイラも需要がでてくれば提供されるでしょう。
これらの全部をインストールする必要はなく、殆どの人は C++、Objective C と Fortran 77 の各コンパイラは省略してよいでしょう。 Intel 版のバイナリは GNU libc 2.1 にリンクされているので、 アップグレードする際にはこれもインストールする必要があるでしょう。
egcs 1.1.2 より古いコンパイラは、 生成するコードにバグがあるため、カーネルのコンパイル用としてはもうサポートされていません。 現時点では、もうだいぶ経っていますが、まだ binutils 2.8.1 をお勧めします。
最初に次のソースパッケージをダウンロードしてきてください。
また、上記のものが現在お勧めのバージョンです。 古いバージョンは動くかどうか分かりません。 もし古いバージョンを使おうと頑張っているということでしたら、バグレポートは送らないでください。 どちらにせよ見ませんので。また、インストールする際には、binutils、egcs、 glibc の順に行ってください。古いバージョンが既に入っている場合を除いては、 この順番を変えると うまくいきません。
インストール時にファイル群をインストールする先のディレクトリを選択しなければなりません。 以下ではそのディレクトリを <prefix> と呼ぶことにします。 特定の条件で発生するような問題を避けるため、<prefix> の値はそのマシンの本来の gcc と同じ値にするのが最良です。 例えば gcc が /usr/bin/gcc としてインストールされているなら、<prefix> として /usr を選んでください。 これからインストールしようとしているパッケージすべてに対して、同じ <prefix> を用いる必要があります。
コンパイル中には、binutils には約 31MB のディスクの空きが必要です。 また、インストールするためには <prefix> のあるパーティションに 7MB の空きが必要です。egcs の作成には 71MB が、インストールには 14MB が必要です。 GNU libc はコンパイルに 149MB の空きが、そしてインストールには 33MB が必要です。注意してほしいのは、これは単なる目安だということです。 異なるプロセッサやオペレーティングシステムやコンパイラオプションによって大きく異なるかもしれません。
MIPS アーキテクチャの特徴的な機能の一つには、R8000 を除くすべてのプロセッサでは、設定によってビッグエンディアンとリトルエンディアンのどちらででも 動作可能であることが挙げられます。 バイトオーダとは、メモリ中にプロセッサが複数のバイトを格納するやり方です。 ビッグエンディアンのマシンでは、最大の桁側のバイト値が最小のアドレス位置に格納されます。 リトルエンディアンのマシンでは、これが最大のアドレス位置に格納されます。 複数の数字からなる数を左から右に書くか、逆順で書くかの違いだ、と考えてください。 クロスコンパイラ環境を正しく設定するためには、クロスコンパイラのターゲットとなるマシンのバイトオーダを知らなければなりません。 この内容を既に知っているのでなければ、マシンのバイトオーダについて ハードウェアプラットフォーム の節を参照してください。
autoconf を使うパッケージの多くは、様々なアーキテクチャとオペレーティングシステムをサポートしています。 これら多くの設定を区別するため、名前が <cpu>-<company>-<os> や <cpu>-<company>-<kernel>-<os> のように付けられています。この表現を使えば、Linux/MIPS の設定の名前は ビッグエンディアン向けには mips-unknown-linux-gnu で、リトルエンディアン向けには mipsel-unknown-linux-gnu です。この二つの名前は多少長いため、順に mips-linux と mipsel-linux という省略形が許されています。 クロスコンパイル時の各パッケージのインストールでは、全パッケージに同じ名前を 使わなければいけません。 また、他の名前、例えば mips-sni-linux や mipsel-sni-linux も正しい設定名ですが、mips-linux と mipsel-linux のほうを使ってください。 これらの名前は Linux カーネルソースなどの他のパッケージでも使っていますので、 上記の二つ以外のものを使うとクロスコンパイル時に変更を行う必要が出てきます。
以下ではターゲットの設定に使う名前は <target> と呼びます。
ここは最初の、最もやさしい部分です (少なくとも多少は真っ当な UNIX 系の OS 上でインストールしようとしている場合には、ですが)。 十分な空き容量のあるディレクトリに cd して、次の処理を行ってください。
gzip -cd binutils-<version>.tar.gz | tar xf - cd binutils-<version> patch -p1 < ../binutils-<version>-mips.patch ./configure --prefix=<prefix> --target=<target> make CFLAGS=-O2 make installこれで通常は正しく動作します。但し、GCC 2.7.x をコンパイラに使っている一部のマシンではコアダンプすることが知られています。 これは GCC の既知のバグで、ホストマシンのコンパイラを GCC 2.8.1 以降のものにすることで修正できます。
一部の人たちの環境には古い assert.h ヘッダファイルがインストールされています。 これはおそらく古いクロスコンパイル環境の残骸だと思いますが、このファイルが残っていると autoconf はなにも言わずに失敗します。 Assert.h が必要になることはなく、これは昔の版の GCC のバグのためにインストールされたものです。 <prefix>/<target>/include/assert.h があなたのインストール環境にないか、チェックしてください。 もしあるなら、単に消してください。 これはどの版のクロスコンパイル環境でもインストールされるべきでは決してありませんし、トラブルの元にもなります。
カーネルソースのインストールは簡単です。 単にお好みのどこかのディレクトリに置き、設定するだけです。設定は必ず行ってください。 というのは、その過程で作成されるファイルが、インストールされるからです。 設定の最後のほうで CONFIG_CROSSCOMPILE を有効にすることを忘れないでください。 引っかかる可能性のある問題は、場合によると bash のような GNU プログラムのインストールが必要になるかもしれないこと、また PATH 環境変数を直して、ベンダの提供したものではなく GNU 版のプログラムが先に呼ばれるようにしなければならないかもしれない、という二点だけです。 インストール後に、直接 <prefix>/<target>/include に行って二個のシンボリックリンク、asm と linux を include/asm と include/linux を指すように作成してください。 この作業は、次のステップ中に必要なヘッダファイルが見つかるようにするために、やっておかなければなりません。
さて、ここからが難所になります。いわゆるブートストラップ (ニワトリと卵) 問題のためです。今回の場合、egcs のインストールには glibc があらかじめインストールされている必要がありますが、まだ動作するクロスコンパイラができていないので glibc のコンパイルができないのです。 ありがたいことに、これを突破する必要があるのは、クロスコンパイラを作る最初の一回だけです。 この後 glibc をインストールし終えたら、物事はずっとスムーズに行きます。 では、行きましょう。
gzip -cd egcs-1.1.2.tar.gz | tar xf - cd egcs-<version> patch -p1 < ../egcs-1.1.2-mips.patch ./configure --prefix=<prefix> --with-newlib --target=<target> make SUBDIRS="libiberty texinfo gcc" ALL_TARGET_MODULES= \ CONFIGURE_TARGET_MODULES= INSTALL_TARGET_MODULES= LANGUAGES="c"慎重に、gcov、protoize、unprotoize とライブラリは作らないように進めます。 Gcov はクロスコンパイラ環境では意味をなしませんし、protoize と unprotoize は gcc の makefile のバグのため、既存の自マシン用のプログラムを上書きしてしまうかもしれません。 最後に、ライブラリは glibc がまだインストールされていないため、作成できません。 すべてうまくいったなら、次のようにインストールしてください。
make SUBDIRS="libiberty texinfo gcc" INSTALL_TARGET_MODULES= \ LANGUAGES="c" installカーネルを作成するためのクロスコンパイラがほしいだけなら、ここで終了です。 libc のクロスコンパイルは、ユーザアプリケーションをクロスコンパイルするためだけに必要になります。
ここまでやってきたことが実際正しく動作するかを確認するには、この時点でカーネルをコンパイルしてみればよいでしょう。 MIPS カーネルソースのディレクトリに cd して、`make clean; make dep; make'' と打ってみてください。 すべて問題ないなら、``make clean'' を行って再度ソースをきれいにしておいてください。
注意:glibc 2.0.6 を egcs 1.0.3a より新しいコンパイラでコンパイルするのは お薦めできません。一部のプログラムが、 バイナリの互換性問題にあたってしまうかもしれませんので。egcs 1.0.3a を使うか、公開されているバイナリパッケージを使うことを勧めます。 また、GNU libc をクロスコンパイルするのは常に次善の方法です、 というのはクロスコンパイル時にはコンパイルされない部分があるからです。 適切なやり方が見つかって安定性が確認されしだい、ここでそのやり方を文書化したいと思います。 それでは、注意が済みましたので、レシピを。
gzip -cd glibc-2.0.6.tar.gz | tar xf - cd glibc-2.0.6 gzip -cd glibc-crypt-2.0.6.tar.gz | tar xf - gzip -cd glibc-localedata-2.0.6.tar.gz | tar xf - gzip -cd glibc-linuxthreads-2.0.6.tar.gz | tar xf - patch -p1 < ../glibc-2.0.6-mips.patch mkdir build cd build CC=<target>-gcc BUILD_CC=gcc AR=<target>-ar RANLIB=<target>-ranlib \ ../configure --prefix=/usr --host=<target> \ --enable-add-ons=crypt,linuxthreads,localedata --enable-profile makeこれでコンパイル済みの GNU libc ができましたが、まだインストールする必要があります。 ここで単に make install と 打ってはいけません。 これをやるとホストマシンのシステムファイルが Linux/MIPS 向けのファイルに置き換わって、破壊的な結果になります。 そうではなく、GNU libc のインストールをどこか他の任意のディレクトリ <somedir> に一旦インストールして、そこからクロスコンパイルに必要になる部品を実際のターゲットディレクトリに移動します。
make install_root=<somedir> installここで、<somedir> に cd して、最後に GNU libc を手動でインストールします。
cd usr/include find . -print | cpio -pumd <prefix>/<target>/include cd ../../lib find . -print | cpio -pumd <prefix>/<target>/lib cd ../usr/lib find . -print | cpio -pumd <prefix>/<target>/libGNU libc には詳しいオンラインドキュメントが含まれています。 あなたのシステムには既にこのドキュメントのどれかの版が含まれているでしょうから、もし info ページをインストールしたくない場合 (1MB 弱節約できます) や、既にインストールされている場合には、次の手順を飛ばしてください。
cd ../info gzip -9 *.info* find . -name \*.info\* -print | cpio -pumd <prefix>/infoブートストラップしない人は、ここでインストールはおしまいです。
最初の egcs の作成は GNU libc が無いため途中で止まっていました。今は libc もインストールしてあるので、ここで egcs の再作成を行えます。 今回はクロスコンパイラとして完全なインストールができます。
gzip -cd egcs-<version>.tar.gz | tar xf - cd egcs-<version> patch -p1 < ../egcs-1.1.2-mips.patch ./configure --prefix=<prefix> --target=<target> make LANGUAGES="c c++ objective-c f77"見たとおり、手順は最初の時と殆ど同じですが、今回は --with-newlib オプションは落とします。このオプションは libgcc のビルドが libc が無いことで落ちるのを防ぐために必要でした。インストールは次のようにします。
make LANGUAGES="c c++ objective-c f77" installさて、殆ど完了です。もし Objective C や F77 コンパイラが不要なら、上記のコマンドから省くことができます。各々 3MB 位の節約になります。gcov、protoize と unprotoize は作成しないでください。
この答えは、クロスコンパイラ環境の目的に大きく依存します。 もしあなたが Linux カーネルを再作成することだけを考えているなら、何もかものセットアップを進める必要はなく、Objective C と F77 コンパイラは省いても問題ないでしょう。但し、C++ コンパイラを作成する必要はあります。これは egcs ディストリビューションに含まれるライブラリを作成するには C++ が必要なためです。
float.h のインストールはもう必要ありません。egcs 1.0.3a の頃から自動的に適切な float.h ヘッダファイルが作成され、インストールされるようになっています。
Origin 200 で IRIX 6.5.1 を走らせている場合、Linux カーネルソースから “make depend” を実行するとクラッシュすることがあります。 Indy 上の IRIX 6.5 と Origin 200 の IRIX 6.5.4 は動くことが分かっています。
System V 系の Unix システム、例えば IRIX や Solaris には子プロセスに渡せる引数の個数に制限があり、この制限を Linux カーネルや GNU libc のクロスコンパイル時に超えてしまうことがあります。 IRIX システムでは引数のリストの最大長の既定値は 20KB ですが、Linux では少なくとも 128KB はあります。このサイズは root から `systune ncargs 131072'' コマンドを使って変更できます。
GDB をクロスデバッガとして作成することに興味を持つのは、カーネル開発者だけでしょう。 カーネル開発者にとっては、GDB は命綱かもしれません。 このようなリモートデバッグの設定はいつも二つの部分、あるマシン上で動く GDB リモートデバッガと、デバッグ対象の Linux/MIPS カーネルの動くターゲットマシン、 からなります。この二台のマシン間は通常シリアルラインで接続されています。 ターゲットマシンのカーネルには『デバッグ用のはめ込みプラグ』を備えておき、 リモートシリアルプロトコルを用いる GDB ホストマシンと通信できるようにしておく必要があります。
ターゲットのアーキテクチャに依存しますが、おそらく『デバッグ用のはめ込みプラグ』は自分で作り込む必要があります。 一般的に言って、シリアルライン用のとても簡単なルーチンを作る必要があるだけです。 この作業は、殆どのマシンが通常 8250 や 16450 相当品 を用いたよく似たシリアルハードウェアを用いているため、更に簡単なものとなっています。
【訳注: 8250 と 16450 は殆ど同じ。16550 はソフトウェア上位互換で、PC-AT 用のシリアルとして使われているもの。】