@emersion I noticed you reverted a change to https://github.com/swaywm/sway/wiki/Development-Setup removing the LD_LIBRARY_PATH environment variable addition.
I think it's important to include this, as otherwise the loaded wlroots.so is likely to be that of the system or user installation, leading to instability and chasing bugs that don't exist.
https://github.com/swaywm/sway/wiki/Development-Setup/_compare/d92f5204175c83d6b8045d0ac3c92efeda36ffd0...43b95c09c046c95dd9f5f750e3978b0454d6498f
https://github.com/swaywm/sway/wiki/Development-Setup/_compare/43b95c09c046c95dd9f5f750e3978b0454d6498f...4c16de34af208f4b005d4dee005c0f21d9fd2f82
I initially ran into this issue working on swaybar, but it affects everything linking to the built wlroots.so.
Using a subproject bakes in a RUNPATH/RPATH in the Sway binary. Adding LD_PRELOAD or LD_LIBRARY_PATH shouldn't be necessary.
I'll look into this. Thanks for the info.
It appears ninja install strips RUNPATH from sway's ELF during install.
As well it appears swaybar does not have the same RUNPATH support that sway does.
Also, I'm not sure that running in-build build/sway/sway will execute the in-build build/swaybar/swaybar (and siblings), which was the source of my problem, leading me to ninja install and requiring setting LD_LIBRARY_PATH to develop swaybar.
I wonder how this can be improved. I was hopeful #5724 would enable resolving it, but you note you don't see a good way for that support.
The subproject setup is not suitable for installing. It's just for developing.
Additional note: when developing you can customize the Sway helper binaries via e.g. swaybg_command in the config file.