Validate local Guile fix on FreeBSD

docs/PROGRESS.md

@@ -66,13 +66,63 @@ Current assessment:
 - the next practical step is to validate a workaround or patch in Guile so subprocess helpers stop crashing
 - after that, continue with Phase 1.2 (minimal native build environment / GNU Hello)
 
+## 2026-04-01 — Phase 1.1 follow-up: local Guile build validated the fix
+
+Completed work:
+
+- installed the additional build tooling needed for a local Guile checkout build:
+  - `autoconf`
+  - `automake`
+  - `libtool`
+  - `gettext-tools`
+  - `texinfo`
+  - `help2man`
+  - `gperf`
+  - `pkgconf`
+- confirmed a FreeBSD-specific bootstrap quirk:
+  - Guile `autogen.sh` needs GNU `m4`
+  - FreeBSD base `/usr/bin/m4` is not sufficient
+  - `M4=gm4 ./autogen.sh` works
+- built a disposable validation copy from `~/repos/guile`
+- confirmed `~/repos/guile` already contains upstream commit:
+  - `eb828801f621d3e130b6fe88cfc4acaa69b98a03`
+  - `Don't use posix_spawn_file_actions_addclosefrom_np with glib posix_spawn`
+- updated the local test harnesses so they can test non-system Guile builds:
+  - `tests/guile/run-phase1-verification.sh`
+  - `tests/guile/run-subprocess-diagnostics.sh`
+  - both now accept `GUILE_BIN`
+  - both now prepend the sibling `../lib` directory to `LD_LIBRARY_PATH` when a matching local `libguile-3.0.so.1` exists
+  - subprocess diagnostics now supports `EXPECT_GUILE_SUBPROCESS_CRASH=0` for fixed builds
+- validated that the packaged Guile still reproduces the crash
+- validated that the locally built Guile succeeds for:
+  - `system*`
+  - `spawn`
+  - `open-pipe*`
+- re-ran the broader Phase 1.1 Scheme verification suite successfully against the local Guile build
+- wrote the results to `docs/reports/phase1-guile-local-build-validation.md`
+
+Important findings:
+
+- the local Guile executable initially still crashed until it was forced to load its matching local `libguile-3.0.so.1`
+- once `LD_LIBRARY_PATH` pointed at the local install lib directory, subprocess helpers worked correctly
+- this strongly supports the earlier diagnosis and shows that the upstream Guile fix resolves the problem in practice
+- the local `~/repos/bdwgc` checkout was not needed for this step; packaged `boehm-gc-threaded` was sufficient so far
+
+Current assessment:
+
+- Phase 1.1 now has both a root-cause analysis and a working validated fix path on amd64
+- no source changes were needed in `~/repos/guile` because the local checkout already contains the relevant upstream fix
+- no source changes were needed in `~/repos/bdwgc` yet, but the earlier FreeBSD warning keeps it on the watch list
+- the project can now move on to Phase 1.2 with a known-good local Guile fallback
+
 Recent commits:
 
 - `e380e88` — `Add FreeBSD Guile verification harness`
 - `cd721b1` — `Update progress after Guile verification`
+- `27916cb` — `Diagnose Guile subprocess crash on FreeBSD`
 
 Next recommended step:
 
-1. patch or locally validate a fix for the `addclosefrom_np` / `REPLACE_POSIX_SPAWN` mismatch
-2. re-run both Guile test harnesses after the fix
-3. once subprocess behavior is stable, continue with Phase 1.2 (minimal native build environment / GNU Hello)
+1. begin Phase 1.2 by creating a minimal native FreeBSD build environment exercise (for example, GNU Hello or an even smaller autotools package)
+2. use the local fixed Guile build when subprocess helpers are required
+3. keep `bdwgc` in reserve if later FreeBSD-specific GC/thread issues appear