Front page | perl.perl5.porters |
Postings from February 2020
Re: MinGW builds broken
Thread Previous
|
Thread Next
From:
Steve Hay via perl5-porters
Date:
February 19, 2020 08:13
Subject:
Re: MinGW builds broken
Message ID:
CADED=K7e6ZcBJR64XSuLGSqbuWgPvDWGSvD9GUi1ctfQeJoujA@mail.gmail.com
On Tue, 18 Feb 2020 at 01:10, sisyphus <sisyphus359@gmail.com> wrote:
> According to https://sourceforge.net/p/predef/wiki/Compilers mingw.org
> 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__
> # ifdef __MINGW64_VERSION_MAJOR
> /* It's mingw-w64 */
> # else
> /* It's mingw.org */
> # endif
> #else
> /* It's not mingw */
> #endif
>
> AIUI, the various "VERSION" macros for those mingw-w64 and mingw.org
> compilers all refer to the version of the mingw runtime.
> The mingw-w64 compilers now also provide a third VERSION number in
> __MINGW64_VERSION_RC.
> To determine the version of the gcc compiler, refer to __GNUC__,
> __GNUC_MINOR__ and __GNUC_PATCHLEVEL__ .
>
Thanks for the info. So we can differentiate between mingw.org and
mingw-w64, and we can tell what version of the mingw-w64 runtime we're
using, but we can't tell what version of the mingw.org runtime we're using?
Unless there is some other #define lurking somewhere that would help then
that just sounds like another reason to do as Tomasz Konojacki has
suggested, and only bother with the latest version of mingw.org, whatever
that might be.
>
> Is mingw.org still active ?
> I quit their mailing list a few years ago.
> I can't access the mingw.org website - but there's a lot of websites that
> I presently can't access via http.
> I can't access mingw.org via https, either.
>
Yes, it is still alive. They released a new gcc (9.2.0) last month.
>
> Cheers,
> Rob
>
> On Tue, Feb 18, 2020 at 5:03 AM Steve Hay via perl5-porters <
> perl5-porters@perl.org> wrote:
>
>> In testing a patch with a variety of builds today I've found that blead
>> currently doesn't build with my mingw.org 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
>> mingw.org 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 mingw.org compilers,
>> or have any views on dropping support for them?
>>
>
Thread Previous
|
Thread Next