build: Bump GLIB_VERSION_MAX_ALLOWED to 2.76

[bbhtt]

libglnx update in d7fcee0 uses g_clear_fd() (GLib >= 2.76), but GLIB_VERSION_MAX_ALLOWED was still 2.70, triggering deprecation warnings when compiling with newer Glib.

g_clear_fd() has a compat implementation inside libglnx so there's no need to bump the minimum GLib requirement.

[bbhtt]

this is a bit tricky, if API newer than 2.66 is accidentally used, we won't get the warning and CI has 2.72 so it won't fail.

[bbhtt]

One option is to wrap it in libglnx for >=2.76

#if !GLIB_CHECK_VERSION(2, 76, 0)
static inline gboolean
g_clear_fd (int     *fd_ptr,
            GError **error)
{
  int fd = *fd_ptr;

  *fd_ptr = -1;

  if (fd < 0)
    return TRUE;

  /* Suppress "Not available before" warning */
  G_GNUC_BEGIN_IGNORE_DEPRECATIONS
  /* This importantly calls _glnx_close to always get async-signal-safe if
   * error == NULL */
  return _glnx_close (fd, error);
  G_GNUC_END_IGNORE_DEPRECATIONS
}

#else

static inline gboolean
_glnx_clear_fd (int     *fd_ptr,
                GError **error)
{
    G_GNUC_BEGIN_IGNORE_DEPRECATIONS
    return g_clear_fd (fd_ptr, error);
    G_GNUC_END_IGNORE_DEPRECATIONS
}
#define g_clear_fd _glnx_clear_fd

#endif

[smcv]

GLIB_VERSION_MAX_ALLOWED just doesn't work very well with a library like libglnx that provides opportunistic backports. It's a useful mechanism to avoid some unintended dependencies on newer GLib versions, but there isn't really any substitute for actually compiling against the oldest distro that is aimed to be supported in CI.

One option is to wrap it in libglnx for >=2.76

Yeah, perhaps libglnx should do that.

[bbhtt]

Opened https://gitlab.gnome.org/GNOME/libglnx/-/issues/7 for this. The min/max macros were added during the Meson port, but the intention is not clear to me in the commit message 62c85a1.

I can drop them but it seems somewhat useful to me to have

[smcv]

In the failing builds, is it failing because of a use of g_clear_fd() in a macro or inline function in a libglnx header, or is libglnx itself being compiled with GLIB_VERSION_MAX_ALLOWED?

If libglnx itself is being compiled with GLIB_VERSION_MAX_ALLOWED, I think the intention is to not do that, and instead compile only the dependent project (flatpak-builder in this case) with options like that.

Or if there's a new use of g_clear_fd() in a macro or inline function in a libglnx header, that could get a more targeted change.

[bbhtt]

If libglnx itself is being compiled with GLIB_VERSION_MAX_ALLOWED, I think the intention is to not do that, and instead compile only the dependent project (flatpak-builder in this case) with options like that.

Yea, f-b's config.h is leaking into libglnx, the Makefile is globally injecting it through AM_CPPFLAGS which is doing echo '#include "config.h"' > libglnx-config.h.

This doesn't affect Meson, only the autotools build system.

[bbhtt]

actually looks like libglnx is itself doing that https://gitlab.gnome.org/GNOME/libglnx/-/blob/ccea836b799256420788c463a638ded0636b1632/Makefile-libglnx.am#L30

[smcv]

The unique quirk of flatpak-builder that is making this worse for f-b than for other libglnx users might be as simple as "is still on Autotools", then.

[bbhtt]

#725 moves it to flatpak-builder only.