Your Search Results

    SpiderMonkey Build Documentation

    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 on non-POSIX platforms, such as Windows, or 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 build

    Use these steps if you just want to install SpiderMonkey or use it as a library. (If you want to work on improving SpiderMonkey itself, use the developer build below.)

    cd js/src
    autoconf-2.13
    ./configure
    make
    

    Note that autoconf version 2.13 is required. No later version will work. The MozillaBuild package for Windows includes autoconf 2.13.

    Note: If you are on Mac and getting an error similar to

    "checking whether the C compiler (gcc-4.2  ) works... no

    configure: error: installation or configuration problem: C compiler cannot create executables."

    You can try configuring like so:

    CC=clang CXX=clang++  ./configure

    This builds an executable named js in the current directory. You can test it with ./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 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.

    cd js/src
    autoconf-2.13
    
    mkdir build-release
    cd build-release
    ../configure
    make
    cd ..
    
    mkdir build-debug
    cd build-debug
    ../configure --enable-debug --disable-optimize
    make
    
    Note:  If you previously did the easy build, you must first delete all the files and directories it created. If you don't, the advanced build will fail with error messages about not being able to open dependency files.

    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:

    ./configure --help
    

    Threadsafe 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 you're compiling an older version of SpiderMonkey.

    SpiderMonkey can be compiled to take advantage of threading. While JavaScript itself is not multi-threaded, SpiderMonkey can have per-thread JavaScript instances, and it can also perform some garbage collection and JIT compilation work off-thread. Until version 28, compiling a threadsafe build required NSPR on all platforms. Right now, this is only the case for Windows.

    Because SpiderMonkey uses newer symbols in NSPR, using an NSPR that ships with your operating system usually does not work. The workaround for this is to build NSPR locally, and explicitly tell configure where to find NSPR. For example, assuming your local NSPR has been installed to /usr/local/nspr:

        --enable-threadsafe \
        --with-nspr-cflags="-I/usr/local/nspr/include/nspr" \
        --with-nspr-libs="/usr/local/nspr/lib/libnspr4.a /usr/local/nspr/lib/libplds4.a /usr/local/nspr/lib/libplc4.a"

    Alternately, you can try:
        --enable-threadsafe \
        --with-system-nspr \
        --with-nspr-prefix=/usr/local/nspr

    If you are on Linux, and get symbol loading or dynamic library errors, you can force the correct NSPR to load with:

       export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/path/to/nspr/lib"

    Similarly on Mac OS X,
          export DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/path/to/nspr/lib"

    NSPR on Windows

    On Windows, nspr-config returns incorrect values, so you must give the compiler and linker flags directly. Assuming that NSPR has been installed in C:\mozilla-build\msys\local, using MozillaBuild, the following commands will build NSPR on Windows:

    # Configure
    ./configure \
       --with-nspr-cflags="-IC:/mozilla-build/msys/local/include" \
       --with-nspr-libs=" \
          C:/mozilla-build/msys/local/lib/libnspr4.lib \
          C:/mozilla-build/msys/local/lib/libplds4.lib \
          C:/mozilla-build/msys/local/lib/libplc4.lib"
    
    # Build
    make.py
    
    # Run. The NSPR dlls need to be available on the PATH.
    # "-- help" displays a help page.
    PATH="$PATH;C:/mozilla-build/msys/local/lib/" ./js --help

    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.

    Note: All directories 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 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
    
    Note: You must have started your MozillaBuild shell with the proper -x64.bat script in order for the 64-bit compilers to be in your PATH.

    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.

    Note: In SpiderMonkey 1.8.5, the js-config script is not generated properly on many platforms. If the instructions below do not work, you can try this workaround.

    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 -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 -L/usr/local/lib -lmozjs -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm  -lm -ldl

    Testing SpiderMonkey

    The commands below assume you're using the advanced build.

    • Run ./js ../Y.js and check if appropriate output is printed.

    • Run the main test suite by running ../tests/jstests.py ./js

    • Run JIT-specific tests by running: ../jit-test/jit_test.py ./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: LinuxWindowsMacothers.

    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
    

    Document Tags and Contributors

    Contributors to this page: Jorend
    Last updated by: Jorend,