# 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:

```text
0d5f60154382fee10b114a1c34e785d8b1f492073ae2d3a6f7b147687b366aa0
```

## Verification command

```sh
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:

```text
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.