Front page | perl.perl5.porters |
Postings from July 2010
On Tue, 29 Jun 2010, Steve Hay wrote:
> It started by emitting a mountain of warnings about type conversions
> for every file that it compiles. Is that normal? Then it produced this
> strange error message immediately after linking perl.exe:
>
> ..\miniperl.exe -I..\lib bin\exetype.pl ..\wperl.exe WINDOWS
> 'x' outside of string in unpack at bin\exetype.pl line 39.
> NMAKE : fatal error U1077: '..\miniperl.exe' : return code '0xff'
> Stop.
>
> Line 39 in that file is:
>
> ($signature,$size,$magic) = unpack "Lx16Sx2S", $record;
>
> What on earth has happened here?
I've managed to build 5.12.1 with the 64-bit version of VS 2008 after
cherry-picking 2 patches from Nicholas (see log messages below).
I seems weird that this is the only part of the complete build and
test cycle that would run into this issue.
Nicholas, does it seem sensible that the win32/bin/exetype.pl script
triggers the error condition that you fixed with those 2 changes?
Are they by themselves suitable for integration into maint-5.12? They
look fine to me, but I'm not sure if they assume some other earlier
fixes in blead or not.
Steve, could you verify that cherry-picking these 2 commits solves the
problem for your configuration as well?
One weirdness I observed is that even with these patches in place it
always takes a *very* long time for exetype.pl to complete, whereas it
is virtually instantaneous when compiled with the Windows 2003 SP1 SDK
compiler. I can see that the process is blocking in the fclose() call,
but I'm not motivated to figure out why that happens. It eventually
terminates, it just takes a minute or so.
Cheers,
-Jan
- Log -----------------------------------------------------------------
commit 4f0556e9541e0e65f0abc5f4f6caf1f16ddf2dcd
Author: Nicholas Clark <nick@ccl4.org>
Date: Sun May 2 21:04:32 2010 +0100
Permit array assignment to steal temps and copy shared hash key scalars.
Scalar assignment to array elements already does this. (As does all other
scalar assignment, and list assignment to hashes.) Prior to 4c8f17b905f2
(change 7867) list assignment to arrays did steal temps.
M pp_hot.c
commit 61e5f455dc8214c9c23deb700f3fcf67b180afa5
Author: Nicholas Clark <nick@ccl4.org>
Date: Sun May 2 20:23:29 2010 +0100
Better fix for RT #2140 (list assignment with duplicated temporaries)
4c8f17b905f2 (change 7867) took the approach of a special case in sv_setsv()
when PL_op indicated that the current OP was OP_AASSIGN. The problem is in one
part of pp_aassign, where it was using sv_mortalcopy() on values that were
correctly marked as temporaries, but also still needed later. Hence a more
targetted solution is to avoid that call, and to instead use API calls that
will not steal temporaries.
M pp_hot.c
M sv.c
Thread Previous
|
Thread Next