Fix compilation with MinGW.org

[xenu]

Fixes #18510

[xenu]

Oops, it seems the Time::HiRes change broke Visual C++. I think it's fixed now.

[nwc10]

Thanks for figuring this stuff out.

If your assumption in #18510 is correct:

IMO it isn't a high-priority issue, it seems that almost no one is using MinGW.org these days. MinGW-w64 has completely replaced it.

and MinGW-w64 is still good, then given that this branch needs to touch code in two dual life modules, and source code outside of just Win32, then my initial thought is to merge this to blead after 5.34.0, but also to

1. get the dual life code upstream and rolled out to CPAN releases to get it more exposure
2. cherry-pick it to maint immediately and attempt to release it as part of a 5.34.1 relatively promptly.

[sisyphus]

I've got a mingw.org gcc-9.2.0 compiler that's throwing an error when building ext/POSIX:

c:/mingw_org/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: POSIX.o:POSIX.c:(.text+0x5d04):
 undefined reference to `isinf'
collect2.exe: erreur: ld a retournÚ 1 code d'Útat d'exÚcution
gmake[1]: *** [Makefile:472: ..\..\lib\auto\POSIX\POSIX.dll] Error 1
gmake[1]: Leaving directory 'C:/comp-xenu/perl-5.34.0/ext/POSIX'

It's a compiler I installed earlier this year using the mingw-get-setup.exe installer from:
https://sourceforge.net/projects/mingw/files/Installer/mingw-get-setup.exe/download

I don't know why that error should arise.
I'll try to get somewhere with it tomorrow.

Another issue is that I see the following warning being issued repeatedly:

c:\mingw_org\include\_mingw.h:413:3: attention : #warning "Direct definition of __USE_MINGW_ANSI_STDIO is deprecated." [-Wcpp]
  413 | # warning "Direct definition of __USE_MINGW_ANSI_STDIO is deprecated."
      |   ^~~~~~~
c:\mingw_org\include\_mingw.h:414:10: note: #pragma message: See <_mingw.h> for preferred feature activation methods.
  414 | # pragma message "See <_mingw.h> for preferred feature activation methods."

As regards __USE_MINGW_ANSI_STDIO, the referenced _mingw.h file tells us:

/* Users should not set this directly; rather, define one (or more)
 * of the feature test macros (tabulated below), or specify any of the
 * compiler's command line options, (e.g. -posix, -ansi, or -std=c...),
 * which cause _POSIX_SOURCE, or __STRICT_ANSI__ to be defined.
 */

Keith Marshall has been warning for years that __USE_MINGW_ANSI_STDIO should not be called directly, and that calling it directly is not guaranteed to work in the future.
It looks like he's preparing to deliver that "future".
The mingw-w64 developers have issued no such warnings - in fact they recommend explicitly defining __USE_MINGW_ANSI_STDIO if you want a more ANSI C99 implementation of printf() etc.

I just wonder whether it's worth all the trouble to keep supporting the mingw.org compilers, especially given that they're only 32-bit.

[jkeenan]

I've got a mingw.org gcc-9.2.0 compiler that's throwing an error when building ext/POSIX:

c:/mingw_org/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: POSIX.o:POSIX.c:(.text+0x5d04):
 undefined reference to `isinf'
collect2.exe: erreur: ld a retournÚ 1 code d'Útat d'exÚcution
gmake[1]: *** [Makefile:472: ..\..\lib\auto\POSIX\POSIX.dll] Error 1
gmake[1]: Leaving directory 'C:/comp-xenu/perl-5.34.0/ext/POSIX'

It's a compiler I installed earlier this year using the mingw-get-setup.exe installer from:
https://sourceforge.net/projects/mingw/files/Installer/mingw-get-setup.exe/download

I don't know why that error should arise.
I'll try to get somewhere with it tomorrow.

Another issue is that I see the following warning being issued repeatedly:

c:\mingw_org\include\_mingw.h:413:3: attention : #warning "Direct definition of __USE_MINGW_ANSI_STDIO is deprecated." [-Wcpp]
  413 | # warning "Direct definition of __USE_MINGW_ANSI_STDIO is deprecated."
      |   ^~~~~~~
c:\mingw_org\include\_mingw.h:414:10: note: #pragma message: See <_mingw.h> for preferred feature activation methods.
  414 | # pragma message "See <_mingw.h> for preferred feature activation methods."

As regards __USE_MINGW_ANSI_STDIO, the referenced _mingw.h file tells us:

/* Users should not set this directly; rather, define one (or more)
 * of the feature test macros (tabulated below), or specify any of the
 * compiler's command line options, (e.g. -posix, -ansi, or -std=c...),
 * which cause _POSIX_SOURCE, or __STRICT_ANSI__ to be defined.
 */

Keith Marshall has been warning for years that __USE_MINGW_ANSI_STDIO should not be called directly, and that calling it directly is not guaranteed to work in the future.
It looks like he's preparing to deliver that "future".
The mingw-w64 developers have issued no such warnings - in fact they recommend explicitly defining __USE_MINGW_ANSI_STDIO if you want a more ANSI C99 implementation of printf() etc.

I just wonder whether it's worth all the trouble to keep supporting the mingw.org compilers, especially given that they're only 32-bit.

@sisyphus, have you been able to further investigate the problems you described earlier in this p.r.?

Thank you very much.
Jim Keenan

[sisyphus]

I spent quite a bit of time on it and got nowhere.
However, I've just found that if I ensure that __USE_MINGW_ANSI_STDIO is not defined, then the xenu/mingw-org branch builds fine, and passes all tests - when the NVTYPE is double, at least.

Seems that __USE_MINGW_ANSI_STDIO is not merely "deprecated", but is already laden with booby traps - wrt the building of perl, anyway.

Thanks for following up !!

Cheers,
Rob

[khwilliamson]

What should we do with this PR?

[xenu]

The question is whether we want to support MinGW.org or not. IMO we shouldn't. I'm not aware of any valid reasons to prefer MinGW.org to MinGW-w64. MinGW.org isn't very popular, it's 32-bit only and its authors clearly go out of their way to break the compatibility with the rest of Windows compilers.

Nevertheless, two commits from this PR (a644daa and 9994e22) make sense even if we don't care about MinGW.org.

[jandubois]

I just got a CPAN testers report about this issue in Win32-0.58 (using Strawberry Perl 5.10.1): http://www.cpantesters.org/cpan/report/c13b1734-6e5c-1014-b256-9c16032c038b

I was thinking about just applying the Win32-specific part of this PR, but I noticed that the tester report also complains about RRF_RT_REG_DWORD which is not defined in this patch.

@xenu, any reason why this wasn't required for your scenario? Maybe because their gccversion='3.4.5' does not match your setup?

Anyways, do you plan to file a PR against Win32 for this, or should I do this myself?

[jkeenan]

Commenters, can we get an update on the status of this pull request (which has acquired merge conflicts)?

[jkeenan]

Commenters, can we get an update on the status of this pull request (which has acquired merge conflicts)?

This p.r. still has merge conflicts.

Last year @xenu commented, "The question is whether we want to support MinGW.org or not." IMO, that's a policy question that should be discussed on the P5P list. Assuming that we do have that discussion there, I would suggest to @xenu that if you want to follow up on the 2 commits you cited above, you open a new p.r. just for them.

Thank you very much.
Jim Keenan

[jkeenan]

Commenters, can we get an update on the status of this pull request (which has acquired merge conflicts)?

This p.r. still has merge conflicts.

Last year @xenu commented, "The question is whether we want to support MinGW.org or not." IMO, that's a policy question that should be discussed on the P5P list. Assuming that we do have that discussion there, I would suggest to @xenu that if you want to follow up on the 2 commits you cited above, you open a new p.r. just for them.

No further discussion since last September; closing.