…an error The loop was using a GConverterResult variable where it meant to use a gssize, and since GConverterResult was ending up as an unsigned type, this meant the (res < 0) check always failed.
In the async case, a failed DNS lookup was causing the proxy resolution to bail out immediately, rather than just moving on to the next potential proxy (which might not need us to do the DNS lookup beforehand). Fix that.
-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.
Signed-off-by: Colin Walters <firstname.lastname@example.org>
The parsing test needs to make some assumption about the locale representation of the string to be parsed, so we need to explicitly override the locale here.
GApplication application ID is now permitted to be NULL, in which case G_APPLICATION_NON_UNIQUE will be implicitly enabled. https://bugzilla.gnome.org/show_bug.cgi?id=671249
In C++ it is invalid to cast a void* to void**. Also add a static check to ensure sizeof(*object_ptr) == sizeof (gpointer). This avoid common mistake of missing '&' in g_clear_object(&obj); https://bugzilla.gnome.org/show_bug.cgi?id=674634
If the launch context is a GAppLaunchContext, and not a GdkAppLaunchContext, then g_app_launch_context_get_display will return NULL because the get_display virtual method is undefined. The DISPLAY might still be inherited from the parent process, in which case overwriting it with NULL breaks the launch. This is a regression introduced in: de834be Fixes: https://bugzilla.gnome.org/672786
…ment When cross-compiling with gcc >= 4.5 AC_CHECK_ALIGNOF fails to detect the correct alignment. Without a previous AC_CHECK_TYPE for the same type, the alignment is silently set to '0'. This makes sure that configure fails and reports the problem. Signed-off-by: Michael Olbrich <email@example.com> https://bugzilla.gnome.org/show_bug.cgi?id=674483
Missed this part in the last commit (cherry picked from commit 62905cd)
gdbus-daemon-generated.[ch] failed to build because it depended on gdbus-2.0/codegen/gdbus-codegen which was build during the SUBDIRS part of the build, however SUBDIRS are done *after* processing BUILT_SOURCES, and these files are in BUILT_SOURCES. The fix is simple, instead of running the gdbus-codegen code we run the gdbus-codegen.in code, which works fine for uninstalled execution. I also removed Makefile from the dependencies to avoid rebuilding the file in tarballs, as Makefiles are written at configure time. We should be able to ship the prebuilt files in the tarballs. When running uninstalled (cherry picked from commit 88bfc9b)
Clean/fix up the Preprocessor Definitions for the various projects, where we purge out the unneeded macros and add _DEBUG to the Debug builds of various projects that somehow lacked this. This will also fix the GIO build under Visual C++ 2008, as the _DEBUG macro in the release builds will cause a debug entry to appear in its manifest file during the build, which will cause GIO-using applications to fail to run on systems not running Visual C++/Studio 2008 due to its embedding of a badly-generated manifest file.