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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list