fruix/docs/PROGRESS.md

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

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