Hi Simon, > > You are encountering an issue that is fixed in gnulib commit > > 9022a57103a974e35e3f077f52ba0531eb5c81fc (2026-07-08), but your package > > is using the stable branch [2] and therefore does not have this fix. > > Ah, thanks for finding that one. That commit was added in > 659b9de65cb04db9b6739c861d4506fff92da542 to stable-202607, so I don't > think tracking gnulib master would make a difference.
Ah, indeed. > I think the problem is that the mingw gcc --version output doesn't > match: > $ x86_64-w64-mingw32-gcc --version|sed 1q > x86_64-w64-mingw32-gcc (GCC) 14-win32 > $ gcc --version|sed 1q > gcc (Debian 14.2.0-19) 14.2.0 > > The mingw --version output is rather weird, maybe it should be reported > to report something better (like '14.2.0-win32'). Yes. As you can see in the "gcc --version" output, there is plenty of possibility to describe a modified gcc in the parenthesized part. Appending it to a major version number, while omitting the minor version number, is too likely to break scripts. > However manywarnings.m4 could also have a more reliable mechanism when > to enable -Wzero-as-null-pointer-constant. Each such test would be a compiler run. While we try to make 'configure' prepared to most imaginable situations, people are already complaining for a long time that 'configure' is slow. (For instance, in GNU gettext, 1/3 of the build time is consumed by running 'configure'.) Bruno
