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
