On 08/10/2012 05:39 PM, Eric Blake wrote:
On 08/10/2012 03:43 AM, Martin Kletzander wrote:
I'm still worried about whether 'struct lconv' will compile on mingw. Then again, any system that lacks localeconf() probably also lacks any locale that would use ',' for the decimal separator, so maybe appropriate ifdef protection is all we need.
As we based it on glib code, I'd say: "they have it like this" :)
But part of the code depends on the configure time checks that were performed, and glib uses different configure checks than libvirt's use of gnulib. While copying the code is easy, tweaking the configure script to pick up the right conditions is where all the porting fun comes when porting a glib function to live in isolation.
+#if HAVE_XLOCALE_H
And where does HAVE_XLOCALE_H get defined? Autoconf conventions say it would map to <xlocale.h> existing, but that is a non-standard header name. Not to mention that we really care about whether newlocale and setlocale exist.
I tried to create a have_xlocale with AC_COMPILE_IFELSE but since uselocale, newlocale and freelocale are part of libc, I haven't managed to make it fail.
Here's how I'd do it. In configure.ac, add:
AC_CHECK_FUNCS_ONCE([newlocale])
if newlocale exits, then so do uselocale and freelocale; if newlocale does not exist, then we go to fallback code.
In bootstrap.conf, add localeconv to gnulib_modules. Then gnulib's localeconv is guaranteed to exist, and we are guaranteed that our fallback code will compile even on mingw.
In util.c, write your code to do:
#if HAVE_NEWLOCALE code using thread-safe locale swapping to our once-init C locale_t #else code using strstr of the localeconv()->decimal_point #endif
I partially had that when I read this mail. I finished it now, but to be honest, even though it works, it's reusable and so on it doesn't look very good. I think I'll cook one more version of that and will post both of them. And if you'd be so kind and had a look once more at that, I'd appreciate that. Martin