gccクロスコンパイラの謎

distcc使ってLinux版ビューアのビルド時間を短縮しようと思ったのです。とりあえず、Linux機 (Athlon X2 BE2350 (4150eの同等品) のほかにWindows機 (Athlon X2 4850e) と Mac mini (Core Duo 1.6HGz) があるので。

そこで、Windows (Cygwin) と Mac mini で、gcc のクロスコンパイラをビルドしたのです。このことがあるので、当然 gcc 4.1.2 です。

で、Linuxのオウンコンパイラでビルドしたものと、distcc でコンパイルした結果を比較すると … 一致しません。いや、どちらも起動すると動くのですが、でもバイナリが、そもそもファイルの寸法すら違う。同じバージョンのgccを使っているし、どのプラットフォームでも target=i386-redhat-linux としてビルドしたのに。

いろいろ調べた結果、MacOSで動かしたクロスコンパイラと、Linuxで動くオウンコンパイラは、ファイルの寸法やオブジェクトの size コマンドの結果が一致することがわかりました。問題は Windows 版のクロスコンパイラのようでした。そこで、さらに追求すると、クラスのコンストラクタが、LinuxのオウンコンパイラとMacOS版のクロスコンパイラでは.textセクションに配置されるのですが、Windows版のクロスコンパイラでは.gnu.linkonce.tというセクションに配置されていることがわかりました。これは、GNU ld でリンクする場合には.gnu.linkonce.tに配置されるほうが正統らしいのですが、Linuxのオウンコンパイラがそうしないのだから、クロス側のバグといわざるを得ません。

で、なぜ、こういう差が出るかというと、configure スクリプトが生成する auto-host.h というファイルで HAVE_COMDAT_GROUP というマクロ (定数) が定義されるのですが、LinuxとMacOSではこれが1になるのに、Windows (Cygwin) では0になっているためであることがわかりました。Windowsでの auto-host.h を手で書き直して 1 にすると、めでたく同じ寸法のオブジェクトが作られるようになりました。

とはいえ、これは、何がなんだか、さっぱりわかりません。auto-host.h は、その名の通りホスト環境 (コンパイラが動作するプラットフォーム) の特徴を記録するものです。なぜ、このファイルの内容の違いが、コンパイラが作り出すオブジェクト (本来、これは、ターゲット環境だけに依存するべき) に影響を与えるのでしょうか。

まぁ、今回の目的はgccのコンフィグのデバッグではないので、動けばよし、ということにしてこれ以上追求しないことにしましたが、気持ち悪いです。

std::string

公開SVNレポジトリでは、LLStringからstd::stringへの書き換えが始まっているらしい。

らしい、というのは、私はアクセスしてないからです。メーリングリスト情報でした。

SLをLinux用にコンパイル

タイトルが与える印象と違い、実は先日の記事の後日談です。

このブログでも何回か書いている通り、しばらくSLの開発から離れていて、現在リハビリ中です。この一環で、Linux上で単純にSL Viewerをコンパイルしようとしたら、無数の警告と、よくわからないエラーがでて、ビルドに失敗しました。最初はエラーが出た辺りのソースを調べていたのですがわからず、boostのファイルに原因があると思って調べましたが、それはハズレ。結局正解は、gccのバージョンが原因でした。

1.19 までの SL Viewer は、Linuxではgcc 3.4によるビルドが標準で、gcc 4.x は若干問題あり、という感じでした。私が使っている Fedora も含め多くの Linux のディストリビューションは gcc 4.x が標準になっていたため、1.19 までは、わざわざ gcc 3.4 のバイナリパッケージをインストールして使っていました。それが、1.20 からは gcc 4.x が標準になり、私も 1.20 RC2は、Fedora の標準の gcc でビルドできていた記憶があります。

そのため、今回も Fedora の標準の gcc を使ったのですが、これが問題。実は Fedora 8 の gcc は 4.1 だったのが　Fedora 9 では 4.3 になったのですが、SL Viewer が期待する gcc は 4.1 だったのです。SL Viewer が、というか、SL Viewer が使っている boost が、かも知れません。（実は、きちんと追求していません。）

Fedora には、互換用の gcc 3.4 のパッケージはあっても、gcc 4.1 のパッケージというのは無いようだったので、gcc-4.1.2 のソースを取ってきて自分でビルド。これでSL Viewer がコンパイルできるようになりました。

英語

やっぱ英語できないとだめだね。あーあ。へこむ。

Fedoraのバージョンアップ

えー、

Fedora 8 から 9 にバージョンアップしたら、少々ハマりました。状況と解決方法を書いておきます。

やったこと:

• Fedora 8 (i386) を Fedora 9 (i386) にバージョンアップ。今回は preupgrade を使ってみた。
• そしたら、一見ちゃんとバージョンアップできたっぽかったのだが、カーネルが 2.6.25.9-40.fc8 のまま。あれっと思って yum を起動したら、動かない。「 No module named _sha256」などと言う。
• Google で検索したら、この記事がみつかった。どうやら、世界中で同じ現象が起きているらしい。これは途中から話が脱線して未解決のままだが、基本的にはaprさんの書いているやりかたがよさそう。
• そこで、ftp://rpmfind.net/linux/fedora/updates/9/i386/ から (私は32ビット使ってるので。Athlon 64 だけど。）
  • python-2.5.1-26.fc9.i386.rpm
  • python-fedora-0.2.99.11.1-1.fc9.noarch.rpm
  • python-libs-2.5.1-26.fc9.i386.rpm
  • yum-3.2.16-2.fc9.noarch.rpm
  をダウンロードして、rpm -Uvh *.rpm を実行。
• そしたらエラーが出た。

  error: Failed dependencies:
      python-bugzilla is needed by python-fedora-0.2.99.11.1-1.fc9.noarch
      python-feedparser is needed by python-fedora-0.2.99.11.1-1.fc9.noarch
      python-simplejson is needed by python-fedora-0.2.99.11.1-1.fc9.noarch
      python-sqlalchemy is needed by python-fedora-0.2.99.11.1-1.fc9.noarch

• まぁ、これは想定内だ。近所を探して、上と同じ場所から
  • python-sqlalchemy-0.4.6-1.fc9.noarch.rpm
  を、 ftp://rpmfind.net/linux/fedora/releases/9/Everything/i386/os/Packages/　から
  • python-bugzilla-0.3-1.fc9.noarch.rpm
  • python-feedparser-4.1-3.fc8.noarch.rpm
  • python-simplejson-1.8.1-1.fc9.i386.rpm
  をダウンロードして再度　rpm -Uvh *.rpm。今度はうまくいく。
• yum update とやるが、何も出ない。そこで、yum clean all をやってから、再度 yum update。今度はたくさん出る。242個。これを言われるがままに更新。

以上で、無事に Fedora 9 になった様子です。

その後、例によって NVIDIA のX11ドライバを入れて、バージョンアップ完了。

SL Wiki の翻訳

http://wiki.secondlife.com/wiki/Project:Languages/Meeting_Agendaってのがあるようで、呼ばれました。イマイチわかってないけど、とりあえず出てみるつもりです。

しかし、議論の項目を見ると、半分くらいは去年の秋に SignpostMarv Martin が文句言ってきたときの彼の主張と同じだなー。またあの話の蒸し返しになったらやだなー。