Hello Paul, I’m not sure why you say it’s a local variable. It’s a “FILE *” isn’t it?
So, with runtime /MDd (/MD doesn’t have the issue), I do have flclose.m4 and fclose.c. I also see checking whether fcloseall is declared... yes I’ve setup a gist at https://gist.github.com/jmarrec/a2492f60623bb8eeee3e7e3f3edf2243 (config.log is 2MB so sending to a mailing list didn't seem like a god idea) in which you'll find: - build_m4.log: this is the console output from running my conan create command (cf [1] below) - config.log: this is the m4 config.log in the build folder - tree.txt: the folder structure in my build folder. the M4 sources are in “source*subfolder”. This is the output of running `tree /F /A C:\Users\julien.conan\data\m4\1.4.19\*_\build\01edd76db8e16db9b38c3cca44ec466a9444c388 > .\tree.txt` [1] If you want to reproduce, and have conan installed and MSVC 2019, this command should do it conan install m4/1.4.19@#7bf4b7de37a545f40f65aeb26e4f135f -b m4 -s arch=x86_64 -s arch_build=x86_64 -s build_type=Debug -s compiler="Visual Studio" -s compiler.runtime=MD -s compiler.version=16 -s os=Windows -s os_build=Windows Best, Julien -- Julien Marrec, EBCP, BPI MFBA Owner at EffiBEM <http://www.effibem.com> T: +33 6 95 14 42 13 LinkedIn (en <https://www.linkedin.com/in/julienmarrec>) *| *(fr <https://fr.linkedin.com/in/julienmarrec/fr>) : <http://www.linkedin.com/in/julienmarrec> Le mer. 26 janv. 2022 à 06:35, Paul Eggert <egg...@cs.ucla.edu> a écrit : > On 1/25/22 14:33, Julien Marrec wrote: > > >> Are the programs in question using the fclose module, either directly or > > indirectly? > > > > Well, simply doing `m4.exe --version` does exhibit the issue. > > For the module info we need to look at something other than that. > > Does your m4 source code contain the files fclose.c and fclose.m4 > somewhere? > > When you configured m4, did it say "checking whether fclose works on > input streams" and if so what was the result? > > When you built m4, did the build compile fclose.c and create an object > file fclose.o? > > > In close_stream, shouldn't the stdout FILE * be set to NULL if the close > > worked > > No, as that's just a local variable so setting it to NULL won't persist > until the next call. >
