develooper Front page | perl.perl5.porters | Postings from August 2012

Re: MSWin32-x86-multi-thread-64int for perl-5.18 ?

Thread Previous
August 1, 2012 18:05
Re: MSWin32-x86-multi-thread-64int for perl-5.18 ?
Message ID:

----- Original Message ----- 
From: "Steve Hay" <>
To: "Steve Hay" <>; "Sisyphus" 
<>; "Steve Hay" <>
Cc: "bulk 88" <>; <>; "kmx" 
Sent: Thursday, August 02, 2012 3:23 AM
Subject: RE: MSWin32-x86-multi-thread-64int for perl-5.18 ?

> Steve Hay wrote on 2012-06-11:
>> Sisyphus wrote on 2012-06-10:
>>> All good so far - though I think I've used the same compiler as you.
>>> I didn't actually get very far with the test suite. The failing TODO
>>> tests in re/reg_eval_scope.t cause crashes, which results in the
>>> termination of the running of the test suite.
>> I don't get the whole test suite terminating -- just a pop-up for the
>> crashing test, which I dismiss and then the rest continues. The pop-up
>> can also be disabled, of course.
>>> A less important issue - in some discussion with kmx we noticed that,
>>> although config.gc defines d_longdbl, it sets d_longlong to undef. And
>>> in config_H.gc, HAS_LONG_DOUBLE is defined, but HAS_LONG_LONG is not.
>>> These are probably inconsequential, but we felt they should be fixed -
>>> if only for consistency, and to avoid confusion. (Unless, of course,
>>> there are good reasons to not do this.) I've built my
>>> MSWin32-x86-multi-thread-5.16.0 and
>>> MSWin32-x86-multi-thread-64int-5.16.0 with both d_longlong and
>>> HAS_LONG_LONG defined - just to see if it causes anything untoward to
>>> happen. (No problems yet that I'm aware of.)
>>> If it's agreed that these are appropriate changes, then now is
>>> probably a good time to make them.
>> Thanks for the spot. I've fixed this in e4a93c7214.
> Sorry it's taken so long, but I've finally got round to pushing changes 
> for enabling a USE_64_BIT_INT makefile option for Windows (commit 
> 1f64ae1564).
> As expected, the approach I've taken is to dynamically edit existing 
> config.h and templates rather than adding yet more canned 
> configurations. I began by editing the existing *.gc64 / *.vc64 files 
> since the 64-bit-int configurations don't differ much from them, and then 
> realized that actually the *.gc64 / *.vc64 files don't differ much from 
> the *.gc / *.vc files either, so I've actually deleted the four 64-bit 
> canned configurations too!
> We now only have one VC++ configuration ( / and one 
> GCC configuration (config.gc / config_H.gc) and 64-bit-int or 64-bit 
> variations are all based on them.
> The config_H.* files can't be edited by miniperl.exe since they are used 
> to build it, so the "editing" of them is done in the makefiles, by 
> appending some lines which first #undef any lines involved in 64-bit-ness 
> and then #define the appropriate values. Once we have miniperl.exe, the 
> config.* files are edited by config_sh.PL to create, from which 
> configpm creates, and config_h.PL creates the real 
> config.h (with which to build perl.exe) from config_h.SH (the config_H.* 
> files are not used for that).
> There is scope here for having just a single config_H.* / config.* pair 
> since the VC++ and GCC pairs don't different much either, but I've not 
> gone that far yet.
> Thanks for the original patch which started this all off, Rob :-)

And thank *you*, Steve, for picking it up and re-structuring it into its 
current form.
Btw, the original patch was really kmx's work .... so I can't even take any 
credit for that ;-)


Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About