# Progress

## 2026-04-01 — Phase 1.1 started: Guile verified on FreeBSD amd64

Completed work:

- installed/confirmed `guile3-3.0.10`
- added a reusable verification harness:
  - `tests/guile/run-phase1-verification.sh`
  - `tests/guile/verify-phase1.scm`
  - `tests/guile/modules/phase1/sample.scm`
- verified the following on `FreeBSD 15.0-STABLE` amd64:
  - module loading
  - deterministic output generation
  - file I/O
  - process handling with `primitive-fork`/`waitpid`
  - loopback TCP sockets
  - FFI calls into libc
  - execution of Guix bootstrap-related code from `(guix build make-bootstrap)`
- wrote the results to `docs/reports/phase1-guile-freebsd.md`

Notable findings:

- `guile3` and `guile-3.0` are present, but there is no unversioned `guile` binary
- `system*` and `open-pipe*` currently segfault on this host (`exit 139`)
- despite that crash, the lower-level process primitives needed for further investigation do work

Current assessment:

- Phase 1.1 has a solid amd64 smoke-verification baseline
- Phase 1.1 is not fully complete yet because `i386` has not been checked and the subprocess crash needs investigation
- verification harness committed as `e380e88` (`Add FreeBSD Guile verification harness`)

## 2026-04-01 — Phase 1.1 follow-up: subprocess crash isolated

Completed work:

- added a dedicated subprocess diagnostic harness:
  - `tests/guile/run-subprocess-diagnostics.sh`
  - `tests/guile/posix-spawn-freebsd-diagnostics.c`
- reproduced crashes for:
  - `system*`
  - `spawn`
  - `open-pipe*`
- confirmed all three fail with `SIGSEGV` / `exit 139`
- confirmed native FreeBSD `posix_spawn` + `posix_spawn_file_actions_addclosefrom_np` works in a standalone C program
- confirmed FreeBSD behavior that triggers gnulib replacement logic:
  - `posix_spawn_file_actions_adddup2` accepts an invalid fd in the gnulib probe
  - `posix_spawn_file_actions_addopen` accepts an invalid fd in the gnulib probe
  - `posix_spawnp` accepts a shebang-less executable script in the gnulib security probe
- wrote the analysis to `docs/reports/phase1-guile-subprocess-crash.md`

Conclusion:

- this is most likely an upstream Guile/gnulib ABI bug on FreeBSD, not a Guix-specific problem
- likely sequence:
  1. gnulib enables `REPLACE_POSIX_SPAWN=1`
  2. Guile still enables `HAVE_POSIX_SPAWN_FILE_ACTIONS_ADDCLOSEFROM_NP`
  3. Guile passes a gnulib replacement `posix_spawn_file_actions_t` object to native `posix_spawn_file_actions_addclosefrom_np`
  4. libc interprets gnulib struct fields as a native pointer and crashes
- evidence from the lldb core matches this hypothesis (`*fa = 0x0000000600000008`, consistent with gnulib `_allocated=8`, `_used=6`)

Current assessment:

- Phase 1.1 amd64 investigation is now much stronger and has a concrete root-cause hypothesis
- 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

## 2026-04-01 — Phase 1.2 started: native GNU Hello build validated on FreeBSD

Completed work:

- added a reusable native build harness:
  - `tests/native-build/run-gnu-hello.sh`
- used the current Guix package definition in `~/repos/guix/gnu/packages/base.scm` as the source of truth for:
  - GNU Hello version `2.12.3`
  - expected Guix nix-base32 source hash `183a6rxnhixiyykd7qis0y9g9cfqhpkk872a245y3zl28can0pqd`
- verified the downloaded tarball against the translated SHA256:
  - `0d5f60154382fee10b114a1c34e785d8b1f492073ae2d3a6f7b147687b366aa0`
- successfully executed the standard native build lifecycle on `FreeBSD 15.0-STABLE` amd64:
  - fetch
  - hash verification
  - extract
  - configure
  - build
  - staged install
  - runtime execution
- confirmed the staged binary runs and prints:
  - `Hello, world!`
- captured build metadata including:
  - compiler and make versions
  - host triplet
  - configure command
  - staged output path
  - runtime shared-library dependencies
- wrote the results to `docs/reports/phase1-native-gnu-hello.md`

Important findings:

- GNU Hello built successfully with FreeBSD base `make`, not just `gmake`
- that contrasts with the earlier local Guile build, which did require GNU `gmake`
- even this minimal GNU package links against FreeBSD-userland-provided libraries such as `libiconv` and `libintl`, which is useful data for later Guix package modeling
- this step is still a native shell-driven build exercise, not yet a real Guix package build

Current assessment:

- Phase 1.2 now has a concrete native autotools success case on FreeBSD
- the host can perform the basic fetch/verify/configure/build/install/run cycle needed for later `gnu-build-system` adaptation work
- Guix-specific build orchestration is still missing, but the environmental baseline is stronger now

Recent commits:

- `e380e88` — `Add FreeBSD Guile verification harness`
- `cd721b1` — `Update progress after Guile verification`
- `27916cb` — `Diagnose Guile subprocess crash on FreeBSD`
- `02f7a7f` — `Validate local Guile fix on FreeBSD`

Next recommended step:

1. extend Phase 1.2 with at least one additional representative GNU/autotools package build on FreeBSD, or
2. prototype a tiny Scheme-based `gnu-build-system`-like phase runner using the known-good local Guile path, starting from the GNU Hello flow
3. continue keeping `~/repos/bdwgc` in reserve if later FreeBSD-specific GC/thread issues appear