Hi,
I got around to testing PAR::Packer build on Linux too, where it fails the same
test.
Just a heads up.
Mark
Mark Dootson wrote:
All,
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 PAR.pm 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, PAR.pm 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.
Regards
Mark
# 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/PAR.pm 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"
hello.pl produce hello.exe?
# '
# at automated_pp_test.pl line 8492.
t/20-pp.................ok 34/34# Looks like you failed 1 test of 34.
t/20-pp.................dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 33
Failed 1/34 tests, 97.06% okay
t/30-current_exec.......# Please wait
t/30-current_exec.......ok
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
