Update G_LOG_DOMAIN to be "GLib-GObject" so that we are consistent with
the autotools builds, and that tests expecting the log domain to be
"GLib-GObject" would not fail.
Define the G_LOG_DOMAIN of the GLib DLL as "GLib", because:
-This makes it consistent with the autotools builds
-Some tests expect the log domain to be "GLib"
Ryan accidentally committed some debugging code a long time ago,
causing this file to always use futex emulation even when real futex
support was available. I noticed this a while later and pointed it out
to him, and assumed he was going to fix it, but I guess he assumed I
was going to fix it, and then neither of us did...
https://bugzilla.gnome.org/show_bug.cgi?id=699500
The GError should be initialized to NULL, otherwise we'll
"pile up" errors, then try to free an uninitialized pointer.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Dan Winship <danw@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=699493
This partially reverts commit ce0022933c255313e010b27f977f4ae02aad1e7e.
It used to be safe to use g_spawn_sync() from processes that had their
own SIGCHLD handler because it simply called wait(). When it was
changed to depend on the GLib child watching infrastructure this meant
that GLib had to own the SIGCHLD handler.
This caused hangs in at least Pidgin.
The patch contained two other improvements to the child watch code which
we want to keep, so only revert the changes to gspawn itself.
https://bugzilla.gnome.org/show_bug.cgi?id=698081
gtk# also has a problem with the new interface-after-init restriction
that nobody noticed until now. Add an exception for them as well so
that they have a cycle or so to sort things out.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
glibmm has a pretty difficult-to-solve problem caused by our recent
change to deny addition of interfaces to classes after initialisation.
They're looking for a long-term workaround for the problem, but in the
meantime we can allow the registration to succeed (with warning) if the
class looks like it's being defined by gtkmm.
https://bugzilla.gnome.org/show_bug.cgi?id=697229
We need to close the stream *before* applying the file modes, because
g_file_replace() allocates a temporary file. At the moment we're
applying the modes to the extant file, then immediately rename()ing
over it with the default perms.
This regressed with commit 166766a89fcd173dcd6ffda11f902029928f7f28.
The real fix here is to have g_file_create_with_info() so that we can
atomically create a file with the permissions we want.
https://bugzilla.gnome.org/show_bug.cgi?id=696014
