On 20/05/18 18:50, Bruno Haible wrote:
> Pádraig Brady wrote:
>> That suggests we're not replacing
>> wcwidth on this OSX system, and that the system implementation
>> is just very slow, which the attached patch should avoid if possible.
>
> If we have a system where wcwidth is very slow, gnulib c
Pádraig Brady wrote:
> That suggests we're not replacing
> wcwidth on this OSX system, and that the system implementation
> is just very slow, which the attached patch should avoid if possible.
If we have a system where wcwidth is very slow, gnulib could
override the function with a faster impleme
On a system with a recent libunistring installed, a testdir of all of gnulib
produces a link error in test-wcwidth (regarding the symbol 'uc_width').
The reason is that the 'libunistring' or 'libunistring-optional' modules
causes 'uc_width' to come from libunistring.
This fixes it.
2018-05-20 B
Hi Paul,
But there is no implementation for native Windows!
Cygwin does it by use of the PDH functions [1], plus some custom
logic to get the averages right. But 'make' needs only the first number,
therefore it would be sufficient to provide the _current_ load instead
of an average, right? In thi
* lib/getloadavg.c: Reinstate ifdef for HAVE_UNISTD_H
* m4/getloadavg.m4: Check for unistd.h
---
An alternative would be to use ifdef WINDOWS32 instead of checking
for unistd.h.
lib/getloadavg.c | 4 +++-
m4/getloadavg.m4 | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/
Now that module 'localcharset' no longer includes m4/glibc21.m4, I get
this error in coreutils:
autoreconf: running: aclocal -I m4 --force -I m4
configure.ac:63: warning: gl_GLIBC21 is m4_require'd but not m4_defun'd
m4/regex.m4:289: gl_PREREQ_REGEX is expanded from...
m4/gnulib-comp.m4:847: gl_IN
Hi,
Since wcwidth() reportedly has become a bottleneck [1][2], and some of the time
the gnulib wcwidth() replacement spends is in localcharset(), let me optimize
localcharset().
Patch 1 removes support for Linux libc5 (obsolete since ca. 2001), glibc 2.0.x
(last used in Red Hat Linux 5.2, obsolet
Hi Jim,
> This is a tool by which one uploads signed tarballs to (usually) GNU
> servers, presumably for mass distribution. As such, I think we are
> justified in holding packagers/uploaders to a higher standard. At the
> very least, we should feel justified in expecting that an uploader run
> on
