Spotting the diff was trivial - it's caused by an idempotency check for
stddef.h that was added to gnulib in commit e529f4f on 8 April 2025
This stddef.h idempotent check makes autoconf set STDDEF_NOT_IDEMPOTENT to 0 in
builds from latest Bison source after Paul's update
Without the check, STDDEF_NOT_IDEMPOTENT is set to 1
The impact is here in gnulib/lib/stddef.h.in
#if (defined __need_wchar_t || defined __need_size_t \ ||
defined __need_ptrdiff_t || defined __need_NULL \ || defined
__need_wint_t) \ /* Avoid warning
triggered by "gcc -std=gnu23 -Wsystem-headers" \ in GCC 13.3 and 14.2
\
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870>. */ \ &&
!@STDDEF_NOT_IDEMPOTENT@/* Special invocation convention inside gcc header
files. In particular, <stddef.h> in some ancient versions of GCC blindly
redefined NULL when __need_wint_t was defined, even though wint_t is not
normally provided by <stddef.h>. (FIXME: It's not clear what GCC versions
those were - perhaps so ancient that we can stop worrying about this?)
Although glibc 2.26 (2017) and later do not use __need_wint_t, for
portability to macOS, Cygwin, Haiku, and older Glibc + GCC, remember if
special invocation has ever been used to obtain wint_t, in which case we need
to clean up NULL yet again. */
# if !(defined _@GUARD_PREFIX@_STDDEF_H && defined
_@GUARD_PREFIX@_STDDEF_WINT_T)# ifdef __need_wint_t# define
_@GUARD_PREFIX@_STDDEF_WINT_T# endif# @INCLUDE_NEXT@ @NEXT_STDDEF_H@ /* On
TinyCC, make sure that the macros that indicate the special invocation
convention get undefined. */# undef __need_wchar_t# undef __need_size_t#
undef __need_ptrdiff_t# undef __need_NULL# undef __need_wint_t# endif
#else/* For @STDDEF_NOT_IDEMPOTENT@. */# undef __need_wchar_t# undef
__need_size_t# undef __need_ptrdiff_t# undef __need_NULL# undef __need_wint_t
/* Normal invocation convention. */...#endif
With latest Bison source this allows in preprocessed AnnotationList.i
#define _WINT_Ttypedef unsigned int wint_t;
but not in builds from earlier Bison source because its gnulib submodule
version was from early 2024 - definitely before 8 April 2025
I hope this helps anyone who runs into this issue trying to build Bison on
Cygwin
Until there's a new Bison release the fix is to use source since Paul's update
commit 2ceaf03
Zartaj
On Friday, July 11, 2025 at 07:05:59 AM CDT, Z. Majeed
<zmaj...@sbcglobal.net> wrote:
This is the latest cygwin I'm using - is it exactly the version you tried?
uname -r3.6.3-1.x86_64
with gcc version16.0.0 20250706 (experimental)
on Windows 24H2 OSBuild 26100.4484 - as shown by winver
Any difference in versions can affect feature-test macros
The build below for the new worktree for commit 4ff0741 was in a completely new
directory build/master.old - it failed on first attempt
The old clone from when I first got the error was deleted after I found out
about Paul's update
I made a new clone and new worktree with new build directory for the successful
build - also worked on first attempt
I'll look at the preprocessed files later for the good and bad bison builds -
shouldn't be hard to find the difference
On Friday, July 11, 2025 at 02:28:44 AM CDT, Bruno Haible <br...@clisp.org>
wrote:
Z. Majeed wrote:
> Here are the steps I followed
> git clone --single-branch git://git.savannah.gnu.org/bison master
>
> git worktree add -b master.old ../master.old 4ff0741
> HEAD is now at 4ff0741f maint: make update-copyright
>
> git submodule update --init --recursive
> ./bootstrap
> git submodule ee27e996435f0daf0f8cd960285abb5859f50a4d gnulib
> (v1.0-1578-gee27e99643) 2f64dcd048b08bb90ec44b26f4cd6b729112a28e
> submodules/autoconf (v2.72-76-g2f64dcd0)
> mkdir build/master.old
> configure --disable-silent-rules CFLAGS="-O0 -ggdb3 -Wall -Wextra"
> CXXFLAGS="-O0 -ggdb3 -Wall -Wextra" LDFLAGS=-ggdb3
>
> make
> make[3]: Leaving directory 'build/master.old/gnulib-po'touch stamp-pomake[2]:
> Leaving directory 'build/master.old/gnulib-po'Making all in .make[2]:
> Entering directory 'build/master.old'gcc -DEXEEXT=\".exe\" -I. -I./lib
> -Imaster.old -Imaster.old/lib -O0 -ggdb3 -Wall -Wextra -MT
> src/bison-AnnotationList.o -MD -MP -MF src/.deps/bison-AnnotationList.Tpo -c
> -o src/bison-AnnotationList.o `test -f 'src/AnnotationList.c' || echo
> 'master.old/'`src/AnnotationList.cIn file included from
> /usr/include/sys/reent.h:16, from /usr/include/stdio.h:60,
> from ./lib/stdio.h:55, from
> master.old/lib/bitset.h:31, from .master.old/lib/bitsetv.h:29,
> from master.old/src/AnnotationList.h:24, from
> master.old/src/AnnotationList.c:23:/usr/include/sys/_types.h:167:5: error:
> unknown type name 'wint_t' 167 | wint_t __wch; | ^~~~~~In file
> included from master.old/src/system.h:173, from
> master.old/src/gram.h:105, from
> master.old/src/InadequacyList.h:25, from
> master.old/src/AnnotationList.h:27:master.old/src/AnnotationList.c: In
> function
> 'AnnotationList__compute_from_inadequacies':master.old/src/AnnotationList.c:465:38:
> warning: comparison of integer expressions of different signedness: 'int'
> and 'size_t' {aka 'long unsigned int'} [-Wsign-compare] 465 |
> aver (item_i < s->nitems); |
> ^master.old/src/AnnotationList.c:465:25: note: in expansion of macro 'aver'
> 465 | aver (item_i < s->nitems); |
> ^~~~make[2]: *** [Makefile:10531: src/bison-AnnotationList.o] Error
> 1make[2]: Leaving directory 'build/master.old'make[1]: *** [Makefile:12146:
> all-recursive] Error 1make[1]: Leaving directory 'build/master.old'make: ***
> [Makefile:4928: all] Error 2
Thanks for providing these. This is something one can attempt to
reproduce and investigate.
I tried that (i.e. state of git://git.savannah.gnu.org/bison master as of
two days ago, including its two submodules), generated a tarball with
./bootstrap
./coonfigure && make && make dist
and built that on Cygwin 3.6.3 with CFLAGS=-O0 CXXFLAGS=-O0.
Result: It builds perfectly fine.
So, Paul's updates from yesterday were not even needed.
> You're right about the update to Bison in March 2025 - your changes were in
> there - but it did not fix the problem in Bison - I don't know why
I'd guess that you had files left in the build tree, from a prior build.
You need to do "make distclean" (or even "./configure; make distclean")
to get rid of such old files, after a "git pull" or "git submodule update"
or similar.
> responding to someone who's just trying to help your project and get some
> help from people who work on the project on a regular basis
> ...
> it usually takes hours of frustration to figure out what went wrong
I understand the frustration. Nonetheless, a frustration report is not
helpful. The only way to make the communication helpful — for both the
reporter and the upstream maintainers — is to state:
1) What did you do?
2) What were the results?
3) [If not obvious:] What other results did you expect?
Bruno
