asm 0.6.0

asm 0.6.0

Version 0.6.0 builds named target implementations from one project and keeps exact dependencies for each target in one lock file.
It also supports standalone Linux cross builds and optional native-library linking on the native host.
Earlier published versions retain their original bytes, manifests, and licenses.

Host and artifact scope

Host	CLI artifact	Native project target
Linux x86-64	asm-0.6.0-x86_64-linux	x86_64-linux
Linux ARM64	asm-0.6.0-aarch64-linux	aarch64-linux
Apple Silicon, macOS 15 or later	asm-0.6.0-aarch64-macos	aarch64-macos

ISA means instruction set architecture.
ABI means application binary interface: the rules for calls, registers, and data layout.

CLI target	ISA	Operating system	ABI and executable format	CPU requirements
x86_64-linux	x86-64	Linux	Linux x86-64 system calls; little-endian ELF64	No optional CPU features declared.
aarch64-linux	AArch64	Linux	Linux AArch64 system calls; little-endian ELF64	ARMv8-A; no optional CPU features declared.
aarch64-macos	AArch64 (arm64)	macOS 15 or later	Apple arm64, Mach-O, and libSystem	Apple Silicon; no optional CPU features declared.

The Linux qualification runners use Ubuntu 24.04.
A minimum Linux kernel version has not been qualified separately.
macOS artifacts use ad-hoc signing; Developer ID signing and notarization remain unrun.
Intel macOS, Windows, and a native RISC-V64 CLI are outside this release's host scope.

The release retains the existing package artifact scope:

Package	Artifacts
stubbi/asm	Three native CLI executables and the platform source archive.
stubbi/hello	Executables and source archives for x86-64, AArch64, and RISC-V64 Linux.
stubbi/math	One source artifact declared for Linux x86-64.

The hello and math source projects contain seven implementations under targets/<target>/.
Source declarations do not establish CLI host support, registry artifact support, or runtime qualification for every implementation.
Windows and Intel macOS implementations retain their manual build instructions and separate qualification limits.

Select a project implementation

The root asm.toml keeps one package identity and declares independent [target.<id>] tables.
Each table supplies a source path and optional test or native-library fields.
The CLI validates all declarations before creating a build stage.
Source, test, and checker path components cannot start with @, which can select compiler argument files.
Legacy [build] manifests and native build/app and build/test output paths remain supported.

Native builds require GNU Binutils on Linux or Xcode Command Line Tools on macOS.
Linux cross builds require matching GNU cross tools in /usr/bin.
Apple Silicon cross builds require Homebrew LLVM and LLD at the paths in the project contract.

From the hello project root, build another Linux implementation:

asm build --target riscv64-linux
asm test --target riscv64-linux --no-run

The commands produce build/riscv64-linux/app and build/riscv64-linux/test.
The test build reports "executed": false in JSON mode.
Ordinary run and test execute only the native host target.
Foreign execution requests fail before changing build files; Asm never starts an emulator automatically.

Optional link = "c" recipes call named native libraries through the system C ABI.
An optional .c checker compiles without execution and does not become an application backend.
The CLI invokes fixed tools with direct arguments and isolates compiler environment settings.
Cross-target native-library linking still requires a sysroot contract and remains unsupported.
See the native-library contract for fields, tools, and failure behavior.

Keep exact dependencies for each target

V2 locks identify each dependency by package and target.
One package can select different exact versions for different targets.
Target-specific mutations preserve selections for other targets.
Every lock row's metadata is checked before cache changes; only the selected target's cached bytes are required.

Existing v1 locks retain their native-target contract.
A successful named-target mutation upgrades the lock atomically.
Older CLIs reject the v2 header before changing files.
Failed updates preserve the prior lock and failed builds preserve the prior executable.

The Linux x86-64 math dependency uses a new source path:

.include "stubbi/math/0.6.0/x86_64-linux/targets/x86_64-linux/src/min.s"

The 0.5.0 package retains its earlier src/min.s path.
Use each exact version's documented interface and license.

Release evidence and limits

The release workflow requires native command checks on all three CLI hosts.
It compares two clean builds and consumes exact-commit macOS bytes with unskipped native-test evidence.
Linux ARM64 release bytes receive additional QEMU version and target-report checks.
Hello builds retain their native or emulated execution labels.
Publication requires exact source, size, digest, executable-format, source-archive, and release-provenance checks.
This document states the release contract; it does not record a completed release run.

The implementation evidence retains checked inputs, artifact digests, failed attempts, and platform limits.
Those development results do not replace qualification of the published release bytes.
The maintenance procedure requires downloaded-byte checks and a real first-project flow after publication.

The bundled-verifier profile remains disabled.
Installation and manual self-update retain the GitHub CLI 2.93.0-or-later prerequisite and existing provenance policy.
The registry still lacks separately signed expiry, rollback protection, and an emergency-revocation service.
Package digest checks do not establish publisher identity, freshness, or that a program is harmless.
Local builds are not a hermetic sandbox; assembly includes can read other local files.
Hosted public builds and formal verification remain planned.
See the security model for the trust boundaries.