Building SpiderMonkey

Use these instructions to build the latest SpiderMonkey source code.

Before you begin, make sure you have the right build tools for your computer: Linux, Windows, Mac, others. When building a version older than 28, you'll additionally need NSPR.

And of course, you'll need to get the SpiderMonkey source code.

Non-developer (optimized) build

Use these steps if you want to install SpiderMonkey for production use or run performance benchmarks. (If you want to use SpiderMonkey as a library in your C++ application, or work on improving SpiderMonkey itself, do a developer/debug build instead, as described below.)

cd js/src

# This name should end with "_OPT.OBJ" to make the version control system ignore it.
mkdir build_OPT.OBJ
cd build_OPT.OBJ
/bin/sh ../configure.in
# Use "mozmake" on Windows
make

A few notes about this:

• The most common build problems are dependency problems. See the build prerequisites page for your platform.

• SpiderMonkey does not support building in your source directory. You must configure and build in a separate build directory, as shown above.

CC=clang CXX=clang++  ../configure

/usr/local/Cellar/llvm/7.0.1/lib/clang/7.0.1/include/inttypes.h:30:15: fatal error: 'inttypes.h' file not found

/usr/local/Cellar/llvm/7.0.1/lib/clang/7.0.1/include/inttypes.h:30:15: fatal error: 'inttypes.h' file not found, err: true

open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pk

This builds an executable named js in the directory build-release/dist/bin. You can test it with dist/bin/js --help, which displays a help page. At this point, you're ready to run and try out the shell.

On Mac, Linux, or UNIX, you can install SpiderMonkey on your system with the additional command make install. This installs the shared library to /usr/local/lib, the C header files to /usr/local/include, and the js executable to/usr/local/bin.

Developer (debug) build

For developing and debugging SpiderMonkey itself, it is best to have both a debug build (for everyday debugging) and an optimized build (for performance testing), in separate build directories. Thus, in addition to following the steps above, you should also create a debug build using these steps:

cd js/src

# This name should end with "_DBG.OBJ" to make the version control system ignore it.
mkdir build_DBG.OBJ
cd build_DBG.OBJ
/bin/sh ../configure.in --enable-debug --disable-optimize
# Use "mozmake" on Windows
make

You can also build debug builds of SpiderMonkey with the JS_GC_ZEAL option, which adds a new built-in function to SpiderMonkey that lets you configure zealous garbage collection.  This can help debug memory leaks and other memory-related problems. See JS_SetGCZeal() for details.

For a list of other available build options, type (assuming the current working directory is one of the above-created build directories):

/bin/sh ../configure.in --help

Generating a Compilation Database

Some tools (like IDEs, static analyzers and refactoring tools) consume a file called compile_commands.json which contains a description of all the pieces required to build a piece of software so that tools don't have to also understand a build system.

To generate a compile_commands.json with the SpiderMonkey configure script, enable the CompileDB backend, like this:

/bin/sh ../configure.in <options> --enable-build-backends=CompileDB,RecursiveMake

(RecursiveMake is there as you'd likely also want to be able to build!)

Windows Builds

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:

/bin/sh ../configure.in --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:

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.

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
...
$

Cross-compiling options

For cross-compiling you will need a cross-compiling compiler. That tends to be easier with clang as clang has cross-compiling support built in. You may need other libraries though.  For example on debian linux you'll need the following to cross compile from x86_64 to x86.

apt install clang libstdc++-8-dev-i386-cross binutils-i686-gnu zlib1g-dev:i386

You'll also need rust, in addition to having normal rust set up you'll need to add another target to your existing rust toolchain (don't add a new toolchain spidermonkey will use only one toolchain and use it for both host and target code:

rustup target add i686-unknown-linux-gnu

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 -mfpmath=sse -msse -msse2" CXX="g++ -m32 -mfpmath=sse -msse -msse2" AR=ar \
$SRC/configure --target=i686-pc-linux

Or for clang.

$SRC/configure --target=i686-pc-linux-gnu

To build a 32-bit arm version on a 64-bit Linux system, that runs in the arm simulator, you can use the following:

   AR=ar CC="gcc -m32 -mfpmath=sse -msse -msse2" CXX="g++ -m32 -mfpmath=sse -msse -msse2" \
    $SRC/configure --target=i686-pc-linux --enable-simulator=arm

To build a 32-bit version on a 64-bit Mac system (the target version is specific to your OS/X SDK), you can use the following:

$SRC/configure --target=i386-apple-darwin16.7.0 # Choose the appropriate SDK version for your version of OS/X

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 the js-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 your js-config.h header or js-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