I can't check with the user for a few days, but I'm seeing the same directory naming issue here on my XP-Home development box.
The 3 extra characters are always present, both when the executable is built (by pp), and when it's executed.
The resulting cache directory *does* have the extra characters in its name. Here are some directory names on my XP box:
cache-b83a83861a7cf7db6cc82e9e980edc9990653c63`�2
cache-b83a83861a7cf7db6cc82e9e980edc9990653c63p�2
cache-829e1673cd0100b0bd0dac81628e04265e166964p�2
cache-d234ff8e4bc49a67842faa3db78630ddad49d5d9�%2
I have recently cleared out my cache directory, but I've seen other 3-character patterns too, sometimes with valid characters.
------------
I tried various things for "PAR_GLOBAL_TEMP". I have just tried: set PAR_GLOBAL_TEMP=c:\RCF_TEMP
Running the pp'd executable gives the error I reported previously.
Running pp generates a Windows error "parl.exe has encountered a problem and needs to close". On clearing the Windows message box, The console shows:
Y:\>pp --add parser.fm --add logview.fm --add sysimage.gif --add buildinfo.txt --output=parser2.exe parser.pl
Can't spawn "C:\Perl\bin\parl.exe": Bad file descriptor at C:\Perl\bin\pp line 413.
-------------
To complete the picture: I'm running ActiveState build 809 (perl v5.8.3), and I installed PAR0.80 using ppm, from the repository at www.bribes.org/perl/ppm.
Maybe I should try re-installing PAR.
Cheers, Rick.
Alan Stewart wrote:
On 7 Apr 2004 at 22:41, Rick Fitzsimmons wrote:
Hi,
Been having problems since updating to 0.80. One user gets error message with Windows 2000 [Version 5.00.2195] when running a pp'd executable, but another user has no trouble at all. After many attempts, I've also seen this happen myself on WinXP [Version 5.1.2600]
Typical error message is:
parser: creation of
C:\DOCUME~1\greya\LOCALS~1\Temp\par-greya\cache-829e1673cd0100b0bd0dac81628e04265e166964?<//perl58.dll failed - aborting with 2.
(The pp'd executable is parser.exe)
The characters ?<// should be just one / path character.
Looks like it failed in static.c, after creating the temp directory with no error, but when it tried to open a file there to extract perl58.dll in it. After this crash, does the directory:
C:\DOCUME~1\greya\LOCALS~1\Temp\par-greya\cache829e1673cd0100b0bd0dac81628e04265e166964
exist? If it does, I presume it does not have any characters after the ...66964 at the end. I wonder if this is the SHA-1 algorithm blowing up or something else.
What puzzles me is the extra characters after the SHA-1 hash, and I wonder if these are causing a problem. There always seem to be three extra characters after the 40-hex-digit hash value, and they are often not valid filename characters.
What other character combos have you seen besides ?<//
As a workaround, I've tried setting the PAR_GLOBAL_TEMP environment variable, but then it fails with the error message:
IO error: opening P*2.exe for read : Invalid argument
at -e line 164
Can't call method "extractTree" on an undefined value at ../blib/lib/PAR.pm line 263.
Can anyone explain what's going wrong?
Has anyone managed to use PAR_GLOBAL_TEMP successfully on Win32?
I've used it on XP and NT. What did you set PAR_GLOBAL_TEMP to?
Also, what options did you run pp with to generate parser.exe?
