On Sunday, March 22nd, 2026 at 18:01, Mazen Neifer <[email protected]> wrote: > On Sun, 2026-03-22 at 12:14 +0100, Mazen Neifer wrote: > > > I'm going to upload both a new version of `git2pas` and `gtk3binding` so > > that you can continue your tests. > > Done
I updated to the latest fp-units-gtk3 version and tested again. In short, all good now:) Thank you! Details: - I'm again testing on Debian "testing", which I see has fp-units-gtk3 0.1.1-1 now ( https://packages.debian.org/forky/fp-units-gtk3 ), and `apt dist-upgrade` indeed shown me `Unpacking ... fp-units-gtk3:amd64 (0.1.1-1) over (0.1.0-4)`. - I added "{$linklib gthread-2.0}" to our code (following your advise to use "-lgthread-2.0") in https://github.com/castle-engine/castle-engine/commit/40b5f752a186124652093c4708ae4b431358f594 , to make linking successful. Is it even possible to use the GLib2 unit without linking to gthread-2.0? From CGE, we don't use the relevant routines from gthread-2.0 explicitly (g_thread_init, g_thread_init_with_errorcheck_mutexes), but we still need this "{$linklib gthread-2.0}" to link OK (as they are used in TGThread wrapper?). So it seems that everyone using GLib2 will need to do "{$linklib gthread-2.0}"... So it may be easier to just do it in the GLib2 sources. I see the LCL version of GTK3, which we forked in CGE, avoided the problem just because it doesn't define g_thread_init* at all. Possibly because it was generated from older GTK 3 definitions? - Note that we have a few "deprecated" warnings. I guess the fp-units-gtk3 have been generated using later GTK 3 version than the ones we took from LCL, and e.g. `gdk_screen_get_primary_monitor` (which we indeed use in CGE code explicitly) is deprecated. For now, I will leave it be (that is, compilation with CASTLE_GTK3_UNITS_GTK4PAS will generate a few "deprecated" warnings from GTK3 usage in CGE), to maximize our portability to older GTK 3 versions. - Anyhow, everything works :) One can test it by taking latest CGE master from GitHub ( https://github.com/castle-engine/castle-engine/ ), building our build tool ( https://castle-engine.io/compiling_from_source ) and then ``` # make sure you don't use CGE GTK3 units rm -Rf src/window/gtk/gtk3/ castle-engine compile --project=examples/window/window_menu/ --compiler-option=-dCASTLE_GTK3_UNITS_GTK4PAS ``` - I'm cool if Debian will want to package CGE this way. I.e. in Debian version, you can really remove `src/window/gtk/gtk3/` from CGE and define `CASTLE_GTK3_UNITS_GTK4PAS` in CGE sources, to affect everyone. Then the CGE package in Debian can depend on fp-units-gtk3 and we're happily "centralized the dependency on GTK3". Regards, Michalis
