[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
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
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-
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
Thanks, I updated the version string.
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
