Xavier Claessens
April 29, 2021
Share this post:
Reading time:
Note: In September 2021, the GStreamer project merged all its git repositories into a single, unified repository, often called monorepo. The build system referred in this post as "gst-build" is now in the root of this combined/mono repository.
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=main 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.
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
Run the test application:
C:\src\gtksourceview>C:\gnome\bin\gtksourceview5-widget.exe
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=main [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.
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!
14/03/2024
In continuation with our series about Kernel Integration we'll go into more detail about how regression detection, processing, and tracking…
21/02/2024
Now included in our Debian images & available via our GitLab, you can build a complete, working BL31 (Boot Loader stage 3.1), and replace…
19/02/2024
Back in 2022, after a series of issues were found in its design, I made the call to rework some of WirePlumber's fundamentals in order to…
08/02/2024
Continuing our Kernel Integration series, we're excited to introduce DRM-CI, a groundbreaking solution that enables developers to test their…
23/01/2024
This is the fourth and final part in a series on persian-rug, a Rust crate for interconnected objects. We've touched on the two big limitations:…
16/01/2024
One of the key high-level challenges of building Mesa drivers these days is figuring out how to best share code between a Vulkan driver…
Whether writing a line of code or shaping a longer-term strategic software development plan, we'll help you navigate the ever-evolving world of Open Source.
한국어 버전의 Collabora.com 보기
Acesse Collabora.com em Português
Comments (18)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Thibaud:
Mar 14, 2023 at 05:02 PM
change revision=master to revision=main as the branch name seems to be different now
Reply to this comment
Reply to this comment
Maarten:
Apr 25, 2023 at 01:23 PM
The gtk.wrap fragment still mentions the master branch, I think this should be main by now. Otherwise many thanks for the example.
Reply to this comment
Reply to this comment
Add a Comment