MSYS2 update seems to mess up GTK3 and/or GtkAda

General
1

Today I updated my MSYS2 installation, which has also GTK3 installed, for use in combination with Gtkada. After the update, which transpired to be a complete MSYS2 upgrade, the installed MSYS version is:

$ cat /proc/version
MINGW64_NT-10.0-19045 version 3.6.7-f2802c5f.x86_64 (runneradmin@runnervmixnmc) (gcc version 15.2.0 (GCC) ) 2026-03-15 08:40 UTC

and the installed GTK3 version is:

$ pacman -Ss mingw-w64-x86_64-gtk3
mingw64/mingw-w64-x86_64-gtk3 3.24.52-1 [installed]
    GObject-based multi-platform GUI toolkit (v3) (mingw-w64)

Now, when running Gtkada apps, before and after recompiling Gtkada and the Gtkada apps, they all fail with these messages:

(motd.exe:2412): GLib-GObject-CRITICAL **: 13:49:08.929: cannot register existing type ‘GdkPixbuf’
(motd.exe:2412): GLib-GObject-CRITICAL **: 13:49:08.929: g_type_add_interface_static: assertion ‘G_TYPE_IS_INSTANTIATABLE (instance_type)’ failed
(motd.exe:2412): GLib-GObject-CRITICAL **: 13:49:08.929: g_type_add_interface_static: assertion ‘G_TYPE_IS_INSTANTIATABLE (instance_type)’ failed
(motd.exe:2412): GLib-CRITICAL **: 13:49:08.945: g_once_init_leave_pointer: assertion ‘result != 0’ failed
(motd.exe:2412): GLib-GObject-CRITICAL **: 13:49:08.945: g_object_new_valist: assertion ‘G_TYPE_IS_OBJECT (object_type)’ failed

Then the app hangs, and must be stopped with the MSWindows task manager. Anybody having the same problem? Or better, a solution?

2
  1. How many versions of Gtk do you have installed? In which order are they searched? E.g. Gnat Studio comes with a copy of Gtk. Then there is Alire.
  2. Did you rebuild GtkAda from the sources? AFAIK MSYS does not have GtkAda packaged. C libraries have tendency not to be backward compatible but linking OK.

P.S. For installing GtkAda under Windows see.

3

For GNAT and Gprbuild I use the ones available from GNAT-FSF-builds (26.0w).

I have multiple versions installed, the CE 2021 version and the 25.0.0 version. The last one is build according to your how-to (as mentioned in your P.S.)

the search order is decided by GPR_PROJECT_PATH and / or by renaming the folders these builds reside in. I find that quicker to do then changing the envvar over and over again.

I guess the are hidden behind de ../bin/gps.lib* folders

I did, more or less using the recipe as provide in your P.S. More or less, because I use the GNAT-FSF-builds for GNAT and gprbuild and not the ones that are available for MSYS2.

Given the fact that when I switch back to the 2021 build, I have no trouble running GTK- application from a DOS-box.However, the same application run from an MSYS2 tty produces the errors.

So, it indeed looks like a search path problem. Got some searching, digging and comparing to do …

4

That is the project search path. The executables (including dynamic libraries) are searched in the order: the working directory first then the PATH.

5

After a lot of trial and error (and some stupidity because I was not able to revert to a working MSYS2 environment because of no backup) I found the following

I was triggered by this post: GNAT Studio 2026.2 just released! where a GTK problem was solved by setting two GDK envars: GDK_PIXBUF_MODULE_FILE and GDK_PIXBUF_MODULEDIR.

When I set these envars to the GDK-pixbuf folders of the GNATStudio installation, only a warning remained:
(motd.exe:9832): GdkPixbuf-WARNING **: 15:56:58.626: Error loading XPM image loader: Image type “legacy-xpm” is not supported

In the MSYS2 installation a similar file and folder designated by these 2 envvars are also present. However, setting these envars to

/mingw64/lib/gdk-pixbuf-2.0/2.10.0/loaders

resp to

/mingw64/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache

then the critical errors are back and the application hangs.

Note that critical errors don’t happen with a simple hello_world test file, the application must do something with pixbufs, e.g. using the GtkAda.Dialog packages.

Updating the cache via “gdk-pixbuf-query-loaders --update-cache” has no effect (that is what the GNATStudio doinstall for Linux does.)

(Maybe better to close this topic as it more and more appears to be less and less Ada related…)

6

@dmitry-kazakov Follow up: On a clean windows 10 computer I did everything exactly as you say in your help on installing GtkAda under windows. Still, if I do not export the GDK_PIXBUF_MODULE_FILE envvar, either to the GnatStudio pixbuf folder or to the /msys64/mingw64 folder, Gtkada apps using pixbufs crash and hang. With the export in place a warning remains:

(motd.exe:19332): GdkPixbuf-WARNING **: 17:44:26.237: Error loading XPM image loader: Image type “legacy-xpm” is not supported

This happens for both values mentioned above for GDK_PIXBUF_MODULE_FILE

7

Isn’t that per design? GDK dropped XPM support. You can find some discussions regarding the issue.

From the practical point of view, I do not load XPM files. I use pixbuf embedded into the application. For that I have a small Ada program xpm2gtkada that converts XPM image into Ada packages. See here.

8

Thanks for the link to the xpm2gtkada program.

However, in this case, I do not load XPM files. I use an XMP defined as a Gtkada.Types.Chars_Ptr_Array in Gtkada.Types. The method to load it is Gdk.Pixbuf.Gdk_New_From_Xpm_Data. In the Gtkada 25.0.0 download that function is not declared obsolescent.
So, I does that implies that Gtkada is not up-to-date? Is it still maintained?

9

That is same. Consider it a memory-mapped file. It parses the content in the background with some messy external tool.

AFAIK GtkAda has a complicated script that generates Ada code from headers. The problem is, how do you know if GTK going to ditch a feature leaving its interface there? The warning is in the documentation. But GTK documentation became a quite mess after numerous “face liftings.” I doubt one could maintain a script to scan it too.

(GtkAda documentation is too no more usable. It was very good in the beginning. But bit decay and itchy hands, you know… :zipper_mouth_face:)