fix(jerbuild): stop forcing in-process compile on FreeBSD ta6fb #84

Merged

ober merged 1 commit from fix/ta6fb-multicall-subprocess into master

2026-09-19 15:41:46 -04:00

ober commented

2026-09-19 06:33:45 -04:00

Owner

Problem

Every standalone binary produced by the FreeBSD (ta6fb) multicall jerbuild dies at startup:

$ ./jcode --version
Exception: library (std native-loader) not found

Reproduced minimally on FreeBSD 14.4 (biggus) with the v0.12.10 freebsd-amd64 release toolchain and a 3-line project importing (jerboa prelude) + (std native-loader) — the resulting binary fails with library (jerboa runtime) not found. The v0.12.10 macos-arm64 artifact builds the same project fine.

Root cause

jerbuild.ss binary-build dispatch forced the in-process compile path on ta6fb (Chez 10.4.0 issue #78 workaround). In the multicall image the stdlib is internalized (already loaded), so compile-imported-libraries skips those libraries, Chez emits references instead of code, and the packaged program requires them at runtime from a search path that cannot resolve them. strings confirms: macOS-built binary carries 11 native-loader references; the FreeBSD one has 2 (the failing require literals).

Fix

Drop the machine-type carve-out so ta6fb multicall builds use the same isolated-subprocess WPO path as every other platform. The #78 hang no longer reproduces on current master — validated natively on FreeBSD 14.4 by running the exact fresh-runtime helper shape (compile-imported-libraries #t + compile-program) over the repro closure: clean completion, all bundle libs recompiled to native .wpo/.so.

JERBOA_BINARY_FORCE_INPROCESS remains as the escape hatch if the hang ever returns.
Source-tree (non-multicall) behavior is unchanged.

Verification

Fresh-runtime compile-program on FreeBSD 14.4: completes, emits all libs (biggus).
Balance/syntax verified via jerboa MCP tools.
Full end-to-end validation (multicall rebuild + consumer binary startup) lands with the v0.12.14 release build; jcode CI re-pins to it (jerboa-code PR #21 chain).

VERSION 0.12.13 → 0.12.14.

## Problem Every standalone binary produced by the FreeBSD (ta6fb) multicall jerbuild dies at startup: ``` $ ./jcode --version Exception: library (std native-loader) not found ``` Reproduced minimally on FreeBSD 14.4 (biggus) with the v0.12.10 freebsd-amd64 release toolchain and a 3-line project importing `(jerboa prelude)` + `(std native-loader)` — the resulting binary fails with `library (jerboa runtime) not found`. The v0.12.10 macos-arm64 artifact builds the same project fine. ## Root cause `jerbuild.ss` binary-build dispatch forced the **in-process** compile path on ta6fb (Chez 10.4.0 issue #78 workaround). In the multicall image the stdlib is internalized (already loaded), so `compile-imported-libraries` skips those libraries, Chez emits references instead of code, and the packaged program requires them at runtime from a search path that cannot resolve them. `strings` confirms: macOS-built binary carries 11 `native-loader` references; the FreeBSD one has 2 (the failing require literals). ## Fix Drop the machine-type carve-out so ta6fb multicall builds use the same isolated-subprocess WPO path as every other platform. The #78 hang no longer reproduces on current master — validated natively on FreeBSD 14.4 by running the exact fresh-runtime helper shape (`compile-imported-libraries #t` + `compile-program`) over the repro closure: clean completion, all bundle libs recompiled to native .wpo/.so. - `JERBOA_BINARY_FORCE_INPROCESS` remains as the escape hatch if the hang ever returns. - Source-tree (non-multicall) behavior is unchanged. ## Verification - Fresh-runtime `compile-program` on FreeBSD 14.4: completes, emits all libs (biggus). - Balance/syntax verified via jerboa MCP tools. - Full end-to-end validation (multicall rebuild + consumer binary startup) lands with the v0.12.14 release build; jcode CI re-pins to it (jerboa-code PR #21 chain). VERSION 0.12.13 → 0.12.14.

ober added 1 commit

2026-09-19 06:33:46 -04:00

fix(jerbuild): stop forcing in-process compile on FreeBSD ta6fb

required-ci / gerbil-compat (pull_request) Successful in 4m3s

Details

version-policy / required (pull_request) Successful in 5m46s

Details

freebsd-required / required (pull_request) Successful in 13m6s

Details

dtrace / freebsd-usdt (pull_request) Successful in 14m37s

Details

required-ci / required (pull_request) Successful in 15m57s

Details

c5903b7a71

The ta6fb-only in-process dispatch (Chez issue #78 workaround) silently
omits every library already loaded in the running image ((jerboa
runtime), (std native-loader), ...) from the emitted program: Chez sees
them as installed, skips compilation, and the packaged binary dies at
startup with 'Exception: library (...) not found'. Every standalone
binary built by the FreeBSD multicall (v0.12.10 freebsd-amd64 release)
is affected - reproduced with a 3-line project importing (jerboa
prelude).

The #78 subprocess hang no longer reproduces: a fresh-runtime
compile-program over the same closure completes cleanly on FreeBSD
14.4 (validated natively). Drop the machine-type carve-out so ta6fb
uses the isolated-subprocess path like every other platform;
JERBOA_BINARY_FORCE_INPROCESS remains the escape hatch.

VERSION 0.12.13 -> 0.12.14.

ober scheduled this pull request to auto merge when all checks succeed

2026-09-19 15:41:36 -04:00

ober merged commit 8b388546a1 into master

2026-09-19 15:41:46 -04:00

ober referenced this pull request from a commit

2026-09-19 15:41:47 -04:00

Merge pull request #84

ober referenced this pull request

2026-09-21 18:36:32 -04:00

Standalone jerbuild binaries omit transitive compiled libraries from app.boot #86