Advance Guix checkout on FreeBSD

This commit is contained in:
2026-04-01 11:21:50 +02:00
parent 47d31e8992
commit d82195beed
4 changed files with 947 additions and 71 deletions

View File

@@ -637,3 +637,92 @@ Next recommended step:
1. obtain recent `Guile-SQLite3` compatible with the fixed local Guile build and install it into the same local dependency prefix
2. re-run the derivation-generation investigation again to identify the next configure-time or checkout-time blocker after `Guile-SQLite3`
3. continue keeping `/frx/store` as the intended experimental store root and keep `~/repos/bdwgc` in reserve if later FreeBSD-specific GC/thread issues appear
## 2026-04-01 — Phase 1.2 follow-up: remaining checkout Guile prerequisites built; next blocker is `./pre-inst-env guix --version`
Completed work:
- installed the remaining missing host C library dependencies required for the next Guile extension stack:
- `libgcrypt`
- `libgpg-error`
- `lzlib`
- added a reproducible build harness for the remaining mandatory Guix checkout Guile modules:
- `tests/guix/build-local-guile-configure-deps.sh`
- extended the derivation-generation investigation harness to:
- probe local recent-enough availability for:
- `(sqlite3)`
- `(gcrypt hash)`
- `(zlib)`
- `(lzlib)`
- `(semver)`
- run checkout `configure` with:
- `MAKE=gmake`
- continue past successful configuration into:
- `gmake scripts/guix`
- `./pre-inst-env guix --version`
- used the current Guix package definitions as source of truth for the following additional module stack:
- `guile-sqlite3` `0.1.3`
- `guile-gcrypt` `0.5.0`
- `guile-zlib` `0.2.2`
- `guile-lzlib` `0.3.0`
- `guile-semver` `0.2.0`
- built and installed those modules into the same shared local dependency prefix already used for prior checkout prerequisites:
- `/tmp/guile-gnutls-freebsd-validate-install`
- validated successfully that the fixed local Guile can now satisfy all of the remaining configure-time Guix module checks encountered so far:
- `(sqlite3)` with `sqlite-bind-arguments`
- `(gcrypt hash)` with `hash-algorithm` lookup
- `(zlib)` with `make-zlib-input-port`
- `(lzlib)`
- `(semver)`
- 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-guix-checkout-configure-stack-freebsd.md`
Important findings:
- `guile-gcrypt` required an explicit configure workaround on this host:
- `--with-libgcrypt-prefix=/usr/local`
- without it, the package's `libgcrypt-config --libs` parsing produced an unusable shared-library name on FreeBSD
- the currently served upstream `guile-lzlib` `0.3.0` tarball no longer matches the Guix-recorded hash:
- expected from Guix: `a7f99c8d2a143e05ea22db2dc8b9ce6c27cae942162b45ee3015ed9027af0ff2`
- observed from current source URL: `6a2847a303a141bb95b1b5d1a4b975b4dbff9cc590eba377cc8072682e7637ec`
- for local validation, the harness fell back to the matching upstream Git tag and recorded commit:
- `474cee42116295bc0bd2acf12d4d6a766043090e`
- once the remaining Guile modules were present, checkout `configure --with-courage` stopped failing on missing modules
- however, the checkout still needed:
- `MAKE=gmake`
to complete configuration successfully on FreeBSD
- after that, `gmake scripts/guix` succeeded as well
- the next concrete blocker has moved from configuration-time prerequisites to runtime behavior of the uninstalled Guix command path:
- `./pre-inst-env guix --version` prints the version banner, then exits with:
- `Wrong type to apply: #<syntax-transformer leave-on-EPIPE>`
Current assessment:
- the checkout-preparation path on FreeBSD has now progressed beyond the missing mandatory Guile module stack that previously blocked configuration
- the current local validation prefix now contains the required configure-time modules encountered so far for a real Guix checkout
- the first blocker after successful checkout configuration and `scripts/guix` generation is now a runtime Scheme failure in the uninstalled `guix` command path itself
- the work is therefore now meaningfully past “cannot configure” and into “configures, builds `scripts/guix`, but fails at `./pre-inst-env guix --version`
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`
Next recommended step:
1. investigate the `leave-on-EPIPE` runtime failure now blocking `./pre-inst-env guix --version`
2. complete the remaining Phase 1.3 FreeBSD system-call mapping/documentation deliverable so Phase 1 foundations can be closed out cleanly
3. continue keeping `/frx/store` as the intended experimental store root and keep `~/repos/bdwgc` in reserve if later FreeBSD-specific GC/thread issues appear

View File

@@ -0,0 +1,239 @@
# Phase 1.2 follow-up: remaining Guix checkout Guile prerequisites built on FreeBSD; next blocker is `./pre-inst-env guix --version`
Date: 2026-04-01
## Summary
This step cleared the remaining mandatory Guile module prerequisites needed by a Guix checkout `configure --with-courage` run on FreeBSD, and then pushed the checkout investigation past configuration into the next executable boundary.
Added/updated files:
- `tests/guix/build-local-guile-configure-deps.sh`
- updated `tests/guix/run-derivation-generation-investigation.sh`
The result is:
1. the remaining required checkout-time Guile modules can be built successfully on FreeBSD against the fixed local Guile build
2. `configure --with-courage` now succeeds when run with `MAKE=gmake`
3. `gmake scripts/guix` also succeeds
4. the next concrete blocker is no longer a missing Guile module; it is a runtime failure from `./pre-inst-env guix --version`
## Inputs used
### Local Guile
The same fixed local Guile build was used:
- `/tmp/guile-freebsd-validate-install/bin/guile`
### Shared local dependency prefix
This step continued using the shared local prefix already created by earlier prerequisite work:
- `/tmp/guile-gnutls-freebsd-validate-install`
At this point the prefix contains at least:
- Guile-GnuTLS
- Guile bytestructures
- Guile-Git
- Guile-JSON
- Guile-SQLite3
- Guile-Gcrypt
- Guile-zlib
- Guile-lzlib
- Guile-semver
### Host-side packages installed for this step
This step installed the missing C library dependencies required by the remaining Guile extension stack:
```sh
sudo pkg install -y libgcrypt lzlib
```
Installed host packages included:
- `libgcrypt` `1.12.0`
- `libgpg-error` `1.59`
- `lzlib` `1.16`
The host already had:
- `sqlite3` `3.50.4`
## Guix source-of-truth package definitions used
This step used the current Guix package definitions in:
- `~/repos/guix/gnu/packages/guile.scm`
- `~/repos/guix/gnu/packages/gnupg.scm`
- `~/repos/guix/gnu/packages/guile-xyz.scm`
Packages built:
- `guile-sqlite3` `0.1.3`
- `guile-gcrypt` `0.5.0`
- `guile-zlib` `0.2.2`
- `guile-lzlib` `0.3.0`
- `guile-semver` `0.2.0`
Resolved Git commits recorded by the harness:
- `guile-sqlite3` tag `v0.1.3`
- `9405dda61347ff26c57e3be7531dc9dc5a19cf40`
- `guile-gcrypt` tag `v0.5.0`
- `1b637955d40b206d2bdebed5443a545a0412f813`
- `guile-semver` tag `v0.2.0`
- `607ca84c24b8950fdb5aca73e9d53d924e49fc24`
Verified tarball hashes:
- `guile-zlib` `0.2.2`
- Guix nix-base32: `04p9lb3bq5y0k358s8agpksx9x68vzx330cb8jkn4qp3qj7cmnx2`
- SHA256: `a2dbca8ec4e36262a7448b8131fadfc8f4d4f5bc4f218dca98c017bcc6a2e912`
## Important FreeBSD-specific findings
### 1. `guile-gcrypt` needed an explicit libgcrypt prefix on this host
`guile-gcrypt` configure failed initially because its `libgcrypt-config --libs` parsing logic derived an unusable dynamic library name on FreeBSD when `/usr/local/bin/libgcrypt-config` emitted both `-lgcrypt` and `-lgpg-error`.
For local validation, configuring with:
```text
--with-libgcrypt-prefix=/usr/local
```
resolved that issue cleanly.
### 2. Current `guile-lzlib` source URL no longer matches the Guix hash
The current upstream tarball at:
```text
https://codeberg.org/guile-compression/guile-lzlib/archive/0.3.0.tar.gz
```
produced this SHA256 on the host:
```text
6a2847a303a141bb95b1b5d1a4b975b4dbff9cc590eba377cc8072682e7637ec
```
but the current Guix package definition expects:
```text
a7f99c8d2a143e05ea22db2dc8b9ce6c27cae942162b45ee3015ed9027af0ff2
```
To continue local validation, the harness fell back to the upstream Git tag matching version `0.3.0` and recorded:
- fallback commit `474cee42116295bc0bd2acf12d4d6a766043090e`
This is useful independent evidence that the currently served upstream tarball has drifted relative to the hash recorded in Guix.
### 3. `MAKE=gmake` is required for the Guix checkout configure/build path here
Once the remaining Guile modules were available, the Guix checkout no longer failed on missing modules. However, configuration still failed unless it was run with GNU make selected explicitly.
Using:
```text
MAKE=gmake
```
allowed `configure --with-courage` to complete successfully on FreeBSD.
## Validation commands
### Build the remaining required Guile modules
```sh
ENV_OUT=/tmp/guile-configure-deps-env.sh \
METADATA_OUT=/tmp/guile-configure-deps-metadata.txt \
./tests/guix/build-local-guile-configure-deps.sh
```
### Re-run the checkout investigation
```sh
GUILE_EXTRA_PREFIX=/tmp/guile-gnutls-freebsd-validate-install \
METADATA_OUT=/tmp/guix-derivation-investigation-next-boundary.txt \
./tests/guix/run-derivation-generation-investigation.sh
```
The investigation still used the requested experimental directories:
- store: `/frx/store`
- local state: `/frx/var`
- sysconf: `/frx/etc`
## Module validation results
The remaining module checks all succeeded:
```text
sqlite3 module check: ok
gcrypt module check: ok
zlib module check: ok
lzlib module check: ok
semver module check: ok
```
The prefix also still satisfied the earlier requirements:
```text
Existing (gnutls) module in prefix: present
Existing (git) module in prefix: present
Existing (json) module in prefix: present
```
## Updated checkout investigation result
After these module builds, the Guix checkout now behaves as follows on FreeBSD:
1. `configure` without `--with-courage` still fails on the explicit unsupported-platform gate
2. `configure --with-courage` now succeeds when run with `MAKE=gmake`
3. `gmake scripts/guix` succeeds
4. `./pre-inst-env guix --version` prints the version banner but exits with a Scheme runtime error
Observed failure signature:
```text
ice-9/eval.scm:619:8: Wrong type to apply: #<syntax-transformer leave-on-EPIPE>
```
The command still printed the expected banner first:
```text
guix (GNU Guix) 1.5.0.7351-62b61
```
So the current boundary has moved past checkout configuration and script generation into runtime behavior of the uninstalled Guix command itself.
## Additional observations
- `configure` now reports these required modules as available and recent enough:
- Guile-JSON
- Guile-SQLite3
- Guile-Gcrypt
- Guile-Git
- Guile-zlib
- Guile-lzlib
- Guile-semver
- `Guile-Lib` still does not satisfy the optional versioned requirement, but that remains a warning rather than a blocker
- `Guile-SSH` is still unavailable and reported as such during configure, but it also does not block this checkout path here
- using `/frx/store` continues to produce the expected warning that substitutes from `gnu.org` will not be usable
## What this step demonstrates
This step demonstrates that:
1. the Guix checkout has now progressed beyond the long sequence of missing mandatory Guile module prerequisites on FreeBSD
2. the next blocker is now in actual execution of the checkout command path rather than in missing configure-time dependencies
3. the current FreeBSD boundary has advanced from “cannot configure” to “configures and builds `scripts/guix`, but `./pre-inst-env guix --version` fails at runtime”
## Recommended next step
Investigate the `leave-on-EPIPE` runtime failure in the uninstalled Guix command path, while also completing the remaining Phase 1.3 syscall-interface mapping/documentation work needed to close out Phase 1 foundations.