Dissatified by:

• Potentially conflicts with our patchelf --set-rpath step in

  ghostty/src/build/GhosttyExe.zig

  Line 36 in 73c7943

  run.addArgs(&.{ "patchelf", "--set-rpath", rpath });

  . I should setup Nix and test if this can be converted to an addRPathSpecial() as well.
• This mixes adding install steps into the deps.add() function
• We don't default to preferring a system-installed gtk4-layer-shell dylib.

Open issues in Zig related to RPath handling in the build system ziglang/zig#17373

FWIW, I applied this on top of 73c7943 on origin/main and can confirm that after removing .zig-cache it points to the system library:

[jbowen@bender ~]$ ldd /usr/local/bin/ghostty | grep libgtk4-layer
        libgtk4-layer-shell.so => /usr/local/bin/../lib/libgtk4-layer-shell.so (0x0000731136135000)
[jbowen@bender ~]$

I don't feel qualified to comment on any other aspects of it, but for now I'm going to carry the patch around to survive reboots.

Just a heads up/FYI, but the patch as-is at time of writing no longer cleanly applies after cfea2ea; cf. this bit (the diff of src/build/SharedDeps.zig is large, so GH doesn't expand it by default >:(, so the link doesn't work neatly, but if you do expand it the relevant portions are highlighted.)

I have the library in $PREFIX/lib/ after doing an install with this patch a few days ago, so I'm able to "survive" the loss of $BUILDDIR/.zig-cache/, but I won't be getting new copies of the library installed after building.

I have the library in $PREFIX/lib/ after doing an install with this patch a few days ago, so I'm able to "survive" the loss of $BUILDDIR/.zig-cache/, but I won't be getting new copies of the library installed after building.

@jwbowen Couldn't you stick to an older commit (i.e.: not upgrade for a bit) until this PR is merged?

@jwbowen Couldn't you stick to an older commit (i.e.: not upgrade for a bit) until this PR is merged?

I certainly could, but I really like riding the bleeding edge where I can and am willing to go out of my way to make it work. I'm not concerned with practicality in this case :)

I should have been clearer in my last message that I wasn't complaining about the patch, I just wanted to give a heads up/FYI.

Edit: I updated my previous comment to hopefully make that clearer. I'm very excited about the project :)

Should I leave the install step config at https://github.com/ghostty-org/ghostty/pull/6706/files#diff-3c27f71e7b0ef00072a7d994ae2af66c62b15fc7301fb43aad52bcd96a64da24R653-R654 or is there a better place to organise it?

At this point, an absolute rpath link is made in Debug mode but we default to system integration for gtk4-layer-shell so a source compile will give a system package not found error.

> ~/zig/0.14.0/files/zig build
install
└─ install ghostty
   └─ zig build-exe ghostty Debug native failure
error: error: unable to find dynamic system library 'gtk4-layer-shell-0' using strategy 'mode_first'. searched paths:
  /usr/local/lib64/libgtk4-layer-shell-0.so
  /usr/local/lib/libgtk4-layer-shell-0.so
  /lib64/libgtk4-layer-shell-0.so
  /lib/libgtk4-layer-shell-0.so
  /usr/lib64/libgtk4-layer-shell-0.so
  /usr/lib/libgtk4-layer-shell-0.so
  /usr/local/lib64/libgtk4-layer-shell-0.a
  /usr/local/lib/libgtk4-layer-shell-0.a
  /lib64/libgtk4-layer-shell-0.a
  /lib/libgtk4-layer-shell-0.a
  /usr/lib64/libgtk4-layer-shell-0.a
  /usr/lib/libgtk4-layer-shell-0.a

Otherwise I think this is in a working state where docs for building on Debian 12 (missing gtk4-layer-shell) need -fno-sys=gtk4-layer-shell and should configure custom prefix lib/ paths via ldconfig.