fruix/docs/reports/phase1-native-gnu-hello.md

Phase 1.2 started: native FreeBSD GNU Hello build exercise

Date: 2026-04-01

Summary

This step begins Phase 1.2 from docs/PLAN.md by validating a minimal native GNU autotools build on FreeBSD.

A reusable harness was added:

• tests/native-build/run-gnu-hello.sh

The harness downloads GNU Hello, verifies the source hash against the current Guix package definition, configures it, builds it, installs it into a staging directory, and runs the resulting binary.

Source and integrity verification

The exercise uses the same GNU Hello release currently referenced by the Guix source tree at ~/repos/guix/gnu/packages/base.scm:

• package: hello
• version: 2.12.3
• Guix nix-base32 hash: 183a6rxnhixiyykd7qis0y9g9cfqhpkk872a245y3zl28can0pqd

The harness converts the Guix nix-base32 hash to hexadecimal using (guix base32) and verifies the downloaded tarball with sha256(1).

Verified SHA256:

0d5f60154382fee10b114a1c34e785d8b1f492073ae2d3a6f7b147687b366aa0

Verification command

METADATA_OUT=/tmp/gnu-hello-metadata.txt ./tests/native-build/run-gnu-hello.sh

Result

The native FreeBSD build succeeds.

Observed outcome:

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

Observed program output:

Hello, world!

Environment used

From the captured metadata:

• host: FreeBSD 15.0-STABLE amd64
• compiler: cc (FreeBSD clang version 19.1.7)
• make tool: make (FreeBSD base make)
• host triplet: x86_64-unknown-freebsd15.0
• configure command: CC=cc .../configure --prefix=/usr/local

Notable findings

1. A simple GNU autotools package builds with FreeBSD base make

GNU Hello built successfully using FreeBSD's native /usr/bin/make.

This is a useful contrast with the earlier local Guile build work, where GNU gmake was required. So for Phase 1.2, the immediate result is:

• some standard GNU autotools packages can build on FreeBSD with native base tooling
• but more complex packages still may require GNU-specific build tools

2. Runtime dependencies reflect FreeBSD userland packaging choices

The staged hello binary is dynamically linked and pulls in:

• libiconv.so.2
• libintl.so.8
• libc.so.7
• libthr.so.3
• libsys.so.7

This is relevant for later Guix porting work because even a minimal GNU package on FreeBSD picks up non-Linux runtime linkage patterns that will need to be modeled correctly.

3. Guile was only needed for hash translation, not for the build itself

The build harness uses Guile plus (guix base32) only to translate the Guix package hash into hexadecimal for source verification.

The actual package build is performed entirely with native FreeBSD/GNU userland tools:

• fetch
• sha256
• bsdtar
• cc
• make

What this step demonstrates

This step demonstrates that the current FreeBSD host can already perform the basic lifecycle expected of a future adapted gnu-build-system flow:

1. fetch source
2. verify source integrity
3. unpack source
4. run configure
5. compile
6. install into a staging directory
7. execute the resulting binary
8. collect basic input/output metadata

Remaining gaps relative to the full Phase 1.2 goal

This is a native build exercise, not yet a real Guix package build.

Still outstanding:

• building the package through Guix abstractions rather than a shell harness
• recording Guix-style dependency graphs and derivation-like metadata
• Linux-vs-FreeBSD output/process comparison from the same package build
• trying at least one more representative GNU package beyond Hello

Recommendation for the next step

Continue Phase 1.2 by either:

1. creating a second native build exercise for another small GNU autotools package, or
2. starting a very small FreeBSD-specific prototype of gnu-build-system-like phase execution in Scheme using the now-validated local Guile path

The current GNU Hello harness provides a good baseline for either direction.