We had the 12 hour time format hard-coded to "%02d:%02d:%02d %s" but it
actually changes depending on the locale. Just with the other formats,
use nl_langinfo() if we have it, otherwise fall back on gettext().
- getmntinfo can take struct statfs or statvfs depending on the
OS. Use getvfsstat and if not found getfsstat instead. Idea from
Dan Winship.
- g_local_file_query_filesystem_info(): use statvfs.f_fstypename
if available
https://bugzilla.gnome.org/show_bug.cgi?id=617949
Improve a few situations where g_date_time_format() was getting the
padding wrong when displaying alt digits (eg: Arabic numerals) for
formatting time.
We now depend on nl_langinfo (_NL_CTYPE_OUTDIGITn_WC) to do the
conversion, which is very likely glibc-specific, but our previous method
relied on a glibc-specific printf() feature, so no harm done there.
Add a configure check for nl_langinfo (_NL_CTYPE_OUTDIGITn_WC).
Uncomment a few testcases that were failing previously.
https://bugzilla.gnome.org/show_bug.cgi?id=658107
Also, link libgio to -lresolv explicitly, rather than depending on
getting it implicitly via the libasyncns build (which should
eventually be going away).
https://bugzilla.gnome.org/show_bug.cgi?id=645336
This makes the source efficient on Linux.
Tested on Fedora 15 x86_64 + updates, kernel-2.6.40-4.fc15.x86_64
Also tested fallback code for unsupported flag TFD_TIMER_CANCEL_ON_SET
on kernel 2.6.38.
https://bugzilla.gnome.org/show_bug.cgi?id=655129
This makes g_date_time_format() react to LC_TIME, which is
what people expect.
Translators: this change means that the GDateTime strings
are only used when the C library does not already provide
suitable translated strings for these (month names, etc).
We need to test the case of eventfd in the libc but no kernel support.
In order to do that, we add a separate compile of the GWakeup testcase
that interposes an 'eventfd' symbol that always returns -1 with errno
set. That will trigger the fallback case.
- move choice of statfs vs statvfs from gio/glocalfile.c to configure.ac
- if statvfs is the choice, then don't check number of arguments to statfs()
- use choice in gio/gunixmounts.c as well
https://bugzilla.gnome.org/show_bug.cgi?id=617949
The Linux eventfd() call is basically tailor made for the main loop
wake up pipe - all we want is a threadsafe way to write to a file
descriptor, and wake up the context on the other end; we don't care
about the content at all.
The eventfd manual page basically explains the benefits:
Applications can use an eventfd file descriptor instead of a
pipe (see pipe(2)) in all cases where a pipe is used simply to
signal events. The kernel overhead of an eventfd file
descriptor is much lower than that of a pipe, and only one file
descriptor is required (versus the two required for a pipe).
When writing my multithreaded spawn test case I actually hit the 1024
file descriptor limit quickly, because we used 2 fds per main context.
This brings that down to 1.
https://bugzilla.gnome.org/show_bug.cgi?id=653140
We can use AC_CHECK_FUNCS to detect if qsort_r is available on
the system or not since it will unconditionnally define
HAVE_QSORT_R, which we don't want since on BSD, qsort_r isn't usable
for us, so we don't want to have HAVE_QSORT_R defined on such platforms.
By using AC_CHECK_FUNC instead, we can defer defining HAVE_QSORT_R until
we have actually tested it's usable.
https://bugzilla.gnome.org/show_bug.cgi?id=651920
When cross compiling, test programs cannot be run. In order to make it
easier to cross compile for targets that do not have qsort_r(), check
for the function before trying to run the test program.
This avoid having to populate cache with glib_cv_have_qsort_r=no with
e.g. mingw cross compiler.
https://bugzilla.gnome.org/show_bug.cgi?id=651920
This avoids the generated types (e.g. ExampleAnimal, ExampleCat,
ExampleObject and ExampleObjectManagerClient) being referenced in the
core gio docs. This was requested by Matthias.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Commit 22e7fc34c4 introduced a regression:
futexes were always disabled and the emulated codepath was always being
used. That commit was in response to an originally buggy
implementationt hat wrote junk into config.h (but happened to be working
properly).
Fix up the mess and while we're at it, close bug #631231 by including
syscall.h from the correct location and using __NR_futex instead of
SYS_futex.
Closes#631231.
When using gcc builtins for atomic operations, provide them
as macros, so gcc can see the builtins and do optimizations.
This change gives considerable speedups in bitlocks, which
use atomic operations heavily, see bug 650458.
Also, don't define G_ATOMIC_OP_MEMORY_BARRIER_NEEDED unconditionally
when using gcc builtins.
https://bugzilla.gnome.org/show_bug.cgi?id=617491
_GNU_SOURCE must be defined before including any other (system)
header, so defining it in glib-unix.h (and hoping no one has included
anything else before that) is wrong. And the "#define _USE_GNU"
workaround for this problem in gnetworkingprivate.h is even wronger
(and still prone to failure anyway due to single-include guards).
Fix this by defining _GNU_SOURCE in config.h when building against
glibc. In theory this is bad because new releases of glibc may include
symbols that conflict with glib symbols, which could then cause
compile failures. However, most people only see new releases of glibc
when they upgrade their distro, at which point they also generally get
new releases of gcc, which have new warnings/errors to clean up
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=649201
