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)

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)

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

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:

Next recommended step:

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