Mozilla SpiderMonkey is a stable, mature, open-source JavaScript engine, ideal for inclusion in any C/C++ software that requires an integrated scripting language.
This page exists because my primary development environment is MinGW-based, and Mozilla offers no obvious support for building the SpiderMonkey JavaScript engine in a MinGW environment. Despite hours of googling, I found unusually little information on this topic (aside from people asking the same question I was, and receiving no reply).
In the absence of a third-party tutorial, I bit the bullet and spent the time to pour over the SpiderMonkey makefiles and modify them to support building on a Windows platform via MinGW. In the end, it wasn't that difficult, but there were nonobvious pitfalls along the way. I've posted this document online with the hopes of helping others who have the same goals.
This document explains step-by-step how to compile SpiderMonkey v1.7.0 under MinGW using GNU Tools.
It is beyond the scope of this document to describe installing and configuring MinGW from scratch. Nonetheless, if you follow these instructions for configuring MinGW/MSys/Eclipse and the wxWidgets library, everything should go quite smoothly.
From this point on, it is expected that you have a working MinGW and MSys environment, and are able to compile a simple program (as evidence of a correct configuration).
Download all of these:
(Version 4.6.4 seems to be the latest version for which prebuilt Windows binaries are available)
Evidently there is a compiler problem which occurs in GCC v3.X (but should be solved in GCC v4.X). This file has been modified to work around the bug.
First you'll want to choose a base directory. Something like C:\SpiderMonkey or C:\Programming\Mozilla should work nicely. (The build process may not work if there are spaces
in the pathname). Create that directory.
Unzip the Netscape Portable Runtime ZIP files as follows:
nspr-4.6.4_OPT.zip into your base directory.
It should create a folder called nspr-4.6.4.
Rename that folder to nspr-4.6.4_OPT.nspr-4.6.4_DBG.zip into your base directory.
Rename the new nspr-4.6.4 folder to nspr-4.6.4_DBG.nspr-4.6.4_IDG.zip into your base directory.
Rename the new nspr-4.6.4 folder to nspr-4.6.4_IDG.You no longer need the original ZIP files, so store them away or delete them as you see fit.
Move preparePathsForJSBuild.bat and genProxyHeader.bat into your base directory.
Unzip js-1.7.0.tar.gz into your base directory. It should create a folder called js
(if you can't open a tar.gz file, use WinRAR).
Technically, you're done with this GZ file and could delete it, but we'll be overwriting some files soon, and you may
want to have it around in case you ever want to restore the originals.
Now it's time to overwrite those nasty non-MinGW-friendly makefiles with my modified versions. I made some effort to avoid breaking them for other build targets (such as GCC on Linux or even MSVC on Windows), but I was more concerned with getting it working than being super-careful. In other words, don't use these makefiles for building on anything other than MinGW.
Unzip js-1.7.0-MinGW-Makefiles.zip into your base directory. You must overwrite each file when
prompted.
Now for the GCC bug workaround. First, find out what version of GCC you're running by opening MSys and
typing gcc -v. If GCC reports a version number less than 4.0.0, you'll want to overwrite
base\js\src\jsapi.c with the modified version you downloaded above.
If you don't use the replacement file and later get a bunch of compilation errors in
jsapi.c saying initializer element is not constant, then this replacement file should
fix those.
Last but not least, we hammer away at the NSPR headers and libraries to get them into the directory structure expected by the makefiles. I wrote these batch files to create the necessary directories, to generate proxy headers that correctly reference the Debug/Release/IDG NSPR headers depending on the current make target, and to copy/rename the NSPR libraries so the Debug/Release/IDG versions can coexist in the same directory.
Open a command prompt (Windows, not MSys) and navigate to your base directory.
Then run preparePathsForJSBuild.bat "4.6.4".
That's it for the setup. Your directory structure under base should look like this:
(Not a fully-expanded view)
Building should be relatively painless. Take note of the full path to your base directory, and substitute
it wherever you see [base] below. Take note of the full path to your MinGW libraries directory
(usually C:\Program Files\MinGW\lib) and substitute it wherever you see [mingwlib] below.
Be sure to use Linux-style path format for those directories (ie: /c/programming/mozilla instead of
c:\programming\mozilla). Don't use a trailing slash. Make sure you use the short name for any
paths that have spaces in them (ie: /c/progra~1/somepath instead of c:\program files\somepath).
The JS_THREADSAFE parameter may be omitted if you do not require thread-safe libraries.
Open an MSys window and navigate to your base directory. Run the following commands:
cd js/src/fdlibmmake -f Makefile.ref JS_THREADSAFE=1 JS_DIST=[base]/dist XLDFLAGS="-L[mingwlib]" BUILD_OPT=1make -f Makefile.ref JS_THREADSAFE=1 JS_DIST=[base]/dist XLDFLAGS="-L[mingwlib]"make -f Makefile.ref JS_THREADSAFE=1 JS_DIST=[base]/dist XLDFLAGS="-L[mingwlib]" BUILD_IDG=1cd ..make -f Makefile.ref JS_THREADSAFE=1 JS_DIST=[base]/dist XLDFLAGS="-L[mingwlib]" BUILD_OPT=1make -f Makefile.ref JS_THREADSAFE=1 JS_DIST=[base]/dist XLDFLAGS="-L[mingwlib]"make -f Makefile.ref JS_THREADSAFE=1 JS_DIST=[base]/dist XLDFLAGS="-L[mingwlib]" BUILD_IDG=1You should now have three output directories containing all the compiled object files (*.o), archives and
import-libraries (*.a), import definitions (*.def), dynamic-link libraries (*.dll),
and executables (*.exe).
The directories are [base]\js\src\MinGW5.1_OPT.OBJ (release version),
[base]\js\src\MinGW5.1_DBG.OBJ (debug version), and
[base]\js\src\MinGW5.1_DBG.OBJD (IDG version).
Mostly useless for building with MinGW
This is for the entire Mozilla suite, and is only marginally helpful when trying to build SpiderMonkey as a standalone package
Additional Linux-focussed instructions for compiling SpiderMonkey as a standalone package
Instructions for compiling Avidemux, which includes an extremely helpful (though outdated) section on building SpiderMonkey v1.5.0 using MinGW. This was the closest thing I could find on the entire web that resembled the "answer" I was looking for. However, SpiderMonkey has changed significantly enough between v1.5.0 and v1.7.0 that their instructions no longer work out-of-the-box.
Solution to "initializer element is not constant" compilation errors, and the source of the modified jsapi.c file from the "Downloads" section, above. I can't figure out why the patch was never formally accepted -- it seems the assumption is "everyone uses GCC 4 now, no need to support GCC 3."
Details on the GCC_OPT_BUG flag that is used in the makefiles
This is purportedly a drop-in replacement for the Netscape Portable Runtime which allows static linking. I haven't tried it yet, but it's next on my to-do list.
Helpful article on linking MSVC lib binaries with MinGW binaries
More MSVC/MinGW linking help
GCC docs that are helpful when trying to decipher various compiler/linker flags
An interesting nonstandard use of SpiderMonkey
A new alternative in the JS Engine market. I'll be watching this one closely as it matures.
Written by Adam Rogers
Contact: adam [at] jargon [dot] ca
Last updated 2008-09-07