Re: Test suite failure for gettext's gnulib on ARMv7HL

2020-08-03 Thread Bruno Haible
Kamil Dudka wrote: > Yes, the `ASSERT (msg3 == msg4 || STREQ (msg3, str3))` check is failing here: > > > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=tests/test-strerror_r.c;h=b11d6fd9#l170 The ASSERT means "either msg3 has been clobbered by the strerror (1729576) call, or it h

Re: Prefer documented autoconf macro 'm4_if' over 'ifelse'

2020-08-03 Thread Bruno Haible
Likewise here (from gettext): 2020-08-03 Bruno Haible Prefer documented autoconf macro 'm4_if' over 'ifelse'. * m4/progtest.m4 (AM_PATH_PROG_WITH_TEST): Use m4_if instead of ifelse. diff --git a/m4/progtest.m4 b/m4/progtest.m4 index f28010a..0355e61 100644 --- a/m4/progtest.m

ffs*, integer_length*: Optimized for MSVC

2020-08-03 Thread Bruno Haible
In new code, I'm making intensive use of the functions ffs and ffsll, for searching in a bitset. So, these functions should better be well optimized, even for MSVC. And while at it, also the integer_length* functions. 2020-08-03 Bruno Haible integer_length_ll: Optimize for MSVC in 64

Re: Some small autoconf macro improvements

2020-08-03 Thread Bruno Haible
> 2020-07-25 Bruno Haible > > sigprocmask: Small autoconf macro improvement. > * m4/signalblocking.m4 (gl_SIGNALBLOCKING): Make it possible for the > user to override the value of gl_cv_func_sigprocmask. > * m4/gnulib-common.m4 (gl_SILENT): New macro. Since two people r

Re: 'fdl' vs. 'fdl-1.3': difference and/or redundant?

2020-08-03 Thread Bernhard Voelker
On 2020-08-02 00:29, Karl Berry wrote: > It would need to be applied upstream (maybe by Karl?). > > Not me, these days. Writing bug-standa...@gnu.org is the right thing to do. I see, thanks. --> https://lists.gnu.org/r/bug-standards/2020-08/msg0.html Have a nice day, Berny

Re: [PATCH] fopen-gnu: do not define __need_FILE.

2020-08-03 Thread Bruno Haible
Harald van Dijk wrote: > __need_FILE is only used here to ensure the system's is > included, not to limit what defines. Use gnulib's > _GL_ALREADY_INCLUDING_STDIO_H for that, which does not conflict with > libc uses of __need_FILE. > > This matches what was already done in 2016 for freopen.c. T

[PATCH] fopen-gnu: do not define __need_FILE.

2020-08-03 Thread Harald van Dijk
__need_FILE is only used here to ensure the system's is included, not to limit what defines. Use gnulib's _GL_ALREADY_INCLUDING_STDIO_H for that, which does not conflict with libc uses of __need_FILE. This matches what was already done in 2016 for freopen.c. --- lib/fopen.c | 4 ++-- 1 file ch

Re: Test suite failure for gettext's gnulib on ARMv7HL

2020-08-03 Thread Kamil Dudka
On Monday, August 3, 2020 2:57:22 PM CEST Bastien Nocera wrote: > On Mon, 2020-08-03 at 12:55 +0200, Kamil Dudka wrote: > > On Friday, July 31, 2020 6:47:08 PM CEST Bastien Nocera wrote: > > > Hey, > > > > > > Gettext 0.20.2's gnulib copy has its test suite failing on Fedora > > > rawhide on ARMv7

Re: Test suite failure for gettext's gnulib on ARMv7HL

2020-08-03 Thread Bastien Nocera
On Mon, 2020-08-03 at 12:55 +0200, Kamil Dudka wrote: > On Friday, July 31, 2020 6:47:08 PM CEST Bastien Nocera wrote: > > Hey, > > > > Gettext 0.20.2's gnulib copy has its test suite failing on Fedora > > rawhide on ARMv7HL. I'm afraid that it's Friday late in the day, > > and I > > don't have mu

Re: Test suite failure for gettext's gnulib on ARMv7HL

2020-08-03 Thread Kamil Dudka
On Friday, July 31, 2020 6:47:08 PM CEST Bastien Nocera wrote: > Hey, > > Gettext 0.20.2's gnulib copy has its test suite failing on Fedora > rawhide on ARMv7HL. I'm afraid that it's Friday late in the day, and I > don't have much more information than what's available in the build > logs. > > Th

Re: Test suite failure for gettext's gnulib on ARMv7HL

2020-08-03 Thread Bastien Nocera
On Fri, 2020-07-31 at 22:36 +0200, Bruno Haible wrote: > [Removing bug-gettext from CC.] > > Bastien Nocera wrote: > > Gettext 0.20.2's gnulib copy has its test suite failing on Fedora > > rawhide on ARMv7HL. > > The current release is gettext 0.21. And its gnulib tests fail in the > same way [1]