GCC 3.0 のインストール

GCC 3.0 と gdb 5.0 をインストールした。

GCC は、configure 時に、--prefix でインストール先のディレクトリを指定したほうがよい。 そうしないと、/usr/local の下にインストールされてしまうので、 万が一、インストールに失敗した場合、今まで動いていた環境が失われてしまう可能性がある。

ところが、--prefix 指定で /usr/local/gcc-3.0 とすべきところを、単に、 gcc-3.0 にしてしまい、make で失敗するはめに。 おかしいなあ。以前は、相対指定でもよかったような記憶があるのだが。 2時間ほどを無駄にしたあと、エラーメッセージから推測して、 --prefix の相対指定に問題がありそうなことに思いいたり、解決。 せっかくなので、インストールまでの流れを記録しておこう。

  % cd ~/archive
  % ftp ftp.dti.ad.jp
  ftp> cd pub/lang/egcs/releases/gcc-3.0
  ftp> bin
  ftp> get gcc-3.0.tar.bz2
  ftp> quit
  % cd ~/work
  % tar xIvf ~/archives/gcc-3.0.tar.bz2
  % cd gcc-3.0
  % mkdir build
  % cd build
  % ../configure --prefix=/usr/local/gcc-3.0
  % make bootstrap
  % su
  # make install 

（2002-07-02 注記） 以前は、

    # mv /usr/local/bin/gcc /usr/local/bin/gcc-old
    # ln -s /usr/local/gcc-3.0/bin/gcc /usr/local/bin/gcc
    # (以下、主なコマンドについて繰り返す)   

のように /usr/local/bin の下からシンボリックリンクを張っていたのだが、 これでは

さて、ソースをコンパイルして、出来た実行ファイル動かそうとしたら、次のようなエラーが。

  debug/dicttest: error in loading shared libraries: libstdc++.so.3: \
  cannot open shared object file: No such file or directory

どうやら、共有ライブラリも新しくなったようだ。 てっきり、/usr/local/lib の下に置けばよいと思ったのだが、それではダメみたい。 しかたがないので、/usr/lib の下から /usr/local/gcc-3.0/lib の下にあるライブラリにリンクを張ったが、こんな安易な解決法でよいのだろうか??

  # cd /usr/lib
  # foreach x (/usr/local/gcc-3.0/lib/*) 
  foreach? ln -s $x
  foreach? end  

ということになってしまうので、マズい。次のように PATH に /usr/local/gcc-3.0/bin を追加すべきである。 そうすれば、勝手に /usr/local/gcc-3.0/lib の下のライブラリを使ってくれるようである。

インストールが完了したら、コマンドサーチパスに、 gcc-3.0 バイナリがコピーされたディレクトリを追加してやる。

  % setenv PATH /usr/local/gcc-3.0/bin:$PATH
  % rehash  

これで gcc や g++ は、めでたく 3.0 になった。

  % gcc -v
  Reading specs from /usr/local/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.0/specs
  Configured with: ../configure --prefix=/usr/local/gcc-3.0
  Thread model: single
  gcc version 3.0   

しかし、私のマシン (P3 450MHz) では、フルビルドに1時間以上かかる。 どうせ Fortran とか Java は使わないんだから、次回は、 configure で、--enable-languages=c,c++ も指定したほうがよいな。

（2002-07-02 注記） あと、gcc によって作成されたプログラムにライブラリを静的にリンクするのではなく、 実行時に共有ライブラリを使うようにしたければ、--enable-shared を指定する。

また、マルチスレッドをサポートしたければ、--enable-threads を指定する。

  % ../configure --prefix=/usr/local/gcc-3.1 --enable-languages=c,c++ --enable-shared --enable-threads

次は gdb 5.0 である。新しい gcc で作成した実行ファイルは、当然ながらと言うべきか、 既存の gdb では扱えなくなってしまった。実行ファイルを読み込んだとたん、gdb が core dump してお亡くなりになってしまう。gdb のバージョンが古いためか (4.18 を使っていた)、あるいは、新しいコンパイラでビルドし直せばよいのか。 まあ、せっかくなので、最新の (と思われる) gdb をインストールすることにした。

gcc と同じミラーサイトにあった、ftp://ftp.dti.ad.jp/pub/GNU/gdb/gdb-5.0.tar.gz をダウンロード。こちらは、展開してできたディレクトリ上で、

  % ./configure
  % make
  % su
  # make install  

で、ビルド & インストールが終了。実に簡単なものである。

よい機会なので、ついでに STLport 4.0 もインストールすることにした。g++ 標準の STL では、たとえば、strstream などがサポートされていないのだが、こいつならサポートされていると思ったからだ。 ドキュメントによれば、4.0 から、SGI製の iostream ライブラリが付いているらしい。 しかも、こいつは、たいていのコンパイラに標準で添付されている iostream よりも高速だという。これはインストールせずにはおかれまい。

ライブラリは、使用しているシステムに合わせてビルドする必要がある。見ると、 いろんなシステム向けの makefile が用意されている。私の場合は、どうやら、 gcc.mak を使えばよいようだ。ということで、早速、make -f gcc.mak。 結果、

もしやと思い、g++ を 2.95.2 に戻したら、すんなりビルド完了。

どうも、g++ 3.0 になって、std 名前空間の扱いが変更されたことが災いしているようだ。 つまり、以前の g++ では、std:: で修飾しなくても、cout とか string とか vector とかが使えたのだが、 3.0 では、using 宣言をするなり、std:: 修飾をするなりしないと 使えなくなった ―― 要するに、

―― のである。ということで、STLport のインストールは、あっさりあきらめ。

とはいえ、g++ を古いバージョンに戻す気はない。STLport もいずれ対応するだろうし。 何といっても、std の扱いがまともになったのは大きい。 これが変だったせいで、VC++ などに移植するときに、どれだけ苦労したことやら。 あと、先日書いた、「using を使ってベースクラスのメンバ関数をインポートする」 というのも確認。C++ なんて、もはや恐竜のような言語になってしまい、 あとはゆっくり死んで行くだけかと思っていたが、 こうして着実にサポートされているのを見ると、本当にうれしくなっちゃいます。

初出: 2001年7月7日

C++ ラビリンスの目次へ