Re: texinfo-6.8.90 pretest

[Gavin Smith]

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  <bruno@clisp.org>

        Support several gnulib-tool invocations under the same configure.ac.
        Reported by Reuben Thomas <rrt@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.