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
We were using AC_LANG_PROGRAM to build a program to test for our ability
to call syscall (__NR_futex, ...);. This macro adds "main () { ... }"
around the provided code segment automatically. The provided code
segment provided its own main() function, however.
The result looked something like:
int main (void) {
int main (void) {
...
}
}
which worked on GCC, but not on clang.
Let's fix that. Let's fix the same mistake copied over for eventfd()
detection while we're at it.
Like the Visual Studio 2012 project files, the Visual Studio 2013 files are
largely the same as the Visual Studio 2010 project files, so support
Visual Studio 2013 by updating the autotools scripts that is used for
Visual Studio 2012. This means that project files for Visual Studio 2012
and Visual Studio 2013 can be maintained by simply maintaining the Visual
Studio 2010 project files, adding minimal maintenance overhead.
On OpenBSD, libintl is installed under /usr/local/lib. When configure
checks unset LDFLAGS, LIBS should also be unset otherwise we end up with
-lintl which cannot be found resulting to the compile check to fail.
https://bugzilla.gnome.org/show_bug.cgi?id=727939
Since the type system does not support reloading its data and assumes
that libgobject remains loaded for the lifetime of the process, we
should link libgobject with a flag indicating that it can't be unloaded.
https://bugzilla.gnome.org/show_bug.cgi?id=707298
