Win32: Define __USE_MINGW_ANSI_STDIO for all gcc builds

[p5pRT]

Migrated from rt.perl.org#130447 (status was 'resolved')

Searchable as RT130447$

[p5pRT]

From @sisyphus

Hi,

Currently the win32/makefile.mk and win32/GNUmakefile that ship with the
perl source contain instructions that conditionally define
__USE_MINGW_ANSI_STDIO.

In win32/makefile.mk​:

.IF "$(USE_LONG_DOUBLE)" == "define"
BUILDOPT += -D__USE_MINGW_ANSI_STDIO
MINIBUILDOPT += -D__USE_MINGW_ANSI_STDIO
.ENDIF

In win32/GNUmakefile​:

ifeq ($(USE_LONG_DOUBLE),define)
BUILDOPT += -D__USE_MINGW_ANSI_STDIO
MINIBUILDOPT += -D__USE_MINGW_ANSI_STDIO
endif

It would be better if the condition was changed so that the symbol is
defined whenever $(CCTYPE) is GCC.

Looks to me that the above sections are already inside a "$(CCTYPE) is GCC"
block, so it's just a matter of removing the .IF and .ENDIF (or ifeq and
endif) lines from the respective makefiles.

This removes laughable behaviour from "nvtype is double" mingw builds of
perl on Windows.

For example, a usual "nvtype is double" mingw build of perl-5.25.7
(__USE_MINGW_ANSI_STDIO *not* defined) produces

C​:\>perl -MPOSIX="DBL_MAX" -le "printf '%f', DBL_MAX;"
17976931348623157000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000.000000
C​:\>perl -V​:nvtype
nvtype='double';

But if the same perl source is built *with* __USE_MINGW_ANSI_STDIO (achieved
by having modified the GNUmakefile as per above) then the output changes to
the correct​:

C​:\>perl -MPOSIX="DBL_MAX" -le "printf '%f', DBL_MAX;"
17976931348623157081452742373170435679807056752584499659891747680315726078002853
87605895586327668781715404589535143824642343213268894641827684675467035375169860
49910576551282076245490090389328944075868508455133942304583236903222948165808559
332123348274797826204144723168738177180919299881250404026184124858368.000000
C​:\>perl -V​:nvtype
nvtype='double';

I've just built and installed both 32-bit and 64-bit versions of
perl-5.25.8, nvtype='double', using the modified win32/GNUmakefile so that
__USE_MINGW_ANSI_STDIO is defined. The 32-bit test report is​:

Test Summary Report

---

porting/pod_rules.t (Wstat​: 0
Tests​: 8 Failed​: 1)
  Failed test​: 3
../ext/IPC-Open3/t/IPC-Open3.t (Wstat​: 0
Tests​: 45 Failed​: 0)
  TODO passed​: 25
Files=2541, Tests=1029438, 1295 wallclock secs (53.21 usr + 2.53 sys =
55.74 CPU)
Result​: FAIL
GNUmakefile​:1755​: recipe for target 'test' failed
make​: *** [test] Error 1

This is no different to the report obtained when I built 5.25.7 *without*
defining __USE_MINGW_ANSI_STDIO.

I can't run the entire test suite for the 5.25.8 x64, nvtype='double' build
because it hangs at​:

../cpan/IO-Compress/t/100generic-deflate.t ......................... 1/794

(This happens irrespective of whether __USE_MINGW_ANSI_STDIO is defined.)

Cheers,
Rob

[p5pRT]

From @sisyphus

Hi,

No sign of any change regarding this in perl-5.25.9.

If this is "too late in the day" to be considered for perl-5.26.0, could we
at least provide a configurable option in the win32/GNUmakefile and
win32/makefile.mk that facilitates defining -D__USE_MINGW_ANSI_STDIO for
"double" builds of mingw-built perl ? (This might encourage others to test
that configuration prior to 5.28 - especially if we also include in the test
suite a test that produces the absurd result and classifies it as a
failure.)

-D__USE_MINGW_ANSI_STDIO affects runtime behaviour only. AFAIK there should
be no binary incompatibility between builds that define the symbol, and
builds that don't - and tests that I have run indicate that this is so.

Cheers,
Rob

-----Original Message-----
From​: sisyphus1@​optusnet.com.au
Sent​: Friday, December 30, 2016 11​:03 AM
To​: perlbug@​perl.org
Subject​: Win32​: Define __USE_MINGW_ANSI_STDIO for all gcc builds

Hi,

Currently the win32/makefile.mk and win32/GNUmakefile that ship with the
perl source contain instructions that conditionally define
__USE_MINGW_ANSI_STDIO.

In win32/makefile.mk​:

.IF "$(USE_LONG_DOUBLE)" == "define"
BUILDOPT += -D__USE_MINGW_ANSI_STDIO
MINIBUILDOPT += -D__USE_MINGW_ANSI_STDIO
.ENDIF

In win32/GNUmakefile​:

ifeq ($(USE_LONG_DOUBLE),define)
BUILDOPT += -D__USE_MINGW_ANSI_STDIO
MINIBUILDOPT += -D__USE_MINGW_ANSI_STDIO
endif

It would be better if the condition was changed so that the symbol is
defined whenever $(CCTYPE) is GCC.

Looks to me that the above sections are already inside a "$(CCTYPE) is
GCC" block, so it's just a matter of removing the .IF and .ENDIF (or ifeq
and endif) lines from the respective makefiles.

This removes laughable behaviour from "nvtype is double" mingw builds of
perl on Windows.

For example, a usual "nvtype is double" mingw build of perl-5.25.7
(__USE_MINGW_ANSI_STDIO *not* defined) produces

C​:\>perl -MPOSIX="DBL_MAX" -le "printf '%f', DBL_MAX;"
179769313486231570000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.000000
C​:\>perl -V​:nvtype
nvtype='double';

But if the same perl source is built *with* __USE_MINGW_ANSI_STDIO
(achieved by having modified the GNUmakefile as per above) then the output
changes to the correct​:

C​:\>perl -MPOSIX="DBL_MAX" -le "printf '%f', DBL_MAX;"
179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000
C​:\>perl -V​:nvtype
nvtype='double';

I've just built and installed both 32-bit and 64-bit versions of
perl-5.25.8, nvtype='double', using the modified win32/GNUmakefile so that
__USE_MINGW_ANSI_STDIO is defined. The 32-bit test report is​:
...

[p5pRT]

@jkeenan - Status changed from 'new' to 'open'

[p5pRT]

From @sisyphus

Is there any interest in getting anything done about this for 5.26.0 ?
Or do we need to wait for 5.28.0 ?

(Severity of this ticket is currently set to "low". I would change that to "normal" if I could work out how to do that.)

Cheers,
Rob

[p5pRT]

From @steve-m-hay

On Tue, 14 Feb 2017 04​:07​:49 -0800, sisyphus wrote​:

Is there any interest in getting anything done about this for 5.26.0 ?
Or do we need to wait for 5.28.0 ?

(Severity of this ticket is currently set to "low". I would change
that to "normal" if I could work out how to do that.)

Cheers,
Rob

Sounds like it would be sensible to me from the evidence you've posted, but I don't really know anything about this option.

Andy/Jan/kmx​: Any opinions from the maintainers of the two most popular builds of perl on Windows (both gcc-based)?

[p5pRT]

From @kmx

On 16.02.2017 9​:27, Steve Hay via RT wrote​:

On Tue, 14 Feb 2017 04​:07​:49 -0800, sisyphus wrote​:

Is there any interest in getting anything done about this for 5.26.0 ?
Or do we need to wait for 5.28.0 ?

(Severity of this ticket is currently set to "low". I would change
that to "normal" if I could work out how to do that.)

Cheers,
Rob
Sounds like it would be sensible to me from the evidence you've posted, but I don't really know anything about this option.

Andy/Jan/kmx​: Any opinions from the maintainers of the two most popular builds of perl on Windows (both gcc-based)?

Sending for the third time, I have no idea what is blocking my messages
sent to p5p mailing list

On 16.02.2017 9​:32, kmx wrote​:

I have already replied, but the message did not reach the mailing list​:

According to my experiences with "long-double" build of strawberry perl
enabling __USE_MINGW_ANSI_STDIO works nice with only one exception
DBD​::Pg which fails to compile.

--
kmx

[p5pRT]

From @steve-m-hay

On 16 February 2017 at 21​:03, kmx <kmx@​atlas.cz> wrote​:

On 16.02.2017 9​:27, Steve Hay via RT wrote​:

On Tue, 14 Feb 2017 04​:07​:49 -0800, sisyphus wrote​:

Is there any interest in getting anything done about this for 5.26.0 ?
Or do we need to wait for 5.28.0 ?

(Severity of this ticket is currently set to "low". I would change
that to "normal" if I could work out how to do that.)

Cheers,
Rob

Sounds like it would be sensible to me from the evidence you've posted,
but I don't really know anything about this option.

Andy/Jan/kmx​: Any opinions from the maintainers of the two most popular
builds of perl on Windows (both gcc-based)?

Sending for the third time, I have no idea what is blocking my messages sent
to p5p mailing list

On 16.02.2017 9​:32, kmx wrote​:

I have already replied, but the message did not reach the mailing list​:

According to my experiences with "long-double" build of strawberry perl
enabling __USE_MINGW_ANSI_STDIO works nice with only one exception DBD​::Pg
which fails to compile.

Third time lucky :-)

Do we have any idea what the DBD​::Pg problem is? Is it something that
module is doing wrongly, or does it indicate some more general problem
with enabling this build option? (I wouldn't want to enable an option
that is going to cause trouble for "double" builds, which we're
potentially just unaware of so far because it's currently only used
for "long double" builds (which, presumably, fewer people use?).)

[p5pRT]

From @sisyphus

-----Original Message-----
From​: Steve Hay via perl5-porters
Sent​: Friday, February 17, 2017 7​:10 PM
To​: kmx
Cc​: perlbug-followup@​perl.org ; perl5-porters@​perl.org ; Andy Grundman ; Jan
Dubois
Subject​: Re​: [perl #130447] Win32​: Define __USE_MINGW_ANSI_STDIO for all gcc
builds

On 16.02.2017 9​:32, kmx wrote​:

I have already replied, but the message did not reach the mailing list​:

According to my experiences with "long-double" build of strawberry perl
enabling __USE_MINGW_ANSI_STDIO works nice with only one exception
DBD​::Pg
which fails to compile.

Third time lucky :-)

Do we have any idea what the DBD​::Pg problem is? Is it something that
module is doing wrongly, or does it indicate some more general problem
with enabling this build option?

Good question - I too am wondering if there's any evidence to indicate that
this problem with DBD​::Pg arises because __USE_MINGW_ANSI_STDIO has been
defined.
I suspect it's probably rather hard to build a useful nvtype='long double'
build without defining __USE_MINGW_ANSI_STDIO.

Another test would be to build an nvtype='double' build of perl with
__USE_MINGW_ANSI_STDIO defined - and then see if DBD​::Pg builds successfully
against that perl.
I have such a perl, but I don't have the extra stuff (eg postgresql) that I
presume is needed.
Are all extra prerequisites readily available ?

Looking a bit further, I've found that my older 32-bit perls (ie up to and
including 5.18.0) that I built using mingw.org's port of gcc-4.7.0 don't
require that __USE_MINGW_ANSI_STDIO be defined.
They get it right even though __USE_MINGW_ANSI_STDIO is *not* defined.
Not sure how that impacts on my request. Could it be that I'm simply
requesting a workaround to a mingw-w64 bug ?

Cheers,
Rob

[p5pRT]

From @kmx

On 20.02.2017 11​:57, sisyphus1@​optusnet.com.au wrote​:

-----Original Message----- From​: Steve Hay via perl5-porters
Sent​: Friday, February 17, 2017 7​:10 PM
To​: kmx
Cc​: perlbug-followup@​perl.org ; perl5-porters@​perl.org ; Andy Grundman ;
Jan Dubois
Subject​: Re​: [perl #130447] Win32​: Define __USE_MINGW_ANSI_STDIO for all
gcc builds

On 16.02.2017 9​:32, kmx wrote​:

I have already replied, but the message did not reach the mailing list​:

According to my experiences with "long-double" build of strawberry perl
enabling __USE_MINGW_ANSI_STDIO works nice with only one exception
DBD​::Pg
which fails to compile.

Third time lucky :-)

Do we have any idea what the DBD​::Pg problem is? Is it something that
module is doing wrongly, or does it indicate some more general problem
with enabling this build option?

Good question - I too am wondering if there's any evidence to indicate
that this problem with DBD​::Pg arises because __USE_MINGW_ANSI_STDIO has
been defined.
I suspect it's probably rather hard to build a useful nvtype='long
double' build without defining __USE_MINGW_ANSI_STDIO.

Another test would be to build an nvtype='double' build of perl with
__USE_MINGW_ANSI_STDIO defined - and then see if DBD​::Pg builds
successfully against that perl.

It is not a problem of "long double".

If you take any "standard" strawberry perl + manual edit Config_heavy.pl
(add -D__USE_MINGW_ANSI_STDIO to ccflags) you can reproduce the failure by
simply running​: cpanm DBD​::Pg -v -f

On my laptop it fails like this​:
dbdimp.c​:5332​:1​: internal compiler error​: in symtab_nonoverwritable_alias,
at symtab.c​:1252
(gcc 4.9.2 bug? mingw-w64-4.0.2 bug? buggy build of libpq-9.5.2?)

For sure it is not a bug in perl core. However, before turning
__USE_MINGW_ANSI_STDIO on by default we should analyse what's going on with
DBD​::Pg.

I want to avoid excluding DBD​::Pg from strawberry perl 5.26.x series due to
__USE_MINGW_ANSI_STDIO incompatibility.

--
kmx

[p5pRT]

From @xenu

On Mon, 20 Feb 2017, at 20​:00, kmx wrote​:

On my laptop it fails like this​:
dbdimp.c​:5332​:1​: internal compiler error​: in
symtab_nonoverwritable_alias,
at symtab.c​:1252
(gcc 4.9.2 bug? mingw-w64-4.0.2 bug? buggy build of libpq-9.5.2?)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61916

[p5pRT]

From @xenu

On Mon, 20 Feb 2017, at 20​:15, me@​xenu.pl wrote​:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61916

Also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212

[p5pRT]

From @kmx

However, before turning __USE_MINGW_ANSI_STDIO on by default we should
analyse what's going on with DBD​::Pg.

According to my research the trouble maker is the following part of Pg.h

#ifndef snprintf
#define snprintf _snprintf
#endif

after removing
#define snprintf _snprintf
DBD-Pg-3.5.3 builds fine with -D__USE_MINGW_ANSI_STDIO

--
kmx

[p5pRT]

From @sisyphus

Hi,

Something else to perhaps consider​:

In a recent (29th May) post to gmpbugs (gmp-bugs@​gmplib.org) Keith Marshall
had this to say about the use of -D__USE_MINGW_ANSI_STDIO​:

[--quote--]

I would also point out that, as a "__USE_*" feature test, users should *not*
define "__USE_MINGW_ANSI_STDIO" themselves; the correct way to enable it is
to enable any of the "__STRICT_ANSI__" standards options, or to stipulate
"_GNU_SOURCE", "_POSIX_C_SOURCE", or "_XOPEN_SOURCE" feature dependencies,
(the latter two with an associated version stipulation), any of which will
cause the MinGW runtime headers to enable "__USE_MINGW_ANSI_STDIO"
implicitly. You may get away with an explicit definition today, but I will
offer no guarantee that a future MinGW Runtime release will not override any
such definition, just as GNU's glibc headers do for their "__USE_*" feature
tests.

[--end quote--]

In view of those comments and as regards perl, should we therefore be
considering doing away with our explicit use of "-D__USE_MINGW_ANSI_STDIO",
opting instead for (say) the "-posix" switch ?

Keith is a (the ?) lead developer at mingw.org.

Cheers,
Rob

[p5pRT]

From @sisyphus

-----Original Message-----
From​: sisyphus1@​optusnet.com.au
Sent​: Wednesday, May 31, 2017 9​:21 PM
To​: Steve Hay ; kmx
Cc​: perlbug-followup@​perl.org ; perl5-porters@​perl.org ; Andy Grundman ; Jan
Dubois
Subject​: Re​: [perl #130447] Win32​: Define __USE_MINGW_ANSI_STDIO for all gcc
builds

Since nothing has happened with this, AFAICT, I thought I'd send a patch
(attached) against the win32/GNUmakefile that shipped with perl-5.27.5.

It merely gives one the *option* of building with -D__USE_MINGW_ANSI_STDIO
when building with nvtype=double.
With the patch applied, the default for such builds is still to build
*without* defining __USE_MINGW_ANSI_STDIO - as has always been the default
for the "nvtype=double" builds.

For "nvtype=long double" builds (as has always been the
case) -D__USE_MINGW_ANSI_STDIO is inevitably defined .... unless, of
course, one hacks the contents of the GNUmakefile.
I don't see any value in building "nvtype=long double" builds without
defining __USE_MINGW_ANSI_STDIO, and see no need to provide such an option.

I hope that someone can apply this patch.
I've tested it and it works as intended.

If it's deemed more appropriate that -D__USE_MINGW_ANSI_STDIO should be the
*default* for "nvtype=double" builds, then I'd be quite happy with that
change, too.

Cheers,
Rob

[p5pRT]

From @sisyphus

GNUmakefile.diff

[p5pRT]

From @steve-m-hay

On Thu, 26 Oct 2017 22​:59​:56 -0700, sisyphus wrote​:

-----Original Message-----
From​: sisyphus1@​optusnet.com.au
Sent​: Wednesday, May 31, 2017 9​:21 PM
To​: Steve Hay ; kmx
Cc​: perlbug-followup@​perl.org ; perl5-porters@​perl.org ; Andy Grundman
; Jan
Dubois
Subject​: Re​: [perl #130447] Win32​: Define __USE_MINGW_ANSI_STDIO for
all gcc
builds

Since nothing has happened with this, AFAICT, I thought I'd send a
patch
(attached) against the win32/GNUmakefile that shipped with perl-
5.27.5.

It merely gives one the *option* of building with
-D__USE_MINGW_ANSI_STDIO
when building with nvtype=double.
With the patch applied, the default for such builds is still to build
*without* defining __USE_MINGW_ANSI_STDIO - as has always been the
default
for the "nvtype=double" builds.

For "nvtype=long double" builds (as has always been the
case) -D__USE_MINGW_ANSI_STDIO is inevitably defined .... unless, of
course, one hacks the contents of the GNUmakefile.
I don't see any value in building "nvtype=long double" builds without
defining __USE_MINGW_ANSI_STDIO, and see no need to provide such an
option.

I hope that someone can apply this patch.
I've tested it and it works as intended.

Thanks for the patch, and apologies for the delay in getting around to looking at it.

I've just applied a slightly modified version in commit f019f33. Please could you confirm that I've not broken it in the course of changing it slightly? If all is well then this ticket can be closed.

[p5pRT]

From @sisyphus

-----Original Message-----
From​: Steve Hay via RT
Sent​: Thursday, November 16, 2017 5​:22 AM
To​: sisyphus1@​optusnet.com.au

I hope that someone can apply this patch.
I've tested it and it works as intended.

Thanks for the patch, and apologies for the delay in getting around to
looking at it.

I've just applied a slightly modified version in commit f019f33. Please
could you confirm that I've not broken it in the course of changing it
slightly? If all is well then this ticket can be closed.

Yep - this is doing the right thing. Thanks for attending to it.

Am *I* supposed to be able to close this ticket ? I logged in to
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=130447 using my bitcard account,
but I couldn't spot any option that would enable me to close it.

Cheers,
Rob

[p5pRT]

From @xsawyerx

On Thu, 16 Nov 2017 04​:29​:02 -0800, sisyphus wrote​:

-----Original Message-----
From​: Steve Hay via RT
Sent​: Thursday, November 16, 2017 5​:22 AM
To​: sisyphus1@​optusnet.com.au

I hope that someone can apply this patch.
I've tested it and it works as intended.

Thanks for the patch, and apologies for the delay in getting around
to
looking at it.

I've just applied a slightly modified version in commit f019f33.
Please
could you confirm that I've not broken it in the course of changing
it
slightly? If all is well then this ticket can be closed.

Yep - this is doing the right thing. Thanks for attending to it.

Am *I* supposed to be able to close this ticket ? I logged in to
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=130447 using my bitcard
account,
but I couldn't spot any option that would enable me to close it.

Done!

[p5pRT]

@xsawyerx - Status changed from 'open' to 'pending release'

[p5pRT]

From @cpansprout

On Thu, 16 Nov 2017 04​:29​:02 -0800, sisyphus wrote​:

Am *I* supposed to be able to close this ticket ? I logged in to
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=130447 using my bitcard
account,
but I couldn't spot any option that would enable me to close it.

’Fraid it’s admins only.

--

Father Chrysostomos

[p5pRT]

From @steve-m-hay

On 16 November 2017 at 21​:05, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

On Thu, 16 Nov 2017 04​:29​:02 -0800, sisyphus wrote​:

Am *I* supposed to be able to close this ticket ? I logged in to
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=130447 using my bitcard
account,
but I couldn't spot any option that would enable me to close it.

’Fraid it’s admins only.

I was surpried that the OP couldn't close his own ticket. I thought
that was possible, and it's just closing other people's tickets that
is restricted to admins?

[p5pRT]

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release yesterday of Perl 5.28.0, this and 185 other issues have been
resolved.

Perl 5.28.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.28.0

If you find that the problem persists, feel free to reopen this ticket.

[p5pRT]

@khwilliamson - Status changed from 'pending release' to 'resolved'