This fixes use of `GIO_USE_VOLUME_MONITOR=help`, and simplifies the
code. The reason this wasn’t used already seems to just be because it
was missed when `_g_io_module_get_default_type()` was introduced in
2013. The previous `get_default_native_class()` code in
`gunionvolumemonitor.c` was introduced in 2007.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1881
This fix build error for projects that use gnome.compile_resources()
when glib is built as a subproject and not installed on the build
machine.
Note that this is not working for cross compilation cases, because it
would require to compile everything twice (for host and build machines).
A better solution would be to rewrite those tools in python. See #1859.
They use the deprecated GTimeVal type, which is not year 2038 safe, so
have to be deprecated.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1438
These are alternatives to g_file_info_{get,set}_modification_time(),
which will soon be deprecated due to using the deprecated GTimeVal
type, which is not year 2038 safe.
The new APIs take a GDateTime instead.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1438
The event source used to handle inactivity_timeout doesn't hold a
reference on the application. Therefore, it is possible for callback
function of the event source to run after the application has been
freed, leading to use-after-free problem. To avoid the problem, we
should remove the event source before the application is freed.
This should fix SIGBUS crash of gio/tests/gapplication on FreeBSD.
https://gitlab.gnome.org/GNOME/glib/issues/1846#note_566550
These are here to prevent linker errors, since `gcontenttype.[ch]`
aren’t compiled on Windows or macOS.
The implementations are stubs to be filled out by someone who knows each
platform, at some point in the future.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1791
We're using the `install` argument for configure_file() all over the
place.
The support for an `install` argument for configure_file() was added in
Meson 0.50, but we haven't bumped the minimum version of Meson we
require, yet; which means we're getting compatibility warnings when
using recent versions of Meson, and undefined behaviour when using older
versions.
The configure_file() object defaults to `install: false`, unless an
install directory is used. This means that all instances of an `install`
argument with an explicit `true` or `false` value can be removed,
whereas all instances of `install` with a value determined from a
configuration option must be turned into an explicit conditional.
We want to use the keyfile backend in sandboxes,
but we want to avoid people losing their existing
settings that are stored in dconf. Flatpak does
a migration from dconf to keyfile, but only if
the app explictly requests it.
From an app perspective, there are two steps to
the dconf->keyfile migration:
1. Request that flatpak do the migration, by adding
the migrate-path key to the metadata
2. Stop adding the 'dconf hole' to the sandbox
To keep us from switching to the keyfile backend
prematurely, look at whether the app has stopped
requesting a 'dconf hole' in the sandbox.
The plugin modules in these tests get statically linked with a separate
copy of GLib so they end up calling vfuncs in their own copy of GLib.
Fixes#1648
v7, based on a patch by mrgard (GNOME/glib#1635)
make w32_adapter_ipv4_addr() C90-compliant
check for ERROR_BUFFER_OVERFLOW when calling GetAdaptersAddresses()
code-style fixes
indentation fixes
use g_try_(re)alloc and g_free
style suggestions by pwithnall
drop uni_count variable
cap maximum allowed interface name string length according to windows documentation
Fixes: #1635
We need to enable building the dirent and gnulib sources for clang-cl,
as we are still using the Microsoft-style headers and lib's and CRT.
We need to also do this for the following, for similar reasoning:
-Symbol export (via __declspec(dllexport))
-Dependency discovery without pkg-config files
-long long and ssize_t detection
We do, however, enable the autoptr tests for clang-cl builds. Note that
at this point real MSVC builds are still better supported than clang-cl
builds, and it will likely remain so for at least the near future,
alhtough real MSVC builds of the GTK stack are consumable and are usable
by clang-cl.
