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.
Provide public access to the GDBusConnect and object path that
GApplication is using. Prevents others from having to guess these
things for themselves based on the application ID.
https://bugzilla.gnome.org/show_bug.cgi?id=671249
g_output_stream_write_async() was not initializing the newly-added
members of the WriteData structure, causing various problems.
Also, g_input_stream_read_async() was now leaking its cancellable. Fix
that as well.
https://bugzilla.gnome.org/show_bug.cgi?id=674612
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:
de834bed30
Fixes: https://bugzilla.gnome.org/672786
Commit f084b60377 incorrectly set
DIST_SUBDIRS for the toplevel Makefile.am. In general actually we
don't need to set it, because modern automake automatically sets
it by looking at conditionals for SUBDIRS.
Tested-by: Rico Tzschichholz <ricotz@t-online.de>
https://bugzilla.gnome.org/show_bug.cgi?id=667806
If all members of GSocketFamily are supported on the platform, then
all of its values will be positive, and so the enum might become
unsigned, in which case testing for "family < 0" might cause warnings.
But we want to return an error if family == 0 (aka
G_SOCKET_FAMILY_INVALID) anyway, so just tweak the test accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=674592
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 <m.olbrich@pengutronix.de>
https://bugzilla.gnome.org/show_bug.cgi?id=674483
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
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.
