この翻訳は不完全です。英語から この記事を翻訳 してください。
この文書は SpiderMonkey の最新版をソースコードからビルドする方法を解説します。
ビルドを始める前に、必要なツールがインストールされていることを確認してください。Linux, Windows, Mac, その他の環境 での準備は、それぞれのドキュメントをごらんください。28 より古いバージョンのビルドをする際は、NSPR が追加で必要となります。
また SpiderMonkey 最新版のソースコード も必要です。
非開発者向け(最適化)ビルド
SpiderMonkey をただインストールする場合、もしくはライブラリとして使用する場合はこの手順に従ってビルドしてください。SpiderMonkey 自身の開発をされる場合は、以下で説明される開発者向け / デバッグ向けビルドを行ってください。
cd js/src autoconf-2.13 # This name should end with "_OPT.OBJ" to make the version control system ignore it. mkdir build_OPT.OBJ cd build_OPT.OBJ ../configure # Use "mozmake" on Windows make
ビルドには autoconf 2.13 が必要です。2.13 より新しい場合は、動作しません。Windows ではMozillaBuild パッケージに autoconf 2.13 が含まれています。
付記:Mac で以下のようなエラーが発生する場合
"checking whether the C compiler (gcc-4.2 ) works... no
"
configure: error: installation or configuration problem: C compiler cannot create executables.
以下のように設定してください:
CC=clang CXX=clang++ ../configure
この手順でビルドした場合、build-release/dist/bin
に js
という名前で実行ファイルが作成されます。dist/bin/js --help
と help オプションをつけて実行しヘルプを表示させることで、動作確認を行えます。以降の操作に関しては JavaScript シェルの紹介 を参照してください。
Mac、Linux、そしてその他の UNIX では、 make install
を実行することで、ファイルをシステムにインストールできます。シェアードライブラリは /usr/local/lib
に、C のヘッダファイルは/usr/local/include
に、実行ファイルは /usr/local/bin
へそれぞれインストールされます。
開発者向け(デバッグ用)ビルド
SpiderMonkey 自身の開発やデバッグを目的とする場合、日々のデバッグにはデバッグビルドを、パフォーマンステストには最適化ビルドを、それぞれ別のディレクトリで行うことになります。デバッグビルドを行うには、上記の手順に加えて以下の 3 ステップを行います:
cd js/src autoconf-2.13 # This name should end with "_DBG.OBJ" to make the version control system ignore it. mkdir build_DBG.OBJ cd build_DBG.OBJ ../configure --enable-debug --disable-optimize # Use "mozmake" on Windows make
JS_GC_ZEAL
オプションをつけてビルドすると、zealous ガベージコレクションが有効になります。これはメモリリークに代表されるメモリ関連のデバッグを行う時に有用です。詳細は JS_SetGCZeal()
をご覧ください。
この他のビルドオプションについては、上記で作成したビルドディレクトリ内で次のコマンドを実行してください:
../configure --help
Windows Builds
Since version 28, threadsafe builds are the default, and should work out of the box on all POSIX platforms. Hence, the following instructions should only be relevant if you're on Windows or compiling an older version of SpiderMonkey.
The MozillaBuild batch file you used to open your shell (e.g. start-shell-msvc2013.bat
or start-shell-msvc2013-x64.bat
) determines whether the compiler toolchain will target 32-bit or 64-bit builds. To create a 64-bit build, note that you must configure with --target=x86_64-pc-mingw32 --host=x86_64-pc-mingw32
.
Since the POSIX NSPR emulation is not available for Windows, a working version of NSPR must be available to your build. The easiest option is to configure with --enable-nspr-build.
This configure option builds the in-tree version of NSPR which is probably what you want; because SpiderMonkey uses newer NSPR symbols, the NSPR that ships with your operating system probably does not work.
If --enable-nspr-build
does not work, explicitly tell configure
where to find NSPR using the --with-nspr-cflags
and --with-nspr-libs
configure options. For example, assuming your local NSPR has been installed to C:/mozilla-build/msys/local
:
./configure --with-nspr-cflags="-IC:/mozilla-build/msys/local/include" \
--with-nspr-libs="C:/mozilla-build/msys/local
/lib/libnspr4.a \
C:/mozilla-build/msys/local
/lib/libplds4.a \
C:/mozilla-build/msys/local
/lib/libplc4.a"
If you get symbol loading or dynamic library errors, you can force the correct NSPR to load with:
PATH="$PATH;C:/mozilla-build/msys/local/lib/" ./js
Specifying installation directories
make install
puts files in the following directories by default. You can override this by passing options to the configure
script:
What it is | Where it gets put | configure option |
---|---|---|
executables, shell scripts | /usr/local/bin |
--bindir |
libraries, data | /usr/local/lib |
--libdir |
architecture-independent data | /usr/local/share |
--sharedir |
C header files | /usr/local/include |
--includedir |
For convenience, you can pass the configure
script an option of the form --prefix=<PREFIXDIR>
, which substitutes <PREFIXDIR>
for /usr/local
in all the settings above, in one step. This is usually the least troublesome thing to do, as it preserves the typical arrangement of lib
, bin
, and the rest.
configure
are recorded in the generated makefile, so you don't need to specify them again until you re-run configure
.Building SpiderMonkey as a static library
By default, SpiderMonkey builds as a shared library. However, you can build SpiderMonkey as a static library by specifying the --disable-shared-js
flag when you run configure
.
Specifying compilers and compiler flags
If you want to use a compiler other than the one the configure
script chooses for you by default, you can set the CXX
variable in the environment when you run configure
. This will save the values you specify in the generated makefile, so once you've set it, you don't need to do so again until you re-run configure
.
If you'd like to pass certain flags to the compiler, you can set the CXXFLAGS
environment variable when you run configure
. For example, if you're using the GNU toolchain, the following will pass the -g3
flag to the compiler, causing it to emit debug information about macros. Then you can use those macros in gdb
commands:
$ CXXFLAGS=-g3 $SRC/configure ... checking whether the C++ compiler (c++ -g3 ) works... yes ... $
To build a 32-bit version on a 64-bit Linux system, you can use the following:
PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig CC="gcc -m32" CXX="g++ -m32" AR=ar $SRC/configure --target=i686-pc-linux
To build a 64-bit version on a 32-bit Mac system (e.g. Mac OS X 10.5), you can use the following:
AR=ar CC="gcc -m64" CXX="g++ -m64" ../configure --target=x86_64-apple-darwin10.0.0
To build a 64-bit Windows version, you can use the following:
$SRC/configure --host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32
Whatever compiler and flags you pass to configure
are recorded in the generated makefile, so you don't need to specify them again until you re-run configure
.
Building your application
While "How to build your complete application" is clearly out of scope for this document, here are some tips that will help get you on your way:
- The SpiderMonkey developers frequently and deliberately change the JSAPI ABI. You cannot use headers built for one version/configuration of JSAPI to create object files which will be linked against another.
- Support for JS_THREADSAFE was recently removed, and threadsafe builds are now enabled by default.
- The
js-config
script, described below, is the recommended way to determine correct include paths, required libraries, etc. for your embedding to use during compilation. We highly recommend calling thejs-config
script from your embedding's makefile to set your CFLAGS, LDFLAGS, and so forth. - To install SpiderMonkey somewhere other than the default, you must use the
configure
--prefix
option, as described above. Failure to do so may break yourjs-config.h
header orjs-config
script. - Some features detected by the
configure
script do not work for cross-compilation.
Using the js-config script
In addition to the SpiderMonkey libraries, header files, and shell, the SpiderMonkey build also produces a shell script named js-config
which other build systems can use to find out how to compile code using the SpiderMonkey APIs, and how to link with the SpiderMonkey libraries.
When invoked with the --cflags
option, js-config
prints the flags that you should pass to the C compiler when compiling files that use the SpiderMonkey API. These flags ensure the compiler will find the SpiderMonkey header files.
$ ./js-config --cflags # Example output: -I/usr/local/include/js -I/usr/include/nspr
When invoked with the --libs
option, js-config
prints the flags that you should pass to the C compiler when linking an executable or shared library that uses SpiderMonkey. These flags ensure the compiler will find the SpiderMonkey libraries, along with any libraries that SpiderMonkey itself depends upon (like NSPR).
$ ./js-config --libs # Example output: -L/usr/local/lib -lmozjs -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm -lm -ldl
Testing SpiderMonkey
-
Run
${BUILDDIR}/dist/bin/js
Y.js
and check if appropriate output is printed. (It should say:5! is 120
.) -
Run the main test suite by running
./tests/jstests.py ${BUILDDIR}/dist/bin/js
-
Run JIT-specific tests by running:
./jit-test/jit_test.py ${BUILDDIR}/dist/bin/js
Building SpiderMonkey 1.8 or earlier
Use these instructions to build SpiderMonkey from an official source release or from the old CVS repository. To build the latest SpiderMonkey sources from Mercurial, see Building SpiderMonkey above.
SpiderMonkey is easy to build from source if you have the usual Mozilla build prerequisites installed. Before you begin, make sure you have right build tools for your computer: Linux, Windows, Mac, others.
First, download a SpiderMonkey source distribution, such as SpiderMonkey 1.8 Release Candidate 1.
To build, use these commands:
tar xvzf js-1.8.0-rc1.tar.gz cd js/src make -f Makefile.ref
This builds a debug version of SpiderMonkey. All build files are created in a subdirectory named depending on your system (for example,Linux_All_DBG.OBJ
if you are on Linux). To install this build on your system, see SpiderMonkey installation instructions.
To build an optimized (non-debug) version of SpiderMonkey:
make BUILD_OPT=1 -f Makefile.ref
To build a thread-safe version of SpiderMonkey:
make JS_DIST=/full/path/to/directory/containing/nspr JS_THREADSAFE=1 -f Makefile.ref