ghosttea-vt-sys 0.4.0

Native linking contract for Ghosttea's pinned Ghostty VT core
docs.rs failed to build ghosttea-vt-sys-0.4.0
Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.

ghosttea-vt-sys

Native artifact and linking contract for Ghosttea's pinned Ghostty VT core. Applications should depend on the safe ghosttea-vt crate instead of using this crate directly.

Repository builds use native/build/ghostty/<target>/install, so one checkout can hold several platforms at once. Consumers can provide an equivalent verified installation with GHOSTTY_VT_PREFIX. Otherwise the crate downloads the target bundle recorded in artifacts.json and verifies the bundle, static library, and public header with SHA-256 before linking.

Supported overrides:

  • GHOSTTY_VT_PREFIX selects an unpacked installation.
  • GHOSTTEA_GHOSTTY_VT_BUNDLE selects a local release bundle.
  • GHOSTTEA_GHOSTTY_VT_BASE_URL redirects downloads to a mirror.
  • GHOSTTEA_GHOSTTY_VT_OFFLINE=1 forbids network fallback.

Every bundle includes the upstream Ghostty license, build metadata, and an SPDX 2.3 SBOM.

Release targets

Target Built by Static archive Reproducible
aarch64-apple-darwin Zig in the pinned Linux builder image lib/libghostty-vt.a yes
x86_64-pc-windows-msvc Zig on a Windows host lib/ghostty-vt-static.lib no

Ghostty installs the Windows static archive under a distinct name because lib/ghostty-vt.lib, the DLL import library, sits beside it.

Windows cannot use the container cross-build: Microsoft's CRT headers and import libraries are not redistributable, so Zig must find an installed MSVC and Windows SDK and therefore builds on a matching host. A container build compiles at fixed in-container paths and reproduces on any host; a native build embeds the building machine's absolute paths in the archive's member table, which no postprocessing step can canonicalize.

reproducible in artifacts.json records that difference and decides how a bundle is trusted:

  • a downloaded or supplied bundle is always verified against its locked checksums, because it is untrusted input;
  • a repository build is verified only when the target is reproducible. It already comes from the pinned Ghostty commit, so its checksum is a reproducibility check rather than a trust boundary.

Because a Windows release cannot be reproduced from the manifest, the bytes that CI publishes are authoritative. The Windows workflow job packages with --allow-mismatch and prints the manifest entry to lock; update artifacts.json from that output when cutting a release.