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 fi
Thanks, I updated the version string.
File: git/gnulib/build-aux/bootstrap
scriptversion=2021-04-11.09;
According to "git blame bootstrap", material has been added at dates
"2021-12-12" and "2022-01-05" without updating the announced string
"scriptversion" in the output of "bootstrap --version".
This also affects the string "cop
hello,
Thanks for the answers, I'm trying to keep up / follow.
> Are the programs in question using the fclose module, either directly or
indirectly?
Well, simply doing `m4.exe --version` does exhibit the issue. Not sure if
I'm answering the question correctly or not.
I'm looking at the close-
On 1/25/22 08:13, Eric Blake wrote:
it something that gnulib should work around by
overriding fclose() to be guaranteed that it has an open fd?
This is a bug that Gnulib's fclose module is already supposed to be
working around. Are the programs in question using the fclose module,
either dire
[adding bug-gnulib]
On Mon, Jan 24, 2022 at 05:00:01PM +0100, Julien Marrec wrote:
> Hello,
>
> I realize this is probably not a combination of platform, compiler and
> build type that you anticipated. m4 is used in a conan - the C++ package
> manager - recipe, and it serves as the basis for many
