ghostty-org
Regression: linking gtk4-layer-shell without system integration uses relative instead of absolute path
#6632 tracked the use case of linking against gtk4-layer-shell without system integration mode (i.e. -fno-sys=gtk4-layer-shell). A recent (?) change (either in Zig or Ghostty) now causes this library to be linked using relative paths instead of absolute paths:
This seems to be broken after zig 0.15 for
-fno-sys=gtk4-layer-shell? Prior to zig 0.15, building with-fno-sys=gtk4-layer-shellgives a binary that has:libgtk4-layer-shell.so => /home/shuhao/apps/ghostty/.zig-cache/o/22ae033a3326d2846087d1173b5052e4/libgtk4-layer-shell.so (0x00007fa0775ab000)But after, it seems to be pointing to a relative path:
libgtk4-layer-shell.so => .zig-cache/o/d984b353071b0fbbf6cf6b695586f76a/libgtk4-layer-shell.so (0x000071df2d157000)This is causing ghostty to not launch.
Originally posted by @shuhaowu in #6632
This prevents Ghostty from being launched from anywhere outside of the source directory where it was built.
This smells like something that never should have worked in the first place. Relying on .zig-cache is never a good idea since it by design is a cache folder that can be removed at any moment, and we should instead install gtk4-layer-shell to $PREFIX/lib and link it with Ghostty there.
I think the proper solution is having the $PREFIX/lib install path be on the LD_LIBRARY_PATH or default library paths[^1]
Instead of relying on the rpath leftover from zig build system. I believe it exists so that executables compiled during a build can be run as a build step, even if they depend on shared libs also compiled as a step. It's not intended to be used/depended on for functionality after build time.
Would documenting this problem or explicitly stripping the rpath be longer term answers?
[^1]: https://www.man7.org/linux/man-pages/man8/ld.so.8.html
For anyone else with this issue, patchelf --set-rpath can be used to update the rpath in the binary back to an absolute path.