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

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

Thread Previous | Thread Next
June 10, 2012 01:52
Re: MSWin32-x86-multi-thread-64int for perl-5.18 ?
Message ID:

----- Original Message ----- 
From: "Steve Hay" <>
To: "Sisyphus" <>
Cc: "Steve Hay" <>; "bulk 88" 
<>; <>
Sent: Sunday, June 10, 2012 3:17 AM
Subject: Re: MSWin32-x86-multi-thread-64int for perl-5.18 ?

> On 29 May 2012 02:54, Sisyphus <> wrote:
>> ----- Original Message ----- From: "Steve Hay" 
>> <>
>>> Sorry, I had meant to respond to this.
>>> I'm happy to see this functionality added, but I don't like the
>>> proliferation of "canned config" files that we're accumulating now
>>> because it makes it increasingly laborious to keep them all up to date.
>> I've nothing against the use of a better option.
>>> There is some facility in win32/config_sh.PL and win32/config_h.PL for
>>> editing the options in config files already and I would like to see this
>>> improved as necessary and made use of. I'm willing to look into this
>>> myself if you can wait a little while for these options?
>> There's no hurry - I think kmx is also going to take a look at what can 
>> be
>> done when he gets the time (which he doesn't have, right now).
>> Anything *you* (or anyone else) can come up with, would be greatly
>> appreciated.
>> We just need a way of setting the appropriate config.gc and config_H.gc
>> values for the following various build options:
>> 1) Those options currently provided by the existing canned config files;
>> 2) The -Duse64bitint option for 32-bit perls;
>> 3) The dbm, gdbm and ndbm options (that Strawberry Perl currently sets - 
>> by
>> patching config.gc and config_H.gc).
>> I guess we also want to be able to readily accommodate future 
>> developments
>> (eg someone might one day provide -Duselongdouble settings), and anything
>> else I've overlooked.
> I've started work on this with commit 7bef440cec, which does away with
> the *.gc64nox canned configs, and instead edits the *.gc64 canned
> configs based on the GCCCROSS setting in the
> Please take a look and confirm that I've not broken anything. I've
> just tested with the compiler taken from the "Win64 Downloads" link on
> (x86_64-w64-mingw32-gcc.exe, version
> 4.7.0) and it works for me, albeit with a couple of test failures
> which I also had before my changes. I think part of that is the
> xcopies near the end of are looking in the wrong place for
> DLLs to copy into t/, the DLLs in my case being in $(CCHOME)\lib
> rather than $(CCHOME)\bin. I will also look into that in due course,
> but now plan on addressing your 64-bit int config with a new macro in
> I might also remove the *.[gv]c64 files and dynamically apply changes
> to the *.[gv]c files instead, based on the WIN64 setting.

Btw, I've added kmx to the cc's. That may be unnecessary (ie he might 
already see these posts ... I don't know) - but since he's the one who 
stands to be most affected by these changes, I think we should ensure that 
he is kept informed. He might want to have some input, too.

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.

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.

I'm a bit pressed for time for the next few days, but beginning Thursday I'm 
free of all $Job commitments (for 8 weeks... whooot!!) so I should then be 
free to perform more rigorous testing.


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