On Sat, Oct 22, 2022 at 11:57:36AM +0300, Eli Zaretskii wrote: > I don't understand why this happens now whereas it didn't happen in > Texinfo-6.8; both XSParagraph.xs and Gnulib's stdlib.h seem to be > identical in both versions of Texinfo. I fixed this temporarily by > adding the following in XSParagraph.c (the actual change should > probably be in XSParagraph.xs instead): > > --- ./tp/Texinfo/XS/XSParagraph.c~0 2022-02-12 00:01:48.000000000 +0200 > +++ ./tp/Texinfo/XS/XSParagraph.c 2022-10-22 10:52:27.900000000 +0300 > @@ -14,6 +14,12 @@ > #define PERL_NO_GET_CONTEXT > #include "EXTERN.h" > #include "perl.h" > +#if defined _WIN32 && !defined __CYGWIN__ > + #undef putenv > + #undef fdopen > + #undef mktemp > + #undef free > +#endif > #include "XSUB.h" > > #include "ppport.h" > > A similar block of #undef's is needed in api.c, for the same reason.
I've added these blocks of #undef's in commit 5c1874da10e984. I put them before including any of the Perl header files. I checked the bug-gnulib archives to see if anybody had asked about similar problems in the past, and found this message: https://lists.gnu.org/archive/html/bug-gnulib/2021-03/msg00003.html > From: Gavin Smith > Subject: How to avoid fdopen redefinition? > Date: Mon, 1 Mar 2021 15:29:26 +0000 I'd forgotten about this. Bruno Haible in that discussion recommended putting GNULIB_MDA_FDOPEN=0 in configure.ac, which we did. However, I found references to a string GL_GNULIB_MDA_FDOPEN: ./gnulib/lib/Makefile.am: -e 's/@''GNULIB_MDA_FDOPEN''@/$(GL_GNULIB_MDA_FDOPEN)/g' \ There appear to have been more changes to gnulib since that discussion that introduced the GL_ prefix to the variable, probably this: 2021-04-11 Bruno Haible <br...@clisp.org> Support several gnulib-tool invocations under the same configure.ac. Reported by Reuben Thomas <r...@sc3d.org> in <https://lists.gnu.org/archive/html/bug-gnulib/2021-04/msg00104.html>. This is done by defining the Gnulib module indicator variables per gnulib-tool invocation. So that a generated .h file is no longer influenced by the set of modules used in other gnulib-tool invocations. * gnulib-tool (func_compute_include_guard_prefix): Set module_indicator_prefix. ... So I expect we can deal with putenv and mktemp the same way. (I haven't investigated why Gnulib wants to redefine 'free'.) It could be worth asking on bug-gnulib again.
