I didn't do this comprehensively, since there's a lot of it, mainly
due to the GDBus object manager stuff, but anyone trying to use
that would fail fast due to lack of the gdbus code generator.
My main goal was to get API additions to existing classes like
g_data_input_stream_read_line_utf8(), as well as the lower level new
API like glib-unix.h.
https://bugzilla.gnome.org/show_bug.cgi?id=676816
Using a caller-supplied buffer for g_input_stream_read() doesn't
translate well to the semantics of many other languages, and using a
non-refcounted buffer for read_async() and write_async() makes it
impossible to manage the memory correctly currently in
garbage-collected languages.
Fix both of these issues by adding a new set of methods that work with
GBytes objects rather than plain buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=671139
Add a G_SPAWN_SEARCH_PATH_FROM_ENVP flag to GSpawnFlags so that
g_spawn_async() etc use the PATH variable from the passed-in child
environment to search for the executable.
If both this flag and the G_SPAWN_SEARCH_PATH flag are set, the
child environment is searched first and only falls back to the
PATH from the process environment if it is unset.
Bug #676398.
In order for this function to have any point, it has to be possible to
pass non-UTF-8 data to it, so annotate @str as being array-of-guint8
instead of utf8.
https://bugzilla.gnome.org/show_bug.cgi?id=672548
Rather than depending on the host's DNS configuration to properly
return an error for a non-existent hostname, just substitute in
a dummy GResolver implementation that does it for us.
GFile doesn't handle some "real" URIs, so check if there's a default
handler for the URI scheme first, and only use g_file_new_for_uri()
and g_file_query_default_handler() if not. Eg, this fixes the case of
opening http URIs with "%2F" in the path.
https://bugzilla.gnome.org/show_bug.cgi?id=666386
gcc gets upset when we do "((GDestroyNotify) destroy) (_p)" because
it's non-portable. But we don't care; we already know glib wouldn't
work on any platform where different pointer types have different
calling conventions. So tweak the code to avoid the warning.
https://bugzilla.gnome.org/show_bug.cgi?id=674634
This essentially adds an accessor for the MimeType field in desktop files,
to retrieve the list of all mime types supported by an application.
The interface though is part of GAppInfo, so it could be implemented
in the future by other backends.
https://bugzilla.gnome.org/show_bug.cgi?id=674111
The logic here is pretty twisted, but basically we were leaking a ref
for each non-existent parent. The clearest way to fix this was to
move to more explicit refcounting logic; when a variable is pointing
to an object, it holds a ref.
https://bugzilla.gnome.org/show_bug.cgi?id=675446
Not doing so is an evil trap, sadly. This patch has been
compile-checked on Fedora 16, and I've verified that the generated
config.status and config.h is exactly the same.
https://bugzilla.gnome.org/show_bug.cgi?id=674483
This way any prerequisites for e.g. AC_CHECK_HEADER are always executed
before the 'if'.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
https://bugzilla.gnome.org/show_bug.cgi?id=674483
-Make up for the missed DLL_EXPORT-it's actually needed for all GLib DLL
builds, omitting this caused problems to surface due to recent works to
make GDBus work on Windows.
-Also use the FFI_BULIDING macro for GObject builds as the suggessted
workaround for using static LibFFI builds (as we do now)-please see
ffi.h(.in). This will fix the build of GObject against LibFFI 3.0.11,
but it is probable that this will change at some point for LibFFI.
If action-if-found is not specified, AC_CHECK_LIB will append the library
to LIBS. As we don't want to link everything against libelf, reset LIBS
after doing the checks.
