Re: lib/malloca.c: error when compiling "groff"

2022-09-14 Thread Bjarni Ingi Gislason
I get the same error with "gcc-11 (Debian 11.3.0-5) 11.3.0" and gcc-10 In "config.log" I see: configure:21128: checking for static_assert configure:21162: /usr/bin/gcc-10 -c -Walloc-zero -Walloca -Wall -Wextra -Wformat=2 -Wattribute-warning -Wdate-time -Wformat-security -Wfree-nonheap-objec

Re: lib/malloca.c: error when compiling "groff"

2022-09-14 Thread Bruno Haible
Bjarni Ingi Gislason wrote: > I had bootstrapped at 19.55 UTC so I missed the latest commit. > > I bootstrapped at 22.39 UTC with these changes: > > Updating file gnulib_m4/assert_h.m4 (backup in gnulib_m4/assert_h.m4~) > Updating file lib/verify.h (backup in lib/verify.h~) > > I made dist

Re: lib/malloca.c: error when compiling "groff"

2022-09-14 Thread Bjarni Ingi Gislason
On Wed, Sep 14, 2022 at 04:45:20PM -0500, Paul Eggert wrote: > Can you reproduce the problem with my recipe? > > One possibility is that you have an old malloca.c left over from an old > build, and it won't compile with the new Gnulib. So it may help to bootstrap > from scratch. > (all times in U

time: Fix compilation errors with clang/MSVC

2022-09-14 Thread Bruno Haible
Building a gnulib testdir on Windows, with clang and the MSVC header files, I get these compilation errors: In file included from C:\cygwin64\home\bruno\testdir-all\gllib\accept.c:27: In file included from ../../gllib/w32sock.h:23: In file included from .\fcntl.h:64: In file included from .\sys/st

Re: lib/malloca.c: error when compiling "groff"

2022-09-14 Thread Paul Eggert
Can you reproduce the problem with my recipe? One possibility is that you have an old malloca.c left over from an old build, and it won't compile with the new Gnulib. So it may help to bootstrap from scratch.

Re: lib/malloca.c: error when compiling "groff"

2022-09-14 Thread Paul Eggert
On 9/14/22 16:08, Bruno Haible wrote: CC lib/libgnu_a-malloca.o ../lib/malloca.c:42:16: error: expected declaration specifiers or '...' before numeric constant 42 | static_assert (2 * sa_alignment_max - 1 <= (small_t) -1); |^ make[1]: *** [Makefile:8629: lib/l

Re: lib/malloca.c: error when compiling "groff"

2022-09-14 Thread Bjarni Ingi Gislason
/usr/bin/gcc-12 -DHAVE_CONFIG_H -I. -I.. -I./src/include -I../src/include -I../lib -I./src/include -I./lib -D_FORTIFY_SOURCE=2 -DGCC_LINT -DGNULIB_NO_VLA -Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef -Wno-unused-function -Wno-unused-parameter -Wno-float-conversion

Re: lib/malloca.c: error when compiling "groff"

2022-09-14 Thread Bruno Haible
Bjarni Ingi Gislason wrote: > CC = gcc (Debian 12.2.0-1) 12.2.0 > > CC lib/libgnu_a-malloca.o > ../lib/malloca.c:42:16: error: expected declaration specifiers or '...' > before numeric constant >42 | static_assert (2 * sa_alignment_max - 1 <= (small_t) -1); > |^

lib/malloca.c: error when compiling "groff"

2022-09-14 Thread Bjarni Ingi Gislason
CC = gcc (Debian 12.2.0-1) 12.2.0 CC lib/libgnu_a-malloca.o ../lib/malloca.c:42:16: error: expected declaration specifiers or '...' before numeric constant 42 | static_assert (2 * sa_alignment_max - 1 <= (small_t) -1); |^ make[1]: *** [Makefile:8629: lib/libgnu_a-

Re: [PROPOSED 2/2] assert-h: prefer to ‘verify’

2022-09-14 Thread Bruno Haible
Paul Eggert wrote: > Where it’s easy, prefer ‘static_assert’ to ‘verify’, In a build of GNU gettext, with clang and the MSVC header files, I get errors starting like this: /bin/sh ./libtool --tag=CXX --mode=compile /home/bruno/msvc/compile clang-cl -ferror-limit=0 -DIN_LIBASPRINTF -DHAVE_CONF

Re: [PATCH 2/2] assert-h: work around include confusion

2022-09-14 Thread Bruno Haible
Paul Eggert wrote: > This works > around bugs in packages that mistakenly include after > including (typically due to double-inclusion of > ). Formally, I don't think it's a bug to include twice in the same compilation unit. We have documented [1] that it needs to included first, but not that i

[PATCH 2/2] assert-h: work around include confusion

2022-09-14 Thread Paul Eggert
* m4/assert_h.m4 (gl_ASSERT_H): Arrange for to not include if assert is already defined. This works around bugs in packages that mistakenly include after including (typically due to double-inclusion of ). Found in coreutils, which I plan to fix. --- ChangeLog | 7 +++ m4/assert_h.m4

[PATCH 1/2] stdbool: depend on C99

2022-09-14 Thread Paul Eggert
Record that stdbool depends on C99 these days. This matters only for ancient compilers that need special flags to support C99 features. * modules/stdbool (Depends-on): Add c99. --- ChangeLog | 8 modules/stdbool | 3 +++ 2 files changed, 11 insertions(+) diff --git a/ChangeLog b/Ch

Re: [PROPOSED 2/2] assert-h: prefer to ‘verify’

2022-09-14 Thread Bruno Haible
> > Where it’s easy, prefer ‘static_assert’ to ‘verify’, > > Compiling a current GNU gettext with MSVC 14, I get this compilation error: I got this working, by using preprocessor tricks, inspired by

Re: [PROPOSED 2/2] assert-h: prefer to ‘verify’

2022-09-14 Thread Bruno Haible
Paul Eggert wrote: > Where it’s easy, prefer ‘static_assert’ to ‘verify’, Compiling a current GNU gettext with MSVC 14, I get this compilation error: libtool: compile: /home/bruno/msvc/compile cl -nologo -DIN_LIBASPRINTF -DHAVE_CONFIG_H -D__USE_MINGW_ANSI_STDIO=0 -I. -I../../../gettext-runtime

posix_spawn-* tests: Fix test failure on mingw when libtool is in use

2022-09-14 Thread Bruno Haible
On mingw, when libtool is in use (such as in GNU gettext when --disable-shared is not specified), 4 gnulib tests fail: test-posix_spawn-inherit0 test-posix_spawn-inherit1 test-posix_spawn-open1 test-posix_spawn-open2 For example, test-posix_spawn-open1 fails with the error test-posix_spa

Re: [PROPOSED 2/2] assert-h: prefer to ‘verify’

2022-09-14 Thread Bruno Haible
Paul Eggert wrote: > Where it’s easy, prefer ‘static_assert’ to ‘verify’, On MSVC 14, in C mode, I get compilation errors: ...\gnulib-tests\test-assert.c(27): warning C4116: unnamed type definition in parentheses ...\gnulib-tests\test-assert.c(27): error C2057: expected constant expression ...\g