develooper Front page | perl.perl5.porters | Postings from February 2020

Re: MinGW builds broken

Thread Previous | Thread Next
February 18, 2020 01:10
Re: MinGW builds broken
Message ID:
According to
compilers define neither __MINGW64_VERSION_MAJOR nor
__MINGW64_VERSION_MINOR, whereas both 32-bit and 64-bit mingw-w64 compilers
define both.

So (untested):
#ifdef __MINGW32__
  /* It's mingw-w64 */
# else
  /* It's */
# endif
 /* It's not mingw */

AIUI, the various "VERSION" macros for those mingw-w64 and
compilers all refer to the version of the mingw runtime.
The mingw-w64 compilers now also provide a third VERSION number in
To determine the version of the gcc compiler, refer to __GNUC__,

Is still active ?
I quit their mailing list a few years ago.
I can't access the website - but there's a lot of websites that I
presently can't access via http.
I can't access via https, either.


On Tue, Feb 18, 2020 at 5:03 AM Steve Hay via perl5-porters <> wrote:

> In testing a patch with a variety of builds today I've found that blead
> currently doesn't build with my x86 compilers v3.4.5 or v4.8.1.
> They both fail in Time::HiRes because of struct timespec not being known.
> They need the same magic as daacfc6568, but I'm fuzzy on the details of
> how to identify a particular version of MinGW gcc and/or its various
> headers and runtime components.
> The MinGW-w64 version of gcc v4.5.3 that I have works fine, so the
> required test would need to be carefully tailored to pick out just old
> versions. Or else we could consider dropping support for them
> and say only the MinGW-w64 versions are now supported, especially since
> MinGW/gcc v5.3.0 and v6.3.0 (the latest one that I have) both have a
> different problem occurring earlier in the build regarding mkstemp being
> redefined.
> Does anyone know how to identify these problematic compilers,
> or have any views on dropping support for them?

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About