You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Phosh: propose upstream options for static libphosh resource registration #210
Propose upstream Phosh Meson options for consumers that embed libphosh statically, based on the working downstream patches in #186 (related: #190).
Make GResource generation support --manual-register for static embedding.
Ensure the resource object is retained from the static archive and registered exactly once during library initialization; Add opt-in static libphosh embedding for GTK3 #186 calls phosh_register_resource() from phosh_shell_init() using g_once_init_enter/leave.
Preserve the normal shared-library resource behavior and validate both shared and static consumers before dropping our downstream patches.
The aim is to replace the patches to phosh/src/meson.build and phosh/src/shell.c with an upstream-supported build option.
@agx may I ask for a temperature test here? Would you accept patch(es) upstream to make it easier for us to statically link libphosh like this?
The diff is quite minimal (see the relevant changes to the two phosh/ files in #186), and I think we'd be able to wrap in a single meson setup -Dstatic=true option (I guess the code in shell.c to invoke phosh_register_resource would be preprocessor-guarded).
I'm not saying we can't do that, I just try to understand how and why static linking would be preferable for phrog.
Understood. I had assumed that the reasons for why phrog would like to be able to statically link libphosh would be self-evident, which is why I opted to ping you. Your previous response made me realize that this is not the case, and I don't have the energy to engage and communicate with you in the manner that you deserve.
I'm opting to keep this mess downstream, so that you can spend your time/energy elsewhere, where it matters :D
Activity
samcday commentedon Sep 20, 2026
@agx may I ask for a temperature test here? Would you accept patch(es) upstream to make it easier for us to statically link libphosh like this?
The diff is quite minimal (see the relevant changes to the two
phosh/files in #186), and I think we'd be able to wrap in a singlemeson setup -Dstatic=trueoption (I guess the code inshell.cto invokephosh_register_resourcewould be preprocessor-guarded).agx commentedon Sep 20, 2026
I'm confused, weren't you the one favoring shared lib over static linking? Also what does "like this" refer to exactly?
samcday commentedon Sep 20, 2026
All good, never mind then. Thanks!
agx commentedon Sep 21, 2026
I'm not saying we can't do that, I just try to understand how and why static linking would be preferable for phrog.
samcday commentedon Sep 21, 2026
Understood. I had assumed that the reasons for why phrog would like to be able to statically link libphosh would be self-evident, which is why I opted to ping you. Your previous response made me realize that this is not the case, and I don't have the energy to engage and communicate with you in the manner that you deserve.
I'm opting to keep this mess downstream, so that you can spend your time/energy elsewhere, where it matters :D