Skip to content

build-notes.md

Latest commit

 

History

History
246 lines (199 loc) · 9.52 KB

build-notes.md

File metadata and controls

246 lines (199 loc) · 9.52 KB
Raw

Build notes

Live log of what we had to discover to get SpiderMonkey 45 out of the TenFourFox tree to build standalone on Tiger/G5 (imacg52). Written in order of discovery so you can see the shape of the yak.

Toolchain expected by TenFourFox's js/src/configure.in

  • autoconf 2.13 (exactly). System autoconf on Tiger is 2.59 which is too new — Mozilla-era configure.in refuses 2.5x. Built from GNU tarball into /opt/autoconf-2.13/bin/autoconf213 with --program-suffix=213 (binary name collision avoidance).
  • Python 2.7 for python/mozbuild. Tiger ships 2.3.5, which is fatally old. tiger.sh python2-2.7.18 drops in a working one at /opt/python2-2.7.18/bin/python2.
  • Perl ≥ 5.6 — system perl on Tiger is 5.8.6, already adequate. Configure's check is use Config; -d $Config{archlib} which passes.
  • gcc with C++11 — /opt has gcc-4.9.4 and gcc-10.3.0. Using 4.9 by default to match the era that TenFourFox itself was built with.
  • Xcode 2.5 / MacOSX10.4u.sdk — present by convention on every Tiger host in the fleet. Passed via --with-macos-sdk=.

Sparse checkout scope

At minimum, js/src/configure.in reads from these sibling trees:

  • mfbt/ (Mozilla framework basic types — STL-alike utilities)
  • mozglue/ (runtime glue: allocator, stubs)
  • nsprpub/ (Netscape Portable Runtime)
  • memory/ (the allocator including the jemalloc vendor drop)
  • config/ (Mozilla build system .mk files, Python helpers)
  • build/ (host-arch detection + autoconf bits)
  • python/ (mozbuild itself)
  • python/mozbuild specifically
  • testing/mozbase/ — not obvious from configure.in, but virtualenv.py asserts on testing/mozbase/packages.txt. We learned this the hard way: configure dies silently (mozbuild's virtualenv exception) when that file is missing. The error only shows up in configure.log, not config.log.

Approximate size after expanding: 212 MB on the main Mac.

Discovery: "configure died silently at full perl installation"

First build run's configure.log tail showed checking for full perl installation and nothing else. No error on stdout. Only configure.log (a different log from config.log — mozbuild layers its own wrapper) held the actual traceback:

AssertionError: '.../testing/mozbase/packages.txt' does not exist

Root cause: missing sparse path. Fix: add testing/mozbase to the sparse checkout. Lesson: always tail configure.log not just config.log on mozbuild configure failures; they are different files. config.log is the autoconf classic; configure.log is mozbuild's python wrapper log.

Discovery: gcc-4.9 binary name

Every binary under /opt/gcc-4.9.4/bin/ is suffixed -4.9 (gcc-4.9, g++-4.9) — not gcc / g++. /usr/local/bin/gcc-4.9 is a symlink. The first build attempt set CC=/opt/gcc-4.9.4/bin/gcc and failed with "No such file or directory" on conftest. Using gcc-4.9 / g++-4.9 binaries directly is correct.

Discovery: -mlong-branch warnings from crt

Tiger's /usr/lib/crt1.o and gcc 4.9's crt3.o were built with -mlong-branch, which the modern linker warns is no longer needed. Harmless, just noisy — ignore.

Discovery: -read_only_relocs suppress and -force_cpusubtype_ALL

Both copied from TenFourFox's G5.mozcfg:

  • -read_only_relocs suppress keeps the 32-bit dynamic linker from choking on relocations into __TEXT segments — standard incantation for mach-o ppc.
  • -force_cpusubtype_ALL stamps the output with cpusubtype=ALL so the binary will run on G3/G4/G5, not just the build host.

Discovery: ICU is required unless disabled

Default configure looks for an in-tree ICU. Without it: "Cannot find the ICU directory". Fix: --disable-icu --without-intl-api. We don't need Intl for v0.1.

Compiler settings we kept

-m32                      (IonPower is 32-bit-only)
-mcpu=G5                  (build-host tune; later rebuild for g3/g4)
-D_PPC970_                (from G5.mozcfg — gates PPC970 hints)
-flax-vector-conversions
-O3
-force_cpusubtype_ALL
-read_only_relocs suppress
-fpermissive              (C++ only — Firefox-era C++ is loose)

Discovery: builtin/Intl.cpp requires mozilla-config.h

Even with --without-intl-api --disable-icu, js/src/moz.build unconditionally adds builtin/Intl.cpp to UNIFIED_SOURCES. The file has #include "mozilla-config.h" at line 43 (unconditional, not guarded). mozilla-config.h is generated by the top-level Mozilla configure — not js/src/configure — so it does not exist in a standalone mozjs build. The equivalent file that js/src/configure does produce is js-confdefs.h.

Fix applied: comment out 'builtin/Intl.cpp', in js/src/moz.build (line 154) and re-run config.status so the RecursiveMake backend regenerates the unified source bundle without it. This skipped building the whole Intl module, which we don't use anyway.

Long-term fix if we want Intl back: create a stub mozilla-config.h in an include path that just does #include "js-confdefs.h", and either populate ICU properly or conditionally compile Intl against its #if ENABLE_INTL_API guards.

Update: jsstr.cpp also requires mozilla-config.h

After disabling Intl.cpp, the next unified bundle hit the same error in jsstr.cpp:54. (And grep -rln '"mozilla-config.h"' only turns up these two files, both TenFourFox-added at the same pattern of mozilla-config.h + plvmx.h.) Rather than patch each file, we stubbed:

echo '#include "js-confdefs.h"' \
  > $OBJDIR/dist/include/mozilla-config.h
cp nsprpub/lib/libc/include/plvmx.h \
  $OBJDIR/dist/include/plvmx.h

$OBJDIR/dist/include is already on the compile-include search path (-I../../dist/include), so both files are now resolvable. With these two files present, Intl.cpp was re-enabled in moz.build and the build proceeds past both includes.

Heads-up: -lcrt1.10.6.o at link time

A parallel Claude session (see status-report-session-B.md) observed during its own abbreviated build attempt that configure's C++ sanity conftest link step can die with:

ld: library not found for -lcrt1.10.6.o

Cause: gcc 4.9 from /opt/gcc-4.9.4/ defaults to the Leopard crt1.10.6.o, which is absent on Tiger. Mozilla's own make rules later pass -mmacosx-version-min=10.4 via --enable-macos-target=10.4 — but configure-time conftest compiles use plain $CC/$CXX without those flags. So you can pass the whole configure phase in one run and die at a make-time link step the next.

Fix applied to scripts/build-mozjs.sh: both CC and CXX now include -mmacosx-version-min=10.4 explicitly, and MACOSX_DEPLOYMENT_TARGET=10.4 is also exported. Either one alone should be sufficient; belt-and-suspenders is cheap.

Discovery: pthread_setname_np is Leopard-only

Hit deep in the unified-compile phase (Unified_cpp_js_src28.cpp → vm/PosixNSPR.cpp:159):

/Users/macuser/tmp/tenfourfox/js/src/vm/PosixNSPR.cpp:159:37: error:
  'pthread_setname_np' was not declared in this scope
     result = pthread_setname_np(name);

Cause: pthread_setname_np shipped in macOS 10.6 (or 10.5 depending on header); it does not exist on Tiger. The Mozilla-era code guards a few platforms (NetBSD, FreeBSD variants) but XP_DARWIN is assumed to always have the SDK that has it.

Fix: short-circuit the function. PR_SetCurrentThreadName is best- effort diagnostics anyway — debuggers won't see thread names, but JS runs fine without them.

 PRStatus
 PR_SetCurrentThreadName(const char* name)
 {
+    (void)name;
+    return PR_SUCCESS;
     int result;
 #ifdef XP_DARWIN
     result = pthread_setname_np(name);

Patched in-place on the imacg52 source tree. If we were going to ship this recipe broadly, the cleaner version would be:

 #ifdef XP_DARWIN
-    result = pthread_setname_np(name);
+# if defined(MAC_OS_X_VERSION_10_6) && \
+     MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_X_VERSION_10_6
+    result = pthread_setname_np(name);
+# else
+    (void)name;
+    result = 0;
+# endif

but that's a v2 concern. Build resumed from Unified_cpp_js_src28 with the short-circuit.

Pending gotchas to check as the build progresses

  • <Availability.h> on Tiger — TenFourFox's own source should already have the AvailabilityMacros.h fallback, but the standalone mozjs subtree may trigger a path that stock Mozilla never fixed. If we see Availability.h: No such file or directory, rewrite the include the way the imacg3-dev skill describes.
  • getcontext/setcontext — Tiger doesn't have them. SpiderMonkey uses them in a few places for async engines; --disable-async or similar at configure time may be needed.
  • jemalloc — Mozilla bundles its own. On Tiger it sometimes wants tricks. We passed --disable-jemalloc up front; the system malloc is fine for a 32-bit debug runtime.
  • NSPR — configure prints checking for nspr-config... no early. Mozilla normally builds in-tree NSPR when --with-system-nspr is absent. We rely on the default behavior.
  • -fno-rtti — Firefox normally disables RTTI; if our standalone shell imports std::type_info anywhere we'd link-fail. Not an issue so far.

Paths of record

  • TenFourFox source (main Mac, sparse): /Users/cell/claude/ionpower-node/external/tenfourfox/
  • TenFourFox source (imacg52): /Users/macuser/tmp/tenfourfox/
  • SpiderMonkey build dir: js/src/build_OPT.OBJ/ under that tree.
  • Install prefix: /opt/mozjs-45-ionpower/.
  • ionpower-node dev tree (main Mac): /Users/cell/claude/ionpower-node/
  • ionpower-node deployed (imacg52): not yet — will rsync once SpiderMonkey install completes.