When inserting custom code to AC_CHECK_ALIGNOF, make sure to not replace
the default includes, but instead append to them.
This fixes ALIGNOF_GUINT32 and ALIGNOF_GUINT64 that were both 0 when cross
compiling. The third 'unsigned long' test wasn't affected because the
AC_CHECK_ALIGNOF call didn't specify the optional 2nd parameter.
We need a stable sort, and we might as well always use it rather
than have multiple sort versions. This picks up the glibc
merge sort implementation which it uses by default for qsort,
except we don't fall back to non-stable quicksort in some cases
like glibc
https://bugzilla.gnome.org/show_bug.cgi?id=672095
There are cases when it should be possible to define at compile time
what range of functions and types should be used, in order to get,
or restrict, the compiler warnings for deprecated or newly added
types or functions.
For instance, if GLib introduces a deprecation warning on a type in
version 2.32, application code can decide to specify the minimum and
maximum boundary of the used API to be 2.30; when compiling against
a new version of GLib, this would produce the following results:
- all deprecations introduced prior to 2.32 would emit compiler
warnings when used by the application code;
- all deprecations introduced in 2.32 would not emit compiler
warnings when used by the application code;
- all new symbols introduced in 2.32 would emit a compiler warning.
Using this scheme it should be possible to have fairly complex
situations, like the following one:
assuming that an application is compiled with:
GLIB_VERSION_MIN_REQUIRED = GLIB_VERSION_2_30
GLIB_VERSION_MAX_ALLOWED = GLIB_VERSION_2_32
and a GLib header containing:
void function_A (void) GLIB_DEPRECATED_IN_2_26;
void function_B (void) GLIB_DEPRECATED_IN_2_28;
void function_C (void) GLIB_DEPRECATED_IN_2_30;
void function_D (void) GLIB_AVAILABLE_IN_2_32;
void function_E (void) GLIB_AVAILABLE_IN_2_34;
any application code using the above functions will get the following
compiler warnings:
function_A: deprecated symbol warning
function_B: deprecated symbol warning
function_C: no warning
function_D: no warning
function_E: undefined symbol warning
This means that it should be possible to gradually port code towards
non-deprecated API gradually, on a per-release basis.
https://bugzilla.gnome.org/show_bug.cgi?id=670542
This lets you poke at resources in elf files and
standalone resource bundles. So far, only listing
and extracting resources is supported. The support
for elf files requires libelf.
In non-UTF-8 locales, the translations and nl_langinfo() return values
must be converted to UTF-8 before being returned to the caller.
Likewise, when making a recursive call to expand a format like '%x',
the format string must first be converted to UTF-8.
https://bugzilla.gnome.org/show_bug.cgi?id=668250
This should help getting static builds working on mingw.
Based on a patch by Volker Grabsch, bug 619126.
At the same time, drop the unnecessary GLIB_RT_LIBS variable;
we are already adding -lrt to G_THREAD_LIBS.
If we don't do the cast to the proper size in 32 bits, things like below
doesn't work:
uint8_t u = 20;
void *p;
p = GUINT_TO_POINTER(u);
Signed-off-by: Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=661546
Add GNetworkMonitor and its associated extension point, provide a base
implementation that always claims the network is available, and a
netlink-based implementation built on top of that that actually tracks
the network state.
https://bugzilla.gnome.org/show_bug.cgi?id=620932
For some reason, the setting of g_atomic_lock_free wasn't making it down
to the lower part of the configure script where glibconfig.h was being
generated when building using mingw32-configure.
If we prefix glib_cv_ to the start of the variable name (like everyone
else is doing) then it magically starts working.
I love you, automake.
We clean up the detection of if we should do 'real' atomic operations or
mutex-emulated ones with the introduction of a new (public) macro:
G_ATOMIC_LOCK_FREE. If defined, our atomic operations are guaranteed to
be done in hardware.
We need to use __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 to determine if our
compiler supports GCC-style atomic operations from the gatomic.h header
because we might be building a program against GLib using a different
set of compiler options (or a different compiler) than was used to build
GLib itself.
Unfortunately, this macro is not available on clang, so it has currently
regressed to using the mutex emulation. A bug about that has been
opened here:
http://llvm.org/bugs/show_bug.cgi?id=11174
These were meant to provide the ability to use GLib directly out of its
build tree but have a couple of rather serious limitations that prevent
their serious use:
- these files only worked with programs built using libtool
- for non-trivial uses, other environment variables will need to be
setup to allow GLib to function properly
- the system doesn't stack well when attempting to use multiple
libraries all uninstalled
The jhbuild --prefix= style system works much better in every way, so we
remove this old hack.
We can just assume that strerror/strsignal are available
nowadays. At the same time, drop use of thread-private storage.
Instead, always return interned strings.
https://bugzilla.gnome.org/show_bug.cgi?id=660849
Now that GMutex is exposed we can avoid the dance we did in ./configure
to allocate the correct amount of space for it within the GStaticMutex.
Remove the checks and move the definitions to gthread.h, trying very
hard to keep ABI-stable (even though we will be deprecating this soon).
Implement g_ascii_strto{d,ll,ull} and g_ascii_formatd using
xlocale functions where available. This is slightly faster
and a lot less icky than our homegrown code.
https://bugzilla.gnome.org/show_bug.cgi?id=640293
configure.ac defined G_THREAD_SOURCE and gthread-impl would #include it.
Instead, since we only have two thread implementations now, and since we
always use the Windows one only on Windows, move the logic to the
Makefile, predicated on 'if OS_WIN32'. Then have the chosen backend do
the #include "gthread-impl.c" from there.
Remove the G_THREAD_SOURCE define from configure.ac.
In particular, remove the libasyncns import, which was only used by
GUnixResolver, which is only used when threads are not available.
Likewise remove GWin32Resolver, and the hacky broken non-threaded
parts of GIOScheduler.
https://bugzilla.gnome.org/show_bug.cgi?id=616754
G_THREADS_ENABLED still exists, but is always defined. It is still
possible to use libglib without threads, but gobject (and everything
above it) is now guaranteed to be using threads (as, in fact, it was
before, since it was accidentally impossible to compile with
--disable-threads).
https://bugzilla.gnome.org/show_bug.cgi?id=616754
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.
