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.
The 'fix' from commit 16292dd753cb63f8ccb2267644aefbd2632dd52c broke the
build on 32 bit because it was missing the parentheses around "gint" / "guint"
in glib_gp[u]i_cast.
https://bugzilla.gnome.org/show_bug.cgi?id=661546
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
