Re: texinfo-6.7.90 pretest

[Eli Zaretskii]

> From: Gavin Smith <gavinsmith0123@gmail.com>
> Date: Sat, 27 Feb 2021 21:34:53 +0000
> Cc: bug-texinfo@gnu.org
> 
> >        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.

Most probably.

> 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

Yes.

> 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

liboldnames is a library used by MinGW64 (the other flavor of MinGW,
not the one I use) to redirect Posix functions like fdopen, read,
etc. to their MS-Windows equivalents _fdopen, _read, etc.

> 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.)

Maybe we should ask about this on the Gnulib mailing list?