The initial MSVC 201x projects inadvertly disabled
RandomizedBaseAddress, which is normally enabled by default, so ensure
that is the case for all 201x builds. This feature is supported by
Visual Studio 2010 or later.
Also, for x64 builds on MSVC 2012 or later, use /HIGHENTROPYVA when
linking.
Pointed out by Ignacio Casal Quinteiro.
If gio open exits before the program it starts fully activates, then
the dbus-daemon may avoid doing the activating method call.
This commit works around the problem by pinging the activated application,
and waiting for a reply.
Same workaround is used in gtk-launch and was used in gvfs-open before
it was replaced by gio open.
https://bugzilla.gnome.org/show_bug.cgi?id=780296
Commit 53ed180 improved mtab processing, however, also introduced bug
in code obtaining mount points. mtab was used by mistake also for
g_unix_mount_points_get implementation, which is obviously wrong and
fstab has to be used instead...
https://bugzilla.gnome.org/show_bug.cgi?id=781867
Make config.h.win32.in reflect on the entries that are in the
autotools/Meson builds more closely.
Also declare that we have fd_set, declare SIZEOF_[SIZE|SSIZE]_T and
SIZEOF_LONG_LONG for 32-bit and x64 builds properly.
Note that since the Visual Studio 2015/2017 CRT's vsnprintf() and
snprintf() are not compliant enough (though they are much closer than
before) for GLib's purporses, we still use the gnulib's implementations
of them, as with the pre-Visual Studio 2015 builds.
The m4 and bash completion items are usable and relevant
depending on the host system's configuration. So, we check for the
presence of the programs that these items depend on, and only install
them when those programs are found.
For the Valgrind suppression files, we don't install them on Windows as
Valgrind is currently not supported on Windows.
Als fix the path where the GDB helpers are installed, as the path is
incorrectly constructed.
This will fix the "install" stage when building on Visual Studio at
least as there are some post-install steps that are related to them,
which will make use of these programs.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Some of the Meson build files are not dist'ed by 'make dist', which are
reqired for things to work, and there was a missing '\' that cause some
of the meson.build files under tests/ not to be disted.
https://bugzilla.gnome.org/show_bug.cgi?id=783210
They are not supported by Visual Studio, so only define them in
glibconfig.h.in when not on Visual Studio. Fixes builds of GTK+-2.x
against Meson/MSVC builds of GLib.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
This reverts commit 799f8dcd46.
This patch seems to break applications that use GTask specific
operations with GSocket. We will need to investigate a bit more
on this issue but for now we revert it and leave it for the
next major release.
This was duplicated also in g_object_interface_install_property().
Now, validations specific to classes happen in
validate_and_install_class_property() - specifically, the checks for
the presence of the get_property() and set_property() methods.
https://bugzilla.gnome.org/show_bug.cgi?id=787551
In the Dictionary section of the gvariant-format-strings documentation
only how to construct a dictionary is shown.
Add a small example showing how to extract data from a nested dictionary
and specifically from a GVariant of type "(oa{sa{sv})". Move also the
Dictionary section after the GVariant * section for the sake of clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=786737
Instead of a full reference, which causes problems for clients that
expect a GSettings instance to stop firing signals once they drop the
last reference.
https://bugzilla.gnome.org/show_bug.cgi?id=780861
Explain the default values of _{get,set}_close_on_unref() in the main
description rather than the argument one, link to the GIOChannel
structure when talking about it, and mention the default value of
"close on unref" in g_io_channel_unix_new().
https://bugzilla.gnome.org/show_bug.cgi?id=787123
Valgrind will check that the third argument to ioctl() is a valid
pointer, but some ioctls interpret that argument as an integer, and that
is the case here (it's a file descriptor), so this is a false positive.
https://bugzilla.gnome.org/show_bug.cgi?id=787109
