Bug 13403 introduced support for the non-POSIX variants of these APIs
found on a system called "DG/UX". Meanwhile, the complicated checks
here are breaking cross-builds on systems that we actually care about.
Remove the complicated checks and replace them with AC_CHECK_FUNCS.
Remove the resulting dead code from a couple of .c files.
https://bugzilla.gnome.org/show_bug.cgi?id=756475
Commit 212e4232e7 introduced a big update
of gnulib. Necessary changes to configure.ac from old gnulib commit
e8e63d1b31bca6c82713cba490b21a861abb24b5 have been forgotten. Actually
available functions are not discovered by autotools.
https://bugzilla.gnome.org/show_bug.cgi?id=759134
This example has been causing on-and-off build breaks for quite some
time. In this case, the code for copying the generated content into the
main docs of GIO is causing problems with srcdir != destdir builds (due
to the files also being copied from the read-only srcdir during
distchecks).
We could probably work around this problem yet again, but since there is
no real benefit to having this content included, so let's remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=734469
It's been a long time since we've been unconditionally saying "static
inline" in GLib headers without complaints so it's safe to assume that
all compilers that we care about support this.
One thing that is not yet totally supported is the unadorned use of the
word "inline". Depending on the flags (-std=c89, for example), even GCC
will complain about this. Detect missing C99 support and define
"inline" to "__inline" in that case. Some research shows "__inline"
appears to be the most widely-supported keyword here, but we may need to
tweak this if we get some reports of breakage.
Clean up all of the configure checks around this and define G_CAN_INLINE
unconditionally. Unfortunately, we must assume that some people are
still using G_IMPLEMENT_INLINES, we must continue to implement that
(including undefining G_CAN_INLINE and redefining G_INLINE_FUNC) if
requested.
It is not our intent to break existing users of the old-style
G_INLINE_FUNC approach and if that has happened, we may need to make
some further adjustments.
https://bugzilla.gnome.org/show_bug.cgi?id=757374
It's a platform-specific macro, so it belongs in glibconfig.h.
This ensures that g-ir-scanner will not pick the wrong definition
for introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=757294
Now that we initialize the quark tables from a constructor,
reloading libglib is just as bad as reloading libgobject,
so add the linker option to the LDFLAGS for all our libraries.
https://bugzilla.gnome.org/show_bug.cgi?id=755609
Add support for receiving multiple messages with a single system call,
using recvmmsg() if available. Otherwise, fall back to looping over
g_socket_receive_message().
This adds new API, g_socket_receive_messages(), and corresponding unit
tests.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
Add a check to configure.ac for strerror_r, since we don't currently
require POSIX.1-2001 conformance in general. Add back a
plain-strerror() case as a fallback, and rearrange the glibc-vs-POSIX
strerror_r() branches.
Update the docs to not claim that "not all platforms support the
strerror() function" (we require C90), but still mention the UTF-8 and
always-valid-string benefits. (And make test_strerror() check that
last part.)
https://bugzilla.gnome.org/show_bug.cgi?id=754788
This "adds" the Visual Studio 2015 Project files by doing what we did
before: copying the Visual Studio 2010 projects and replacing items
in them, as the formats of the Visual Studio 201x projects are largely
the same.
Use a simple all-purpose utility script to generate the glib-mkenums
PERL script with the version info, and stop using the script that
tries to parse the autotools files. Move the things that
were taken out from build/win32/setup.py back there.
We don't need to run binaries we just built in order to successfully
build GLib and friends any more.
Since commit b74e2a7, we don't need to run glib-genmarshal when building
GIO; since commit f9eb9eed, all our tests (including the ones that do
need to run binaries we just built) are only built when running "make
check", instead of unconditionally at every build.
This means that we don't need to check for existing, native binaries
when cross-compiling, and fail the configuration step if they are not
found — which also means that you don't need to natively build GLib for
your toolchain, in order to cross-compile GLib.
We can also use the cross-compilation conditional, and skip those tests
that require a binary we just built in order to build.
https://bugzilla.gnome.org/show_bug.cgi?id=753745
FreeBSD and NetBSD have field st_birthtim and st_birthtime in struct stat,
respectively, which can be used to get file creation time on supported file
systems such as UFS2 and tmpfs.
https://bugzilla.gnome.org/show_bug.cgi?id=749492
AC_C_BIGENDIAN can return 'universal' as the result in the case that we
are trying to do a universal build on Mac OS. This has to be opted into
explicitly by using multiple -arch CFLAGS.
Previously, we detected this result and fell back to doing our own check
based on the endianness of the build machine, hardcoding that. This
means that universal builds might successfully build, but the binaries
would never actually run correctly on the 'opposite' arch.
This check was added because of a bug in the intial implementation of
this detection in autoconf, which was inappropriately identifying
non-macos compilers as 'universal'. That was hitting ppc64 systems.
See https://bugzilla.redhat.com/show_bug.cgi?id=449944 for more info.
Commit b0e687ef42e21b1eb7af18c4eaebcd41b0bd5632 in autoconf ("Limit
AC_C_BIGENDIAN univeral checks to Mac OS X") solved this issue in 2008,
so let's remove our workaround. For good measure, if we detect
"universal" in the result, error out.
https://bugzilla.gnome.org/show_bug.cgi?id=742548
Allows sending of multiple messages (packets, datagrams)
in one go using sendmmsg(), thus drastically reducing the
number of syscalls when sending out a lot of data, or when
sending out the same data to multiple recipients.
https://bugzilla.gnome.org/show_bug.cgi?id=719646
