The ability to cross-compile glib got broken after the
merge of the 'signal-performance' branch as the assumption
was made that the generated glib-genmarshal can be executed
on the host (which isn't valid when cross-compiling).
Fixed this by using the just-built glib-genmarshal for normal
compilations and the native (host) glib-genmarshal when doing a
cross-compilation as was also done in several other areas of GLib
Tested for host=x86_64-unknown-linux-gnu, target=x86_64-unknown-linux-gnu
and host=x86_64-unknown-linux-gnu, target=i686-w64-mingw32
https://bugzilla.gnome.org/show_bug.cgi?id=671676
If there are no modules installed then the most appropriate thing is to
have no cachefile instead of an empty one. This unbreaks the "clean
directory after 'make uninstall'" check that automake does.
https://bugzilla.gnome.org/show_bug.cgi?id=671664
This warning appears when unicode chars that cannot be displayed in the
current Windows code page is used anywhere in the file, including comment
blocks. We probably don't need to see these, especially as problems
caused by such characters are manifested as other warnings or errors,
for example, the need to add BOM to a file when compiling code with
complex script on Windows.
In the code generation portion, va_copy() is not universally available,
so use the existing G_VA_COPY macro that in turn calls va_copy() if it
is available or call an appropriate emulation otherwise.
va_vopy() is not universally available in all compilers, so make use of
the existing G_VA_COPY macro which either calls va_copy() if it is
available, or emulates it if otherwise.
Otherwise we get criticals a'la
GLib-GIO-CRITICAL **: g_cancellable_release_fd: assertion `cancellable->priv->fd_refcount > 0' failed
when reading/writing to certain kinds of file descriptors.
Patch reviewed by Dan Winship on IRC.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Rename G_SPAWN_ERROR_2BIG to G_SPAWN_ERROR_TOO_BIG (while keeping the
old name for compatibility), to fix problems with language bindings
where the old name translates into something that would be
syntactically invalid due to starting with a digit.
https://bugzilla.gnome.org/show_bug.cgi?id=671025
We were attempting to unregister our ownership of our D-Bus name even in
the case that we were non-unique (ie: we didn't actually own the name).
Rework the logic a bit to prevent that: for non-unique, we leave
impl->bus_name as NULL and we only register/unregister if it is
non-NULL.
When there is only one closure handling a signal emission and
it doesn't have a bunch of complicated features enabled we
can short circuit the va_args collection into GValues and call the
callback via the va_marshaller directly.
https://bugzilla.gnome.org/show_bug.cgi?id=661140
If the signal argumment types matches a built in standard
marshaller we use the va_marshaller for that, and also the
normal marshaller if NULL was specified (as its faster than
the generic one).
This lets you set a va_marshaller on your signal which will be
propagated to all closures for the signal. Also, automatically
uses the generica va_marshaller if you specify a NULL c_marshaller.
https://bugzilla.gnome.org/show_bug.cgi?id=661140
This means we're not abusing the notifiers for meta_marshallres,
and we're able to later cleanly add other fields to GClosure.
We still have to leave the ABI intact for the GClosure->meta_marshal
bit, as old G_CLOSURE_N_NOTIFIERS macro instances still accesses it.
However, we always set it to zero to keep those macros working.
https://bugzilla.gnome.org/show_bug.cgi?id=661140
