distcc その後の大逆転
こんな ML の痕跡を発見しまして、
もしや？！と思い立って、再度 distccを試してみたところ....おお〜！ distccmon-text が distributed address を表示してるぅ〜(号涙
ということで、アッサリ上手く行っちまいやがりました。今回の一連の騒動は、/tmp にマウントしていた tmpfs に原因があった、と思われます。tmpfs を umount したら、上述の通りです。
ちなみに、試した組み合わせをまとめさせていただきますと、最終的に下記の通りとなります。
| 成否 | tmpfs の有無 | distcc | gcc |
|---|---|---|---|
| X | O | 2.18.3_10 | 4.2.1 20070719 |
| O | X | 〃 | 〃 |
| X | O | 3.1 (野良ビルド) | 〃 |
| 成否 | tmpfs の有無 | distcc | gcc |
|---|---|---|---|
| X | O | 2.18.3_10 | 4.2.1 20070719 |
| O | X | 〃 | 〃 |
| X | O | 3.1 (野良ビルド) | 〃 |
| 成否 | tmpfs の有無 | distcc | gcc |
|---|---|---|---|
| X | X | 2.18.3_10 | 4.2.1 20070719 |
| X | X | 3.1 (野良ビルド) | 〃 |
| X | X | 〃 | 4.3.4 20090405 |
前回は tmpfs を使用していない 8.0-current で失敗しておりましたので、早期発見に繋がりませんでした(8.0-current を常用しようと思っておりましたが、こういう細かいところにまだまだ不具合が在るところがやはり current の成せる技なのか、と思いました)。
やはり、伸縮するディスク、という性質が、それを想定していないコードとの間に問題を発生させているのでしょうか。OS 絡みのコードにはあまり詳しくありませんので、子細はちょっと不明ではありますが、それにしても、さすが extra experimental feature、してやられました。
ただ、私の環境で time を取ったところでは、一時ファイルの収容先を tmpfs に変更するだけで、平均 3割前後のコンパイル時間の短縮に貢献しておりましたので、いささか残念ではあります。
さぁ、これで足の遅いラップトップにもガンガンにインストールできるようになりました。いよいよ swap の ZFS 化と、もろもろの設定、と行きたいところです。
が、しかし、cocelo さまから頂いたコメントにもありますように、buildworld では distcc が発動しませんでした。さらにしかし、buildworld こそ、distcc を使わねばならない工程ですから、せっかく稼働するところまで辿り着きましたので、調査継続です。
