Build GTK3 with meson using MSYS2 on Windows fails

Trying to build stable release 3.24.21 of GTK3 from the git sources using MSYS2 on Windows following these instructions. I’ve successfully built this version earlier from the tar.xz sources and MSYS2 configure/make so I know I have all the required dependencies.

After cloning the gtk repo, I checkout the desired version. Then I run meson as described in the instructions.

git checkout -b issue1234 3.24.21
meson setup --prefix /opt/gtk3 _build

For some reason, meson fails to find either pkg-config or cmake, both of which exist in the PATH. It also believes it needs to build the latest version of glib2 although a sufficient version exists. When meson tries to build glib2, it bombs out with:

subprojects/glib/ ERROR: Entry _WIN32_WINNT not in configuration data.

_WIN32_WINNT was presumably set in the following glib/ block (it’s the only place in the file where it’s set):

# Windows SDK requirements and checks
if host_system == 'windows'
  # Check whether we're building for UWP apps
  code = '''
  #include <windows.h>
  #error "Not building for UWP"
  if cc.compiles(code, name : 'building for UWP')
    glib_conf.set('G_WINAPI_ONLY_APP', true)
    # We require Windows 10+ on WinRT
    glib_conf.set('_WIN32_WINNT', '0x0A00')
    # We require Windows 7+ on Win32
    glib_conf.set('_WIN32_WINNT', '0x0601')

And the last line of this block in glib/ is where it bombs:

if has_syspoll and has_systypes
  poll_includes = '''
elif has_winsock2
  poll_includes = '''
      #define _WIN32_WINNT @0@
      #include <winsock2.h>'''.format(glib_conf.get('_WIN32_WINNT'))

Any ideas about what’s going on? Why aren’t pkg-config/cmake found? Why the need to build glib2? And why the build failure?

1 Like

I don’t know what’s going wrong with Meson here. What version are you using?

I’m using meson 0.54.3, the latest version available from MSYS2.

I see a version 0.55.0 came out three weeks ago, but the stable GTK sources I’m trying to build are a bit older than that. Any ideas on things to try? I’m at a brick wall on this.

CMake is irrelevant: nothing used CMake in the GTK stack. The fact that Meson cannot find pkg-config makes me thing you don’t really have in your PATH from inside the MSYS2 shell that you’re using.

You’ll have to ask the MSYS2 and/or Meson developers for help.

GTK3 has an MSYS2 pipeline, and it successfully build GTK 3.24 a day ago. You may want to copy what it does.

I’ll check out the pipeline you linked to. Thanks.

BTW: pkg-config is in my MSYS2 path.

The pipeline sets the PKG_CONFIG_PATH env var to an absolute Windows path.

The default PKG_CONFIG_PATH setting that MSYS2 assigns is a Linux relative path, but to the same locations that the pipeline uses.


I’ve tried several ways to assign it an absolute Windows path–including defining it in a Windows shell and hoping MSYS2/bash would inherit it–but all have been unsuccessful.

Those paths are built-in. That environment variable is for additional paths. If you don’t have any additional paths, then don’t set that variable, at all. The MinGW versions of pkg-config automatically translate between POSIX and Windows paths.

Here is an example from my system (note that pkg-config finds “/mingw64/lib/pkgconfig/epoxy.pc”):

$ declare -p PKG_CONFIG_PATH
declare -x PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"

$ ls -R /usr/local/lib
libslang.a  pkgconfig


$ cat /usr/local/lib/pkgconfig/slang.pc

Name: slang
Description: S-Lang programming library and interpreter
Version: 2.3.3
Libs: -L${libdir} -lslang
Libs.private:  -ldl  -lm
Cflags: -I${includedir}

$ pkg-config --cflags --libs slang
-IC:/msys64/usr/local/include -LC:/msys64/usr/local/lib -lslang

$ pkg-config --libs --cflags epoxy
-IC:/msys64/mingw64/include -LC:/msys64/mingw64/lib -lepoxy

Thanks for the information.

MSYS2 sets the PKG_CONFIG_PATH env var to that default value. I tried clearing the variable, but meson still doesn’t find pkg-config. It’s a recent, fresh MSYS2 installation with everything updated and using the mingw64 repo’s version of Python, as the meson installation instructions state.

Thanks again.

This looks very similar to .

MSYS2’s multiple shells can easily cause issues if you’re not careful - are you using the correct MSYS shell and corresponding meson package?

Yes! That link describes my issue exactly.

Following the information in the link, I verified that I was running the MSYS64 shell and had installed mingw-w64-x86_64 versions of the prerequisites, except meson…the exact situation that the issue’s poster experienced.

I installed the mingw64 version of meson and will try a new build with renewed hope.

Thanks much for that great catch!

Bah! I NEVER use pacman. pacboy saves me a lot of typing, and it helps me to avoid that problem.

FYI: The meson build runs to completion now! Thanks much!

Unfortunately, ninja bombs out trying to link libgtk-4-0.dll with glib/gobject/libobject-2.0.dll. All the sources compiled cleanly using the meson --buildtype=debug option. The .ninja_log file provides no clues.


But the good news is that the meson hurdle has been cleared. Thanks again!

Yes, pacboy would have gotten me the desired meson package. Good tip! Thanks!

That looks like this issue we had with sub projects on our CI pipeline. It seems the only solution is to install the dependencies.

Thanks for the info. I think you’ve correctly identified the situation.

Unfortunately, MSYS2 doesn’t have the latest builds of the gtk4 dependencies. Scanning the gtk file, I didn’t see any build-and-install-dependencies type target. Installing the dependencies manually goes beyond my current capabilities.

Is there a ninja command that would build/install just the gtk subprojects?

Thanks again for your help!

When I wrote “you will have to install the dependencies”, I meant: you will need to build GLib, Pango, and every other dependency that is currently a sub-project, separately and install them into the same prefix as you are going to use for GTK. In other words: you cannot use them as sub-projects until somebody familiar with MSYS2 understands why the linker is failing.

Thanks for the clarification.

Building and installing each sub-project manually was my understanding from your previous message. But doing that (and building and installing their dependencies) is not a task I’ll be able to accomplish. Meanwhile, ninja appeared to successfully build each sub-project, so I was hoping for a target where it would also install them. It seems like my best option at this point is to install Linux on an available computer.

Thanks again.

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