configure.ac: tweak inotify check

Our check for inotify_init1() being defined is broken.  We happily
declare that inotify is supported, even if the check fails.

This was originally intended to check for inotify_init1 in the libc so
that we could fall back to inotify_init if it was not yet defined.

FreeBSD has a libinotify that emulates the inotify API via kqueue.  It
installs a <sys/inotify.h> header and requires linking to -linotify.  We
don't want to falsely detect working inotify in this case.

Treat the lack of inotify_init1() in the libc as a lack of inotify
support.  This requires only a new libc -- we still support old kernels:
in the case that inotify1_init() fails, we fall back to inotify_init().

https://bugzilla.gnome.org/show_bug.cgi?id=724330
docs: let go of &ast;

Since we are no longer using sgml mode, using /&ast; &ast;/ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
docs: Remove some unneeded decorations

@var is not expanded inside literal `` blocks.
Just remove those @ characters.
docs: Remove a few trailing <literal>s
Fix g_socket_get_available() with TCP on Windows

Windows needs a special inefficient hack to implement
g_socket_get_available() correctly for UDP sockets, but that hack
isn't needed for TCP, and in fact, might give the wrong answer in that
case. Fix it to only use the hack with UDP.

Also, fix that case to handle non-blocking sockets as well.

And add a test case for g_socket_get_available() with TCP.

https://bugzilla.gnome.org/show_bug.cgi?id=723422
gobject: re-allow finalization from constructor()

Although returning NULL from constructor is strongly discouraged, some
old libraries need to keep doing it for ABI-compatibility reasons.
Given this, it's rude to forbid finalization from within
constructor(), since it would otherwise work correctly now anyway (and
the critical when returning NULL should discourage any new uses of
returning NULL from constructor()).

https://bugzilla.gnome.org/show_bug.cgi?id=661576
gio: don't accept nonstandard IPv4 "numbers-and-dots" addresses

In addition to the standard "192.168.1.1" format, there are numerous
legacy IPv4 address formats (such as "192.168.257",
"0xc0.0xa8.0x01.0x01", "0300.0250.0001.0001", "3232235777", and
"0xc0a80101"). However, none of these forms are ever used any more
except in phishing attempts. GLib wasn't supposed to be accepting
these addresses (neither g_hostname_is_ip_address() nor
g_inet_address_new_from_string() recognizes them), but getaddrinfo()
accepts them, and so the parts of gio that use getaddrinfo()
accidentally did accept those formats.

Fix GNetworkAddress and GResolver to reject these address formats.

https://bugzilla.gnome.org/show_bug.cgi?id=679957
only '#pragma GCC' outside of functions

Don't use #pragma GCC inside of function scope.

https://bugzilla.gnome.org/show_bug.cgi?id=724417
win32: fixup lib.exe invocation

We have a configure.ac check for lib.exe that attempts to enable
creation of .lib files for our 5 public libraries.  That has been broken
for a long time for two reasons:

 1) the Makefiles hardcode 'lib' instead of 'lib.exe'

 2) we dropped generation of .def files quite some time ago (except for
    in gthread where we have the two-symbol file under version control)

Add new rules for creating .def files from dumpbin.exe (which you should
have if you have lib.exe) and fix the .lib rules to use lib.exe.

Add a bit of $(AM_V_GEN) all around, as well.

https://bugzilla.gnome.org/show_bug.cgi?id=722033
Fix the build on FreeBSD by replacing EAI_NODATA with EAI_NONAME.

https://bugzilla.gnome.org/show_bug.cgi?id=724434
g_simple_async_result_is_valid: fix for NULL source tag

If a GSimpleAsyncResult has a NULL source tag, allow it to compare
valid to a non-NULL source tag in g_simple_async_result_is_valid(), to
simplify cases where, eg, g_simple_async_result_new() and
g_simple_async_result_report_error_in_idle() are both used.

https://bugzilla.gnome.org/show_bug.cgi?id=721458
Annotate g_application_add_main_option_entries
subprocess: Init and clear the mutex

Fixes the leak of the GMutexImpl allocated inside the first call to g_mutex_lock()
on an uninitialized GMutex.

https://bugzilla.gnome.org/show_bug.cgi?id=724401
gio/tests: fix race when generating code

There is a race condition in the makefile that can result in build failures like this in parallel builds:

| ./gdbus-test-codegen-generated.h:7:0: error: unterminated #ifndef
|  #ifndef __GDBUS_TEST_CODEGEN_GENERATED_H__

This is because a rule like this:

x.c x.h: prerequisites
	@commands

doesn't consider x.c and x.h together. Instead, it expands to two rules, one to
generate x.c and one to generate x.h, which happen to run the same commands.  In
the worst case they execute in parallel, overwriting each other's output.

Signed-off-by: Ross Burton <ross.burton@intel.com>

https://bugzilla.gnome.org/show_bug.cgi?id=723616
gtestutils: make the new assert messages more detailed

g_assert_true(), g_assert_false(), g_assert_null(), and
g_assert_nonnull() simply printed out the expression they were
checking, without any further explanation of what went wrong. (In
particular, "g_assert_true(x)" and "g_assert_false(x)" would both
print the same thing on failure.) Add a little bit more context.

https://bugzilla.gnome.org/show_bug.cgi?id=724385
gsocket: fix g_socket_condition_timed_wait() recovery after EINTR

After getting an EINTR, g_socket_condition_timed_wait() has to adjust
its timeout, but it was trying to convert from nanoseconds to
microseconds by multiplying by 1000 rather than dividing... Oops.

https://bugzilla.gnome.org/show_bug.cgi?id=724239
Bump gtk-doc dep to 1.20
GApplication: disable some more tests

Disable some racy GApplication testcases.  We need some better non-hacky
GApplication tests...

https://bugzilla.gnome.org/show_bug.cgi?id=724126
Work around test failure in gdbus-names

This is caused by g_test_dbus_down() returning too soon.

Add a sleep for now.

https://bugzilla.gnome.org/show_bug.cgi?id=711807
GLib 2.39.90