Front page | perl.perl5.porters |
Postings from June 2012
Re: MSWin32-x86-multi-thread-64int for perl-5.18 ?
Thread Previous
|
Thread Next
From:
Sisyphus
Date:
June 10, 2012 01:52
Subject:
Re: MSWin32-x86-multi-thread-64int for perl-5.18 ?
Message ID:
E7A50B3F5E4F419DA83B7FA305BCD3D7@desktop2
----- Original Message -----
From: "Steve Hay" <steve.m.hay@googlemail.com>
To: "Sisyphus" <sisyphus1@optusnet.com.au>
Cc: "Steve Hay" <Steve.Hay@verosoftware.com>; "bulk 88"
<bulk88@hotmail.com>; <perl5-porters@perl.org>
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 <sisyphus1@optusnet.com.au> wrote:
>>
>> ----- Original Message ----- From: "Steve Hay"
>> <Steve.Hay@verosoftware.com>
>>
>>
>>>
>>> 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 makefile.mk
>
> 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
> http://mingw-w64.sourceforge.net/ (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 makefile.mk 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
> makefile.mk...
>
> 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.
Cheers,
Rob
Thread Previous
|
Thread Next