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

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

2026-04-01 — Phase 1.2 follow-up: Guix builder-side GNU Hello phase runner validated

Completed work:

• added a Scheme-driven GNU Hello build prototype:
  • tests/native-build/gnu-hello-guix-phase-runner.scm
  • tests/native-build/run-gnu-hello-guix-phase-runner.sh
• required the previously validated fixed local Guile build for this harness because it depends on subprocess-heavy Scheme operations
• used Guix modules directly from ~/repos/guix, including:
  • (guix base32)
  • (guix build gnu-build-system)
  • (guix build utils)
• fetched and hash-verified GNU Hello 2.12.3 again against the Guix package hash:
  • nix-base32: 183a6rxnhixiyykd7qis0y9g9cfqhpkk872a245y3zl28can0pqd
  • SHA256: 0d5f60154382fee10b114a1c34e785d8b1f492073ae2d3a6f7b147687b366aa0
• successfully executed a subset of Guix builder-side %standard-phases on FreeBSD:
  • set-SOURCE-DATE-EPOCH
  • unpack
  • configure
  • build
  • check
  • install
• installed GNU Hello into a store-like output path under the temporary work directory rather than using a /usr/local DESTDIR staging layout
• executed the resulting binary successfully and confirmed output:
  • Hello, world!
• captured metadata including:
  • host triplet
  • selected phase list
  • runtime dependencies
  • test-suite summary
• wrote the results to docs/reports/phase1-guix-gnu-hello-phase-runner.md

Important findings:

• this is the first validation step in the repo that successfully exercised actual Guix builder-side GNU build logic on FreeBSD instead of only a shell approximation
• the harness works when driven by the fixed local Guile build, confirming that the earlier Guile subprocess-fix validation is directly useful for FreeBSD Guix build orchestration
• GNU Hello's make check test suite also passed in this mode:
  • total: 7
  • pass: 7
  • fail: 0
• the resulting binary's runtime dependencies differ from the earlier /usr/local-prefixed native shell harness; in this store-like output layout it only showed:
  • libc.so.7
  • libsys.so.7
• that difference is a useful clue that Guix-style output layout/build invocation can materially affect FreeBSD runtime linkage behavior

Current assessment:

• Phase 1.2 now has both:
  • a shell-driven native GNU Hello build harness, and
  • a Scheme-driven prototype that uses real Guix builder-side GNU phases
• this is still short of a true Guix package/derivation build, but it significantly narrows the gap between host validation and real gnu-build-system execution on FreeBSD
• the known-good local Guile path is now validated as part of a practical Guix-adjacent build workflow, not just standalone subprocess diagnostics

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
• 4aebea4 — Add native GNU Hello FreeBSD build harness

Next recommended step:

1. run the Scheme-driven phase-runner pattern against at least one more small GNU/autotools package on FreeBSD, or
2. document the concrete gaps between this prototype and a real Guix package/derivation build, especially around store management and build isolation
3. continue keeping ~/repos/bdwgc in reserve if later FreeBSD-specific GC/thread issues appear

2026-04-01 — Phase 1.2 follow-up: second Scheme-driven GNU package build validated with GNU which

Completed work:

• added a second Scheme-driven GNU package harness:
  • tests/native-build/gnu-which-guix-phase-runner.scm
  • tests/native-build/run-gnu-which-guix-phase-runner.sh
• again used the previously validated fixed local Guile build because this harness depends on subprocess-heavy Guix/Scheme builder logic
• used the current Guix package definition in ~/repos/guix/gnu/packages/base.scm as the source of truth for:
  • GNU which version 2.21
  • expected Guix nix-base32 source hash 1bgafvy3ypbhhfznwjv1lxmd6mci3x1byilnnkc7gcr486wlb8pl
• verified the downloaded tarball against the translated SHA256:
  • f4a245b94124b377d8b49646bf421f9155d36aa7614b6ebf83705d3ffc76eaad
• successfully executed the same subset of Guix builder-side %standard-phases on FreeBSD as used for GNU Hello:
  • set-SOURCE-DATE-EPOCH
  • unpack
  • configure
  • build
  • check
  • install
• executed the resulting which binary successfully with a deterministic command:
  • PATH=/bin:/usr/bin ./which sh
• confirmed output:
  • /bin/sh
• captured metadata including:
  • host triplet
  • phase list
  • runtime dependencies
  • check-phase success status
  • executed command output
• wrote the results to docs/reports/phase1-guix-which-phase-runner.md

Important findings:

• this confirms the Scheme-driven Guix builder-side phase-runner pattern is not limited to GNU Hello; a second small GNU/autotools package also succeeds on FreeBSD
• GNU which's check phase passed, but it did not leave behind an Automake-style test-suite.log or testsuite.log
• GNU which emitted a non-fatal configure warning about Guix's standard --enable-fast-install flag being unrecognized
• the source also emitted several clang warnings about deprecated non-prototype C declarations/definitions, but the build still completed successfully
• the resulting which binary again showed a minimal store-like runtime linkage profile:
  • libc.so.7
  • libsys.so.7
• unlike GNU Hello, the source tree did not present an obvious shipped config.guess, so the harness used cc -dumpmachine as a fallback for host-triplet metadata

Current assessment:

• Phase 1.2 now has two successful Scheme-driven Guix builder-side GNU package validations on FreeBSD:
  • GNU Hello
  • GNU which
• this increases confidence that a narrow but real subset of gnu-build-system builder-side execution already works on FreeBSD when paired with the fixed local Guile build
• the next uncertainty is now less about whether basic builder phases run at all, and more about where real Guix package/derivation/store integration and isolation will first require FreeBSD-specific adaptation

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
• 4aebea4 — Add native GNU Hello FreeBSD build harness
• c944cdb — Validate Guix builder phases on FreeBSD

Next recommended step:

1. document the concrete remaining gap between these Scheme-driven phase-runner prototypes and a true Guix package/derivation/store-daemon build on FreeBSD, especially around store management, implicit inputs, and build isolation
2. or choose a somewhat more demanding GNU package with non-trivial declared inputs to identify the first builder-side FreeBSD adaptation points
3. continue keeping ~/repos/bdwgc in reserve if later FreeBSD-specific GC/thread issues appear

2026-04-01 — Phase 1.2 follow-up: documented the gap to a real Guix package build

Completed work:

• analyzed the concrete remaining gap between the current FreeBSD validation harnesses and a real Guix package/derivation/store-daemon build
• wrote the analysis to:
  • docs/reports/phase1-guix-build-gap-analysis.md
• based the analysis on the current local Guix source tree, including the relevant host-side and daemon-side code paths in:
  • guix/packages.scm
  • guix/build-system/gnu.scm
  • guix/gexp.scm
  • guix/store.scm
  • guix/derivations.scm
  • gnu/packages/commencement.scm
  • doc/guix.texi
  • nix/libstore/build.cc
• compared those real Guix layers against the currently validated FreeBSD prototypes:
  • shell-driven native GNU Hello harness
  • Scheme-driven GNU Hello builder-phase runner
  • Scheme-driven GNU which builder-phase runner

Main conclusions recorded:

• the current FreeBSD work has validated a narrow but real builder-side slice of Guix execution:
  • Guile can run the needed Scheme code when using the fixed local build
  • (guix build gnu-build-system) phases can build small GNU packages on FreeBSD
• however, the current prototypes still bypass several critical layers of a real Guix build:
  • package -> bag lowering
  • bag -> derivation lowering
  • imported module closure/store materialization
  • real daemon RPC and build submission
  • canonical /gnu/store management and metadata
  • build users, chroot/container or jail-style isolation
  • substitute/graft/offload handling
• documented that the current phase runners rely on host tools already present on FreeBSD, whereas real gnu-build-system uses implicit inputs drawn from %final-inputs
• identified the most actionable next milestone as a derivation-generation investigation for a tiny package, to locate the first failure boundary among:
  • host-side lowering
  • store interaction
  • derivation emission
  • daemon availability
  • daemon-side execution

Current assessment:

• Phase 1.2 now has both practical build validation and a clearer architectural map of what remains before a true Guix package build can work on FreeBSD
• the project has reduced uncertainty around builder-side GNU phase portability
• the next uncertainty is now specifically the host-side lowering/store/daemon boundary, not the builder-phase boundary

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
• 4aebea4 — Add native GNU Hello FreeBSD build harness
• c944cdb — Validate Guix builder phases on FreeBSD
• 0a2e48e — Validate GNU which builder phases on FreeBSD

Next recommended step:

1. investigate whether a tiny package can be lowered far enough on FreeBSD to produce a real derivation, and capture the exact first failure point
2. if derivation generation proves immediately blocked, document whether the blocker is generated Guix modules/configuration, store connectivity, or daemon assumptions
3. continue keeping ~/repos/bdwgc in reserve if later FreeBSD-specific GC/thread issues appear

2026-04-01 — Phase 1.2 follow-up: derivation-generation investigation identified the first real checkout blockers

Completed work:

• added a reproducible checkout/bootstrap/configure investigation harness:
  • tests/guix/run-derivation-generation-investigation.sh
• used the previously validated fixed local Guile build for the investigation:
  • /tmp/guile-freebsd-validate-install/bin/guile
• followed the operator instruction for future store setup by parameterizing the checkout attempts to use:
  • store directory: /frx/store
  • local state directory: /frx/var
  • sysconf directory: /frx/etc
• created a disposable shared clone of ~/repos/guix
• successfully ran ./bootstrap from that disposable checkout on FreeBSD
• attempted configure without --with-courage
• attempted configure again with --with-courage
• confirmed directly that the local fixed Guile build currently cannot load:
  • (gnutls)
• wrote the results to:
  • docs/reports/phase1-guix-derivation-generation-investigation.md

Important findings:

• a stock Guix checkout currently fails configuration on FreeBSD before any derivation/store/daemon work is reached, due to the explicit unsupported-platform gate:
  • configure: error: `x86_64-freebsd15.0' is not a supported platform.
• re-running configure with --with-courage gets past that gate, but then stops on a second blocker:
  • configure: error: The Guile bindings of GnuTLS are missing; please install them.
• a direct module-load test with the same local Guile confirms the problem more concretely:
  • (use-modules (gnutls)) fails with no code for module (gnutls)
• this means the current effort is still blocked before reaching:
  • usable pre-inst-env generation for Guix commands
  • package -> bag lowering in a live checkout
  • bag -> derivation lowering
  • daemon connectivity
  • actual /frx/store population

Current assessment:

• the first practical boundary between the earlier FreeBSD builder-phase prototypes and a real Guix checkout has now been located more precisely
• the project is no longer blocked by vague uncertainty at this stage; it is blocked by two concrete checkout-preparation issues:
  1. unsupported-platform configure gating
  2. missing Guile (gnutls) bindings
• importantly, the derivation-generation investigation has not yet reached the store/daemon boundary, so the next step must first clear the (gnutls) dependency issue

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
• 4aebea4 — Add native GNU Hello FreeBSD build harness
• c944cdb — Validate Guix builder phases on FreeBSD
• 0a2e48e — Validate GNU which builder phases on FreeBSD
• 245a47d — Document gaps to real Guix FreeBSD builds

Next recommended step:

1. obtain working Guile (gnutls) bindings compatible with the fixed local Guile build and re-run the derivation-generation investigation
2. once configuration succeeds, continue until the next failure boundary is identified among:

• pre-inst-env usability
• derivation emission
• daemon connectivity
• daemon-side /frx/store assumptions

3. continue keeping ~/repos/bdwgc in reserve if later FreeBSD-specific GC/thread issues appear

2026-04-01 — Phase 1.2 follow-up: local Guile-GnuTLS built on FreeBSD; next blocker is Guile-Git

Completed work:

• installed the host-side C GnuTLS stack needed for Guile-GnuTLS builds:
  • gnutls
  • libtasn1
  • nettle
  • p11-kit
• added a reproducible local Guile-GnuTLS build harness:
  • tests/guix/build-local-guile-gnutls.sh
• updated the derivation-generation investigation harness so it can consume extra Guile module prefixes through:
  • GUILE_EXTRA_PREFIX
• used the current Guix package definition in ~/repos/guix/gnu/packages/tls.scm as the source of truth for:
  • guile-gnutls version 5.0.1
  • expected Guix nix-base32 source hash 0kqngyx4520gjk49l6whjd2ss994kaj9rm78lli6p3q6xry0945i
• verified the downloaded Guile-GnuTLS tarball against the translated SHA256:
  • b190047cee068f6b22a5e8d49ca49a2425ad4593901b9ac8940f8842ba7f164f
• built and installed a local Guile-GnuTLS validation copy against the previously validated fixed local Guile build under:
  • /tmp/guile-gnutls-freebsd-validate-install
• validated successfully that the fixed local Guile can now load:
  • (gnutls)
• re-ran the checkout derivation-generation investigation with:
  • GUILE_EXTRA_PREFIX=/tmp/guile-gnutls-freebsd-validate-install
  • store directory still set to /frx/store
• wrote the results to:
  • docs/reports/phase1-guile-gnutls-freebsd.md

Important findings:

• Guile-GnuTLS does not build with FreeBSD base make; it requires GNU gmake
• a FreeBSD-specific source compatibility issue surfaced in guile/src/core.c:
  • it includes <alloca.h> unconditionally
  • on this host, alloca is available through <stdlib.h> instead
• for local validation, the harness applies a small disposable-tree patch that uses <stdlib.h> on __FreeBSD__
• after that fix, the local Guile-GnuTLS build succeeded and (use-modules (gnutls)) worked with the fixed local Guile build
• re-running the Guix checkout investigation confirms the earlier (gnutls) blocker is genuinely cleared
• the next configure-time blocker is now:
  • configure: error: Guile-Git is missing; please install it.

Current assessment:

• the first checkout-preparation blocker after unsupported-platform gating has advanced from missing (gnutls) to missing Guile-Git
• this is meaningful progress because the project is now moving farther into the dependency chain required for a real Guix checkout on FreeBSD
• the requested experimental store path remains /frx/store, but the effort still has not yet reached actual store population or daemon interaction

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
• 4aebea4 — Add native GNU Hello FreeBSD build harness
• c944cdb — Validate Guix builder phases on FreeBSD
• 0a2e48e — Validate GNU which builder phases on FreeBSD
• 245a47d — Document gaps to real Guix FreeBSD builds
• d62e9b0 — Investigate Guix derivation generation on FreeBSD

Next recommended step:

1. obtain Guile-Git compatible with the fixed local Guile build and re-run the derivation-generation investigation again
2. once checkout configuration succeeds, continue until the next failure boundary is identified among:

• pre-inst-env usability
• derivation emission
• daemon connectivity
• daemon-side /frx/store assumptions

3. continue keeping ~/repos/bdwgc in reserve if later FreeBSD-specific GC/thread issues appear