[Users] networkドライバganiのテスター募集

[ISHIKAWA,chiaki]

はじめまして、すでに解決されているかもしれませんが、

> ***
> *   Your source tree contains these files:
> *         /home/atsushi/src/mozilla-release/Makefile
> *         /home/atsushi/src/mozilla-release/config/autoconf.mk
> *   This indicates that you previously built in the source tree.
> *   A source tree build can confuse the separate objdir build.
> *
> *   To clean up the source tree:
> *     1. cd /home/atsushi/src/mozilla-release
> *     2. gmake distclean
> ***
> *** Fix above errors and then restart with
> "/usr/bin/python2.7
> /home/atsushi/src/mozilla-release/build/pymake/pymake/../make.py -f
> client.mk build"

にあるように、ソースツリーの中で
make distclean

gamke distclean

を行ってから再度実行されてみたらどうでしょうか？（だめなときには、再度ソースを
インストールして、きれいなままで実行する。）

mozconfigで、MOZ_OBJDIRは明示して設定されていますか？
実行例だと、
> Adding client.mk options from /home/atsushi/src/mozilla-release/.mozconfig:
>    MOZ_OBJDIR=$(TOPSRCDIR)/../obj-$(CONFIG_GUESS)

が見えるので多少気になります。

私の手元のThunderbirdをlinuxでコンパイルしているときの例です。
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-tb3

私のthunderbirdの経験ですが、
以前最初気づかずに、ソースとオブジェクトを同じディレクトリにしてしまい
makeなどを実行してから上と同様の警告に出会い、make distclean をしても
どうもうまく動作せず、結局もういちどソースを再度インストールしなおしてから、
mozconfigの内容でMOZ_OBJDIRを別のところに設定するようにから無事先にすすめるように
なりました。
（たぶん当時は、make distclean しても正しい状態にもどっていなかった。いまでも
make distcleanで、上のような環境設定の誤りによる正しくないリンクなどが１００％戻る保証はないと
思います。そこまでmozillaのテストは行き届いてないというのが私の体験からの判断。
トップレベルでmakeを実行すると、どう考えても不要な再度のコンパイルなどが実行されてしまうのが
新規の開発は行わないと明言しているthunderbirdの側では現実に起こっています。
開発の中心となるfirefoxの側はもっとまともなのかもしれません。）

>firefoxの公式MLで質問すべきでしょうけれど、何か英語・日本語ともに乱立しているような・・・適当な場所が見つかりませんでし
た・・・

Firefoxの公式ＭＬというのはdev-*@lists.mozilla.orgのことですか？
（公式のＭＬが乱立というのは初耳でした。）

OSとしてのSolarisはメイン(tier-1)のサポートの対象となっていません。現在たぶん以前と
変更がなければSunじゃないOracleの中国のチームがSolarisのThunderbird/Firefoxのメインテナンスをしていると思いました(tier-3
の対象として）。運がよければその人たちがメイルをみてなにか投稿してくれるかもしれません。
 2009年のmozilla.dev.platform ニュースグループ（たしかdev-platform ＠ lists.mozilla.orgの記事が流れている）に
次のような記事がありました。
> 
>> * As suggested by Mark Banner(bugzilla ＠ standard8.plus.com), we probably should add OpenSolaris platform as a
>> tier_2_platform on page https://developer.mozilla.org/en/Supported_build_configurations , so that developers in
>> community can be easier to find out if their commit broken the code tree on Solaris platform,and contact the proper
>> developers quickly like Ginn.chen ＠ sun.com, alfred.peng ＠ sun.com. I think that would be very helpful for peoples
>> focus on OpenSolaris.


上のWEBページがいつ更新されたか不明ですが、あいかわらずtier-3の対象としてsun.comのメイルアドレスが二つでています。

とりあえず、MOZ_OBJDIRを明示して設定して、make distclean (gmake distclean)をしてチャレンジしてみる。
だめなら、MOZ_OBJDIRをどこかにセーブしておいて、再度きれいなソースを
いれなおして、再度MOZ_OBJDIRを明示して設定してチャレンジする。
といったところでしょうか。

dtraceが使える(open)solaris環境は, 性能のチューニングとか、どこで無駄な時間を食っているかのチェックに
良いとおもうのですが、なかなか手元でのコンパイルのハードルが高いせいかあまりそういった目的で使われてないようで
残念です。私ももう少し手元ＰＣにメモリをつめれば、仮想環境でlinuxに加えて　solarisを走らせてthunderbirdをそちらでも
コンパイルしようと思いましたが、thundirbird のリンク時に仮想メモリを大量に利用するために,
もうsolaris側でのコンパイルはあきらめました。（他の小さなプログラムのテストにはsolarisの利用はポータビリティのチェックと
かPOSIX準拠のＡＰＩチェックに使えました。linuxのシステムコールがおかしなところがあり、solaris側と挙動が違うことで
問題がはっかくしました。）

thunderbird/firefoxのビルドではlinux側でも32bitの仮想記憶を使い尽くす（つまり３ＧＢをこえたメモリを
利用しようとする）ということで32-bit バージョンのlinuxでは、コンパイルリンクに支障があり、ビルドは64-bit linuxに移行する
というアナウンスがつい先日出ています。（手元のＰＣには８ＧＢしか積めない　:-( )
solarisは最初から６４ビットなのでその意味では問題はすくないでしょう。（ですが、GNU ld, goldというリンカーが巨大な
バイナリのリンクには推奨されています。実はこれを使うと32-bit linuxでも無事リンクできます。また仮想記憶の利用が少ないの
で、かなりリンク時間が短縮されます。thundirbirdUNIXのフィロソフィーを破って、ひとつのバイナリでいろいろなことをしようと
しているのでこんな大きなバイナリになってしまい、そのために問題を抱えているということもできるでしょうね。）


ちなみにコンパイラは　GCCをお使いですか、Sun のコンパイラですか？　ソースの変更というのが気になりました。

石川