Mailing List Archive

MinGW builds broken
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?
Re: MinGW builds broken [ In reply to ]
On Mon, 17 Feb 2020 18:03:31 +0000
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.

mingw.org added the timespec struct to their headers in 2014[1].

>
> 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?

IMO supporting old mingw.org versions is a waste of time.

mingw.org was almost completely replaced by mingw-w64 more than 10 years
ago. Almost no one is using it these days.

Also, upgrading a compiler is a very easy task on Windows, much easier
than on the other platforms because it isn't integrated with the OS. I
suppose that's the reason why mingw.org doesn't even provide downloads
for non-latest versions of their environment.

Nevertheless, if the build is broken on the *latest* version of
mingw.org, I think we should fix it.

[1] - https://osdn.net/projects/mingw/scm/git/mingw-org-wsl/commits/b83d2b297de77aece4b2b37855c69be2431f060b
Re: MinGW builds broken [ In reply to ]
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__ .

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.

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?
>
Re: MinGW builds broken [ In reply to ]
On Tue, 18 Feb 2020 at 00:50, Tomasz Konojacki <me@xenu.pl> wrote:

> On Mon, 17 Feb 2020 18:03:31 +0000
> 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.
>
> mingw.org added the timespec struct to their headers in 2014[1].
>
> >
> > 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?
>
> IMO supporting old mingw.org versions is a waste of time.
>
> mingw.org was almost completely replaced by mingw-w64 more than 10 years
> ago. Almost no one is using it these days.
>
> Also, upgrading a compiler is a very easy task on Windows, much easier
> than on the other platforms because it isn't integrated with the OS. I
> suppose that's the reason why mingw.org doesn't even provide downloads
> for non-latest versions of their environment.
>
> Nevertheless, if the build is broken on the *latest* version of
> mingw.org, I think we should fix it.
>
>
Thanks. I think I agree. It would be nice if older versions worked too, but
I struggle to justify any time working on it if it doesn't just work unless
anyone comes up with some reason why they have to use mingw.org and can't
use the latest one.

I am trying out 9.2.0, and will probably just end up updating readmes etc
as appropriate if that is working.
Re: MinGW builds broken [ In reply to ]
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?
>>
>
Re: MinGW builds broken [ In reply to ]
On Wed, Feb 19, 2020 at 7:13 PM Steve Hay <steve.m.hay@googlemail.com>
wrote:

> ...but we can't tell what version of the mingw.org runtime we're using?

For that, you look at __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION
(which both mingw-w64 and mingw.org define.

I expected that, with a mingw-w64 compiler, __MINGW64_VERSION_MAJOR and
__MINGW32_MAJOR_VERSION would report the same value - and same, too, for
__MINGW64_VERSION_MINOR and __MINGW32_MINOR_VERSION.
But that's not the case.
On my mingw-w64 gcc-8.1.0, I compiled this script:

#include <stdio.h>
int main(void){
printf("%d %d %d\n", __MINGW64_VERSION_MAJOR, __MINGW64_VERSION_MINOR,
__MINGW64_VERSION_RC);
printf("%d %d\n", __MINGW32_MAJOR_VERSION, __MINGW32_MINOR_VERSION);
return 0;
}

That outputs:

6 0 0
3 11

So, I gather mingw-w64 and mingw,org use different numbering systems for
the same runtime ??

> They released a new gcc (9.2.0) last month

This is where mingw-w64 could bring themselves undone.
They haven't provided a release since 8.1.0, and steadfastly refuse
requests to release anything more recent.
Instead they point people to the build scripts - which, I think, is a risky
business plan to be pursuing.
Now, maybe they'll get away with that but I certainly don't want to be
messing around with building gcc from source.
Luckily, Strawberry Perl build and provide a new compiler every year when
the next stable perl is released - so, these days, I just end up using the
compiler that they're providing.

I might give this mingw.org version of gcc-9.2.0 a try.

Cheers,
Rob
Re: MinGW builds broken [ In reply to ]
On Wed, 19 Feb 2020 at 10:49, sisyphus <sisyphus359@gmail.com> wrote:

>
> I might give this mingw.org version of gcc-9.2.0 a try.
>
>
Did you get round to trying this? I've never had so much trouble trying to
get a mingw.org version of gcc running. I've downloaded more packages than
I usually get in order to build perl, but still it won't run. On the first
C file that it attempts to compile it gives me a popup error from cc1.exe
saying, "The application was unable to start correctly (0xc0000022). Click
OK to close the application."

My guess is that some DLL is missing, but depends.exe tells me nothing and
I don't know what other packages could be relevant. Here's the list of what
I've got so far...:

binutils-2.32-1-mingw32-bin.tar.xz
gcc-c++-9.2.0-1-mingw32-20200111-1-bin.tar.xz
gcc-core-9.2.0-1-mingw32-20200111-1-bin.tar.xz
gettext-0.18.3.2-2-mingw32-bin.tar.xz
libatomic-9.2.0-1-mingw32-20200111-1-dll-1.tar.xz
libgcc-9.2.0-1-mingw32-20200111-1-dll-1.tar.xz
libgmp-6.1.2-3-mingw32-dll-10.tar.xz
libgnat-9.2.0-1-mingw32-20200111-1-dll-9.tar.xz
libgomp-9.2.0-1-mingw32-20200111-1-dll-1.tar.xz
libiberty-2.32-1-mingw32-dev.tar.xz
libiconv-1.14-4-mingw32-dll-2.tar.xz
libisl-0.21-1-mingw32-dll-15.tar.xz
libmingwex-5.2.3-mingw32-dev.tar.xz
libmpc-1.1.0-1-mingw32-dll-3.tar.xz
libmpfr-4.0.2-1-mingw32-dll-6.tar.xz
libquadmath-9.2.0-1-mingw32-20200111-1-dll-0.tar.xz
libssp-9.2.0-1-mingw32-20200111-1-dll-0.tar.xz
libstdc++-9.2.0-1-mingw32-20200111-1-dll-6.tar.xz
libz-1.2.11-1-mingw32-dll-1.tar.xz
mingwrt-5.2.3-mingw32-dev.tar.xz
pthreads-GC-w32-2.10-mingw32-pre-20160821-1-dll-3.tar.xz
w32api-5.2.3-mingw32-dev.tar.xz
Re: MinGW builds broken [ In reply to ]
Hi Steve,
I can't even find this gcc-9.2.0.

I've downloaded the mingw-wget installer, but it's only offering me 8.2.0.
Where do I find this gcc-9.2.0 ?

Google throws up the following as possible causes of the 0xc0000022 error
1) files that are corrupted or have accessibility issues.
2) interference with security software

Cheers,
Rob

On Fri, Feb 28, 2020 at 7:13 PM Steve Hay <steve.m.hay@googlemail.com>
wrote:

> On Wed, 19 Feb 2020 at 10:49, sisyphus <sisyphus359@gmail.com> wrote:
>
>>
>> I might give this mingw.org version of gcc-9.2.0 a try.
>>
>>
> Did you get round to trying this? I've never had so much trouble trying to
> get a mingw.org version of gcc running. I've downloaded more packages
> than I usually get in order to build perl, but still it won't run. On the
> first C file that it attempts to compile it gives me a popup error from
> cc1.exe saying, "The application was unable to start correctly
> (0xc0000022). Click OK to close the application."
>
> My guess is that some DLL is missing, but depends.exe tells me nothing and
> I don't know what other packages could be relevant. Here's the list of what
> I've got so far...:
>
> binutils-2.32-1-mingw32-bin.tar.xz
> gcc-c++-9.2.0-1-mingw32-20200111-1-bin.tar.xz
> gcc-core-9.2.0-1-mingw32-20200111-1-bin.tar.xz
> gettext-0.18.3.2-2-mingw32-bin.tar.xz
> libatomic-9.2.0-1-mingw32-20200111-1-dll-1.tar.xz
> libgcc-9.2.0-1-mingw32-20200111-1-dll-1.tar.xz
> libgmp-6.1.2-3-mingw32-dll-10.tar.xz
> libgnat-9.2.0-1-mingw32-20200111-1-dll-9.tar.xz
> libgomp-9.2.0-1-mingw32-20200111-1-dll-1.tar.xz
> libiberty-2.32-1-mingw32-dev.tar.xz
> libiconv-1.14-4-mingw32-dll-2.tar.xz
> libisl-0.21-1-mingw32-dll-15.tar.xz
> libmingwex-5.2.3-mingw32-dev.tar.xz
> libmpc-1.1.0-1-mingw32-dll-3.tar.xz
> libmpfr-4.0.2-1-mingw32-dll-6.tar.xz
> libquadmath-9.2.0-1-mingw32-20200111-1-dll-0.tar.xz
> libssp-9.2.0-1-mingw32-20200111-1-dll-0.tar.xz
> libstdc++-9.2.0-1-mingw32-20200111-1-dll-6.tar.xz
> libz-1.2.11-1-mingw32-dll-1.tar.xz
> mingwrt-5.2.3-mingw32-dev.tar.xz
> pthreads-GC-w32-2.10-mingw32-pre-20160821-1-dll-3.tar.xz
> w32api-5.2.3-mingw32-dev.tar.xz
>
Re: MinGW builds broken [ In reply to ]
On Fri, 28 Feb 2020 at 22:39, sisyphus <sisyphus359@gmail.com> wrote:

> Hi Steve,
> I can't even find this gcc-9.2.0.
>
> I've downloaded the mingw-wget installer, but it's only offering me 8.2.0.
> Where do I find this gcc-9.2.0 ?
>

Manual downloads of the latest of everything from
https://osdn.net/projects/mingw/releases/



>
> Google throws up the following as possible causes of the 0xc0000022 error
> 1) files that are corrupted or have accessibility issues.
> 2) interference with security software
>
>
>>
I hadn't considered security software. I have found that the simple "hello
world" program compiled with gcc-8 from mingw.org is detected as a threat
by Sophos and gets deleted. Maybe it's being even more aggressive with
gcc-9 and won't let it run to start with?!

I will try this on a different machine with different a/v s/w.
Re: MinGW builds broken [ In reply to ]
On Mon, 17 Feb 2020 at 18:03, Steve Hay <steve.m.hay@googlemail.com> 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?

I've just fixed the Time::HiRes build problem for my mingw.org
compilers 3.4.5-4.8.1 (using mingw runtimes < 5.0) in commit
43b3b04375.

I will look at the mkstemp() build problem for later mingw.org
compilers (using mingw runtimes >= 5.0) soon.