Adapt GNU build phases for FreeBSD

This commit is contained in:
2026-04-01 12:18:55 +02:00
parent e404e2e08d
commit eb0d77cdf0
5 changed files with 718 additions and 0 deletions

View File

@@ -1079,3 +1079,76 @@ Next recommended step:
2. carry forward the concrete real-checkout runtime blocker for later integration work:
- investigate the `leave-on-EPIPE` failure in `./pre-inst-env guix --version`
3. continue using `/frx/store` rather than `/gnu/store` for FreeBSD store experiments
## 2026-04-01 — Phase 3.1 completed: reusable FreeBSD GNU build-system adaptation validated across five packages
Completed work:
- added a reusable Scheme runner for FreeBSD-adapted GNU package builds:
- `tests/build-system/gnu-package-freebsd-phase-runner.scm`
- added a shell wrapper for the generic runner:
- `tests/build-system/run-gnu-package-freebsd-phase-runner.sh`
- added a five-package validation matrix:
- `tests/build-system/run-freebsd-gnu-package-matrix.sh`
- wrote the Phase 3.1 report:
- `docs/reports/phase3-freebsd-gnu-build-system.md`
- ran the matrix successfully and captured summary metadata under:
- `/tmp/freebsd-gnu-package-matrix-summary.txt`
Important findings:
- the build adaptation is now centralized rather than package-specific and is applied through a dedicated pre-configure FreeBSD environment phase
- the adaptation consistently uses:
- GNU `gmake` via a `make` path shim
- FreeBSD Clang via `cc`/`gcc` and `c++`/`g++` tool shims
- `CONFIG_SHELL=/bin/sh`
- `/usr/local` include/library/pkg-config search paths
- five representative GNU packages from current Guix package definitions now build successfully through the adapted runner on the current FreeBSD amd64 host:
- `hello` `2.12.3`
- `which` `2.21`
- `time` `1.9`
- `patch` `2.8`
- `nano` `8.7.1`
- the resulting binaries executed correctly with deterministic checks appropriate to each package:
- `hello` -> `Hello, world!`
- `which` -> `/bin/sh`
- `time` -> `time (GNU Time) 1.9`
- `patch` -> `GNU patch 2.8`
- `nano` -> `GNU nano, version 8.7.1`
- the matrix also validated a package with meaningful runtime dependencies:
- `nano` linked against FreeBSD/base and `/usr/local` libraries including `libintl`, `libmagic`, `libncursesw`, `libtinfow`, and `libz`
- one package-specific FreeBSD test boundary was recorded explicitly instead of being hidden:
- `time` required `RUN_TESTS=0` because the upstream `time-max-rss` test was not reliable on this host
Current assessment:
- Phase 3.1 is now satisfied on the current prototype track
- the main question has shifted from “can adapted GNU builder phases run on FreeBSD?” to “how should FreeBSD system components themselves be described and installed as profile-usable packages?”
- the next step is therefore Phase 3.2: define a minimal FreeBSD package set with explicit dependencies and validate profile-style installation/usability
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`
- `c0a85ed``Build local Guile-GnuTLS on FreeBSD`
- `15b9037``Build local Guile-Git on FreeBSD`
- `47d31e8``Build local Guile-JSON on FreeBSD`
- `d82195b``Advance Guix checkout on FreeBSD`
- `9bf3d30``Document FreeBSD syscall mapping`
- `7621798``Prototype FreeBSD jail build isolation`
- `d65b2af``Prototype FreeBSD build user isolation`
- `e404e2e``Prototype FreeBSD store management`
Next recommended step:
1. complete Phase 3.2 by defining a minimal FreeBSD system package set with explicit dependency relationships and profile-style installation validation
2. carry forward the concrete real-checkout runtime blocker for later integration work:
- investigate the `leave-on-EPIPE` failure in `./pre-inst-env guix --version`
3. continue using `/frx/store` rather than `/gnu/store` for future FreeBSD store experiments when the prototype work needs a persistent store root