Re: cygwin build fix for master, gawk-5.1-stable

[arnold]

Hi Tom,

Thanks. I'll remove the extraneous ifdefs.

Arnold

Tom Gray <tom_gray@keysight.com> wrote:

> Hi Arnold,
> My tests showed that only io.h is required in order to satisfy a declaration 
> for setmode().
>
> In gawkmisc.c:
>
> #ifdef __CYGWIN__
> //#include <stdio.h>
> //#include <windows.h>
> //#include <sys/cygwin.h>
> #include <io.h>
> #endif
>
> I made gcc more restrictive to be sure I didn't miss anything:
> gawk/awklib/Makefile:         CFLAGS = -g -O2 -DNDEBUG -Wall -Werror
> gawk/extension/Makefile:   CFLAGS = -g -O2 -Wall -Werror
> gawk/Makefile:                      CFLAGS = -g -O2 -DNDEBUG -Wall -Werror 
> -Wno-error=unused-function
> gawk/support/Makefile:       CFLAGS = -g -O2 -DNDEBUG -Wall -Werror
>
> make clean; make check;
> passes all tests
>
> Tom
>
> -----Original Message-----
> From: arnold@skeeve.com <arnold@skeeve.com> 
> Sent: Sunday, May 15, 2022 2:11 AM
> To: Tom Gray <tom_gray@keysight.com>; eliz@gnu.org; arnold@skeeve.com
> Cc: bug-gawk@gnu.org
> Subject: Re: cygwin build fix for master, gawk-5.1-stable
>
> Hi.
>
> >> The problem is the inclusion of windows.h for Cygwin builds.
>
> Those includes date from 2011. I suspect they aren't needed anymore.
> If you remove the include of <windows.h>, do things work OK?
>
> Corinna, can you comment please?
>
> Thanks,
>
> Arnold
>
> arnold@skeeve.com wrote:
>
> > Hi Tom.
> >
> > If you're using code with the BOOL flag that means you're building 
> > from master.  Technically speaking, you really should stick with the 
> > released versions until a new release comes out, unless you really 
> > need a particular bug fix.
> >
> > I am not going to have a lot of time for gawk in the next few days but 
> > will take a look at this eventually.
> >
> > Thanks for the report,
> >
> > Arnold
> >
> > Tom Gray <tom_gray@keysight.com> wrote:
> >
> > > Sorry, didn't mean to complicate things.
> > >
> > > I don't care about the Msys builds. I just used that to test my "hacks" 
> > > because I had it easily available.
> > >
> > > I latched on usage of BOOL in pc/popen.c but that is not problem.
> > >
> > > The problem is the inclusion of windows.h for Cygwin builds.
> > >
> > > The problem showed up when "BOOL" was introduced as a flag in the node 
> > > structure. Nov 2021 about?
> > >
> > > It is a gawk problem.
> > >
> > > Tom
> > >
> > > -----Original Message-----
> > > From: Eli Zaretskii <eliz@gnu.org>
> > > Sent: Friday, May 13, 2022 10:08 AM
> > > To: Tom Gray <tom_gray@keysight.com>
> > > Cc: bug-gawk@gnu.org
> > > Subject: Re: cygwin build fix for master, gawk-5.1-stable
> > >
> > > CAUTION: This message originates from an external sender.
> > >
> > > > From: Tom Gray <tom_gray@keysight.com>
> > > > CC: "bug-gawk@gnu.org" <bug-gawk@gnu.org>
> > > > Date: Fri, 13 May 2022 16:03:33 +0000
> > > >
> > > > Gcc on Cygwin and "Msys2 Msys" both define __CYGWIN__
> > >
> > > That is true, but a MinGW build of Gawk and an MSYS build of Gawk are two 
> > > different builds.  MSYS build is indeed very similar to Cygwin, but the 
> > > MSYS build, too, should not use the files in the pc/ subdirectory, AFAIK.
> > >
> > > > Gawk does not build out of the box with this shell and MSYS2 does not 
> > > > provide a pre-built package.
> > >
> > > You should take this up with the MSYS2 folks, they are the ones who 
> > > should care about the MSYS build of Gawk.
> > >
> > > > The "MSYS2 MinGW 64" shell looks likes this.
> > > >
> > > > $ uname -a
> > > > MINGW64_NT-10.0-19042 CND7252M5N 3.3.4-341.x86_64 2022-02-15 17:24 
> > > > UTC
> > > > x86_64 Msys $  gcc -dumpmachine
> > > > x86_64-w64-mingw32
> > > > $  echo |  gcc -dM -E - | grep MING #define __MINGW32__ 1 #define 
> > > > __MINGW64__ 1
> > >
> > > Yes, this build indeed uses pc/popen.c, but it isn't a Cygwin build.
> > >