Re: bison 3.7.1 failing to build due to autoconf cache

Hi Paul, Paul Smith wrote: > > If I compare the configure output from a run with using the cache > > (fails) with one that doesn't use the cache (succeeds) the only > > difference of interest is: > > -checking for sigprocmask... (cached) 1 > +checking for sigprocmask... yes > ... >

[PATCH] fcntl: document some F_SETLK errno variations

* doc/posix-functions/fcntl.texi (fcntl): Document OpenIndiana, GNU/Linux, FreeBSD on NFS files. --- ChangeLog | 6 ++ doc/posix-functions/fcntl.texi | 8 2 files changed, 14 insertions(+) diff --git a/ChangeLog b/ChangeLog index cec93905a..b078da4d3 100644 ---

Re: bison 3.7.1 failing to build on Centos 7: verify_NSIG_constraint

On Sun, 2020-08-02 at 18:58 -0400, Paul Smith wrote: > If I compare the configure output from a run with using the cache > (fails) with one that doesn't use the cache (succeeds) the only > difference of interest is: > > @@ -378,7 +379,7 @@ >checking whether program_invocation_name is

Re: bison 3.7.1 failing to build on Centos 7: verify_NSIG_constraint

On Sun, 2020-08-02 at 17:54 -0400, Paul Smith wrote: > The latest Bison release 3.7.1 is not compiling for me, and it > appears to be a gnulib issue. > > Here's the failure: > > gcc -DEXEEXT=\"\" -I. -I./lib -Ibison-3.7.1 -Ibison-3.7.1/lib \ > -DDEFAULT_TEXT_DOMAIN=\"bison-gnulib\"

bison 3.7.1 failing to build on Centos 7: verify_NSIG_constraint

The latest Bison release 3.7.1 is not compiling for me, and it appears to be a gnulib issue. Here's the failure: gcc -DEXEEXT=\"\" -I. -I./lib -Ibison-3.7.1 -Ibison-3.7.1/lib \ -DDEFAULT_TEXT_DOMAIN=\"bison-gnulib\" -march=nehalem -mtune=intel \ -ffile-prefix-map=bison-3.7.1/= -O2 -fPIC

oset: Add an 'iterator_atleast' operation

In an application that uses an ordered set (gl_oset), I need an iterator that starts at the first element that has a value >= threshold. And it should be fast in the case when only 1 or 2 or 3 elements from that iterator are needed, but the entire set is large. It can't be realized with the

oset-c++, omap-c++: Remove restriction for search_atleast method

The threshold argument in the search_atleast method is meant to be unrelated to the ELTYPE or KEYTYPE types, respectively. 2020-08-02 Bruno Haible oset-c++, omap-c++: Remove restriction for search_atleast method. * lib/gl_oset.hh (gl_OSet::search_atleast): Allow the threshold

Re: signal.h:682:13: error: size of array 'verify_NSIG_constraint' is negative

On 02.08.20 15:41, Bruno Haible wrote: > Tim Rühsen wrote: >> The surrounding code in lib/signal.h is >> #if 1 >> # if !0 > > Huh? HAVE_POSIX_SIGNALBLOCKING evaluates to 0 ?! > > There was a change to m4/signalblocking.m4 recently, but for me it works. > Can you take a look at the "checking for

Re: signal.h:682:13: error: size of array 'verify_NSIG_constraint' is negative

Tim Rühsen wrote: > The surrounding code in lib/signal.h is > #if 1 > # if !0 Huh? HAVE_POSIX_SIGNALBLOCKING evaluates to 0 ?! There was a change to m4/signalblocking.m4 recently, but for me it works. Can you take a look at the "checking for sigprocmask..." test in config.log? Bruno

Re: signal.h:682:13: error: size of array 'verify_NSIG_constraint' is negative

Hi Tim, > after updating gnulib, I see this on all CI pipelines (Debian, Fedora, > Alpine, Arch, ...): > > In file included from /usr/include/x86_64-linux-gnu/sys/param.h:28, > from ./minmax.h:34, > from md2.c:30: > ./signal.h:682:13: error: size of array

signal.h:682:13: error: size of array 'verify_NSIG_constraint' is negative

Hey, after updating gnulib, I see this on all CI pipelines (Debian, Fedora, Alpine, Arch, ...): In file included from /usr/include/x86_64-linux-gnu/sys/param.h:28, from ./minmax.h:34, from md2.c:30: ./signal.h:682:13: error: size of array