macOS: Separate Build Portability From Runtime Authority

This historical address still receives technical citations. The note is newly written. This publication is not the original CloudABI project, is not affiliated with its maintainers, and does not provide former macOS instructions or binaries.

A program that compiles on macOS has passed a build test. It has not proved that its authority model, event behavior, filesystem assumptions, or production runtime is portable. Build portability and runtime portability must be recorded as separate results.

Classify the test

Name what the macOS system is doing. It can be a developer workstation, a continuous-integration runner, a cross-compilation host, a local functional-test host, or a production runtime. Each role exposes different evidence.

For a build host, record compiler and linker versions, SDK, target triple, deployment target, dependency sources, and output artifact. For a runtime host, add OS version, architecture, signing state, entitlements, sandbox configuration, supplied resources, and observed system interfaces.

The minimum record includes:

1. host role;
2. macOS and SDK versions;
3. architecture and target;
4. toolchain and dependency lock state;
5. artifact format and signature state;
6. filesystem and network assumptions;
7. authority supplied at launch; and
8. tests executed on the artifact.

Do not translate by name alone

UNIX-like platforms share many interface names. Their details can still differ. Error codes, event notification, path normalization, file metadata, process controls, socket behavior, and thread scheduling can change application behavior. Treat every host mapping as an adapter with tests.

Keep the portable contract smaller than the host interface. If the workload needs a monotonic clock, request that contract. Do not expose an entire time API only because the host offers it. If the workload needs one prepared directory, pass that resource instead of teaching core logic to discover user-specific paths.

Test the produced artifact elsewhere

A cross-compiler success is evidence about the toolchain. Run the resulting artifact in the actual target environment. Store the artifact hash so that build and runtime results refer to the same bytes. Include negative boundary tests, not only a successful startup message.

If the artifact cannot run on macOS and macOS is only the build host, say so. That is a valid workflow. Portability does not require every host to execute every artifact; it requires the relationship to be explicit.

Keep old project claims in history

The former project source is available in the historical repository. It can explain the earlier project structure and its former platform intentions. It cannot establish current macOS support. This site does not reproduce or update those claims.

A good macOS record ends with a bounded statement: this toolchain built this artifact, these tests ran on this host, and these runtime properties remain untested. That precision prevents a convenient developer platform from becoming an unsupported production promise.