News from GLib 2.58

Next September, GLib will hit version 2.58. There have been a few changes during the past two development cycles, most notably the improvement of the Meson build, which in turn led to an improved portability of GLib to platforms such as Windows, macOS, and Android. It is time to take stock of the current status of GLib, and to highlight some of the changes that will impact GLib-based code.

  • Meson – Thanks to the ongoing work of Nirbheek Chauhan and Xavier Claessens, the Meson build has been constantly improving, to the point that we can start switching to it as the default build system. The plan—as outlined on the mailing list—is to release GLib 2.58 using Meson, while keeping the Autotools build in tree and available in the release archive; then, we’ll drop the Autotools build during the following development cycle, and release GLib 2.60 without Autotools support. Linux distributors are very much welcome to start testing the Meson build in their builders; we’ve been running the Meson build as part of our CI process for a while, now, but more exposure will bring out eventual regressions that we missed; additionally, it would be stellar if people with different toolchains than GCC/Clang/MSVC would start trying the Meson build and report bugs. In the meantime, if you’re using GLib on macOS and Windows, we already recommend you switch to Meson to build GLib, as it’s easier and better integrated with those platforms than Autotools
  • Reliability and portability – GLib switched to GitLab alongside the rest of GNOME, which meant being able to run continuous integration outside of the GNOME Continuous builds. Now we run CI on multiple toolchains, multiple build systems, and multiple platforms for every commit and merge request, which significantly reduces the chances of a broken build. We’ve also improved the code coverage in the test suite. Of course, we could always do better; for instance, we don’t have a CI runner for macOS and the Solaris family of OSes, and more runners for the *BSD family would be greatly appreciated. We’ve issued a call for help, if you have a spare machine and some bandwidth that you can donate
  • File monitoring on *BSD – Apropos the *BSD family, the kqueue backend for file monitoring in GIO has been completely overhauled by Martin Pieuchot and Ting-Wei Lan; the new code is simpler, more robust, and passes all the tests
  • Use posix_spawn() for efficient process launching — Thanks to Daniel Drake, GLib now can use posix_spawn() under specific circumstances, if the platform’s C library supports it; this allows hitting fast paths in the kernel, compared to manually calling fork() + exec(); those fast paths are especially beneficial when running on memory constrained platforms
  • Reference counting types and allocations — GLib uses reference counting as a memory management and garbage collection mechanism in many of its types, but lacks the public API to allow other people to implement the same semantics in their own data structures; this leads to much copy-pasting and re-implementations, and typically to things like undefined behavior when it comes to saturation and thread safety. GLib 2.58 has a grefcount and a gatomicrefcount types, alongside their API, to reduce this duplication. Additionally, taking a cue from other languages like Rust, GLib provides a way to add reference counting semantics on memory allocations, by adding a low level API that allows you to allocate structures that do not have a reference count field, and automatically add reference counting semantics to them
  • Deprecations – A few soft deprecations have become real deprecations in this last development cycle:
      • g_type_class_add_private() has finally been deprecated, five years after we introduced the instance private data macros; if you’re still using that function in your class initialization, please switch to G_DEFINE_TYPE_WITH_PRIVATE or G_ADD_PRIVATE
      • g_main_context_wait() is officially deprecated, but you should have already seen run time warnings about its use
      • gtester, the GTest harness provided by GLib, is deprecated; if you’re using Autotools, you should use the TAP harness that comes with Automake

There have been lots of contributions in GLib, in this past cycle, thanks to the tireless efforts of Philip Withnall; he’s been instrumental in reviewing patches, triaging bugs, and implementing changes in the development process of the project. The switch over to GitLab has also improved the contribution process, with many more developers opening merge requests:

  • 2.54.0..c182cd68: 968 changesets from 143 developers, up from 412 changesets and 68 developers during the 2.53 development cycle
  • A total of 31851 lines added, 27976 removed (delta: +3875)
Developers with the most changesets
Philip Withnall 303 31.3%
Xavier Claessens 79 8.2%
Emmanuele Bassi 69 7.1%
Christoph Reiter 42 4.3%
Ting-Wei Lan 21 2.2%
Chun-wei Fan 21 2.2%
Nirbheek Chauhan 21 2.2%
Ondrej Holy 20 2.1%
Руслан Ижбулатов 20 2.1%
Mikhail Zabaluev 20 2.1%
Simon McVittie 15 1.5%
Matthias Clasen 14 1.4%
Christian Hergert 13 1.3%
Iñigo Martínez 12 1.2%
Bastien Nocera 10 1.0%
Rafal Luzynski 9 0.9%
Michael Catanzaro 9 0.9%
Will Thompson 8 0.8%
Allison Lortie 8 0.8%
Daniel Boles 8 0.8%

Make sure to test your code with GLib 2.57.2, the next development snapshot towards the 2.58.0 stable release.

4 thoughts on “News from GLib 2.58”

  1. If gtester is deprecated, and TAP depends on autotools, which is the recommended test framework then?

  2. Been trying for hours to build glib 2.58.1, on a CentOS 6.6 Linux box. This box is 32-bit, but has current i686 libs, Firefox 60.2.1 runs, Gnome is fine, etc. But the build for glib 2.58.1 crashes. Running ./ causes to crash on the first AC_DEFINE with “ error possibly undefined macro: AC_DEFINE If this token and others are legitimate, please use m4_pattern_allow.”
    This is a common wastebasket-error response, and typically means pkg-config, or libtools is not installed, or versions of autoconf are insufficient. Not the case here. This build-fail means I am stuck at glib-2.28.8.

    Let me pls request; If you are going to make software, then please at least include build instructions that folks like me out at the edge of things, might have a hope of using. I’ve only just heard of “meson” tonite. (oh joy, another build-system to learn…).
    Basically, I have now spent *hours* trying to trouble-shoot this broken build, and have googled & read a lot of probably out-dated material, that has been of no use.

    Please, if we don’t have a working build configuration, and no one includes build instructions that can be followed by users, (and please, not just the arrogant “RTFM …” – like the autoconf error messages basically are…), then everyone’s effort is just wasted. I am *way* down a rabbit-hole here, trying to get some software to work, and at the bottom, I seem to have reached this glib-2.58 requirement. But it cannot be built. All the documentation that I can find, and the version-checking I have done re. dependencies, suggests that this should work. But all I am getting is basically an autoconf/autotools error message that says the macro AC_DEFINE is not working.

    I’ve just installed the “autoconf-archive” and it all seems to be there. And all the components of the toolchain seem to be current, or at least within stated spec.

    And just to check, I cd’ed to the glib-2.28.0 directory, and ran ./, and it ran just fine, creates the configure and then runs it, and ends by providing me a helpful message saying: “Now type ‘make’ to compile Glib”.

    But what we seem to have here, in glib-2.58.1, is just a broken build. And it looks like it will pooch my project, since glib – a core component – seems to be at the bottom of the this deep hole.
    And that is a shame. :(
    – MCL

Comments are closed.