We're hiring!
*

Build your own application with GTK 4 as a Meson subproject!

Xavier Claessens avatar

Xavier Claessens
April 29, 2021

Share this post:

Welcome back to my blog series on GTK 4 and Visual Studio! If you're just joining us, make sure to take a look at the previous episode, where we saw how we can easily build and run GTK 4 on Windows with Visual Studio.

Now, on to the news. First up, GTK 4 now builds out of the box without applying any extra patches, thanks to the last remaining fix (!3135) being merged.

Furthermore, and more importantly, you can now build GTK 4 as a Meson subproject for your own application! This is not only useful for Windows builds, but also for many Linux distributions that do not yet package a recent enough version of GTK 4 and/or its dependencies.

To make your own application fall back to build GTK 4 as a Meson subproject in case the system does not provide it, simply add the following subprojects/gtk.wrap file. This file instructs Meson on where to fetch the gtk4 dependency if it cannot be found on the system:

[wrap-git]
directory=gtk
url=https://gitlab.gnome.org/GNOME/gtk.git
push-url=ssh://git@gitlab.gnome.org:GNOME/gtk.git
revision=master
depth=1

[provide]
dependency_names=gtk4

That's it! When your meson.build does dependency('gtk4'), Meson will automatically configure a GTK4 subproject if GTK4 is not found on the system. It will also fetch and build any GTK4 dependencies which are not found, for example glib, which could be outdated on your system as well.

Build GtkSourceView 5.0 with Visual Studio

Recently, Christian Hergert announced the release of GtkSourceView 5.0, the first application ported to GTK4.

I'm happy to report that all needed fixes to make it build on Windows with GTK4 as a Meson subproject have been merged on time!

Here is how to fetch and build the GtkSourceView master branch, including GTK4 and all of its dependencies, on Windows with Visual Studio. Note that -Dinstall_tests=true is only needed to have the test application installed, it is not needed if you're only interested in the library.

Make sure to follow instructions from the previous blog post to set up your build environment.

C:\src>git clone https://gitlab.gnome.org/GNOME/gtksourceview.git
C:\src>cd gtksourceview
C:\src\gtksourceview>meson setup build --prefix C:/gnome -Dinstall_tests=true
C:\src\gtksourceview>meson compile -C build
C:\src\gtksourceview>meson install -C build

Collabora - x64 Native Tools Command Prompt for VS 2019

Run the test application:

C:\src\gtksourceview>C:\gnome\bin\gtksourceview5-widget.exe

Collabora - GtkSourceView Test

Bonus: Build GTK4's GStreamer media backend with Visual Studio

GTK 4 has an optional dependency on GStreamer for its multimedia widgets. It is possible to also build GStreamer and all its dependencies, including FFmpeg, as Meson subprojects for GTK 4, or even your own application! Simply add gst-build as a subproject: subprojects/gst-build.wrap.

[wrap-git]
url=https://gitlab.freedesktop.org/gstreamer/gst-build.git
revision=master

[provide]
dependency_names=gstreamer-player-1.0

At the time of writing, there is still a build issue (#152) but this can easily be worked around by deleting related code in subprojects/gst-build/meson.build. A proper fix is still needed.

Collabora - GTK4's GStreamer media backend with Visual Studio

What's next?

Now that you can use GTK 4 as a subproject of a real application, and build both GtkSourceView 5.0 and GTK4's GStreamer media backend, what's next? Add Windows CI to GTK 4? Stay tuned!

And of course, if you have any questions about GTK4 and GStreamer on Windows, please get in touch!

Comments (16)

  1. collahelp:
    Jul 07, 2021 at 10:38 AM

    I think your PR !236 in the #152 issue you mentioned needs your attention

    Reply to this comment

    Reply to this comment

    1. Xavier Claessens:
      Aug 31, 2021 at 07:38 PM

      Thanks for pointing this out. It has been fixed already (https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/259) and I wrote a fix for that in Meson (https://github.com/mesonbuild/meson/pull/9192) to not have to repeat that in every project any more.

      Reply to this comment

      Reply to this comment

  2. Vinicius:
    Aug 31, 2021 at 07:01 PM

    I have a problem trying to compile gtksourceview:

    gtk| Run-time dependency gstreamer-player-1.0 found: NO (tried pkgconfig and cmake)

    subprojects\gtk\modules\media\meson.build:44:0: ERROR: Dependency "gstreamer-player-1.0" not found, tried pkgconfig and cmake

    A full log can be found at C:\src\gtksourceview\build\meson-logs\meson-log.txt

    Apparently it complains the lack of gstreamer-player-1.0... I tried to add gst-build as a subproject but I couldn't solve that build issue (it doesn't worked for me)

    I could compile gst-build as a standalone project with success... Is there a way to make meson search external dependencies to locate this gstreamer I had compiled?

    Regards,
    Vinicius

    Reply to this comment

    Reply to this comment

    1. Xavier Claessens:
      Aug 31, 2021 at 07:45 PM

      Unfortunately this has regressed. This is intentional change made by GTK maintainers because they do not want people to build GTK without GStreamer. I personally totally disagree with their decision.

      You can still disable GStreamer support by adding `-Dgtk:media-gstreamer=disabled` meson option.

      If you wish to build GTK with GStreamer support, you need to write subprojects/gst-build.wrap with to information to download gst-build and dependencies it provides. GTK maintainers should push one, I'm not sure why they haven't yet.

      Reply to this comment

      Reply to this comment

      1. Vinícius de Ávila Jorge:
        Aug 31, 2021 at 10:19 PM

        I started over and tried to compile gtksourceview using gst-build as a subproject. But I'm still getting the error:

        gtk| Dependency gstreamer-player-1.0 found: YES 1.19.1.1 (overridden)
        gtk| Dependency gstreamer-gl-1.0 found: YES 1.19.1.1 (overridden)

        subprojects\gtk\modules\media\meson.build:59:10: ERROR: Dependencies must be external dependencies

        A full log can be found at C:\src\gtksourceview\build\meson-logs\meson-log.txt

        SEE meson-log.txt (last lines):
        Message: Building subprojects: gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-bad, gst-plugins-ugly, gst-libav, gst-rtsp-server, gst-devtools, gst-integration-testsuites, gst-editing-services, gst-examples
        Pkg-config binary for MachineChoice.HOST is cached.
        Determining dependency 'gstreamer-full-1.0' with pkg-config executable 'C:\\pkg-config\\bin\\pkg-config.EXE'
        env[PKG_CONFIG_PATH]: c:\GNOME\lib\pkgconfig
        Called `C:\pkg-config\bin\pkg-config.EXE --modversion gstreamer-full-1.0` -> 1

        CMake binary for 1 is cached.
        Preliminary CMake check failed. Aborting.
        Run-time dependency gstreamer-full-1.0 found: NO (tried pkgconfig and cmake)
        Program gst-env.py found: YES (c:\users\vinicius\appdata\local\programs\python\python39\python.exe C:\src\gtksourceview\subprojects\gst-build\gst-env.py)
        Program git-update found: YES (c:\users\vinicius\appdata\local\programs\python\python39\python.exe C:\src\gtksourceview\subprojects\gst-build\git-update)
        Build targets in project: 1918
        Subproject gst-build finished.

        Dependency gstreamer-player-1.0 found: YES 1.19.1.1 (overridden)
        Dependency gstreamer-gl-1.0 found: YES 1.19.1.1 (overridden)

        subprojects\gtk\modules\media\meson.build:59:10: ERROR: Dependencies must be external dependencies

        Any idea? Thanks in advance

        Reply to this comment

        Reply to this comment

        1. Xavier Claessens:
          Aug 31, 2021 at 10:55 PM

          That's indeed another regression since I wrote this blog post, thanks for spotting it. I commented there: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3506#note_1260233.

          Reply to this comment

          Reply to this comment

      2. Vinícius de Ávila Jorge:
        Aug 31, 2021 at 10:21 PM

        I wanted to compile with GStreamer support but if it continues to give me headaches, I will give up and pass this option to compile without this support

        Reply to this comment

        Reply to this comment

        1. Xavier Claessens:
          Sep 01, 2021 at 03:00 PM

          Made a fix already: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3910. You can comment there if it doesn't work for you.

          Reply to this comment

          Reply to this comment

    2. Xavier Claessens:
      Aug 31, 2021 at 07:47 PM

      Note that if you built and installed gst-build, you need to point PKG_CONFIG_PATH to the place it installed its pc files, so meson will find it when configuring GTK.

      Reply to this comment

      Reply to this comment

      1. Vinícius de Ávila Jorge:
        Aug 31, 2021 at 10:23 PM

        I tried this way and worked, but during ninja build pass, i started to have many errors, complaining lack of some dll, is thene any other variable I should set to make the program find these libs? some kind of LD_LIBRARY_PATH?

        Reply to this comment

        Reply to this comment

        1. Xavier Claessens:
          Aug 31, 2021 at 10:56 PM

          On Windows there is no LD_LIBRARY_PATH, it search dlls in PATH. But I never tried this workflow myself, so I'm not sure how to get it working.

          Reply to this comment

          Reply to this comment

          1. Vinícius de Ávila Jorge:
            Sep 01, 2021 at 05:10 PM

            Ok. I imagined that. I will try to add more to PATH variable. I'm going to clean the mess I did and try to start over again.

            Reply to this comment

            Reply to this comment

  3. Vinícius de Ávila Jorge:
    Aug 31, 2021 at 07:16 PM

    I'm using MSVC 2019 in Windows 11

    Reply to this comment

    Reply to this comment

  4. Vinícius de Ávila Jorge:
    Sep 01, 2021 at 01:58 AM

    Now I have another error compiling gsourceview and disabling gstreamer:

    [1825/4074] Linking target subprojects/libjpeg-turbo-2.1.0/jpeg-8.2.2.dll
    FAILED: subprojects/libjpeg-turbo-2.1.0/jpeg-8.2.2.dll subprojects/libjpeg-turbo-2.1.0/jpeg-8.2.2.pdb
    "link" @subprojects/libjpeg-turbo-2.1.0/jpeg-8.2.2.dll.rsp
    Criando biblioteca subprojects\libjpeg-turbo-2.1.0\jpeg.lib e objeto subprojects\libjpeg-turbo-2.1.0\jpeg.exp
    jcphuff.c.obj : error LNK2019: símbolo externo não resolvido, ___builtin_ctzl, referenciado na função _count_zeroes
    subprojects\libjpeg-turbo-2.1.0\jpeg-8.2.2.dll : fatal error LNK1120: 1 externo não resolvidos
    [1834/4074] Compiling C++ object subprojects/harfbuzz/src/harfbuzz-subset.dll.p/hb-subset.cc.obj
    c:\src\gtksourceview\subprojects\harfbuzz\src\hb-ot-post-table.hh(149): warning C4996: 'strncpy': This function or variable may be unsafe. Consider using strncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
    c:\src\gtksourceview\subprojects\harfbuzz\src\hb-ot-cff1-table.hh(1329): warning C4996: 'strncpy': This function or variable may be unsafe. Consider using strncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
    c:\src\gtksourceview\subprojects\harfbuzz\src\hb-repacker.hh(87): warning C4334: '

    Reply to this comment

    Reply to this comment

    1. Xavier Claessens:
      Sep 01, 2021 at 06:08 PM

      I didn't had that error, you could report the issue against libjpeg-turbo meson port: https://github.com/mesonbuild/wrapdb.

      Reply to this comment

      Reply to this comment

  5. Vinícius de Ávila Jorge:
    Sep 02, 2021 at 02:57 AM

    Just to report. I started over... again... but this time I was going to build just the GTK4 toolchain, using meson and MSVC 2019. And it worked! Below some steps I did:

    1 - Clone gtk: git clone https://gitlab.gnome.org/GNOME/gtk.git
    2 - Add gtk\subprojects\gst-buid.wrap with the content posted in this blog:
    [wrap-git]
    url=https://gitlab.freedesktop.org/gstreamer/gst-build.git
    revision=master

    [provide]
    dependency_names=gstreamer-player-1.0

    3 - I edited gtk\modules\media\meson.build according to https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3910/diffs, removing this code:

    if host_machine.system() == 'windows'
    new_gst_gl_display_code = \
    '''#include
    int main (int a, char ** g) {
    GstGLDisplay *d = gst_gl_display_new_with_type (GST_GL_DISPLAY_TYPE_WIN32);
    return 0;
    }'''
    if cc.links(new_gst_gl_display_code, dependencies : gstgl_dep)
    message('libgstgl has gst_gl_display_new_with_type()')
    extra_win_cflags += '-DHAVE_GST_GL_DISPLAY_NEW_WITH_TYPE'
    endif

    And inserting this:
    if host_machine.system() == 'windows' and gstgl_dep.version().version_compare('>=1.19.1')
    message('libgstgl has gst_gl_display_new_with_type()')
    extra_win_cflags += '-DHAVE_GST_GL_DISPLAY_NEW_WITH_TYPE'

    With these steps, meson setup runs well. But I faced another problem during compilation: I couldn't link jpeg-x.x.x.dll (from libjpeg-turbo), becauso of this error:
    jcphuff.c.obj : error LNK2019: unresolved external symbol ___builtin_ctzl referenced in function _count_zeroes
    subprojects\libjpeg-turbo-2.1.0\jpeg-8.2.2.dll : fatal error LNK1120: 1 unresolved externals

    I solved it by editing gtk\subprojects\libjpeg-turbo-2.1.0\jconfig.h.in and commenting out this line:
    #cmakedefine HAVE_BUILTIN_CTZL

    I really don't know if programs built with this toolchain will complain, but at least, meson compile and meson install worked and gtk-demo.exe ran correctly (apparently).

    Wow. That was my experience. It was hard but possible. I think it would be good to share these binaries, what do you think?

    Many thanks for your help!
    Best regards.

    Reply to this comment

    Reply to this comment


Add a Comment






Allowed tags: <b><i><br>Add a new comment:


Search the newsroom

Latest Blog Posts

An xrdesktop summer of code

10/09/2021

This summer, Christoph Haag and I had the pleasure of taking part in Google Summer of Code as mentors for xrdesktop, the Open Source project…

Adding VP9 and MPEG2 stateless support in v4l2codecs for GStreamer

23/06/2021

Earlier this year, from January to April 2021, I worked on adding support for stateless decoders for GStreamer as part of a multimedia internship…

Bag of Freebies for XR Hand Tracking: Machine Learning & OpenXR

17/06/2021

In our previous post, we presented a project backed by INVEST-AI which introduces a multi-stage neural network-based solution. Now let's…

Testing cameras with lc-compliance on KernelCI

15/06/2021

Initiated as a joint effort by the Google Chrome OS team and Collabora, the recent KernelCI hackfest brought the addition of new tests including…

Zink: Summer 2021 update

14/06/2021

There's a lot that has happened in the world of Zink since my last update, so let's see if I can bring you up to date on the most important…

Open Source OpenGL ES 3.1 on Mali GPUs with Panfrost

11/06/2021

Panfrost, the open source driver for Arm Mali, now supports OpenGL ES 3.1 on both Midgard (Mali T760 and newer) and Bifrost (Mali G31, G52,…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2021. All rights reserved. Privacy Notice. Sitemap.

Collabora Limited is registered in England and Wales. Company Registration number: 5513718. Registered office: The Platinum Building, St John's Innovation Park, Cambridge, CB4 0DS, United Kingdom. VAT number: 874 1630 19.