bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Gray
Subject: RE: cygwin build fix for master, gawk-5.1-stable
Date: Fri, 13 May 2022 18:57:36 +0000

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]