Beyond Linux® From Scratch (System V Edition) - Version r12.2-652

Chapter 9. General Libraries

SpiderMonkey from firefox-128.4.0

Introduction to SpiderMonkey

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]

Note

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.

Package Information

SpiderMonkey Dependencies

Required

ICU-76.1, rustc-1.82.0, and Which-2.21

Recommended

LLVM-19.1.0 (with Clang, required for 32-bit systems without SSE2 capabilities)

[Important]

Important

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.

Installation of SpiderMonkey

[Note]

Note

Unlike most other packages in BLFS, the instructions below require you to untar firefox-128.4.0esr.tar.xz and change into the firefox-128.4.0 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.

If you are using ICU-76.1 or later, adapt the build system to use the correct library: 

sed -i 's/icu-i18n/icu-uc &/' js/moz.configure

Install SpiderMonkey by running the following commands:

[Note]

Note

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

If you wish to run the test suite, adapt it to be compatible with Python 3.13.0 or newer: 

sed 's/pipes/shlex/' -i ../js/src/tests/lib/results.py

To run the SpiderMonkey test suite, issue: 

make -C js/src check-jstests \
     JSTESTS_EXTRA_ARGS="--timeout 300 --wpt=disabled" | tee jstest.log

Because we are building with system ICU, 158 tests (out of a total of more than 50,000) are known to fail. The list of failed tests can be extracted via grep 'UNEXPECTED-FAIL' jstest.log. Pass the -c option to grep if you only want the total number of failed tests.

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 the following command. Note that 6 tests in the 'timezone.js' suite are known to fail due to ICU-76. 

make -C js/src check-jit-test JSTESTS_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, use JITTEST_EXTRA_ARGS="--timeout=300 -j5" to run the test suite with 5 parallel jobs so the memory usage won't exceed 15 GB.

[Caution]

Caution

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.4.0). 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

Command Explanations

--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++: BLFS used to prefer to use gcc and g++ instead of upstream's defaults of the clang programs. With the release of gcc-12 the build takes longer with gcc and g++, primarily because of extra warnings, and is bigger. Pass these environment variables to the configure script if you wish to continue to use gcc, g++ (by exporting them and unset them after the installation, or simply prepending them before the ../js/src/configure command). If you are building on a 32-bit system, also see below.

CXXFLAGS="-msse2 -mfpmath=sse": Use SSE2 instead of 387 for double-precision floating-point operations. It's needed by GCC to satisfy the expectations of upstream (Mozilla) developers with floating-point arithmetic. Use it if you are building this package on a 32-bit system with GCC (if Clang is not installed or GCC is explicitly specified). Note that this will cause SpiderMonkey to crash on a processor without SSE2 capability. If you are running the system on such an old processor, Clang is strictly needed. This setting is not needed on 64-bit systems because all 64-bit x86 processors support SSE2 and the 64-bit compilers (both Clang and GCC) use SSE2 by default.

Contents

Installed Programs: js128 and js128-config
Installed Libraries: libmozjs-128.so
Installed Directories: /usr/include/mozjs-128

Short Descriptions

js128

provides a command line interface to the JavaScript engine

js128-config

is used to find the SpiderMonkey compiler and linker flags

libmozjs-128.so

contains the Mozilla JavaScript API functions