- Mozilla ビルドプラットフォームはどのシステムでサポートされていますか？
- Mozilla ビルド "サポート" には複数のレベルまたは段階があります。
第 1 段階のプラットフォームは開発のプライマリーフォーカスであるプラットフォームが該当します。これらのプラットフォーム上での主要な問題はショーストッパーによって重んじられます。これらはまた SeaMonkey tinderbox ページに現れるプラットフォームです。
- linux/x86 (gcc)
- win32/x86 (msvc)
- OS X (gcc)
第 2 段階のプラットフォームは積極的にメンテナンスしようとしている開発者と貢献者の小さく変化しているサブセットのプラットフォームです。しかし全体の開発はこれらのプラットフォーム上での問題のために停止しません。これらのプラットフォームは大抵、SeaMonkey-Ports tinderbox ページに Ports として参照されます。 第 2 段階のプラットフォームは：
- aix 4.3 (aCC)
- beos 5.0.3 (gcc)
- bsdi 4.x (gcc)
- hpux 10.x,11.x (HP cc)
- irix 6.x/gcc (gcc/MIPSpro)
- linux/ppc (gcc)
- os/2 (gcc)
- osf1 5.x (Compaq cc)
- solaris (sparc & x86) 2.6+ (gcc/Forte)
第 3 段階のプラットフォームは全体的にプロジェクトの主要な開発者が活動的でないプラットフォームですが修正がサードパーティによってもたらされています。 第 3 段階のプラットフォームは：
- freebsd (gcc)
- linux/alpha (gcc)
- netbsd (gcc)
- openvms (?)
- ps2linux (gcc)
- qnx 6 (gcc)
- win32/x86 (gcc)
その他の全てのプラットフォームは主要な mozilla 開発者によって "サポート外" です。"サポート外" は本当に "重要でなく活動的でないもの" を意味します。
ほとんどの Mozilla 開発者は第 1 段階以外のプラットフォームにアクセスしません。なので第 1 段階以外のプラットフォームに対するどんなバグも問題の原因と適切な解決策を定めバグのオーナーを助ける情報で満ちているべきです。あなたがパッチもしくは開発者のパッチがあなたのプラットフォームで動作することを立証するものを準備しているなら、それはあなたのバグを修正しツリーにチェックするのを大変、助けるでしょう。
- Mozilla はどんなタイプのビルドシステムを使いますか？
- Mozilla は全てのプラットフォーム上で動作が弱弱しい GNU 設定レイヤーに加えて再帰的なレガシー Netscape makefile ビルドシステムを使います。ほとんどの設定ベースのプロジェクトのように、設定スクリプトを生成するために GNU autoconf を使います。GNU make はビルド過程を進めるのに使われます。
- なぜ GNU make を使うのですか？
- GNU make は多くのシステムへ移植されています。これは Mozilla をこれらのシステムに少し簡単に移植します。10 の異なったプラットフォームで特有の make プログラムによってサポートされている make 機能の唯一のサブセットを使うことはビルドシステムに不必要なコンパイルを引き起こすでしょう。
- make のその他のバージョンで動作しますか？
- いいえ。Mozilla makefile は GNU make でのみ動作する特有の機能を使っています。
- なぜあなた方は automake を使わないのですか？
- Netscape レガシーシステムの一部は GNU make の使用を必要としています -それらを使うのを必要としている Makefile の少数のファイルから共通のルールセットを含む機能を含んでいます。この中心のルールシステムで、主要な automake のセリングポイントの 1 つは重要度が低いものでした。また当時、Mozilla のビルドライブラリの方式はライブツールと調和していませんでした。
- nmake と CodeWarrior ビルドシステムで何が起こりますか？
- それらは現在のツリーで長く存在しません。nmake ビルドサポートは Mozilla 1.2a リリースサイクルの間に中止されました。mac cfm ビルドシステムは Mozilla 1.3 リリース後、すぐの OS9 サポートと共に中止されました。
- なぜ ant、tmake、scons または あなたの好みのビルドシステムをここに挿入してください？
- 主に、Mozilla をこれらのシステムで実行する人がいなかったからです。Mozilla が最初にオープンソースにされた時、それはただレガシー Netscape システムを含むだけでした。autoconf レイヤーはunix ビルドで標準ビルドシステムになる前、 6 ヶ月間でブランチへの追加とメンテナンスが並行して行われました。
- 私の気に入ったビルドシステムで Mozilla を実行する場合、 Mozilla はそれを使って起動しますか？私はそれを使うかどうかで私の時間を無駄にしたくない。
- Mozilla に書かれたどんなコードもデフォルトツリーに受け入れられるという保証はありません。実行されたどんなビルドシステムもそれが現在のビルドシステムよりも全体的に良いことを示さなければなりません。速さ、適応性、ポータビリティそして現在のビルドシステムで 3 年以上の経験がある開発者の大きなグループに簡単に新しいシステムに移ってもらう能力が切り替えを決める中で主要な要因になります。あなたが本気でかつ、多くの仕事をするのをいとわないのであれば、あなたの提案の詳細を話し合うために en:User:Benjamin Smedberg にコンタクトを取ってください。
- なぜ Mozilla は autoconf 2.5x をサポートしないのですか？
- 単に、autoconf 2.5x は、アップグレードを努力してみる価値があるようにする何も提供しません。 Autoconf 2.5x は autoconf 2.13 との共存へ戻れず、更に制限は autoconf の新しいバージョンが不確かな増加のために Mozilla ビルドシステムの重大な書き直しを要求することによって引き起こされます。
サブ設定のための引数を通すための能力のように 2.13 機能のいくつかは 2.5x で利用できません。人々は好意的な返答無しに autoconf メーリングリストでこれらの機能について繰り返し尋ねてきました。Mozilla (NSPR & LDAP) のサブプロジェクトの設定の書き直しは受け入れることのできない取引です。サブプロジェクトはまた独立したプロジェクトでビルドシステムの相反が馬鹿げているせいで全体のコードベースが分岐しています。
- なぜ NSS は autoconf を使わないのですか？
- NSS プロジェクトはまた Mozilla プロジェクトの外で使われており、NSS プロジェクトのメンバーは autoconf へ移行することはコスト価値があることとは感じませんでした。詳細は{{ Bug(52990) }}を見てください。
- 1 つのソースツリーから多様な Mozilla ベースのプロジェクトをビルドしても良いですか？
- はい！それぞれのプロジェクトでそれ自身のオブジェクトディレクトリでビルドされなければなりません。
- オブジェクトディレクトリとは何ですか？
- オブジェクトディレクトリビルドはソースのある場所と異なった場所に出力されたファイルを作るプロセスを適用します。これは、ほとんどの設定ベースのプロジェクトの標準的な機能です。それはネットワークファイルシステムを使うなら多様なプラットフォームを含む多様な設定のために 1 つのソースツリーからビルドするのを許します。あなたのツリー中のファイルがビルドプロセスによって変更されなかったことを知るには、ソースツリーを汚すのを避けます。
もし手動で設定を実行したなら、ディスク上の適当な場所に空のディレクトリを作りそのディレクトリに移ってそこから /path/to/mozilla/configure を実行するという標準的な方法を使うことができます。
mkdir obj-debug
cd obj-debug
../mozilla/configure
ビルドするのに client.mk を使ったなら、mozconfig ファイルを以下のように追加できます：
mk_add_options MOZ_OBJDIR=/path/to/objdir
- Mozilla をクロスコンパイルして良いですか？
- はい、詳細については Mozilla クロスコンパイルドキュメントを見てください。いいえ、カナダ英語クロスコンパイルはサポートされていません。
- How can I test out a build of just certain files, instead of the whole tree, while I'm changing code? 私がコードを変更している間に全体のツリーの代わりに特定のファイルだけをテストするにはどうすれば良いですか？
- あなたのオブジェクトディレクトリを変更してください、ビルドしたい特定のディレクトリ（オブジェクトディレクトリのディレクトリ構造はソースディレクトリの構造と合致します）に入れ替えてください、そして "make" （必要ならばまたは "gmake"）とタイプしてください。これはただ "Makefile" （ソースツリーの同等のディレクトリは "Makefile.in" に含まれるでしょう）が含まれているディレクトリを見つけた時にのみ動作します。それよりもよりはっきりと得たいならば、"make <ファイル名>.obj" をしてみることが出来ます。Incremental Build をご覧ください。
- Mozilla への並列 (make -j) ビルドは動作しますか？
- はい。最適な処理についての入り口は GNU Make 並列実行マニュアルを見てください。
並列ビルド（特に可能な限り並列で多くのタスクを実行するために -jN の代わりに -j を使っている時）を使っている時に不明瞭なビルドエラーが出る場合、N の減少による並列タスク数を減らしてみてください（または無制限の並列処理を使った場合、小さい数字 N を -j に追加してください）。
-j4 と -j8 を並列ビルドで用いるとよく動作するようです。
- ビルドシステムに私の mozconfig ファイルへの変更を集めるよう強いるにはどうすれば良いですか？
- ツリー中の設定スクリプトに接してください。mozconfig ファイルは MOZCONFIG 環境変数によってどこにでも存在でき、ファイル上に明白な依存物はありません
- error: file '../../toolkit/locales/en-US/chrome/necko/contents.rdf' doesn't exist at ../../config/make-jars.pl line 418, <STDIN> line 9.
- あなたは Configuring Build Options 上の説明に従わずに Firefox をビルドしようとしています。特に、あなたの mozcconfig ファイルは Firefox をデフォルトの mozconfig ファイルで調達しなければなりません：
. $topsrcdir/browser/config/mozconfig
# ここに好みの追加オプションを追加してください
- Initial cvs checkout fails with the message:
cvs {{ mediawiki.external('checkout aborted') }}: *PANIC* administration files missing
- "CVS" という名前のディレクトリの元に cvs ツリーを作ることはできません。これは cvs の機能/バグです。cvs は特定の管理ファイルを CVS ディレクトリで見つけ、それらが行方不明である場合には不満を言うでしょう。
- Error: ../coreconf/rules.mk:406: target `c' doesn't match the target pattern
- make 3.80 が必要で 3.81 のようなその他のバージョンは必要ありません。
- make 3.80 は長く Cygwin セットアップインストーラで利用されていません。なのであなた自身でそれを見つけなければなりません。make-3.80-1.tar.bz2 と google でき、それはまたここから入手できます。
- Mozilla をビルドするための Microsoft Visual Studio プロジェクトファイルはありますか？
- いいえ。cygwin と GNU make を使わなければなりません。
- cmd.exe からビルドコマンドを実行しても良いでしょうか？
- はい。Make はコマンドを実行するために cygwin /bin/sh サブシェルを呼びます。なので何のシェルが make を呼ぶのに使われるかは重要ではありません。
- cygwin の autoconf パッケージのどのバージョンが使うのに必要でしょうか？
- autoconf 2.1x と 2.5x が相反するせいで、cygwin 維持管理者たちは autoconf 設定スクリプトが必要としているバージョンを決定しその autoconf のバージョンを呼ぶラッパースクリプトを書きました。autoconf(-wrapper) & autoconf-stable パッケージが必要です。詳細については http://cygwin.com/ml/cygwin-announce.../msg00177.html を見てください。
- Microsoft ツール（CL, LINK, RC）が file not found エラーを示す
- INCLUDE と LIB 環境変数は Microsoft Visual C++ ツールによって使われます。それらは大抵 vcvars32.bat でセットアップされます。あなたのビルドしたモジュールに依存しているなら、MFC と ATL が必要かもしれませんし必要ないかもしれません。下のは Visual C++ が "C:\msvs": にインストールされている場合に動作するパスです。
set INCLUDE=C:\msvs\VC\Include;C:\msvs\VC\ATLMFC\Include
set LIB=C:\msvs\VC\Lib;C:\msvs\VC98\ATLMFC\Lib
- cvs update: authorization failed: server XXXX rejected access -- used empty password; try "cvs login" with a real password
- wincvs と cygwin cvs が混じっています。どちらか一方だけを使ってください。
- cvs {{ mediawiki.external('checkout aborted') }}: cannot rename file CVS/Entries.Backup to CVS/Entries: Permission denied
- cygwin 1.3.13 で、ntsec はデフォルトで有効です。ntsec はもっと Windows NT のセキュリティ機能をベースにしたパーミッションのような UNIX を得るための cygwin の試みです。そのエラーメッセージは cygwin の /etc/passwd ファイルにリストされた unix パーミッションと Windows NT によって使われるそれらとの間にマッピング不一致があることを指し示しています。回避方法として、あなたの CYGWIN 環境変数に "nontsec" を追加することができます。適切な修正はマッピング問題を修正することです。
- Make が a command not found error, or about not being able to find a .dtd file と吐く
- 多分、ソースアーカイブを解凍するのに WinZIP を使っています。それを使わないでください。デフォルトで WinZIP は tar.gz アーカイブから 0 長のファイルを解凍しません。他のユーティリティを使うか、または WinZIP が展開しなかったファイルをチェックアウトするのに pull スクリプトを使ってください。
- nsinstall または他のネイティブ Win32 プログラムが a file not being found とエラーを出す
- Running the mount command should return something similar to: あなたの cygwin マウントテーブルをチェックしてください。マウントコマンドを実行することは以下によく似たことを返すはずです：
c: on /cygdrive/c type user (binmode,noumount)
e: on /cygdrive/e type user (binmode,noumount)
c:\cygwin on / type system (binmode)
c:\cygwin\bin on /usr/bin type system (binmode)
c:\cygwin\lib on /usr/lib type system (binmode)
ビルドシステムは動かしているパーティションが prefix を動かすと /cygdrive を使ってマウントされることを期待しています。c: または e: が prefix を動かす時なければ、その後、これらのドライブを使って Mozilla を使うことはできません。コマンドを使うことによって期待されたスポットで手動でマウントする必要があります：
mount -s "e:\" /cygdrive/e
あなたのソースツリーが $HOME 以下ならば、マウントモードは binmode (UNIX スタイルラインエンジン）であるべきです。そうでなければビルドは多くのファイルを腐敗させるのに十分な失敗をするでしょう。ソースツリーが $HOME の外にあるなら、マウントモードはあなたのソースエディタが Unix スタイルラインエンジンを認める以上問題ではありません。
- アクセス違反で xpidl.exe がクラッシュする
- これはコンパイラと glib と libIDL ライブラリまたは glib か libIDL ライブラリの間で食い違っているせいでいつも発生します。
あなたが Visual Studio .NET でビルドしているのであれば、その時に glib と libIDL DLL の VC7 ビルトバージョンに対してリンクを張らなければなりません。Visual Studio .NET 2003 のために VC 7.1 バージョンを使ってください。Visual Studio 2005 に対しては VC8 バージョンを使ってください。
あなたのコンパイラのため特有のこれらのライブラリのバージョンを含んでいるディレクトリはどんなこれらのライブラリのバージョンの前に PATH になければなりません。.dll と .lib ファイルは実行できるようでなければ（chmod 755）cygwin はそれらをロードしないでしょう。
VC7 とそれ以降のビルドについてのより多くの Tips については Windows ビルド要件を見てください。
またたくさんの代わりの静的ライブラリが {{ Bug(242870) }} でコンパイラの特定のライブラリの代わりに使えるかもしれません。
VC6 を使っているのであれば、その時に VC7 ライブラリをビルドタイムまたはランタイムで使って いない ことを確かめなければなりません。
- configure: error: the midl major version, , does not match the compiler suite version, <Visual C++ バージョン番号> -- same for linker
- シンボリックリンクのための cygwin ツール "link.exe" がオブジェクトリンカーを Microsoft コンパイラスイーツと間違えているか、midl がそれぞれ見つけられていない。Microsoft ツールが PATH で cygwin よりも前にあるか確かめるか（説明を見てください）、/bin/link.exe をリネームするか削除してください。シェルが起動した時に cygwin が PATH を修正するかもしれないことに注意してください、そして cygwin シェルの
export も見てください。
- configure: error: installation or configuration problem: C compiler cannot create executables.
- あなたの PATH 変数が全ての必要なディレクトリを含んでいるか確かめてみてください。MS Visual Studio を使っているならば、vcvar32.bat を実行してください（PATH, LIB, そして INCLUDE 変数を設定します）。ビルド環境が変化しているならば、config.cache ファイル（mozilla またはオブジェクトディレクトリで）を削除しビルドし直す必要があります。
- build error: ../coreconf/rules.mk:365: target `c' doesn't match the target pattern
- cygwin インストーラから make 3.81 が使用されています。make 3.80 を使わなければなりません。説明を読んでください。
- fatal error LNK1112: module machine type 'IA64' conflicts with target machine type 'X86'
- PATH, LIB, そして INCLUDE 変数でディレクトリ命令を変えてみてください。他の "win64" またはより終端に近い "IA64" （または "AMD64"）を含むディレクトリに移動してください。
- LINK : fatal error LNK1104: cannot open file 'atlthunk.lib'
- この Microsoft フォーラムスレッドによると、フリープラットフォームソフトウェア開発キット (PSDK) 内の Active Template Library (ATL) は Visual Studio 内のと異なるバージョンです。Visual Studio ATL は 32 ビットも 64 ビットも両方サポートして atlthunk.lib を要求しないのに PSDK 内の ATL は 32 ビットコードをサポートしておらず 64 ビットのみをサポートしています。見たところ、Visual C++ ツールキットと Visual Studio Express に含まれている atlthunk.lib ファイルは利用できず 自由に利用できるツール からビルドできません。ATL のそれらのバージョンを使うには Visual Studio を完全なバージョンにアップグレードするか、次の方法で atlbase.h （PSDK ディレクトリ下の \include\atl）のいくつかのコードを変更することによってこの問題を回避するかどちらか一方をすることが出来ます。
--- atlbase.h.old 2006-06-08 08:20:26.671875000 -0400
+++ atlbase.h 2006-06-08 08:13:26.578125000 -0400
@@ -283,7 +283,7 @@
}
};
#pragma pack(pop)
-
+/*
PVOID __stdcall __AllocStdCallThunk(VOID);
VOID __stdcall __FreeStdCallThunk(PVOID);
@@ -291,6 +291,11 @@
#define FreeStdCallThunk(p) __FreeStdCallThunk(p)
#pragma comment(lib, "atlthunk.lib")
+*/
+
+// workaround for not having atlthunk.lib in PSDK or VC++ 2005 Express Edition
+#define AllocStdCallThunk() HeapAlloc(GetProcessHeap(),0,sizeof(_stdcallthunk))
+#define FreeStdCallThunk(p) HeapFree(GetProcessHeap(), 0, p)
#elif defined (_M_AMD64)
#pragma pack(push,2)
私はまたコンパイラにこの変更を反映するためにオブジェクトディレクトリを削除して一からコンパイルする必要がありました。
- cygwin と VS 6.0 で実行ファイルをコンパイルまたはビルドするときの結果 FIND: Parameter format not correct と出る
- System32 "find" と cygwin の /usr/bin/find との間で混乱が生じています。望ましい find は cygwin の方のです。これは Path の整理によって生じます。2,3 の解決法が利用できます：
- 一時的に system32/find.exe をリネームする。
- system32 path が記入される前に cygwin が記入されていることを確認してください。
- 私はインストーラによって問題なく Firefox をパッケージ化した：
make -C ${OBJ_DIR}/browser/installer installer インストーラは欠けている mozz.dll を要求してインストールが失敗する。
- Thunderbird と Firefox は両方とも --enable-static--disable-shared 設定フラグでコンパイルされるべきです。
- shlibsign.exe - Entry Point Not Found; The procedure entry point CERT_GetFirstEmailAddress could not be located in the dynamic link library nss3.dll.
- あなたの Path でマシン上の nss3.dll の複数からなるインスタンスをしているのかもしれません。このファイルの全てのインスタンスのためにマシン上で検索を実行してください。 ビルド中は別にしてどんなインスタンスも Firefox ビルドツリーの外に移動してください。そしてビルドされる時にそれらを元の名前にリネームしてください。 </dd>
{{ languages( { "en": "en/Mozilla_Build_FAQ", "es": "es/Preguntas_frecuentes_sobre_la_compilaci\u00f3n_de_Mozilla", "fr": "fr/FAQ_sur_la_compilation_de_Mozilla" } ) }}