self/fruix
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Validate GNU which builder phases on FreeBSD

Browse Source
This commit is contained in:
Steffen
2026-04-01 09:49:54 +02:00
parent c944cdba5f
commit 0a2e48eda4
4 changed files with 474 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
docs/PROGRESS.md
View File

@@ -236,3 +236,69 @@ 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

157
docs/reports/phase1-guix-which-phase-runner.md Normal file
View File

@@ -0,0 +1,157 @@
# 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:
```text
f4a245b94124b377d8b49646bf421f9155d36aa7614b6ebf83705d3ffc76eaad
```
## Verification command
```sh
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:
```text
/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:
```sh
PATH=/bin:/usr/bin ./which sh
```
Observed output:
```text
/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:
```text
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:
```text
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