libghostty-vt-sys: use pkg-config when available

[domenkozar]

Summary

• Try pkg-config first to find libghostty-vt; if available (e.g. NixOS where the wrapper adds rpath automatically), skip the zig build entirely
• Fall back to vendored zig build when pkg-config cannot find the library
• After a vendored build, generate ghostty-vt.pc so downstream consumers can discover the library via pkg-config

Test plan

• Verify vendored build still works (cargo build)
• Verify pkg-config mode works when PKG_CONFIG_PATH points at the generated .pc file
• Verify NixOS rpath is handled automatically via pkg-config wrapper

🤖 Generated with Claude Code

[domenkozar]

Now I see that this landed upstream: https://github.com/ghostty-org/ghostty/pull/12210/changes

[Uzaaft]

lets make this an opt-in feature. @domenkozar

[domenkozar]

lets make this an opt-in feature. @domenkozar

I've made it optional if pkg-config is around, do you want to make it a feature to have one dependency less?

[Uzaaft]

lets make this an opt-in feature. @domenkozar

I've made it optional if pkg-config is around, do you want to make it a feature to have one dependency less?

Yes.

[domenkozar]

Done - CI fails because of github errors.

[Uzaaft]

Sorry for the delay in the last round of review. Doing it now :)

[Uzaaft]

Gonna do one last round of review tomorrow before merging. I expect it to need more edits.

FWIW @domenkozar instead of just slopping out a half-assed PR I’d appreciate it if either you use your AI in a more skilful manner, or just open an issue instead.

[Uzaaft]

@domenkozar I'm struggling to see how the rpath stuff applied to libghostty-vt.
From the docs:

Isn't rpath for like runtime path detection, i.e dlopen etc.
We don't do that in libghostty-vt.

Another thing is that we need stronger compat. guard on the pkg-config path.

build.rs accepts any installed libghostty-vt >= 0.1.0, but this crate’s bindings are checked in from a specific Ghostty snapshot. Since the C API is still unstable, >= 0.1.0 is not enough to guarantee that the discovered native library actually matches the Rust bindings.

This risks turning into link failures for newer symbols or, worse, ABI mismatches.

[domenkozar]

Isn't rpath for like runtime path detection, i.e dlopen etc.

rpath isn't just for dlopen — it's the runtime library search path the dynamic loader uses for any DT_NEEDED entry (including normal -lghostty-vt
links). The vendored build puts libghostty-vt.so.0.1.0 in OUT_DIR, which isn't on the system loader's default path, so without rpath the final binary fails
at startup with "cannot open shared object file." That's the only reason it's there.

Another thing is that we need stronger compat. guard on the pkg-config path.

Given that C API is unstable, I'm not sure if restricting versioning makes sense, but I'm open to change it however you'd like.

[Uzaaft]

Honestly with the C API being unstable, I'm unsure if pkg-config makes sense at all. me and @pluiedev gotta discuss when pre-1.0.0 means a bit more, and the 'guarantees'.

i'll come back to this PR

[domenkozar]

Note that libghostty ships pkg-config, and here we're just consuming it.

It's the only way on linux to make packaging sane, but we can maintain our fork if you decide not to use.

[Uzaaft]

Replaced with #29