Gtk warning about gdbus.exe not being found on Windows (msys2)

While running my Gtk3 application, built on Windows with msys2, I get a warning about not finding gdbus.exe:

(pixeleditor.exe:10604): GLib-GIO-WARNING **: 19:08:20.306: win32 session dbus binary not found: C:\vice\\gdbus.exe

Why would Gtk complain about a missing gdbus.exe in a directory that is not related to my current project? And we also never used gdbus.exe in VICE (the other project). The dir “C:\vice” is in my Windows $PATH and also in my msys2 $PATH, so perhaps Glib-GIO searches there for gdbus.exe, in which case the question becomes: how does Gtk search for that binary?

DBus is a necessary component of the GTK stack.

The gdbus binary is needed to create a session bus on Windows, which doesn’t have a DBus server spawned automatically when the session starts. When GTK tries to acquire the application’s name on the session bus, it will spawn the DBus server provided by GIO on Windows. The component responsible for searching the gdbus.exe binary is GIO, not GTK.

The gdbus.exe binary should be installed in the same directory as the GIO DLL.

Right, that explains why GIO would look for gdbus.exe in C:\vice:

$ ntldd src/pixeleditor.exe
        KERNEL32.dll => C:\WINDOWS\SYSTEM32\KERNEL32.dll (0x00000000006a0000)
        msvcrt.dll => C:\WINDOWS\SYSTEM32\msvcrt.dll (0x00000000006a0000)
        libcairo-2.dll => C:\vice\libcairo-2.dll (0x00000000006a0000)
        libgdk-3-0.dll => C:\vice\libgdk-3-0.dll (0x0000000000fe0000)
        libgio-2.0-0.dll => C:\vice\libgio-2.0-0.dll (0x0000000001110000)
        libglib-2.0-0.dll => C:\vice\libglib-2.0-0.dll (0x00000000011f0000)
        libgobject-2.0-0.dll => C:\vice\libgobject-2.0-0.dll (0x00000000006a0000)
        libgtk-3-0.dll => C:\vice\libgtk-3-0.dll (0x0000000002300000)

My binary finds the libgio DLL in C:\vice and thus expects to find gdbus.exe there. When I rename C:\vice. to C:\vice.bak, my application finds libgio (and other required libs) in the msys2 tree:

$ ntldd src/pixeleditor.exe
        KERNEL32.dll => C:\WINDOWS\SYSTEM32\KERNEL32.dll (0x00000000006a0000)
        msvcrt.dll => C:\WINDOWS\SYSTEM32\msvcrt.dll (0x00000000006a0000)
        libcairo-2.dll => C:\msys64\mingw64\bin\libcairo-2.dll (0x0000000000dd0000)
        libgdk-3-0.dll => C:\msys64\mingw64\bin\libgdk-3-0.dll (0x00000000010d0000)
        libgio-2.0-0.dll => C:\msys64\mingw64\bin\libgio-2.0-0.dll (0x0000000001200000)
        libglib-2.0-0.dll => C:\msys64\mingw64\bin\libglib-2.0-0.dll (0x0000000001290000)
        libgobject-2.0-0.dll => C:\msys64\mingw64\bin\libgobject-2.0-0.dll (0x00000000006a0000)
        libgtk-3-0.dll => C:\msys64\mingw64\bin\libgtk-3-0.dll (0x0000000002340000)

So it looks like I have to be careful with $PATH. After removing ‘/c/vice’ from $PATH in the msys2 shell, and renaming c:\vice.bak back to c:\vice, my application properly finds the gdbus.exe in /msys64/bin/ and links to the DLL’s in /msys64/bin.

You’re strongly encouraged to never depend on “system” or shared installations of your dependencies on Windows. You should always copy all the dependencies, including ancillary binaries, into your application’s directory. This also makes it easier to package and distribute.

Yes, I do that for Gtk3 applications, not yet for this one since I haven’t got to creating make install or make bindist rules.
Once I do, it’ll be similar to how Windows distributions of the VICE emulator are done: copy all DLLs and required binaries (such as gspawn-winxx-helper*.exe) into a directory and use subdirs such as share/ and lib/ for glib schemas, icons, gdk-pixbuf loaders and such.

1 Like

Now that we’re talking about properly distributing Gtk applications on Windows, I think we (VICE) don’t exactly follow the rules, we store our bins in the root of a dir, while I seem to recall reading some docs claiming binaries should be installed in .bin/ (with bla.exe then looking in …/share etc for supporting files).

Are there any docs about creating a proper Windows distribution with Gtk? We’ve been working on making VICE respect the ‘normal’ Linux/BSD/XDG rules, might as well get the Windows stuff right.

There are no hard rules for the directory layout of projects on Windows.

The path of least resistance is typically to have your binary in the same directory are your DLLs; you can manipulate the environment from within your binary and change the look up paths for most other assets—things like GSettings schemas, icon theme paths, etc.—but if you don’t want to, following the same layout as a Linux installation is fairly easy.

In many cases, like ancillary files and other assets, it’s recommended to use GResource; GTK can load a lot of things from resource paths, like UI descriptions, themed icons, etc.

1 Like

With VICE we use a gresource file containing some icons, logos etc and load that from the filesystem, since we have 11 different emulator binaries, so compiling in the gresources via .c/.h files would only add bloat. We also don’t use UI descriptor files, since that’s not flexible enough to allow reusing dialogs or custom widgets for those emulators.

With my own project I do compile/link in the gresource.{c,h} and use UI descriptor files since it’s a single binary and it doesn’t use 200-600+ interacting settings like VICE.

But anyway, I think the original question was answered, so thanks for that.

1 Like

If you want to add the Gtk+ runtime for Windows to an installer for your project, you may be interested in

The installers that I provide can be used to install Gtk system wide, but you can also easily include them into your own installation scripts (like Inno Setup or NSIS) and ensure they are available only to your own binaries.

The libraries and executables are fetched from the MSYS2 project, so you will need to use that to compile and link your own code for this to work, but that seems to be the case already :slight_smile:

Oh and it contains gdbus.exe :wink:

1 Like

Thanks for that, but currently it won’t be of much use to us. We currently ship only the gtk/glib libs we used to compile against, and a bunch of other non-gtk libs depending on configure options.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.