Close output file to ensure all buffered output actually gets written.
Otherwise, glib-genmarshal output is sometimes empty (for example, when trying
to build gdk-pixbuf on Windows, with Meson installed from .msi package).
argparse.FileType doesn't get closed automagically when the script exits:
https://bugs.python.org/issue13824
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2341
When GLib code is checked out with Windows line endings (happens on Windows),
data-to-c.py embedded that line endings into generated string literal. And
then they translated to double newlines in glib-compile-resources output.
clang-cl failed to compile such files because of empty lines in the middle of
multiline macros:
#define G_MSVC_CTOR(_func,_sym_prefix) \
static void _func(void); \
To fix the issue, enable 'universal newlines' mode when reading the input in
data-to-c.py - translate both '\n' and '\r\n' to '\n'.
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2340
Run `systemd-machine-id-setup` when creating the image, so that
`/etc/machine-id` is created with a valid ID. Since systemd isn’t
started when running the CI image with podman/Docker, it’s not created
otherwise. This causes some tests to fail.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Include the size of the `machine-id` file, but not the value itself as
that is sensitive for non-throwaway machines. What’s most useful for
debugging CI problems is knowing whether, and where, the `machine-id` is
set.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
So the tests can access `/var/lib/dbus/machine-id`. This is not a
behaviour change relative to older behaviour on CI.
In future, it might make more sense to revert this commit and change the
CI scripts so they symlink
`/home/user/glib-installed/var/lib/dbus/machine-id` to the system
machine ID; or ensure that `/etc/machine-id` exists on all the CI
machines. That’s too complicated to do right now though.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This will require distributions to ensure they pass
`--localstatedir=/var` correctly to Meson, but they should be doing that
already.
See https://mesonbuild.com/Builtin-options.html#directories for details
about how Meson treats `localstatedir` differently from most other `dir`
variables.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s unlikely that the machine ID will be invalid (it’s system
configuration), but it would be helpful to not propagate invalid IDs
further, since a lot of things rely on it.
It’s not easy to test this (it requires factoring out the code so it can
be used from a test program, or allowing it to load a machine ID from a
custom path), so I haven’t added unit tests. I’ve tested manually by
overriding the loaded machine ID.
Coverity CID: #1430944
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The changes in 4273c43902 did not guard
macros in `gatomic.h` which use `glib_typeof`. This meant that when
552b8fd862 was committed, moving the
include of `<type_traits>` under such a guard, these macros were still
trying to use it. This broke the build of at least vte.
Fix this by guarding the API break in `gatomic.h` too.
This release series of GLib began using features that are provided in
the Windows 8 SDK and later for Visual Studio builds. This also means
that it is no longer possible to build GLib with Visual Studio 2008 nor
2010 since the Windows 8+ SDKs do not work with those compiler versions.
Mention that people that still need to use those Visual Studio versions
should continue sticking on to glib-2.66.x, and so remove the section
about the workarounds that need to be applied for Visual Studio 2008
builds, since they are no longer applicable.
Meson incorrectly detects strcasecmp, strncasecmp on clang-cl if 'prefix:'
is not specified for cc.has_function().
See https://github.com/mesonbuild/meson/issues/5628
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2337
Before this change:
msvc was using _stricmp()
gcc on mingw was using strcasecmp()
gcc on linux was using strcasecmp()
clang-cl was trying to use strcasecmp()
After this change:
msvc is using _stricmp()
gcc on mingw is using strcasecmp()
gcc on linux is using strcasecmp()
clang-cl is using _stricmp()
Tests are still failing to build with clang-cl, but that's a separate issue.
The doc used different phrasing for the same thing, e.g. "if any thread"
vs "any other thread."
Also make it clear that trying to take a write lock while already having
a lock, or trying to take a read lock while having a write lock, is
undefined.
For non-Linux UNIX systems, the label 'close_libutil:' in
'test_pollable_unix_pty()' will have no statement that goes with that
label. Just do a 'return' on non-Linux UNIX systems.
When included inside an `extern "C"` block, this causes build failures
that look something like:
/usr/include/c++/10/type_traits:2930:3: error: template with C linkage
2930 | template<typename _Fn, typename... _Args>
| ^~~~~~~~
../../disas/arm-a64.cc:20:1: note: ‘extern "C"’ linkage started here
20 | extern "C" {
| ^~~~~~~~~~
Commit 4273c43902 made this opt in for
projects which are defining `GLIB_VERSION_MIN_REQUIRED`, but the include
of `<type_traits>` via `gmacros.h` was not included in this. If we move
the include out to the places where `glib_typeof` is called, we can make
it covered by this macro too, and save a few consumers from FTBFSing.
That also means that, if you don't want to fix your use of the headers,
and as long as this version is sufficient for you, a quick workaround is
to define `GLIB_VERSION_MIN_REQUIRED` to `GLIB_VERSION_2_66` or lower.
Suggested by Simon McVittie.
Alternative to: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1935
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2331
File monitor creation may fail. We should check for this, rather than
ignoring it and then spewing criticals upon improperly assuming that we
have a valid GFileMonitor rather than NULL.
In practice, creating the GFileMonitors here fail when opening a large
number of tabs in Epiphany. I'm still investigating to see why, but it
doesn't matter for the purposes of this commit.
Expand an existing unit test to check that the target FD of a
`g_subprocess_launcher_take_fd()` call doesn’t get closed when
`g_subprocess_launcher_close()` is called. Only the source FD should be
closed by the parent process.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2332
This is a regression introduced in commit 67a589e505. Previously, the
source/target FD pairs were stored in `needdup_fd_assignments`, in
consecutive entries, so source FDs had even indices and target FDs had
odd indices.
I didn’t notice that the array index was being incremented by 2 when
closing FDs, when porting from the old code. So previously the code was
only closing the source FDs; after the port, it was closing source and
target FDs.
That’s incorrect, as the target FDs are just integers in the parent
process. It’s only in the child process where they are actually FDs —
and `g_subprocess_launcher_close()` is never called in the child
process.
This resulted in some strange misbehaviours in any process which used
`g_subprocess_launcher_take_fd()` with target FDs which could have
possibly aliased with other FDs in the parent process (and which weren’t
equal to their mapped source FDs).
Thanks to Olivier Fourdan for the detailed bug report.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2332
This was correctly annotated for proper return values but in case of out
parameters it was only annotated as (optional) and not additionally as
(nullable).
