fruix/docs/reports/phase1-guix-which-phase-runner.md

Phase 1.2 follow-up: second Scheme-driven GNU package build validated with GNU which

Date: 2026-04-01

Summary

This step extends the Scheme-driven FreeBSD validation from GNU Hello to a second small GNU/autotools package: GNU which.

Added files:

• tests/native-build/gnu-which-guix-phase-runner.scm
• tests/native-build/run-gnu-which-guix-phase-runner.sh

Like the earlier GNU Hello phase-runner, this harness uses a fixed local Guile build plus Guix's builder-side (guix build gnu-build-system) code to execute a subset of %standard-phases on FreeBSD.

Source identity

The source of truth was the current Guix package definition in ~/repos/guix/gnu/packages/base.scm:

• package: which
• version: 2.21
• Guix nix-base32: 1bgafvy3ypbhhfznwjv1lxmd6mci3x1byilnnkc7gcr486wlb8pl

Translated and verified SHA256:

f4a245b94124b377d8b49646bf421f9155d36aa7614b6ebf83705d3ffc76eaad

Verification command

METADATA_OUT=/tmp/gnu-which-guix-metadata.txt \
  ./tests/native-build/run-gnu-which-guix-phase-runner.sh

The harness used the previously validated fixed local Guile build:

/tmp/guile-freebsd-validate-install/bin/guile

Guix builder phases exercised

The harness ran this subset of (guix build gnu-build-system) %standard-phases:

• set-SOURCE-DATE-EPOCH
• unpack
• configure
• build
• check
• install

Result

The Scheme-driven GNU which build succeeded on FreeBSD 15.0-STABLE amd64.

Observed outcomes:

• source fetch: success
• source hash verification: success
• configure: success
• build: success
• check: success
• install: success
• runtime execution: success

The installed binary was executed as:

PATH=/bin:/usr/bin ./which sh

Observed output:

/bin/sh

Notable findings

1. The Scheme-driven phase-runner pattern is not limited to GNU Hello

This confirms that the earlier GNU Hello success was not a one-off. A second small GNU/autotools package also builds successfully on FreeBSD when driven by Guix's builder-side GNU build logic.

2. GNU which did not emit a test-suite.log, but check still succeeded

The check phase completed successfully, but this package did not leave behind a test-suite.log or testsuite.log file.

That is a useful reminder for future FreeBSD validation harnesses: passing make check cannot always be summarized by the presence of Automake-style test log files.

3. Guix's default --enable-fast-install configure flag is not universally recognized

During configure, GNU which reported:

configure: WARNING: unrecognized options: --enable-fast-install

The build still succeeded. This is a small but useful data point for later FreeBSD/Guix compatibility work: some packages tolerate Guix's standard configure flag set while emitting non-fatal warnings.

4. Older GNU package code triggers modern clang warnings on FreeBSD

GNU which built successfully, but the build emitted several warnings about deprecated non-prototype C function declarations/definitions.

These warnings did not prevent the build, but they are good evidence that older GNU packages may need warning-tolerance assumptions when validated with modern FreeBSD clang toolchains.

5. Runtime linkage again matched a minimal store-like output profile

The resulting which binary linked against:

• libc.so.7
• libsys.so.7

That matches the store-like GNU Hello Scheme-runner result more closely than the earlier /usr/local-staged native shell GNU Hello build.

Additional metadata captured

The harness recorded:

• verified source hash
• selected Guix phase list
• host triplet
• runtime dependencies
• executed command and expected output
• confirmation that the check phase passed

The host triplet recorded was:

x86_64-unknown-freebsd15.0

Because this source tree did not ship an obvious config.guess, the harness fell back to cc -dumpmachine for host-triplet metadata.

What this step demonstrates

This step strengthens Phase 1.2 in two ways:

1. it validates a second GNU/autotools package using Guix builder-side Scheme phases on FreeBSD
2. it reveals a few practical compatibility details already visible at this stage:
   • optional absence of Automake-style test logs
   • non-fatal --enable-fast-install warnings
   • clang warnings in older GNU source

Current implication for the porting effort

With both GNU Hello and GNU which validated through Scheme-driven builder-side Guix phases, the project now has evidence that FreeBSD can already support a narrow but real subset of gnu-build-system execution, provided the locally fixed Guile build is used.

That still falls short of a true package/derivation/store-daemon build, but it further reduces uncertainty around builder-side phase execution itself.

Recommended next step

The next useful step is likely one of:

1. document the concrete remaining gap between these phase-runner prototypes and a real Guix package/derivation build on FreeBSD, or
2. choose a slightly more demanding GNU package with non-trivial inputs to see where builder-side execution first starts needing FreeBSD-specific adaptation