SpiderMonkey is Mozilla's JavaScript and WebAssembly Engine, written in C++ and Rust. In BLFS, the source code of SpiderMonkey is taken from Firefox.
![[Note]](../images/note.png)
Development versions of BLFS may not build or run some packages properly if LFS or dependencies have been updated since the most recent stable versions of the books.
Download (HTTP): https://archive.mozilla.org/pub/firefox/releases/128.3.1esr/source/firefox-128.3.1esr.source.tar.xz
Download MD5 sum: 8d2e8b9115580dcbdeafeee60699ec81
Download size: 484 MB
Estimated disk space required: 3.6 GB (40 MB installed after removing 36 MB static lib; add 34 MB for the main tests and 37 MB for the jit tests)
Estimated build time: 1.9 SBU (with parallelism=4; add 1.1 SBU for the main tests and 3.7 SBU for the jit tests)
ICU-75.1, rustc-1.82.0, and Which-2.21
LLVM-19.1.0 (with Clang, required for 32-bit systems without SSE2 capabilities)
![[Important]](../images/important.png)
If you are building this package on a 32-bit system, and Clang is
not installed or you're overriding the default compiler choice
with the environment variable CXX,
please read the Command Explanations section first.
Unlike most other packages in BLFS, the instructions below
require you to untar firefox-128.3.1esr.tar.xz and change into the
firefox-128.3.1 directory.
Extracting the tarball will reset the permissions of the current
directory to 0755 if you have permission to do that. If you do
this in a directory where the sticky bit is set, such as
/tmp it will end with error
messages:
tar: .: Cannot utime: Operation not permitted
tar: .: Cannot change mode to rwxr-xr-t: Operation not permitted
tar: Exiting with failure status due to previous errors
This does finish with non-zero status, but it does NOT mean there is a real problem. Do
not untar as the root user in a
directory where the sticky bit is set - that will unset it.
Install SpiderMonkey by running the following commands:
If you are compiling this package in chroot you must ensure that
/dev/shm is mounted. If you do not
do this, the Python
configuration will fail with a traceback report referencing
/usr/lib/pythonN.N/multiprocessing/synchronize.py.
As the root user, run:
mountpoint -q /dev/shm || mount -t tmpfs devshm /dev/shm
Compiling the C++ code respects $MAKEFLAGS and defaults to 'j1', the rust code will use all processors.
mkdir obj &&
cd obj &&
../js/src/configure --prefix=/usr \
--disable-debug-symbols \
--disable-jemalloc \
--enable-readline \
--enable-rust-simd \
--with-intl-api \
--with-system-icu \
--with-system-zlib &&
make
To run the SpiderMonkey test suite, issue: make -C js/src check-jstests JSTESTS_EXTRA_ARGS="--timeout 300 --wpt=disabled". It's recommended to redirect the output into a log. Because we are building with system ICU, 39 tests (out of a total of more than 50,000) are known to fail. The test suite is executed with all CPU cores available: even in a cgroup with less cores assigned, it still attempts to spawn as many testing jobs as the number of all cores in the system; fortunately the kernel still won't run these jobs on cores not assigned to the cgroup so the CPU usage is still controlled.
To run the JIT test suite, issue: make -C js/src check-jit-test
JITTEST_EXTRA_ARGS="--timeout 300". Like the
SpiderMonkey test suite, the number of test jobs is same as the
number of all CPU cores in the system even if a cgroup is used. To
make things worse, there are six tests which will use 3 GB each of
system memory, so the peak memory usage may be up to 18 GB if the
number of cores is six or more. Running the JIT test suite without
enough memory may invoke the kernel OOM killer and cause stability
issues. If you don't have enough system memory available, append
-jN after --timeout 300 with N replaced by the number of
parallel test jobs you want to start. For example, if you have 16
GB system memory available and 8 CPU cores, issue make -C js/src check-jit-test
JITTEST_EXTRA_ARGS="--timeout=300 -j5" to run the
test with 5 parallel jobs so the memory usage won't exceed 15 GB.
![[Caution]](../images/caution.png)
An issue in the installation process causes any running program which links to SpiderMonkey shared library (for example, GNOME Shell) to crash if SpiderMonkey is reinstalled, or upgraded or downgraded without a change of the major version number (128 in 128.3.1). To work around this issue, remove the old version of the SpiderMonkey shared library before installation:
rm -fv /usr/lib/libmozjs-128.so
Now, as the root user:
make install && rm -v /usr/lib/libjs_static.ajs && sed -i '/@NSPR_CFLAGS@/d' /usr/bin/js128-config
--disable-debug-symbols:
Don't generate debug symbols since they are very large and most
users won't need it. Remove it if you want to debug SpiderMonkey.
--disable-jemalloc: This
switch disables the internal memory allocator used in SpiderMonkey.
jemalloc is only intended for the Firefox browser environment. For
other applications using SpiderMonkey, the application may crash as
items allocated in the jemalloc allocator are freed on the system
(glibc) allocator.
--enable-readline: This
switch enables Readline support in the SpiderMonkey command line
interface.
--enable-rust-simd: This
switch enables SIMD optimization in the shipped encoding_rs crate.
--with-intl-api: This
enables the internationalization functions required by Gjs.
--with-system-*: These
parameters allow the build system to use system versions of the
above libraries. These are required for stability.
rm -v /usr/lib/libjs_static.ajs: Remove a large static library which is not used by any BLFS package.
sed -i '/@NSPR_CFLAGS@/d' /usr/bin/js128-config: Prevent js128-config from using buggy CFLAGS.
CC=gcc
CXX=g++
CXXFLAGS="-msse2
-mfpmath=sse"