Re: texinfo-6.7.90 pretest

[Gavin Smith]

On Sat, Feb 27, 2021 at 12:11:05PM +0200, Eli Zaretskii wrote:
> Nothing is ever simple with MinGW builds...

Thanks for testing it anyway, it's very unlikely that the issues would
get fixed otherwise.


> 1. There are multiple compilation warnings due to Gnulib's redefining of
> fdopen.  Two typical examples:
> 
>      XSParagraph.c  -DDLL_EXPORT -DPIC -o .libs/XSParagraph.o
>      In file included from XSParagraph.xs:8:
>      D:/usr/Perl/lib/CORE/XSUB.h:524: warning: "fdopen" redefined
>        524 | #    define fdopen  PerlSIO_fdopen
>          |
>      In file included from D:/usr/Perl/lib/CORE/win32.h:160,
>                     from D:/usr/Perl/lib/CORE/win32thread.h:4,
>                     from D:/usr/Perl/lib/CORE/perl.h:2690,
>                     from XSParagraph.xs:7:
>      ./gnulib/lib/stdio.h:795: note: this is the location of the previous 
> definition
>        795 | #   define fdopen _fdopen
>          |
> 
>      In file included from xspara.c:40:
>      D:/usr/Perl/lib/CORE/XSUB.h:524: warning: "fdopen" redefined
>        524 | #    define fdopen  PerlSIO_fdopen
>          |
>      In file included from xspara.c:20:
>      ./gnulib/lib/stdio.h:795: note: this is the location of the previous 
> definition
>        795 | #   define fdopen _fdopen
>          |
> 
> (It's arguably a problem in the Perl headers, at least in the version
> I have here: they should have used #undef before redefining.)
> 
> The fix to avoid this is to #undef fdopen before including these Perl
> headers, but unfortunately we don't have any "catchall" header file in
> XS that is included in parsetexi sources before Perl headers.
> 
> A less elegant fix is to manually #undef fdopen in each and every
> source file that have this problem; I'd like to avoid this if
> possible.
> 
> Thoughts?

It's annoying that we have to deal with this, as we do not actually
use the fdopen function anywhere.  It looks like the stdio gnulib
module gets pulled in by others.

stdin.h is a generated file so exactly what is in it depends on the
results of configuration checks.  I'm guessing you are in the following
clause in stdin.h.in:

#elif @GNULIB_MDA_FDOPEN@
/* On native Windows, map 'fdopen' to '_fdopen', so that -loldnames is not
   required.  In C++ with GNULIB_NAMESPACE, avoid differences between
   platforms by defining GNULIB_NAMESPACE::fdopen always.  */
# if defined _WIN32 && !defined __CYGWIN__
#  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
#   undef fdopen
#   define fdopen _fdopen
#  endif
_GL_CXXALIAS_MDA (fdopen, FILE *, (int fd, const char *mode));
# else 
_GL_CXXALIAS_SYS (fdopen, FILE *, (int fd, const char *mode));
# endif
_GL_CXXALIASWARN (fdopen);
#endif

I don't know anything about -loldnames but this appears to have been
changed faily recently in Gnulib:

https://lists.gnu.org/archive/html/bug-gnulib/2020-12/msg00220.html

It talks there about a way of turning it off, so maybe we could
AC_SUBST a "GNULIB_MDA_FDOPEN" variable to disable it.  (I don't know
what MDA is though so am probably missing a big part of the picture
here.)