Re: iswprint() and wcwidth() don't work properly on some platforms with certain unicodes

Eric Blake wrote: > > variable > >gl_cv_func_wcwidth_works=no > > at configure time. > > ... it is not a wise idea to codify > that into libvirt's configure.ac (or any other project). Yes, I agree. > Rather, if libvirt is hitting test failures due solely to the difference > of Unicode vers

Re: iswprint() and wcwidth() don't work properly on some platforms with certain unicodes

On 08/31/2018 12:42 PM, Bruno Haible wrote: Yes. This particular character (U+1F600) was added in Unicode 6.1 [1][2]. The iswprint() function is implemented in the libc, which is why you see differences across platforms. After a new Unicode release is made, it takes some time until the picks it

Re: Regression: "wchar: fix bug when checking for ‘inline’" breaks distcc usage

Thomas Deutschmann wrote: > > From 285334ca5ac8f537bc183abd121aa68984e5a515 Mon Sep 17 00:00:00 2001 > > From: Paul Eggert > > Date: Sun, 1 Jul 2018 18:57:01 -0700 > > Subject: wchar: fix bug when checking for ‘inline’ > > (https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=285334ca5ac8f

Re: Problem with localcharset test

Le 03/09/2018 à 21:22, Bruno Haible a écrit : Thanks, you made it easy for me to reproduce the issue. Fixed as follows: 2018-09-03 Bruno Haible gnulib-tool: Fix build order when $testsbase is a subdir of $sourcebase. Reported by Antoine Luong in

Regression: "wchar: fix bug when checking for ‘inline’" breaks distcc usage

Hi, I noticed that the following change has broken distcc usage: > From 285334ca5ac8f537bc183abd121aa68984e5a515 Mon Sep 17 00:00:00 2001 > From: Paul Eggert > Date: Sun, 1 Jul 2018 18:57:01 -0700 > Subject: wchar: fix bug when checking for ‘inline’ (https://git.savannah.gnu.org/gitweb/?p=gnulib