[Pkg-pascal-devel] Bug#967284: Bug#967284: Using fp-units-gtk3 ( https://gitlab.com/gtk4pas/gtk3bindings ) for GTK 3 in Castle Game Engine

[Michalis Kamburelis]

On Sunday, March 22nd, 2026 at 18:01, Mazen Neifer <mazen at debian.org> 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