develooper Front page | perl.par | Postings from May 2008

Re: Archive::Unzip::Burst on Win32

Thread Previous | Thread Next
Mark Dootson
May 16, 2008 11:29
Re: Archive::Unzip::Burst on Win32
Message ID:

A couple of issues have arisen so far with Archive::Unzip::Burst on Win32.

If I build PAR::Packer when Archive::Unzip::Burst is already installed (and therefore Archive::Unzip::Burst ends up in the PAR::Packer test execs ) then I fail test t/20-pp.t 33. This is testing the -a option. I shall investigate and try to figure out reason. It's probably something to do with file packed as -a already being extracted. Output from failing build pasted at end of mail in case anyone can spot anything obvious. Is this a Win32 only problem?

The second issue is that as it stands doesn't really make best use of an archive extracted by Archive::Unzip::Burst. For example, I started to test extract times for a Wx script - a good mix of large dll files and all the utf8 and posix stuff gets packaged too.

I don't see improvements because, of course, Archive::Unzip::Burst extracts all the Wx dlls to ../shlib/archname, then PAR uses Archive::Zip to extract them again from the zip to the root of $ENV{PAR_TEMP}.

So, needs amending so that read_file etc recognises that Archive::Zip isn't needed and we get shlibs on PATH / LD_LIBRARY_PATH etc.

I think it is simple enough to store how each par file in @LibCache was extracted and act accordingly. However, the shlib question is more difficult. Adding ../shlib/archname to the paths is a possibility - however, I tend to think that to maintain compatibility with existing behaviour and to honour the 'no_shlib_unpack' option of PAR::import, when a par file has been extracted with Archive::Unzip::Burst, PAR should copy the contents of $ENV{PAR_TEMP}/shlib/archname to $ENV{PAR_TEMP}/ when 'no_shlib_unpack' => 0 and do nothing when 'no_shlib_unpack' => 1.

Just thought I'd report initial issues using Archive::Unzip::Burst.



#   Failed test 'pp_test_small_minus_a
t/20-pp.................NOK 33/34# [430]
# Test 32_9 The command string " hello.exe " in directory C:\PAR\build\mingw\PAR-Packer-0.980\contrib\automated_pp_test\pp_switch_tests\
temp2,did not produce :: "hello" ::
# Instead, it produced :: Could not unzip into 'C:\DOCUME~1\MARKDO~1\LOCALS~1\Temp\par-Mark_Dootson\cache-19e0427425d6bdd2de70a37172a8635e9c
97df27/inc'. Error: No such file or directory at C:/BasePerl/perl510/site/lib/ line 577.
# warning:  stripped absolute path spec from /PAR/build/mingw/PAR-Packer-0.980/contrib/automated_pp_test/pp_switch_tests/temp2/text ::
# End of [430] results
# Did pp -o hello.exe -a "C:/PAR/build/mingw/PAR-Packer-0.980/contrib/automated_pp_test/pp_switch_tests/temp2/text;/PAR/build/mingw/
PAR-Packer-0.980/contrib/automated_pp_test/pp_switch_tests/temp2/text" produce hello.exe?
# '
#   at line 8492.
t/20-pp.................ok 34/34# Looks like you failed 1 test of 34.
        Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 33
        Failed 1/34 tests, 97.06% okay
t/30-current_exec.......# Please wait
        1/4 skipped: various reasons
Failed Test Stat Wstat Total Fail  List of Failed
t/20-pp.t      1   256    34    1  33

Steffen Mueller wrote:
> Hi Mark, hi list,
> Mark Dootson wrote:
>> Attached is patch against Archive-Unzip-Burst-0.02_01 which seems to
>> work with both VC6 and MinGW.
>> If anyone would like to test, that would be good.
>> It is a direct lift from the info-zip dll usage example, although
>> objects are linked into Burst.dll rather than linking to an extenral
>> unzip32.dll.
> Awesome! I don't have a win32 to test on, but I checked that Linux still
> works with the patch applied. In fact I already committed it to trunk so
> people can try it more easily. We can always revert if breakage occurs.
> Thanks a lot for fixing this!
> Best regards,
> Steffen

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