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.
mnml-libghostty-vt-sys
Raw FFI bindings to Ghostty's libghostty-vt C ABI, generated at build time
by bindgen against vendored headers under vendor/include/ (inside this
crate — self-contained for crates.io consumers, no reach-up to a workspace
root).
This crate exists so mnml owns its Ghostty binding surface directly against
Ghostty's official C headers, rather than depending on a third-party
libghostty-vt-sys on crates.io.
Linking
build.rs clones ghostty at the pinned GHOSTTY_COMMIT (kept in
lock-step with the vendored headers) and runs zig build -Demit-lib-vt,
then links the produced static .a. Needs zig 0.16.0 + git on PATH;
the resulting .a is cached under target/ between cargo runs.
A pkg-config feature is default-on and tried first — if a
libghostty-vt-static.pc shows up on PKG_CONFIG_PATH (e.g. a future
prebuilt setup), that path wins and zig isn't invoked. As of 2026-08-02
no such .pc is checked in, so every host source-builds by default.
Ergonomic wrapper
Application code should depend on mnml-libghostty-vt (the safe wrapper), not this
sys crate directly.
[lib].name is libghostty_vt_sys
The Cargo package is mnml-libghostty-vt-sys but the Rust [lib].name is
set to libghostty_vt_sys, so use libghostty_vt_sys::… is the import
path. mnml itself masks the mnml-prefixed package name via a workspace
alias libghostty-vt-sys = { package = "mnml-libghostty-vt-sys", ... }
in its Cargo.toml; consumers reaching for this crate directly still
write use libghostty_vt_sys::….