Front page | perl.perl5.porters |
Postings from January 2018
On 25 January 2018 at 10:38, <sisyphus1@optusnet.com.au> wrote: > > > -----Original Message----- From: Karl Williamson > Sent: Thursday, January 25, 2018 12:46 PM > To: sisyphus1@optusnet.com.au ; perl5-porters@perl.org > Subject: Re: [win32] perl.h now defines INTMAX_C and UINTMAX_C > > On 01/22/2018 09:10 PM, sisyphus1@optusnet.com.au wrote: >>> >>> On Windows, as of 5.27.7, INTMAX_C and UINTMAX_C are being defined by >>> perl.h. >>> Both symbols are normally defined in stdint.h. > > ... >>> >>> Is this behaviour of perl.h wise/acceptable/desirable/allowable ? > > >> Line 692 of perl.h includes stdint.h if Configure has found defined the >> symbol I_STDINT. Maybe the windows config file should change to define >> that symbol. I see that it currently isn't. Maybe it should be done only >> for more recent releases? > > > Amending config_H.gc doesn't do the trick as the generated config.h still > fails to define I_STDINT. > (Actually, the config.h that gets written initially at the beginning of the > 'make' stage does define I_STDINT, but shortly into the build it gets > overwritten with a rendition that does *not* define I_STDINT. I think I've > seen somewhere that config.h gets written initially for miniperl, then > subsequently rewritten for perl.) > Have you tried amending config.gc too? I think that's what the real config.h used by perl is made from, if my cold-filled head remembers correctly.Thread Previous | Thread Next