Re: [libvirt] [PATCH v2] json: fix interface locale dependency

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