Re: PAR Packer, Win32::Exe (exe_update) --icon not working

[Mark Dootson]

Hi

On 22/01/2013 04:59, Krishna Kumar Khatri (kkhatri) [CONT - Type 2] wrote:



Can someone please advise, if this is a known issue and is there a workaround? 
I want to get icon of my executable changed either through pp or through 
exe_update. Thanks.



It is a known issue (Win32::Exe cannot handle pp packed executables) and 
there is no workaround.


Regards

Mark

Re: PAR::Packer cpan install problems on Strawberry Perl

[Mark Dootson]

Hi,

This particular problem has several alternate solutions posted to this 
list. The main problem is that the acceptable parameters to some 
binutils progs are a moving target so what works on my gcc may not work 
on your gcc.


For Strawberry see kmx post of 24 May 2012 to this list or

https://rt.cpan.org/Public/Bug/Display.html?id=77408

I would suggest this needs to work (for MinGW flavours) on the MinGW for 
Strawberry 32 and 64 bit and the MinGW installed by ActivePerl PPM for 
32 and 64 bit - all of which will have different binutils versions.


I posted the patch below in February but I now can't remember which 
versions of binutils I tested against. It certainly wasn't tested 
against the 64 bit MinGW ActivePerl currently installs.


Anyhow, what needs to happen is someone finding the time to install and 
test the above four setups with choice of

a) single line or two step resource creation.
b) explicit architecture or rely on defaults.

I think my experience was all the versions I tried supported the single 
line resource compilation and relying on default architectures worked 
fine - but that was February and kmx's different patches are proven to 
work with Strawberry.


Hope It Helps

Mark


Index: myldr/Makefile.PL
===
--- myldr/Makefile.PL   (revision 1354)
+++ myldr/Makefile.PL   (working copy)
@@ -115,8 +115,13 @@
 if( $^O =~ /^(?:MSWin|cygwin)/ ){
$res = 'ppresource.coff';
$pre_res = qq(winres\\pp.res);
-   $rt_cmd = qq(windres -F pei-i386 -i winres\\pp.rc -o $pre_res);
-   $res_cmd = qq(windres -o ppresource.coff $pre_res);
+
+   # some versions of binutils cannot handle two-step creation
+   #$rt_cmd = qq(windres -F pei-i386 -i winres\\pp.rc -o $pre_res);
+   #$res_cmd = qq(windres -o ppresource.coff $pre_res);
+   $rt_cmd = qq(windres -o ppresource.coff -i winres\\pp.rc);
+   $res_cmd = q(-$(NOOP));
+
$res_section = $res;
 }
 $mt_cmd = '-$(NOOP)';
Index: myldr/winres/pp.rc
===
--- myldr/winres/pp.rc  (revision 1354)
+++ myldr/winres/pp.rc  (working copy)
@@ -5,7 +5,7 @@
 #define PP_MANIFEST_FILEFLAGS 0
 #include 

-CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "pp.manifest"
+CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "winres\\pp.manifest"

 VS_VERSION_INFO VERSIONINFO
 FILEVERSION0,0,0,0
@@ -37,5 +37,5 @@
 END
 END

-WINEXE ICON pp.ico
+WINEXE ICON winres\\pp.ico






On 04/10/2012 16:32, smu johnson wrote:

Hi,

I got this email address from Steffen Müller, after he mentioned on IRC
that he no longer maintains PAR::Packer.

I'm not sure if anyone in charge knows yet, but this module hasn't compiled
on Strawberry Perl for the last few years.  There was a time I could get it
working by using a somewhat old version of the module, but even after
trying all the old versions I can find from https://metacpan.org/ last
week they still result in the same problem(s).  I decided to finally
write in after seeing a surprising amount of people joining #win32 on
irc.perl.org and asking about it.

All that is needed to demonstrate this is install any recent version of
Strawberry Perl, and run:  cpan PAR::Packer on Windows.

Can anything be done?  Any information would be greatly appreciated.  Thank
you, to whoever reads this.  I'd be more than happy to be the mule that
attempts to try different versions to see if any suggested patch might make
this work again.

Here is an error log, from the command:  cpan PAR::Packer 1>  pp-error.txt
2>&1

=

CPAN: CPAN::SQLite loaded ok (v0.202)
Database was generated on Thu, 04 Oct 2012 15:16:25 GMT
Running install for module 'PAR::Packer'
Running make for R/RS/RSCHUPP/PAR-Packer-1.013.tar.gz
CPAN: Digest::SHA loaded ok (v5.71)
CPAN: Compress::Zlib loaded ok (v2.055)
Checksum for
C:\strawberry\cpan\sources\authors\id\R\RS\RSCHUPP\PAR-Packer-1.013.tar.gz
ok
CPAN: Archive::Tar loaded ok (v1.88)
CPAN: File::Temp loaded ok (v0.22)
CPAN: Parse::CPAN::Meta loaded ok (v1.4404)
CPAN: CPAN::Meta loaded ok (v2.120921)
CPAN: Module::CoreList loaded ok (v2.70)

   CPAN.pm: Building R/RS/RSCHUPP/PAR-Packer-1.013.tar.gz

Checking if your kit is complete...
Looks good
Prototype mismatch: sub main::prompt: none vs ($;$) at
C:/strawberry/perl/lib/ExtUtils/MakeMaker.pm line 219.
Writing Makefile for par.exe
Writing MYMETA.yml and MYMETA.json
Writing Makefile for PAR::Packer
Writing MYMETA.yml and MYMETA.json
cp lib/App/Packer/PAR.pm blib\lib\App\Packer\PAR.pm
cp lib/PAR/Packer.pm blib\lib\PAR\Packer.pm
cp lib/PAR/Filter/Obfuscate.pm blib\lib\PAR\Filter\Obfuscate.pm
cp lib/PAR/Filter/PodStrip.pm blib\lib\PAR\Filter\PodStrip.pm
cp lib/PAR/StrippedPARL/Base.pm blib\lib\PAR\StrippedPARL\Base.pm
cp lib/PAR/Filter.pm blib\lib\PAR\Filter.pm
cp lib/PAR/Filter/PatchContent.pm blib\lib\PAR\Filter\PatchContent.pm
cp lib/PAR/Filter/Bytecode.pm blib\lib\PAR\Filter\Bytecode.pm
cp lib/pp.pm blib\lib\pp.pm
cp lib/PA

Re: PAR::Packer - problem installing under Windows / Strawberry portable

[Mark Dootson]

Hi,

See previous post 'Building on Windows with mingw resource bug'.

It gave patch to fix mingw windres issues.

Re attached to this post.

Win32::Exe still not working :(
Maybe soon.

Mark


Index: myldr/Makefile.PL
===
--- myldr/Makefile.PL   (revision 1354)
+++ myldr/Makefile.PL   (working copy)
@@ -115,8 +115,13 @@
 if( $^O =~ /^(?:MSWin|cygwin)/ ){
$res = 'ppresource.coff';
$pre_res = qq(winres\\pp.res);
-   $rt_cmd = qq(windres -F pei-i386 -i winres\\pp.rc -o $pre_res);
-   $res_cmd = qq(windres -o ppresource.coff $pre_res);
+
+   # some versions of binutils cannot handle two-step creation
+   #$rt_cmd = qq(windres -F pei-i386 -i winres\\pp.rc -o $pre_res);
+   #$res_cmd = qq(windres -o ppresource.coff $pre_res);
+   $rt_cmd = qq(windres -o ppresource.coff -i winres\\pp.rc);
+   $res_cmd = q(-$(NOOP));
+
$res_section = $res;
 }
 $mt_cmd = '-$(NOOP)';
Index: myldr/winres/pp.rc
===
--- myldr/winres/pp.rc  (revision 1354)
+++ myldr/winres/pp.rc  (working copy)
@@ -5,7 +5,7 @@
 #define PP_MANIFEST_FILEFLAGS 0
 #include 

-CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "pp.manifest"
+CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "winres\\pp.manifest"

 VS_VERSION_INFO VERSIONINFO
 FILEVERSION0,0,0,0
@@ -37,5 +37,5 @@
 END
 END

-WINEXE ICON pp.ico
+WINEXE ICON winres\\pp.ico



On 02/03/2012 07:30, Roderich Schupp wrote:

On Thu, Mar 1, 2012 at 20:08, Eljot na Onet.pl  wrote:

I guess the key line is here:
windres: unexpected version string length 68 != 32 + 8


No clue - I see the same on 32-bit. Note that the resource stuff is currently
under construction, cc'ing Mark Dootson...

Maybe the previous version of PAR::Packer works for you.

Cheers, Roderich

Re: [rt.cpan.org #75193] [PATCH] Fix build on Win32/VC++

[Mark Dootson]

Hi,

I've got a partly working solution for PAR::Packer + Win32::Exe. 
Compiling the 'extracted Perl executable' in as a data resource means I 
can apply Icons and manifest privileges etc to the inner executable as 
well as the outer. I am properly disassembling and re-assembling the pp 
produced executables now so no more mangling. ( pp now always finds the 
bound files and 'PAR.pm' signature at the end of the file as expected).


Two issues remain.

1. MSVC execs still have problems - I'll figure out what this is. It 
occurs whenever a section increases in size so it is most likely some 
incorrect boundary padding. (So --icon is most common cause but --info 
could cause it too if the block size increases).


2. Now that I properly get the bound files and zip section re-added to 
the end of the exec, I get an apparentley harmless warning about:


'Format Error: bad signature ' for every file extracted using 
Archive::Zip. I know this issue has been fixed before and wondered if 
someone could point me to a quick solution. I realise that it occurs 
because the zip contents are now at a different absolute offset in the 
file.( the inner 'Perl' executable can now change in size if I add icons 
to it - making the total 'boot exec' larger).


Regards

Mark



On 23/02/2012 17:56, Steve Hay wrote:

Roderich Schupp wrote on 2012-02-23:

On Wed, Feb 22, 2012 at 23:09, Mark Dootson
wrote:

I read the pp code as concatenating chunks of the final exec onto
itself


I just checked latest code and there have been many updates in this
area since I last looked.


There was some weird code in there that definitely modified the "inner"
executable stashed somewhere in the "outer" executable for "pp --gui"
just to flip the wants-a-console-window bit in the executable header on
both these executables. I took that out and now copy the relevant header
byte at runtime from the outer executable to the inner executable, just
after the latter has been extracted and before it is invoked.  For that
I reimplemented parts of PAR::Packer::_fix_console in C, see
seek_to_subsystem in myldr/boot.c.

I'm not sure which of inner or outer executable really produces the
"not a valid Win32 executable" error. Note that the failing test does
"pp --gui --icon ...". AFAICT Win32::Exe is not used to implement --
gui, only for the --icon part.


As I'm the current keeper of the Win32:Exe dark magic, I'll take a
look tomorrow and post a fix, one way or the other.




I'm pretty sure it's only the --icon part which causes the problem. I can 
reproduce the error by running a one-liner like this on a simple PAR executable 
called test.exe:

perl -MWin32::Exe -e "$e=Win32::Exe->new('C:\Temp\test.exe'); 
$e->update(icon=>'C:\Temp\newtest.ico')"

Before I run that command my test.exe runs fine, but afterwards it gives the "... is 
not a valid Win32 application" error.

Windows + gcc 4.5, 4.6, 4.7

[Mark Dootson]

Hi,

On Windows, for a Perl built with mingw gcc where the gcc version is 
greater than 4.4, the perl5xx.dll may be linked to libstdc++ in addition 
to libgcc. It depends on how the gcc toolchain was built and how Perl 
was built. Dynamic linking to libstdc++ is not an uncommon case. I 
expect the next releases of Strawberry Perl may use a dynamically linked 
libstdc++.


The attached patch copies the methods used to load libgcc with the 
addition of a check to see if perl5xx.dll is actually linked to libstdc++.


Regards

Mark
Index: myldr/boot.c
===
--- myldr/boot.c(revision 1354)
+++ myldr/boot.c(working copy)
@@ -30,6 +30,9 @@
 #ifdef LOAD_MY_LIBGCC
 #include "my_libgcc.c"
 #endif
+#ifdef LOAD_MY_LIBSTDCPP
+#include "my_libstdcpp.c"
+#endif
 
 /* Note: these two defines must be negative so as not to collide with 
  * any real file descriptor */
@@ -190,6 +193,18 @@
 
 #endif
 
+#ifdef LOAD_MY_LIBSTDCPP
+/* extract libgcc DLL into stmpdir */
+i = my_mkfile( argv[0], stmpdir, name_load_my_libstdcpp, 
size_load_my_libstdcpp, &my_file );
+if ( i != MKFILE_ALREADY_EXISTS ) {
+if ( i == MKFILE_ERROR ) DIE;
+if ( write_chunks(i, chunks_load_my_libstdcpp) == -1 ) DIE;
+if ( close(i) == -1 ) DIE;
+chmod(my_file, 0755);
+}
+
+#endif
+
 /* save original argv[] into environment variables PAR_ARGV_# */
 sprintf(buf, "%i", argc);
 par_setenv("PAR_ARGC", buf);
Index: myldr/Makefile.PL
===
--- myldr/Makefile.PL   (revision 1354)
+++ myldr/Makefile.PL   (working copy)
@@ -209,12 +214,16 @@
 # may depend on some libgcc*.dll (Strawberry Perl 5.12 is an example).
 # This libgcc*.dll has to be included into with any packed executbale 
 # in the same way as libperl*.dll itself, otherwise a packed executable
-# won't run when libgcc*.dll isn't installed.
+# won't run when libgcc*.dll isn't installed. Perl may also depend
+# on libstc++ but we can only know this by checking perl5xx.dll
+
 my $libgcc;
+my $libstdcpp;
+
 if ($dynperl and $^O eq 'MSWin32'
 and defined $Config{gccversion} # gcc version 4.x or above was used
 and $Config{gccversion} =~ m{\A(\d+)}ms && $1 >= 4) {
-# look for a libgcc_*.dll 
+# look for a libgcc_*.dll 
 # - in the same directory as the perl executable itself
 # - in the same directory as gcc (only useful if it's an absolute path)
 # - in PATH
@@ -222,22 +231,46 @@
 File::Basename::dirname($^X),
 File::Basename::dirname($cc),
 File::Spec->path;
+   
+   # check if we need libstdc. Just because it is present in gcc tools does
+   # not mean Perl is linked to it
+   
+   my @dumplines = qx(objdump -x $libperl);
+
+   for ( @dumplines ) {
+   if( /^\s+DLL Name: (libstdc++)(.+\.dll)\s+$/ ) {
+   my $libstdcname = $1 . $2;
+   # look for a libgcc_*.dll 
+   # - in the same directory as the perl executable itself
+   # - in the same directory as gcc (only useful if it's 
an absolute path)
+   # - in PATH
+   
+   ($libstdcpp) = map { glob(File::Spec->catfile($_, 
$libstdcname)) }
+   
File::Basename::dirname($^X),
+   
File::Basename::dirname($cc),
+   File::Spec->path;
+   last;
+   }
+   }
 }
 $libgcc ||= "";
+$libstdcpp ||= "";
 
 my $my_stuff = "my_par.c my_libperl.c";
 if ($libgcc) {
 $cflags .= " -DLOAD_MY_LIBGCC";
 $my_stuff .= " my_libgcc.c";
 }
+if ($libstdcpp) {
+$cflags .= " -DLOAD_MY_LIBSTDCPP";
+$my_stuff .= " my_libstdcpp.c";
+}
 
-
 my @strippedparl = qw( Static.pm );
 push @strippedparl, qw( Dynamic.pm ) if $dynperl;
 my @parl_exes = $parl_exe;
 push @parl_exes, $parldyn_exe if $dynperl;
 
-
 # Determine whether we can find a config.h. If yes, include it in
 # usernamefrompwuid.h. If not, set I_PWD to undefined in that header.
 # -- Steffen
@@ -251,7 +284,6 @@
 }
 close PWOUT;
 
-
 WriteMakefile(
 NAME=> "par$exe",
 SKIP=> [qw(static static_lib dynamic dynamic_lib test)],
@@ -346,6 +378,9 @@
 
 my_libgcc.c:
\$(PERLRUN) $f2c -c $chunk_size $libgcc \$@ load_my_libgcc
+   
+my_libstdcpp.c:
+   \$(PERLRUN) $f2c -c $chunk_size $libstdcpp \$@ load_my_libstdcpp
 
 Dynamic.pm: Dynamic.in $par_exe
\$(PERLRUN) encode_append.pl Dynamic.in $par_exe Dynamic.pm

Building on Windows with mingw resource bug

[Mark Dootson]

Hi,

Looking at the issues with windows resources I have found that the 
changes to the windows resource build in version 1.013 only work in 
fairly recent versions of Strawberry Perl.


Other binutils installations may suffer from a couple of bugs/problems:

1) Older versions of windres (as included with early Strawberry releases 
or any non-recent mingw) do not check for resource includes ( manifest 
and icon files) in the same directory as the resource ( .rc ) file so 
cannot find the pp manifest and icon files.


2) Some versions of binutils (including some of the latest releases) 
have a bug that prevents using the two-step resource creation method. ( 
rc to res file; res file to object )


The attached patch fixes both issues and is tested against recent and 
old versions of Strawberry Perl, and a custom Perl using mingw + gcc 
4.6.2 + binutils 2.22.51.2008


It doesn't fix any of the recently discussed Windows resource issues - 
it just fixes a basic build failure for several mingw versions so I 
thought it worth posting A.S.A.P.


Regards

Mark



Index: myldr/Makefile.PL
===
--- myldr/Makefile.PL   (revision 1354)
+++ myldr/Makefile.PL   (working copy)
@@ -115,8 +115,13 @@
 if( $^O =~ /^(?:MSWin|cygwin)/ ){
$res = 'ppresource.coff';
$pre_res = qq(winres\\pp.res);
-   $rt_cmd = qq(windres -F pei-i386 -i winres\\pp.rc -o $pre_res);
-   $res_cmd = qq(windres -o ppresource.coff $pre_res);
+   
+   # some versions of binutils cannot handle two-step creation
+   #$rt_cmd = qq(windres -F pei-i386 -i winres\\pp.rc -o $pre_res);
+   #$res_cmd = qq(windres -o ppresource.coff $pre_res);
+   $rt_cmd = qq(windres -o ppresource.coff -i winres\\pp.rc);
+   $res_cmd = q(-$(NOOP));
+   
$res_section = $res;
 }
 $mt_cmd = '-$(NOOP)';
Index: myldr/winres/pp.rc
===
--- myldr/winres/pp.rc  (revision 1354)
+++ myldr/winres/pp.rc  (working copy)
@@ -5,7 +5,7 @@
 #define PP_MANIFEST_FILEFLAGS 0
 #include 
 
-CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "pp.manifest"
+CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "winres\\pp.manifest"
 
 VS_VERSION_INFO VERSIONINFO
 FILEVERSION0,0,0,0
@@ -37,5 +37,5 @@
 END
 END
 
-WINEXE ICON pp.ico
+WINEXE ICON winres\\pp.ico
 

Re: [rt.cpan.org #75193] [PATCH] Fix build on Win32/VC++

[Mark Dootson]

On 22/02/2012 21:53, Mark Dootson wrote:



I read the pp code as concatenating chunks of the final exec onto itself


I just checked latest code and there have been many updates in this area 
since I last looked.
As I'm the current keeper of the Win32:Exe dark magic, I'll take a look 
tomorrow and post a fix, one way or the other.


Regards

Mark

Re: [rt.cpan.org #75193] [PATCH] Fix build on Win32/VC++

[Mark Dootson]

On 22/02/2012 21:35, Roderich Schupp via RT wrote:

Wed Feb 22 16:35:26 2012: Request 75193 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
  Subject: [PATCH] Fix build on Win32/VC++
Broken in: 1.012
 Severity: Important
Owner: RSCHUPP
   Requestors: s...@cpan.org
   Status: open
  Tickethttps://rt.cpan.org/Ticket/Display.html?id=75193>


On 2012-02-22 09:04:04, steve...@planit.com wrote:

Works fine for
me, except that 20-pp.t still fails test 32 as before. Is that
supposed to be fixed now? Do I need a newer Win32-Exe than I've got?
I'm using 0.17.


That's the most recent version.

Test 32 checks "pp --gui", right?


(The error is different now: it now complains about
not being a valid Win32 executable, rather than complaining that its
side-by-side configuration is incorret.)


Yeah, I see that sometimes, too. And always with "pp --info ...".
Somehow Win32::Exe seems to corrupt the executable - it's workings
are black magic to me.


I read the pp code as concatenating chunks of the final exec onto itself 
whenever the --gui option is called. This results in a huge corrupt 
executable. I never quite figured out why mingw compiled base 
executables would still run in this state but MSVC ones would not.


I sort of got side tracked from working out a fix as I could not 
implement a whole solution. Win32::Exe cannot get at the code for the 
Perl executable that will be extracted at run time so just setting the 
icon, privileges etc. of the main executable seemed unsatisfactory.


The full solution I thought of was that on Windows, the Perl exe, Perl 
dll plus libgcc etc where appropriate sould be added to the executable 
as resources. It is then possible to update some or all of these 
resources as required.


I guess just fixing the bug in the basic pp building code is needed though.


There doesn't seem to exist a standard command
on Windows to change icon or properties of an executable,
the only MS sanctioned way seems to set them from a resource file
when linking the executable.


BeginUpdateResource() if you have Win XP or above.

usage demonstrated in Win32::Exe & Win32::Resources



Cheers, Roderich




Regards

Mark

Re: par packer created executable dies on Twig

[Mark Dootson]

Hi,

I googled this whilst searching for a solution to my own XML::Twig 
problems - and the probable cause of the error seen by user is an 
interesting one to note I think.


XML::Twig uses Scalar::Util::weaken and consumes stack during parsed 
structure destruction.


On MS Windows the stack reserve is set when linking your executable.
Up to and including Perl 5.12, when Perl is compiled using MS Visual C, 
(as perl ActivePerl) win32/Makefile contains settings to pass a huge 
stack size of 16mb.


When compiling PAR::Packer with Visual C the default stack size of 1mb 
is used. (default for MinGW is 2mb)


So, if XML::Twig is used to parse an entire file at once, you will run 
out of stack a lot quicker in a PAR::Packer executable.


The fix for XML::Twig users is to parse as the module author suggests - 
chunk by chunk.


According to the commit that drops the 16mb setting for Perl 5.14, it 
was there to cope with some recursive feature of the regex engine but 
has not been needed since Perl 5.10 was released. MinGW compiled Perls 
(e.g. Strawberry) have never had this increased stack limit.


XML::Twig apart, it seemed worth noting that stack overflow errors in 
PAR::Packer on Windows may actually just be code that consumes the stack 
but happens not to use 16 mb of it in the user's tests.


The original test error

t/20-pp.t  31

is an issue with the handling of --gui and --icon options to pp - which 
always fails with VC built executables. It produces a mangled exec with 
a large chunk of rubbish appended which fails in unpleasant ways. MinGW 
execs are also mangled - but for some reason the boundary in the gcc 
exec where the rubbish begins does not seem to matter - it is on my list 
to fix. I had wanted to fix the whole Win32::Exe , application manifest 
permission issues - but some of the problems are in PAR::Packer itself 
and I haven't got around to testing even basic fixes yet.


Anyway, hope the stack info helps.

Mark



On 07/01/2011 10:48, Roderich Schupp wrote:

On Mon, Jan 3, 2011 at 7:20 PM, Ani Taggu  wrote:

(b) For the bug.xml file mentioned in the earlier post, everything
works correctly if I do this:
 perl myapp.pl<--- OK no problem.

  However, if I do
  pp -o a.exe myapp.pl
  .\a.exe
  the crash mentioned above occurs for the sample XML file.


Sorry, I can't reproduce this here, but I don't have exactly the
same setup as you (at least Windows XP vs Vista).

As your experiments show the most likely cause is the custom
perl interpreter used by the packed executable or the few
"essential" modules that it uses during bootstrap. Did you
build PAR::Packer yourself or installed it vis ppm?
If the latter: can you try to build PAR::Packer from source
(including running "dmake test"), install it, then re-pack bug2.pl
and try the resulting executable?

Cheers, Roderich

Re: Windows compilation - resource sections - Update

[Mark Dootson]

That's cleaner !

For info on the thread, Steve's pointer to

Perl_win32_init(): see win32/win32.c.

gives a much better way of determining if you have a compiler that 
automates manifests etc as well as having many different CRT features. i.e.


#if _MSC_VER >= 1400 && defined(_WRITE_ABORT_MSG)

Code not needed in boot.c now but I've seen so many nastier ways of 
doing this that I thought it was worth repeating the above here.


I'll post shortly on general progress with pp + windows

Mark


On 22/07/2011 09:28, Roderich Schupp wrote:

On Fri, Jul 22, 2011 at 9:48 AM, Mark Dootson  wrote:

So, the int / file descriptor we pass to close() is being interpreted as
invalid.


Got it: the code for the first file written from boot.c does a second
close() on an
already closed file descriptor:


 i = my_mkfile( argv[0],
stmpdir, par_basename(par_findprog(argv[0],
strdup(par_getenv("PATH",
size_load_my_par,&my_perl );
 if ( !i ) return 2;
 if ( i != -2 ) {
 if (write_chunks(chunks_load_my_par, i) || close(i))
 return 2;
 close(i);<
delete this line
 chmod(my_perl, 0755);

write_chunks(...) returns 0 on success, so next expression in || will
be evaluated.
close(i) (first call) succeeds, i.e. returns 0, hence if condition is
not satisfied
and we proceed to call close(i) again This code is horribly warped.


Cheers, Roderich

Re: Windows compilation - resource sections - Update

[Mark Dootson]

Hi,

In CRT versions greater than Server 2003, the close() function checks 
its parameters.
It expects a valid file descriptor ( the param check definition seems to 
say that an int is expected which should be a valid file descriptor.)


So, the int / file descriptor we pass to close() is being interpreted as 
invalid.


On older crts, there is no param check - so close proceeds and returns 
-1 if it fails.


But on new CRTs, the param is checked first, and if invalid, the 
standard invalid parameter handler is called. This default handler exits 
the application.  It seems utter nonesense that by default close() can 
never return -1. But that's how it seems to be.


see http://msdn.microsoft.com/en-us/library/5fzwd5ss.aspx

You can also look at the Server 2003 version from that page which 
indicates close() simply returns -1 if it does not succeed.


My current workaround is in the attached patch which makes build.c 
rather ugly. I do nothing in my custom invalid parameter handler leaving 
close() to behave as in earlier CRTs.


Why the descriptor is found invalid I don't know. It is always '3' ( so 
not -1 ) which seems reasonable as at that stage in the code everything 
is constant.


I tried changing the open flags to different params with no joy.















On 22/07/2011 07:34, Roderich Schupp wrote:

On Thu, Jul 21, 2011 at 9:04 PM, Mark Dootson  wrote:

The close(fh) statements in boot.c may cause application to crash if the CRT
version is 1400 or above for 32 bit or 1500 and above for 64 bit.


What exactly is the problem with close(fh) here? Invalid fh?

Cheers, Roderich
Index: myldr/boot.c
===
--- myldr/boot.c(revision 1271)
+++ myldr/boot.c(working copy)
@@ -1,6 +1,12 @@
 #undef readdir
-
+#ifdef _MSC_VER
+#include 
+#if ( _MSC_VER > 1400 ) || ( _MSC_VER >= 1400 && !defined(_WIN64) )
+#define PAR_MS_CRT_MODERN
+#endif
+#else
 #include 
+#endif
 
 typedef struct my_chunk
 {
@@ -25,6 +31,29 @@
 #include "my_libgcc.c"
 #endif
 
+#ifdef PAR_MS_CRT_MODERN
+void myInvalidCloseParameterHandler(const wchar_t* expression,
+   const wchar_t* function, 
+   const wchar_t* file, 
+   unsigned int line, 
+   uintptr_t pReserved)
+{ }
+#endif
+
+int my_close_fh (int fh) {
+int rval;
+#ifdef PAR_MS_CRT_MODERN
+_invalid_parameter_handler oldHandler, newHandler;
+newHandler = myInvalidCloseParameterHandler;
+oldHandler = _set_invalid_parameter_handler(newHandler);
+#endif
+rval = close(fh);
+#ifdef PAR_MS_CRT_MODERN
+_set_invalid_parameter_handler(oldHandler);
+#endif
+return rval;
+}
+
 int my_mkfile (char* argv0, char* stmpdir, const char* name, off_t 
expected_size, char** file_p) {
 int i;
 struct stat statbuf;
@@ -67,7 +96,7 @@
 #define ASFW_ANY -1
 #endif
 #endif
-
+
 par_init_env();
 
 stmpdir = par_mktmpdir( argv );
@@ -76,7 +105,7 @@
fprintf(stderr, "%s: creation of private temporary subdirectory %s 
failed - aborting with errno %i.\n", argv[0], stmpdir, errno);
return 2;
 }
-
+
 /* extract custom Perl interpreter into stmpdir 
(but under the same basename as argv[0]) */
 i = my_mkfile( argv[0], 
@@ -84,9 +113,9 @@
   size_load_my_par, &my_perl );
 if ( !i ) return 2;
 if ( i != -2 ) {
-if (write_chunks(chunks_load_my_par, i) || close(i))
+if (write_chunks(chunks_load_my_par, i) || my_close_fh(i))
return 2;
-close(i); 
+my_close_fh(i); 
 chmod(my_perl, 0755);
 #ifdef __hpux
 {
@@ -102,7 +131,7 @@
 i = my_mkfile( argv[0], stmpdir, name_load_my_libperl, 
size_load_my_libperl, &my_file );
 if ( !i ) return 2;
 if ( i != -2 ) {
-if (write_chunks(chunks_load_my_libperl, i) || close(i))
+if (write_chunks(chunks_load_my_libperl, i) || my_close_fh(i))
return 2;
 chmod(my_file, 0755);
 }
@@ -112,7 +141,7 @@
 i = my_mkfile( argv[0], stmpdir, name_load_my_libgcc, size_load_my_libgcc, 
&my_file );
 if ( !i ) return 2;
 if ( i != -2 ) {
-if (write_chunks(chunks_load_my_libgcc, i) || close(i))
+if (write_chunks(chunks_load_my_libgcc, i) || my_close_fh(i))
return 2;
 chmod(my_file, 0755);
 }

Re: Windows compilation - resource sections - Update

[Mark Dootson]

Hi,

Just an update to this.

I have now tested MS VC 2010 and have a couple of points.

The close(fh) statements in boot.c may cause application to crash if the 
CRT version is 1400 or above for 32 bit or 1500 and above for 64 bit.


So that would be MS VC 2005 and above.

On older CRTs, close(fh) just returns -1 if it encounters problems.

I have a work around that fixes boot.c compilation and usage with these 
CRT versions.


However -- test t/20-pp.t  31/34 fails just as it does 
with MS VC 6, only this time I get better error messages telling me the 
image is corrupt.


Fixes soon - I'm getting there. :)

Regards

Mark


On 21/07/2011 08:58, Mark Dootson wrote:

Hi,

The attached file winres.patch prepared against SVN contains changes to

Windows compilation - resource sections

[Mark Dootson]

Hi,

The attached file winres.patch prepared against SVN contains changes to

myldr/Makefile.PL
myldr/boot.c

changes have 2 goals

1) allow compilation with a Microsoft compiler (changes to boot.c and 
boot.exe section in Makefile.PL)


2) allow compilation of resource files on Windows with MinGW and MS 
compilers.


the file at

http://www.wxperl.co.uk/winres.tar.gz

contains the following additional files needed for the patch to work

myldr/winres/pp.manifest
myldr/winres/pp.ico
myldr/winres/pp.rc

If the patch and extra files are applied, the following 3 files can be 
removed from distribution.


myldr/win32.coff
myldr/win32.obj
myldr/win32.res

The patch has been successfully tested with

Windows XP 32 Bit
MinGW.org gcc 3.4.5 ( as installed by ActivePerl if no compiler present)
MinGW.org gcc 4.5.0 - as installed from www.mingw.org
mingw-w32 gcc 4.4.7 - as installed from mingw-w64.sourceforge.net

Windows Vista 32 bit
mingw-w32 gcc 4.4.7 - as installed from mingw-w64.sourceforge.net

Windows Vista 64 bit
mingw-w64 gcc 4.4.7 - as installed from mingw-w64.sourceforge.net
MS Platform SDK 2003 64 bit compiler

Note that in all cases, Module::ScanDeps 1.01 was used.

Module::ScanDeps 1.03 causes test failures as noted in attached 
'failures.txt'.


I have one unresolved failure.
Windows XP 32 bit
MS Visual C++ 6
Tests fail as noted in attached failures.txt. I assume this is a Visual 
C++ 6 issue (gcc compilers test fine on Win XP 32 bit) but I am not sure.


To do - testing by someone using a VC 2005 (or greater) built Perl.

I think the patch is OK to apply as is. Current CPAN and SVN cannot 
compile with any MS compiler so it is at least an improvement on that 
and hopefully someone can chip in with some VC 2005 - VC 2010 testing.


Regards

Mark





















Index: myldr/boot.c
===
--- myldr/boot.c(revision 1271)
+++ myldr/boot.c(working copy)
@@ -1,6 +1,9 @@
 #undef readdir
-
+#ifdef _MSC_VER
+#include 
+#else
 #include 
+#endif
 
 typedef struct my_chunk
 {
Index: myldr/Makefile.PL
===
--- myldr/Makefile.PL   (revision 1271)
+++ myldr/Makefile.PL   (working copy)
@@ -83,17 +83,28 @@
 
 my $lib_path = join(' ', map qq(-I"$_"), @INC); # FIXME run_with_inc.pl
 
-my( $out, $ccdebug, $lddebug, $warn, $rm, $mv, $res, $mt_cmd );
+my( $out, $ccdebug, $lddebug, $warn, $rm, $mv, $res, $mt_cmd, $res_cmd, 
$res_section, $rt_cmd, $pre_res );
 
+$res = '';
+$pre_res = '';
+$res_cmd = '-$(NOOP)';
+$rt_cmd = '-$(NOOP)';
+$res_section = 'noresource.o'; # is never built
+
 if( $cc =~ m/^cl\b/i ) {
 $out = '-out:';
 $ccdebug = $debug ? '-Zi -Zm1000 ' : '-Zm1000 ';
 $lddebug = $debug ? '-debug ' : '-release ';
 $warn = $debug ? '-W3' : '';
-$res = $Config{ptrsize} == 4 ? 'win32.obj' : '';
+my $machinearch = ( $Config{ptrsize} == 8 ) ? 'AMD64' : 'X86';
+   $pre_res = qq(winres\\pp.res);
+   $rt_cmd = qq(rc winres\\pp.rc);
+$res_cmd = qq(cvtres /NOLOGO /MACHINE:$machinearch /OUT:ppresource.obj 
$pre_res);
+$res = 'ppresource.obj';
+   $res_section = $res;
 # Embed the manifest file for VC 2005 (aka VC8) or higher, but not for the
-# 64-bit Platform SDK compiler
-if( $Config{ivsize} == 4 and $Config{ccversion} =~ /^(\d+)/ and $1 >= 14 ) 
{
+# 64-bit Platform SDK compiler.
+if( $Config{ptrsize} == 4 and $Config{ccversion} =~ /^(\d+)/ and $1 >= 14 
) {
 $mt_cmd = 'mt -nologo -manifest $@.manifest -outputresource:$@;1';
 } else {
 $mt_cmd = '-$(NOOP)';
@@ -103,14 +114,19 @@
 $ccdebug = $debug ? '-g ' : '';
 $lddebug = ($debug or $^O eq 'darwin') ? '' : '-s ';
 $warn = $debug ? '-Wall -Wno-comments ' : '';
-$res = ($^O =~ /^(?:MSWin|cygwin)/ && $Config{ptrsize} == 4) ? 
'win32.coff' : '';
+if( $^O =~ /^(?:MSWin|cygwin)/ ){
+   $res = 'ppresource.coff';
+   $pre_res = qq(winres\\pp.res);
+   $rt_cmd = qq(windres -F pei-i386 -i winres\\pp.rc -o $pre_res);
+   $res_cmd = qq(windres -o ppresource.coff $pre_res);
+   $res_section = $res;
+}
 $mt_cmd = '-$(NOOP)';
 } else {
 $out = '-o ';
 $ccdebug = '';
 $lddebug = '';
 $warn = '';
-$res = '';
 $mt_cmd = '-$(NOOP)';
 }
 
@@ -271,12 +287,16 @@
 
 main$o: main.c my_par_pl.c perlxsi.c internals.c \$(MKTMP_STUFF)
 
+$res_section:
+   $rt_cmd
+   $res_cmd
+
 sha1.c:
\$(PERLRUN) sha1.c.PL
 
 clean::
-\$(RM_F) my_*.c
-   -\$(RM_F) main$o boot$o
+   -\$(RM_F) main$o boot$o $res $pre_res
-\$(RM_F) sha1.c
-\$(RM_F) *.opt *.pdb perlxsi.c
-\$(RM_F) usernamefrompwuid.h
@@ -321,7 +341,7 @@
 boot$o: \$(MKTMP_STUFF) $my_stuff
 
 $boot_exe: boot$o
-   \$(CC) boot$o \$(STATIC_LDFLAGS) $res $out$boot_exe_link
+   \$(LD) boot$o \$(STATIC_LDFLAGS) $res $out$boot_exe_link
$mt_cmd
 
 my_par.c: $par_exe
#---
# Test Failure Windows XP 32 bit - MS VC++ 6
#---

Re: Problem with IPC::Cmd under windows

[Mark Dootson]

Hi,

Just to confirm that I'm not completely daft - and that I probably have 
too much time on my hands, example script below works as intended when 
packaged as


pp -o testipc.exe testipc.pl

Of course, it makes complete sense to use qx or IPC::Run3 if that fits 
requirement.


Regards

Mark

---

BEGIN {

if($^O =~ /^mswin/i && defined($ENV{PAR_0}) && -f $ENV{PAR_0} ) {
$^X = $ENV{PAR_PROGNAME};
my $command = join(' ', @ARGV);
if($command =~ / -MIPC::Run::Win32Pump -e 1 \d+ \d+ \d+ \d+ \d+ 
\d+ \d+ /) {

while( my $arg = shift( @ARGV )) {
last if($arg eq '1');
}
eval{ require IPC::Run::Win32Pump; };
die $@ if $@;
exit(0);
}
}
}

use strict;
use warnings;
use IPC::Run qw( run );

my @cmd = ('help');

run \@cmd, '1>', \&RedirectOutput;

sub RedirectOutput
{
my $output = shift;
my @lines = split(/\n/, $output);
print qq(IPCOUTPUT: $_\n) for (@lines);
return;
}

1;


On 23/05/2011 14:30, Roderich Schupp wrote:

On Mon, May 23, 2011 at 2:49 PM, Mark Dootson  wrote:

The following may be worth a try then, assuming pp passes all the arguments
and assigning to S^X doesn't break everything else. :-)


Err, no. pp doesn't enter the picture at run time. And when invoking
$ENV{PAR_PROGNAME}
you MUST pass "--par-options --reuse" followed by a real script (no -M, no -e).
I suggest to punt: use IPC::Run3 instead, the whole machinery of IPC::Run
isn't necessary in the original usecase.

Cheers, Roderich

Re: Problem with IPC::Cmd under windows

[Mark Dootson]

Or 

A warning against running the 'monster' code --- it actually re-executes 
the packed exec on every iteration.


It needed to exit(0); after running IPC::Run::Win32Pump, not just 'return;'

Now I'm really sorry.

Mark

On 23/05/2011 14:50, Mark Dootson wrote:



On 23/05/2011 14:17, Philip Kime wrote:

Hmm, I tried Mr Dootson's monster but it almost hung the machine and
never returned ... I think this is probably too hard for what I need -


After reading Roderich's reply, I think the code set $^X to undef which
probably vexed CreateProcess somewhat.

Sorry

Mark

Re: Problem with IPC::Cmd under windows

[Mark Dootson]

On 23/05/2011 14:17, Philip Kime wrote:

Hmm, I tried Mr Dootson's monster but it almost hung the machine and
never returned ... I think this is probably too hard for what I need -


After reading Roderich's reply, I think the code set $^X to undef which 
probably vexed CreateProcess somewhat.


Sorry

Mark

Re: Problem with IPC::Cmd under windows

[Mark Dootson]

Hi,

The following may be worth a try then, assuming pp passes all the 
arguments and assigning to S^X doesn't break everything else. :-)


The code attempts:

If I am packed exec and this is windows {
  assign my execpath to $^X
  Check if this is special case of IPC::Run::Win32Pump
run IPC::Run::Win32Pump and return.


So $^X -MIPC::Run::Win32Pump -e 1 blah blah
when called from pp packed executable ought to work


BEGIN {

if($^O =~ /^mswin/i && defined($ENV{PAR_0}) && -f $ENV{PAR_0} ) {
$^X = $ENV{PAR_PROGNAME};
my $command = join(' ', @ARGV);
if($command =~ / -MIPC::Run::Win32Pump -e 1 \d+ \d+ \d+ \d+ \d+ 
\d+ \d+ /) {

while( my $arg = shift( @ARGV )) {
last if($arg eq '1');
}
eval{ require IPC::Run::Win32Pump; };
die $@ if $@;
return;
}
}
}





On 23/05/2011 13:19, Roderich Schupp wrote:

On Mon, May 23, 2011 at 1:34 PM, Mark Dootson  wrote:

$^X -MIPC::Run::Win32Pump -e 1 blah blah

Come to think of it, to make my ugly code work I think you need to use the
--reuse option to pp - then I assume you get something workable in $^X.


It's even more complicated :(

- $^X is always the dummy string "perl"
- instead of $^X one could use
  $ENV{PAR_PROGNAME}  --par-options --reuse
- the original script must have been packed with "pp --reusable ..."
- even then perl command line options (e.g. -M, -e) won't work

See also the recent thread about similar problem with POE.

Cheers, Roderich

Re: Problem with IPC::Cmd under windows

[Mark Dootson]

Hi

On 23/05/2011 12:23, Philip Kime wrote:


So I assumed that it couldn't find Win32::Process and added it with a
--module flag but this made no difference. I don't really understand
why this works fine unpacked but doesn't when packed ...



because when unpacked IPC::Run calls

$^X -MIPC::Run::Win32Pump -e 1 blah blah

Come to think of it, to make my ugly code work I think you need to use 
the --reuse option to pp - then I assume you get something workable in $^X.


Regards

Mark

Re: Problem with IPC::Cmd under windows

[Mark Dootson]

Hi,

IPC::Run calls $^X on windows to run IPC::Run::Win32Pump

The following at the top of your script (or something like it) may work.

BEGIN {
if($^O =~ /^mswin/i && defined($ENV{PAR_0}) && -f $ENV{PAR_0} ) {
my $command = join(' ', @ARGV);
if($command =~ / -MIPC::Run::Win32Pump -e 1 \d+ \d+ \d+ \d+ \d+ 
\d+ \d+ /) {

while( my $arg = shift( @ARGV )) {
last if($arg eq '1');
}
eval{ require IPC::Run::Win32Pump; };
die $@ if $@;
return;
}
}
}





On 23/05/2011 10:13, Philip Kime wrote:

Greetings, I am using the current Par::Packer and have a strange
problem. Under windows and Strawberry perl, I am using IPC::Cmd with
IPC::Run to run a command and get the stdout back. This works on all
platforms I use (Mac, Linux, Windows). As soon as I pack the program
for Windows, this stops working. It continues to work for all other
platforms.

 scalar run( command =>  [ 'kpsewhich', $filename ],
 verbose =>  0,
 buffer =>  \$found );

After packing on Windows, $found is undef. Bizarrely, if I add print
`kpsewich $filename` just before this, I get what I expect. Is there
something wrong with IPC::Run or IPC::Cmd in conjunction with
Par::Packer on Windows?

PK

Re: PP failure

[Mark Dootson]

Hi,

$Config{ptrsize} seems the definitive method. It is 4 or 8 for 32bit / 
64bit Perl and gets you the right answer if you are running a 32 bit 
Perl on 64 bit Windows.


I think $Config{ivsize} as used in current pp makefiles should always 
work too, but using $Config{ptrsize} seems more directly connected to 
the question.


For choosing 64 bit vs 32 bit pre compiled objects it is the Perl you 
are interested in rather than the operating system.


For info only - I use $ENV{PROCESSOR_IDENTIFIER} if I want to know the 
operating system bitness. This will tell me correct answer even if I'm 
running a 32 bit Perl on a 64 bit system. I keep meaning to seek out a 
better way which there must be.



Regards

Mark





On 31/03/2011 08:50, Roderich Schupp wrote:

On Thu, Mar 31, 2011 at 1:48 AM, Mark Dootson  wrote:

The zip

http://www.wxperl.co.uk/ppamd64_resource.zip

Contains objects that can be unzipped into the current PAR::Packer source in
the directory myldr. You want the contained win32.coff / win32.obj to
replace the originals.


Thanks, Mark. I'll try to incorporate this stuff into PAR::Packer over
the weekend.
This begs the obvious question: how do I know that I am building for
64 bit Windows?

Cheers, Roderich

Re: PP failure

[Mark Dootson]

Bob,

For info,

The only file that gets used out of the zip in your case is win32.coff.
I included the other files as they were used to create win32.coff so 
that win32.coff is recreatable / amendable by anyone who might wish to 
do so.


The change of requireAdministrator is something that would have to 
happen in code that made binary replacements to the finished exec. 
Changing it in the raw manifest will make no difference (as you noticed.).


Glad it worked for you.

Regards

Mark

On 31/03/2011 03:41, Bob R wrote:

Thank you all for your efforts on this. Let me start out by saying I got
the packer running on my machine! To recap for your files, it's a
Windows operating system: Windows 7 Home Premium 64 bit Intel dual
processor @ 2.8 Gb per. I'm running Strawberry Perl, version 5.12.2. I
changed out the Win32 components in the first link you gave me and it
worked with nothing else needed. I did however change out the

Re: PP failure

[Mark Dootson]

One further thought on this.

The object files in the zips contain a basic manifest that includes

against a pp exec and hit the manifests in both the 'boot' executable 
and the 'perlish' executable. It probably only matters for the 'boot' 
exec - but it does give a quick way of producing a pp exec that gets 
elevated privileges.


Now all that needs to happen is to check that the addition of dependency 
manifests by modern ms compilers works out OK.



On 31/03/2011 00:48, Mark Dootson wrote:

Hi,

Further to previous message ( which seems to have disappeared into the
ether - so pasted below: )

The zip

http://www.wxperl.co.uk/ppamd64_resource.zip

Contains objects that can be unzipped into the current PAR::Packer
source in the directory myldr. You want the contained win32.coff /
win32.obj to replace the originals.

Should then compile OK on Strawberry.

The zip

http://www.wxperl.co.uk/parpackerresource.zip

contains file prefixed with ppres as noted in original message below.
These file are for possible inclusion in PAR::Packer source.

Hope it helps.


Mark


ORIGINAL MESSAGE

Hi All.

The issue is getting a basic resource file with version info that can be
compiled into the pp executables.

With standard microsoft tools, the process is as follows:

Start with a Win32.rc file (it could be named anything.rc, but we'll use
Win32/ Win64 for explanation).

The .rc file is a plaintext file that describes the version info. It can
also specify icons and other resources to import. It is platform
agnostic. For pp we want version info, and an icon. We need to test what
happens if we add a basic manifest and an MS compiler also adds a
manifest for dependencies. I think it should work ...

Teh rc file gets converted to a .RES file using the rc compiler
rc Win32.rc Win32.RES

This is still platform agnostic.

The next step is where we get platform specific. The ms tools will
produce usable obj / coff files, for specific architectures

cvtres /MACHINE:X86 /OUT:Win32.COFF Win32.RES
cvtres /MACHINE:X86 /OUT:Win32.OBJ Win32.RES
cvtres /MACHINE:AMD64 /OUT:Win64.COFF Win32.RES
cvtres /MACHINE:AMD64 /OUT:Win64.OBJ Win32.RES
cvtres /MACHINE:IA64 /OUT:Win64.OBJ Win32.RES

and you have an object you can pass to the linker.

The problem arises when using mingw32 / mingw-w64.
The resource compilers (windres etc) often choke at various points,
although latest version with mingw-w64 seems to work .. sometimes.

Solution for pp would appear to be:

create objects as follows, for use instead of Win32.obj / coff

ppres_x86.coff
ppres_x86.obj
ppres_amd64.coff
ppres_amd64.obj
ppres_ia64.obj ? (is this needed )

When creating makefile, specify correct resource for linking depending
on compiler and platform.

I can create and upload the above objects to SVN and also the source used:

ppres.rc
ppres.ico
ppres.RES

but I won't have the time to become familiar enough with the makefile
writing process to do the right thing there. At least not in the
immediate future.

I would be happy to test any changes against compilation with mingw32,
mingw-w32, mingw-w64 and VC6. If someone else could chip in with some
tests against modern MS compilers, that would be nice.

In the interim, I'll also prepare a zip containing

Win32.rc
Win32.RES
Win32.OBJ
Win32.COFF

which are for amd64 architecture - this could be unzipped over the
downloaded pp source and you should be able to build a working pp on
amd64 architecture from current code. It's ugly but it will give an
instant fix.

Regards

Mark



On 30/03/2011 23:51, Travis Williams wrote:

If it helps any, I did the cpan install of PAR::Packer 1.009 (which had
a pre-req of Module::Scandeps 1.01 that got installed) on windows 7 64
bit and strawberry 5.12.2.
Travis

On Wed, Mar 30, 2011 at 5:13 PM, Roderich Schupp
mailto:roderich.sch...@googlemail.com>>
wrote:

Hi Bob,

I'm forwarding this to the par@perl.org <mailto:par@perl.org>
mailing list. This is
generally the first address to turn
to with questions and problems about PAR, PAR::Packer,
Module::ScanDeps and
related stuff. You can also find it as "perl.par" in Google Groups.

As for your problem: the "prototype mismatch" warning is harmless
and the
win32.coff is serious. Yes, this file probably needs a 64 bit
replacement
when building on 64 bit Windows, but I know next to nothing about
this subject.
I've cc'ed Mark Dootson which maintains Win32::Exe and who has
apparently
already ventured into 64 bit Windows land.

Cheers, Roderich



-- Forwarded message --
From: Bob R mailto:engin...@fuse.net>>
Date: Wed, Mar 30, 2011 at 10:18 PM
Subject: PP failure
To: rsch...@cpan.org <mailto:rsch...@cpan.org>


Hi,

I downloaded the latest Par-Packer (1.09) today and tried installing
it but it failed. I have to run on Windoze here so I have Windows 7
and 64 bit Pentium dual processor. I’m running Strawberry Perl V
5.12.2. I may even be 

Re: PP failure

[Mark Dootson]

Hi,

Further to previous message ( which seems to have disappeared into the 
ether - so pasted below: )


The zip

http://www.wxperl.co.uk/ppamd64_resource.zip

Contains objects that can be unzipped into the current PAR::Packer 
source in the directory myldr. You want the contained win32.coff / 
win32.obj to replace the originals.


Should then compile OK on Strawberry.

The zip

http://www.wxperl.co.uk/parpackerresource.zip

contains file prefixed with ppres as noted in original message below. 
These file are for possible inclusion in PAR::Packer source.


Hope it helps.


Mark


ORIGINAL MESSAGE

Hi All.

The issue is getting a basic resource file with version info that can be 
compiled into the pp executables.


With standard microsoft tools, the process is as follows:

Start with a Win32.rc file (it could be named anything.rc, but we'll use 
Win32/ Win64 for explanation).


The .rc file is a plaintext file that describes the version info. It can 
also specify icons and other resources to import. It is platform 
agnostic. For pp we want version info, and an icon. We need to test what 
happens if we add a basic manifest and an MS compiler also adds a 
manifest for dependencies. I think it should work ...


Teh rc file gets converted to a .RES file using the rc compiler
rc Win32.rc Win32.RES

This is still platform agnostic.

The next step is where we get platform specific. The ms tools will 
produce usable obj / coff files, for specific architectures


cvtres /MACHINE:X86 /OUT:Win32.COFF Win32.RES
cvtres /MACHINE:X86 /OUT:Win32.OBJ Win32.RES
cvtres /MACHINE:AMD64 /OUT:Win64.COFF Win32.RES
cvtres /MACHINE:AMD64 /OUT:Win64.OBJ Win32.RES
cvtres /MACHINE:IA64 /OUT:Win64.OBJ Win32.RES

and you have an object you can pass to the linker.

The problem arises when using mingw32 / mingw-w64.
The resource compilers (windres etc) often choke at various points, 
although latest version with mingw-w64 seems to work .. sometimes.


Solution for pp would appear to be:

create objects as follows, for use instead of Win32.obj / coff

ppres_x86.coff
ppres_x86.obj
ppres_amd64.coff
ppres_amd64.obj
ppres_ia64.obj  ? (is this needed )

When creating makefile, specify correct resource for linking depending 
on compiler and platform.


I can create and upload the above objects to SVN and also the source used:

ppres.rc
ppres.ico
ppres.RES

but I won't have the time to become familiar enough with the makefile 
writing process to do the right thing there. At least not in the 
immediate future.


I would be happy to test any changes against compilation with mingw32, 
mingw-w32, mingw-w64 and VC6. If someone else could chip in with some 
tests against modern MS compilers, that would be nice.


In the interim, I'll also prepare a zip containing

Win32.rc
Win32.RES
Win32.OBJ
Win32.COFF

which are for amd64 architecture - this could be unzipped over the 
downloaded pp source and you should be able to build a working pp on 
amd64 architecture from current code. It's ugly but it will give an 
instant fix.


Regards

Mark



On 30/03/2011 23:51, Travis Williams wrote:

If it helps any, I did the cpan install of PAR::Packer 1.009 (which had
a pre-req of Module::Scandeps 1.01 that got installed) on windows 7 64
bit and strawberry 5.12.2.
Travis

On Wed, Mar 30, 2011 at 5:13 PM, Roderich Schupp
mailto:roderich.sch...@googlemail.com>>
wrote:

Hi Bob,

I'm forwarding this to the par@perl.org <mailto:par@perl.org>
mailing list. This is
generally the first address to turn
to with questions and problems about PAR, PAR::Packer,
Module::ScanDeps and
related stuff. You can also find it as "perl.par" in Google Groups.

As for your problem: the "prototype mismatch" warning is harmless
and the
win32.coff is serious. Yes, this file probably needs a 64 bit
replacement
when building on 64 bit Windows, but I know next to nothing about
this subject.
I've cc'ed Mark Dootson which maintains Win32::Exe and who has
apparently
already ventured into 64 bit Windows land.

Cheers, Roderich



-- Forwarded message --
From: Bob R mailto:engin...@fuse.net>>
Date: Wed, Mar 30, 2011 at 10:18 PM
Subject: PP failure
To: rsch...@cpan.org <mailto:rsch...@cpan.org>


Hi,

I downloaded the latest Par-Packer (1.09) today and tried installing
it but it failed. I have to run on Windoze here so I have Windows 7
and 64 bit Pentium dual processor. I’m running Strawberry Perl V
5.12.2. I may even be something doing wrong. I’m not all that great at
C and am just learning XS, but if there is anything I can do to help
out here please let me know. I recently helped out Cosimo on the API
package by testing it on a 64 bit system for several runs and he got
it working in a week or so. Here are my messages in loading – there
seem to be two reported errors – prototype mi

Re: OSX problem packing for 10.5 on 10.6

[Mark Dootson]

Hi,

Yep. I just don't have the time to confirm its the case for 10.5 too. 
According to my reading, support for -fstack-protector code isn't in the 
system libraries until 10.6 but I could be wrong. Hence my advice to 
check it out for yourself.


On the wider point, PAR::Packer builds with the same flags as Perl is 
configured with - so it's unlikely to be something that can be fixed in 
PAR::Packer alone.


Regards

Mark

On 13/03/2011 13:40, Philip Kime wrote:

Hmm, that patch mentions that the stack pointer issue is on 10.4, not 10.5?

PK

On 13 Mar 2011, at 2:27 PM, Mark Dootson wrote:


Hi,

Don't take my word for it.

Attached are a patch for Perl 5.12.3 source and an sh file with appropriate 
config args.

You could build a Perl 5.12 on 10.6 and check out that this really is the issue.

Regards

Mark

<5.12.3-osx.patch>





On 13 Mar 2011, at 13:08, Philip Kime wrote:


Hmm, I have to use 5.12 unfortunately, I may need to see if I can get this 
working on a real 10.5 machine.

PK

On 13 Mar 2011, at 2:05 PM, Mark Dootson wrote:


Hi,

I'm pretty sure none of the binary components of your Perl can run on anything 
lower than 10.6 because of the  -fstack-protector flag introduced with Perl 
5.12.

As an experiment, try a MacPort of 5.10 and I think all will work.

Regards

Mark

On 13/03/2011 12:55, Philip Kime wrote:

[bbf-osx32][~]>   perl -V
Summary of my perl5 (revision 5 version 12 subversion 3) configuration:

Platform:
   osname=darwin, osvers=10.6.0, archname=darwin-thread-multi-2level
   uname='darwin bbf-osx32.local 10.6.0 darwin kernel version 10.6.0: sun jan 9 
16:31:48 est 2011; legacy kernel v6 :xnu-1504.9.26buildobjrelease_i386 i386 '
   config_args='-D inc_version_list=5.12.2/darwin-thread-multi-2level 5.12.2 
5.12.1/darwin-thread-multi-2level 5.12.1 5.12.0/darwin-thread-multi-2level 
5.12.0 -Dusethreads -Duseshrplib -des -Dprefix=/opt/local 
-Dscriptdir=/opt/local/bin -Dcppflags=-I/opt/local/include -isysroot 
/Developer/SDKs/MacOSX10.5.sdk -Dccflags=-pipe -O2 -isysroot 
/Developer/SDKs/MacOSX10.5.sdk -arch i386 -Dldflags=-L/opt/local/lib 
-Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -arch i386 
-Dvendorprefix=/opt/local -Dusemultiplicity=y -D cc=/usr/bin/gcc-4.0 -D 
ld=/usr/bin/gcc-4.0 -D man1ext=1pm -D man3ext=3pm -D 
man1dir=/opt/local/share/man/man1p -D man3dir=/opt/local/share/man/man3p -D 
siteman1dir=/opt/local/share/man/man1 -D siteman3dir=/opt/local/share/man/man3 
-D vendorman1dir=/opt/local/share/man/man1 -D 
vendorman3dir=/opt/local/share/man/man3 -D pager=/usr/bin/less -sR'
   hint=recommended, useposix=true, d_sigaction=define
   useithreads=define, usemultiplicity=define
   useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
   use64bitint=undef, use64bitall=undef, uselongdouble=undef
   usemymalloc=n, bincompat5005=undef
Compiler:
   cc='/usr/bin/gcc-4.0', ccflags ='-pipe -O2 -isysroot 
/Developer/SDKs/MacOSX10.5.sdk -arch i386 -fno-common -DPERL_DARWIN 
-I/opt/local/include -isysroot /Developer/SDKs/MacOSX10.5.sdk -no-cpp-precomp 
-fno-strict-aliasing -fstack-protector -I/opt/local/include',
   optimize='-O3',
   cppflags='-I/opt/local/include -isysroot /Developer/SDKs/MacOSX10.5.sdk 
-no-cpp-precomp -pipe -O2 -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch i386 
-fno-common -DPERL_DARWIN -I/opt/local/include -isysroot 
/Developer/SDKs/MacOSX10.5.sdk -no-cpp-precomp -fno-strict-aliasing 
-fstack-protector -I/opt/local/include'
   ccversion='', gccversion='4.0.1 (Apple Inc. build 5493)', gccosandvers=''
   intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
   d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
   ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
   alignbytes=8, prototype=define
Linker and Libraries:
   ld='env MACOSX_DEPLOYMENT_TARGET=10.6 /usr/bin/gcc-4.0', ldflags 
='-L/opt/local/lib -Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -arch i386 
-fstack-protector'
   libpth=/opt/local/lib /usr/lib
   libs=-lgdbm -ldbm -ldl -lm -lutil -lc
   perllibs=-ldl -lm -lutil -lc
   libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib
   gnulibc_version=''
Dynamic Linking:
   dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
   cccdlflags=' ', lddlflags='-L/opt/local/lib 
-Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -arch i386 -bundle -undefined 
dynamic_lookup -fstack-protector'


Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
   PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_ITHREADS
   USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF
   USE_REENTRANT_API
Built under darwin
Compiled at Mar 11 2011 22:30:02
@INC:
   /opt/local/l

Re: OSX problem packing for 10.5 on 10.6

[Mark Dootson]

Hi,

Don't take my word for it.

Attached are a patch for Perl 5.12.3 source and an sh file with appropriate 
config args.

You could build a Perl 5.12 on 10.6 and check out that this really is the issue.

Regards

Mark



5.12.3-osx.patch
Description: Binary data




myconfig.sh
Description: Binary data




On 13 Mar 2011, at 13:08, Philip Kime wrote:

> Hmm, I have to use 5.12 unfortunately, I may need to see if I can get this 
> working on a real 10.5 machine. 
> 
> PK
> 
> On 13 Mar 2011, at 2:05 PM, Mark Dootson wrote:
> 
>> Hi,
>> 
>> I'm pretty sure none of the binary components of your Perl can run on 
>> anything lower than 10.6 because of the  -fstack-protector flag introduced 
>> with Perl 5.12.
>> 
>> As an experiment, try a MacPort of 5.10 and I think all will work.
>> 
>> Regards
>> 
>> Mark
>> 
>> On 13/03/2011 12:55, Philip Kime wrote:
>>> [bbf-osx32][~]>  perl -V
>>> Summary of my perl5 (revision 5 version 12 subversion 3) configuration:
>>> 
>>>  Platform:
>>>osname=darwin, osvers=10.6.0, archname=darwin-thread-multi-2level
>>>uname='darwin bbf-osx32.local 10.6.0 darwin kernel version 10.6.0: sun 
>>> jan 9 16:31:48 est 2011; legacy kernel v6 
>>> :xnu-1504.9.26buildobjrelease_i386 i386 '
>>>config_args='-D inc_version_list=5.12.2/darwin-thread-multi-2level 
>>> 5.12.2 5.12.1/darwin-thread-multi-2level 5.12.1 
>>> 5.12.0/darwin-thread-multi-2level 5.12.0 -Dusethreads -Duseshrplib -des 
>>> -Dprefix=/opt/local -Dscriptdir=/opt/local/bin 
>>> -Dcppflags=-I/opt/local/include -isysroot /Developer/SDKs/MacOSX10.5.sdk 
>>> -Dccflags=-pipe -O2 -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch i386 
>>> -Dldflags=-L/opt/local/lib -Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk 
>>> -arch i386 -Dvendorprefix=/opt/local -Dusemultiplicity=y -D 
>>> cc=/usr/bin/gcc-4.0 -D ld=/usr/bin/gcc-4.0 -D man1ext=1pm -D man3ext=3pm -D 
>>> man1dir=/opt/local/share/man/man1p -D man3dir=/opt/local/share/man/man3p -D 
>>> siteman1dir=/opt/local/share/man/man1 -D 
>>> siteman3dir=/opt/local/share/man/man3 -D 
>>> vendorman1dir=/opt/local/share/man/man1 -D 
>>> vendorman3dir=/opt/local/share/man/man3 -D pager=/usr/bin/less -sR'
>>>hint=recommended, useposix=true, d_sigaction=define
>>>useithreads=define, usemultiplicity=define
>>>useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
>>>use64bitint=undef, use64bitall=undef, uselongdouble=undef
>>>usemymalloc=n, bincompat5005=undef
>>>  Compiler:
>>>cc='/usr/bin/gcc-4.0', ccflags ='-pipe -O2 -isysroot 
>>> /Developer/SDKs/MacOSX10.5.sdk -arch i386 -fno-common -DPERL_DARWIN 
>>> -I/opt/local/include -isysroot /Developer/SDKs/MacOSX10.5.sdk 
>>> -no-cpp-precomp -fno-strict-aliasing -fstack-protector 
>>> -I/opt/local/include',
>>>optimize='-O3',
>>>cppflags='-I/opt/local/include -isysroot /Developer/SDKs/MacOSX10.5.sdk 
>>> -no-cpp-precomp -pipe -O2 -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch 
>>> i386 -fno-common -DPERL_DARWIN -I/opt/local/include -isysroot 
>>> /Developer/SDKs/MacOSX10.5.sdk -no-cpp-precomp -fno-strict-aliasing 
>>> -fstack-protector -I/opt/local/include'
>>>ccversion='', gccversion='4.0.1 (Apple Inc. build 5493)', gccosandvers=''
>>>intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
>>>d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
>>>ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
>>> lseeksize=8
>>>alignbytes=8, prototype=define
>>>  Linker and Libraries:
>>>ld='env MACOSX_DEPLOYMENT_TARGET=10.6 /usr/bin/gcc-4.0', ldflags 
>>> ='-L/opt/local/lib -Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -arch 
>>> i386 -fstack-protector'
>>>libpth=/opt/local/lib /usr/lib
>>>libs=-lgdbm -ldbm -ldl -lm -lutil -lc
>>>perllibs=-ldl -lm -lutil -lc
>>>libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, 
>>> libperl=libperl.dylib
>>>gnulibc_version=''
>>>  Dynamic Linking:
>>>dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
>>>cccdlflags=' ', lddlflags='-L/opt/local/lib 
>>> -Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -arch i386 -bundle 
>>> -undefined dynamic

Re: OSX problem packing for 10.5 on 10.6

[Mark Dootson]

Hi,

I'm pretty sure none of the binary components of your Perl can run on 
anything lower than 10.6 because of the  -fstack-protector flag 
introduced with Perl 5.12.


As an experiment, try a MacPort of 5.10 and I think all will work.

Regards

Mark

On 13/03/2011 12:55, Philip Kime wrote:

[bbf-osx32][~]>  perl -V
Summary of my perl5 (revision 5 version 12 subversion 3) configuration:

   Platform:
 osname=darwin, osvers=10.6.0, archname=darwin-thread-multi-2level
 uname='darwin bbf-osx32.local 10.6.0 darwin kernel version 10.6.0: sun jan 
9 16:31:48 est 2011; legacy kernel v6 :xnu-1504.9.26buildobjrelease_i386 i386 '
 config_args='-D inc_version_list=5.12.2/darwin-thread-multi-2level 5.12.2 
5.12.1/darwin-thread-multi-2level 5.12.1 5.12.0/darwin-thread-multi-2level 
5.12.0 -Dusethreads -Duseshrplib -des -Dprefix=/opt/local 
-Dscriptdir=/opt/local/bin -Dcppflags=-I/opt/local/include -isysroot 
/Developer/SDKs/MacOSX10.5.sdk -Dccflags=-pipe -O2 -isysroot 
/Developer/SDKs/MacOSX10.5.sdk -arch i386 -Dldflags=-L/opt/local/lib 
-Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -arch i386 
-Dvendorprefix=/opt/local -Dusemultiplicity=y -D cc=/usr/bin/gcc-4.0 -D 
ld=/usr/bin/gcc-4.0 -D man1ext=1pm -D man3ext=3pm -D 
man1dir=/opt/local/share/man/man1p -D man3dir=/opt/local/share/man/man3p -D 
siteman1dir=/opt/local/share/man/man1 -D siteman3dir=/opt/local/share/man/man3 
-D vendorman1dir=/opt/local/share/man/man1 -D 
vendorman3dir=/opt/local/share/man/man3 -D pager=/usr/bin/less -sR'
 hint=recommended, useposix=true, d_sigaction=define
 useithreads=define, usemultiplicity=define
 useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
 use64bitint=undef, use64bitall=undef, uselongdouble=undef
 usemymalloc=n, bincompat5005=undef
   Compiler:
 cc='/usr/bin/gcc-4.0', ccflags ='-pipe -O2 -isysroot 
/Developer/SDKs/MacOSX10.5.sdk -arch i386 -fno-common -DPERL_DARWIN 
-I/opt/local/include -isysroot /Developer/SDKs/MacOSX10.5.sdk -no-cpp-precomp 
-fno-strict-aliasing -fstack-protector -I/opt/local/include',
 optimize='-O3',
 cppflags='-I/opt/local/include -isysroot /Developer/SDKs/MacOSX10.5.sdk 
-no-cpp-precomp -pipe -O2 -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch i386 
-fno-common -DPERL_DARWIN -I/opt/local/include -isysroot 
/Developer/SDKs/MacOSX10.5.sdk -no-cpp-precomp -fno-strict-aliasing 
-fstack-protector -I/opt/local/include'
 ccversion='', gccversion='4.0.1 (Apple Inc. build 5493)', gccosandvers=''
 intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
 alignbytes=8, prototype=define
   Linker and Libraries:
 ld='env MACOSX_DEPLOYMENT_TARGET=10.6 /usr/bin/gcc-4.0', ldflags 
='-L/opt/local/lib -Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -arch i386 
-fstack-protector'
 libpth=/opt/local/lib /usr/lib
 libs=-lgdbm -ldbm -ldl -lm -lutil -lc
 perllibs=-ldl -lm -lutil -lc
 libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib
 gnulibc_version=''
   Dynamic Linking:
 dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
 cccdlflags=' ', lddlflags='-L/opt/local/lib 
-Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -arch i386 -bundle -undefined 
dynamic_lookup -fstack-protector'


Characteristics of this binary (from libperl):
   Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
 PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_ITHREADS
 USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF
 USE_REENTRANT_API
   Built under darwin
   Compiled at Mar 11 2011 22:30:02
   @INC:
 /opt/local/lib/perl5/site_perl/5.12.3/darwin-thread-multi-2level
 /opt/local/lib/perl5/site_perl/5.12.3
 /opt/local/lib/perl5/vendor_perl/5.12.3/darwin-thread-multi-2level
 /opt/local/lib/perl5/vendor_perl/5.12.3
 /opt/local/lib/perl5/5.12.3/darwin-thread-multi-2level
 /opt/local/lib/perl5/5.12.3
 /opt/local/lib/perl5/site_perl
 /opt/local/lib/perl5/vendor_perl




[bbf-osx32][~]>  otool -L /opt/local/bin/perl
/opt/local/bin/perl:

/opt/local/lib/perl5/5.12.3/darwin-thread-multi-2level/CORE/libperl.dylib 
(compatibility version 5.12.0, current version 5.12.3)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 111.1.4)
/usr/lib/libutil.dylib (compatibility version 1.0.0, current version 
1.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
1.0.0)



On 13 Mar 2011, at 1:53 PM, Mark Dootson wrote:


Hi,

What's your output from perl -V and  otool -L path/to/bin/perl



On 13/03/2011 12:

Re: OSX problem packing for 10.5 on 10.6

[Mark Dootson]

Hi,

What's your output from perl -V and  otool -L path/to/bin/perl



On 13/03/2011 12:46, Philip Kime wrote:

Greetings,
   I have to package an application for OSX 10.5 32-bit on a 64-bit OSX 10.6 
box. I am using macports for all of the software and have set this to use only 
the 10.5 SDK and 32-bit compilation which all works fine. This works as 
macports sets some compile flags to point to the 10.5 SDK for all compiles. 
perl is compiled like this and so all perl modules get the same flags and every 
piece of the stuff to package is 10.5 compliant. However, when I come to pack 
with pp, it doesn't seem to use the flags which perl was compiled with to 
create the binary and so the executable dies on 10.5 with the famous:


dyld: unknown required load command 0x8022
Trace/BPT trap


which is a known problem trying to run 10.6 compiled binaries on 10.5. This 
should work however if you compile for 32-bit only and also force the 10.5 SDK, 
which is what I have done. pp doesn't seem to understand this though and the 
resulting binary fails on 10.5. Since I'm not sure how pp prepares its binary, 
I am wondering if I can add flags to the compiler step or something similar to 
force it to use the 10.5 SDK so that the 10.6-specific features which cause 
this problem can be avoided?

PK

--
Dr Philip Kime

Re: Running with elevated privileges on Windows

[Mark Dootson]

Hi,

I have it on my 'todo' list to add 'Win32::Exe::PP' to the Win32::Exe dist.

What i think it will do is:

Split the PAR exec into 3 parts - exec stub, binary extract (libperl 
etc) and the appended zip.


extract the 'second' executable from zip.

Carry out all Win32::Exe operations on both the exec stub and the 
'second' exe.


Win32::Exe::PP->write;

will join everything up again.

So then,

my $exe = Win32::Exe::PP->new('c:\\path\\to-par-exec.exe');
my $manifest = $exe->get_manifest;
$manifest->set_execution_level('requireAdministrator');
$exe->set_manifest($manifest);
$exe->write;

would do what you want.

But ..

I have not looked at PAR::Packer internals for quite some time, so the 
assumption that a pp exec is constructed in the three parts above may be 
wrong.



Regards

Mark

















On 10/02/2011 18:56, Michael Carman wrote:

There's a question on Stack Overflow
[http://stackoverflow.com/questions/4441767] about running a
PAR-packed application with elevated privileges. Since it hasn't
received any answers I'm forwarding it here:


Does anyone know how to make a PAR packed Perl application run with higher 
privileges?
I've read that there must be somewhere some kind of manifest file, but how 
should this file
look like and how to combine it with the PAR packed executable? This is still 
unknown to me.


If you have a SO account feel free to answer there. If not, I'll post
anything useful that comes out of this thread.

-mjc

Problems compiling Win32::Exe on Windows XP with mingw

[Mark Dootson]

Hi,

Just a 'heads up' to the list for Win32::Exe compilation problems using 
MinGW / gcc 3.4.5 toolchain on Windows XP. It appears there's an issue, 
probably with dlltool, on that combination.


See http://rt.cpan.org/Ticket/Display.html?id=63685

for full details.

In short, if you see an "Invalid access to memory location" error

# Failed test 'use Win32::Exe::InsertResourceSection;'
# at t/0-load.t line 6.
t/0-load.t ... 1/1 # Tried to use 'Win32::Exe::InsertResourceSection'.
# Error: Can't load 'C:\perl\cpan\build\Win32-Exe-0.15-OufTVO\blib\arch/aut
o/Win32/Exe/InsertResourceSection/InsertResourceSection.dll' for module
Win32::E
xe::InsertResourceSection: load_file:Invalid access to memory location
at C:/per
l/lib/DynaLoader.pm line 201.
# at (eval 4) line 2


then it is probably the same issue. I'm a bit surprised I can't find 
much more evidence of the issue affecting other modules - as it most 
certainly does. Perhaps I'm looking in the wrong places?


Anyway, hope this will help someone else who suffers the same failure.

Regards

Mark

Re: Problem whit PP

[Mark Dootson]

Hi,

Could you tell me how you installed Win32::Exe ?

Best regards

Mark


On 03/07/2010 09:11, Zico Zicaus wrote:


Hi,

thanks for answer, now i get different problem:

C:\Perl\produzi\Annulli_Tecnici>exe_update.pl --info Comments=ciao 
Annulli_Tecnici.exe
Can't
load
'C:/Perl/site/lib/auto/Win32/Exe/InsertResourceSection/InsertResourceSection.dll'
for module Win32::Exe::InsertResourceSection: load_file:Invalid
access to memory location at C:/Perl/site/lib/XSLoader.pm line 70.
  at C:/Perl/site/lib/Win32/Exe/InsertResourceSection.pm line 29
Compilation failed in require at C:/Perl/site/lib/Win32/Exe.pm line 332.


Mybe
must add some to my .pl file first of compiled and when loaunch the
command exe_update.pl --info Comments=ciao Annulli_Tecnici.exe ?
How can i resolve this problem?

Thanks

Best regards

From: zicozic...@hotmail.com
To: par@perl.org
Subject: RE: Problem whit PP
Date: Thu, 1 Jul 2010 15:44:54 +








Hi,



i have try to registration to web site, but i get occured the follow message 
error:



Si è verificato un problema nella sessione che identifica l'accesso; il sistema 
non ha eseguito il comando impartito per precauzione. Tornare alla pagina 
precedente con il tasto 'Indietro' del proprio browser, ricaricare la pagina e 
riprovare.



How can i do for registration?



Thanks



By Simone











From: zicozic...@hotmail.com
To: par@perl.org
Subject: Problem whit PP
Date: Thu, 1 Jul 2010 15:32:01 +



Hi,

i have problem whit use pp, when i try to compiled source .pl in .ex this is 
ok, but when i launch the command for add information on file exe, i get error:

C:\Perl\produzi\Annulli_Tecnici\bin>pp -N Comments=ciao -o Annulli_Tecnici.exe 
Annulli_Tecnici.pl
Set up gcc environment - 3.4.5 (mingw-vista special r3)
Set up gcc environment - 3.4.5 (mingw-vista special r3)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

No resource section found in file parlMveo.exe at C:/Perl/site/lib/Win32/Exe.pm 
line 348.
No resource section found in file parlMveo.exe at C:/Perl/site/lib/Win32/Exe.pm 
line 348.
Access is denied.

The version pp is 1.006
When i must try to do the test whit pp i get this:

C:\Perl\PAR-Packer-1.006\PAR-Packer-1.006>dmake test
C:\Perl\bin\perl.exe -e "chmod(oct('0600'), 
'..\blib\lib\PAR\StrippedPARL\Static.pm');"
C:\Perl\bin\perl.exe encode_append.pl static.exe 
..\blib\lib\PAR\StrippedPARL\Static.pm
C:\Perl\bin\perl.exe -e "chmod(oct('0444'), 
'..\blib\lib\PAR\StrippedPARL\Static.pm');"
C:\Perl\bin\perl.exe -e "chmod(oct('0600'), 
'..\blib\lib\PAR\StrippedPARL\Dynamic.pm');"
C:\Perl\bin\perl.exe encode_append.pl par.exe 
..\blib\lib\PAR\StrippedPARL\Dynamic.pm
C:\Perl\bin\perl.exe -e "chmod(oct('0444'), 
'..\blib\lib\PAR\StrippedPARL\Dynamic.pm');"
C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'inc', 
'blib\lib', 'blib\arch')" t/00-pod.t t/10-parl-generation.t  t/20-pp.t t/30-current_
exec.t t/40-packer_cd_option.t
t/00-pod.t ... skipped: Set environment variable PERL_TEST_POD=1 to 
test POD
t/10-parl-generation.t ... ok
t/20-pp.t  31/34 No resource section found in file parltde9.exe 
at C:/Perl/site/lib/Win32/Exe.pm line 348.
No resource section found in file parltde9.exe at C:/Perl/site/lib/Win32/Exe.pm 
line 348.
Can't call method "remove" on an undefined value at 
C:/Perl/site/lib/Win32/Exe.pm line 473.
#   Failed test 'pp_gui_tests
# amsg572: sub pp_gui_tests cannot system pp --gui --icon hi.ico -o hello.exe 
hello.pl:No such file or directory:
# '
#   at automated_pp_test.pl line 8445.
t/20-pp.t  34/34 # Looks like you failed 1 test of 34.
t/20-pp.t  Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/34 subtests
t/30-current_exec.t .. # Please wait
t/30-current_exec.t .. ok
t/40-packer_cd_option.t .. ok
Test Summary Report
---
t/20-pp.t  (Wstat: 256 Tests: 34 Failed: 1)
   Failed test:  32
   Non-zero exit status: 1
Files=5, Tests=71, 1797 wallclock secs ( 0.13 usr +  0.19 sys =  0.31 CPU)
Result: FAIL
Failed 1/5 test programs. 1/71 subtests failed.
dmake.exe:  Error code 255, while making 'test_dynamic'

How can i do for resolve this problem?

Thanks a lot

Best regards

Simone



Non sei a casa? Accedi a Messenger dal Web. 
10 buoni motivi per scegliere   Hotmail 
Personalizza il tuo Messenger con nuove e divertenti emoticon   

_
Il tuo mondo MSN a portata di clic. Scarica IE8 per MSN
http://events.it.msn.com/internet-explorer-8

Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll

[Mark Dootson via RT]

Sun May 30 08:20:47 2010: Request 57948 was acted upon.
Transaction: Correspondence added by mark.doot...@znix.com
   Queue: PAR-Packer
 Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and 
a missing dependency libgcc_s_sjlj-1.dll
   Broken in: (no value)
Severity: (no value)
   Owner: RSCHUPP
  Requestors: m...@iki.fi
  Status: open
 Ticket https://rt.cpan.org/Ticket/Display.html?id=57948 >


Hi,

On 29/05/2010 17:55, RSCHUPP via RT wrote:

>
> So I see two possible options:
> - stick with a dynamically linked custom Perl and
>modify (conditionally for Strawberry only) the whole
>load_me_* shebang in myldr and add a load_me_3 file that
>would contain libgcc_s_*.dll (which would get extracted
>alongside par.exe and perl512.dll)
> - link the custom Perl statically, then the whole second
>bootstrap phase is omitted and the problem goes away
>
> I definitely don't want to touch the load_me stuff with a
> ten-foot pole, so I experimented with the latter option.
> However, even after tweaking myldr/Makefile by hand I
> couldn't produce a par.exe there that was NOT dynamically
> linked against perl512.dll.
>
> @Mark: Do you know why even
>
> g++ main.o my_par_pl.o  -Wl,-Bstatic -Lc:\strawberry\perl\lib\CORE
> -lperl512 -o par.exe
>
> generates par.exe with a reference to perl512.dll?
>
> Cheers, Roderich
>

I'm not absolutely certain of the total effect of passing -static to ld 
on windows. For '-lperl512' what matters is what is contained in 
perl512.lib or libperl512.a.

I don't think you can mix and match your linking model on Windows. So if 
you had a static perl.exe (or par.exe) you could not then load separate 
xs code dynamically - you would have to compile in all the xs modules 
you require. That's why, by default, you don't get a static perl built 
on MSWin. It is not generally useful.

In a dynamic perl, all the xs dll's are dynamically linked to 
perl512.dll. You can't mix and match static / dynamic linking.

You have to add a load_me_3 file or some windows specific function that 
does the same thing, I'm afraid.


Regards

Mark

Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll

[Mark Dootson]

Hi,

On 29/05/2010 17:55, RSCHUPP via RT wrote:



So I see two possible options:
- stick with a dynamically linked custom Perl and
   modify (conditionally for Strawberry only) the whole
   load_me_* shebang in myldr and add a load_me_3 file that
   would contain libgcc_s_*.dll (which would get extracted
   alongside par.exe and perl512.dll)
- link the custom Perl statically, then the whole second
   bootstrap phase is omitted and the problem goes away

I definitely don't want to touch the load_me stuff with a
ten-foot pole, so I experimented with the latter option.
However, even after tweaking myldr/Makefile by hand I
couldn't produce a par.exe there that was NOT dynamically
linked against perl512.dll.

@Mark: Do you know why even

g++ main.o my_par_pl.o  -Wl,-Bstatic -Lc:\strawberry\perl\lib\CORE
-lperl512 -o par.exe

generates par.exe with a reference to perl512.dll?

Cheers, Roderich



I'm not absolutely certain of the total effect of passing -static to ld 
on windows. For '-lperl512' what matters is what is contained in 
perl512.lib or libperl512.a.


I don't think you can mix and match your linking model on Windows. So if 
you had a static perl.exe (or par.exe) you could not then load separate 
xs code dynamically - you would have to compile in all the xs modules 
you require. That's why, by default, you don't get a static perl built 
on MSWin. It is not generally useful.


In a dynamic perl, all the xs dll's are dynamically linked to 
perl512.dll. You can't mix and match static / dynamic linking.


You have to add a load_me_3 file or some windows specific function that 
does the same thing, I'm afraid.



Regards

Mark

Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll

[Mark Dootson via RT]

Sat May 29 09:03:30 2010: Request 57948 was acted upon.
Transaction: Correspondence added by mark.doot...@znix.com
   Queue: PAR-Packer
 Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and 
a missing dependency libgcc_s_sjlj-1.dll
   Broken in: (no value)
Severity: (no value)
   Owner: RSCHUPP
  Requestors: m...@iki.fi
  Status: open
 Ticket https://rt.cpan.org/Ticket/Display.html?id=57948 >


Hi,

perl5xx.dll depends on libgcc_s_sjlj-1.dll, so libgcc_s_sjlj-1.dll needs 
to be packed with, and extracted with perl5xx.dll before any Perl code 
is run at all.

Cheers

Mark

On 28/05/2010 20:49, mjk via RT wrote:
> Fri May 28 15:49:57 2010: Request 57948 was acted upon.
> Transaction: Correspondence added by m...@iki.fi
> Queue: PAR-Packer
>   Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable 
> and a missing dependency libgcc_s_sjlj-1.dll
> Broken in: (no value)
>  Severity: (no value)
> Owner: RSCHUPP
>Requestors: m...@iki.fi
>Status: open
>   Tickethttp://rt.cpan.org/Ticket/Display.html?id=57948>
>
>
>>
>> Known problem, buried deep in #57272.
>>
>> Can you please try the patch attached to
>> https://rt.cpan.org/Ticket/Display.html?id=57272#txn-776549
>>
>> Note that you must rebuild PAR::Packer with this patch, install it
>> and then repack your script to test the fix.
>>
>
> I tried the patch mentioned above. The problem still exists. The end
> result of the pp still depends on the libgcc_s_sjlj-1.dll. My guess is
> that including this library inside the packed script does not help
> because the executable for some reason requires the DLL at pretty
> early stage of the execution. So, the DLL inside the packed script has
> no effect in this case.
>
> If I have time, I have to investigate, what the PAR::Packer is doing
> while compiling the stub. I imagine that it should be possible to
> compile the stub in such way that this DLL is not needed when the stub
> part of the package is executing.
>
>
> -Matti
>
>
>

Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll

[Mark Dootson]

Hi,

perl5xx.dll depends on libgcc_s_sjlj-1.dll, so libgcc_s_sjlj-1.dll needs 
to be packed with, and extracted with perl5xx.dll before any Perl code 
is run at all.


Cheers

Mark

On 28/05/2010 20:49, mjk via RT wrote:

Fri May 28 15:49:57 2010: Request 57948 was acted upon.
Transaction: Correspondence added by m...@iki.fi
Queue: PAR-Packer
  Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and 
a missing dependency libgcc_s_sjlj-1.dll
Broken in: (no value)
 Severity: (no value)
Owner: RSCHUPP
   Requestors: m...@iki.fi
   Status: open
  Tickethttp://rt.cpan.org/Ticket/Display.html?id=57948>




Known problem, buried deep in #57272.

Can you please try the patch attached to
https://rt.cpan.org/Ticket/Display.html?id=57272#txn-776549

Note that you must rebuild PAR::Packer with this patch, install it
and then repack your script to test the fix.



I tried the patch mentioned above. The problem still exists. The end
result of the pp still depends on the libgcc_s_sjlj-1.dll. My guess is
that including this library inside the packed script does not help
because the executable for some reason requires the DLL at pretty
early stage of the execution. So, the DLL inside the packed script has
no effect in this case.

If I have time, I have to investigate, what the PAR::Packer is doing
while compiling the stub. I imagine that it should be possible to
compile the stub in such way that this DLL is not needed when the stub
part of the package is executing.


-Matti

Re: PAR::Packer .par binaries

[Mark Dootson]

Hi,

I think you can drop the binaries.
You might also want to drop the Win32.obj / Win32.coff files. I think 
you will need to retain the Win32.res file. I can never seem to get 
'windres' on any flavour of mingw to compile from a .rc file - but that 
could just be me and my rc files.
However, I found from my work on Win32::Exe that the .res files are not 
processor or compiler specific. So, for mingw


windres -o winrc.coff Win32.res

for msvc

cvtres Win32.res winrc.obj

will work for both x86 and x64 targets.

Sorry, I don't have time to test a patch properly - especially against 
various modern MSVC compiler versions. However, I'd be happy to test 
changes against MinGW, mingw-w64, VC6 and VC7 for x64 if that helps 
someone else incorporate this in a release.


Regards

Mark



On 03/05/2010 16:55, Steffen Mueller wrote:

Dear PAR users,

for the past few PAR::Packer releases, we haven't bothered to upload new
.par binaries for those win32 developers without a compiler.

Now, to the best of my knowledge, there are three major win32 Perl
distributions:

- ActivePerl
- Strawberry Perl
- cygwin's perl

cygwin and Strawberry come with C compilers and should be able to
install PAR::Packer directly from CPAN. ActivePerl users can get a MinGW
installation from PPM with a single command (citation needed).

Do we still need the .par binaries on CPAN? They mean that somebody
other than me has to compile then on win32, send them to me, and I
upload them to my CPAN directory because the mechanism used by
PAR::Packer searches one author directory only.

I believe we can drop the binaries since with PAR::Packer, we are
targeting developers, not end-users.

What do you think? Users of the .par binaries, speak up!

Cheers,
Steffen

Re: [rt.cpan.org #57272] Error building on Strawberry 5.12.0.1 32-bit (can't find script/parl.exe)

[Mark Dootson via RT]

Fri May 07 17:34:10 2010: Request 57272 was acted upon.
Transaction: Correspondence added by mark.doot...@znix.com
   Queue: PAR-Packer
 Subject: Re: [rt.cpan.org #57272] Error building on Strawberry 5.12.0.1 
32-bit (can't find  script/parl.exe)
   Broken in: (no value)
Severity: Important
   Owner: RSCHUPP
  Requestors: csjew...@cpan.org
  Status: new
 Ticket https://rt.cpan.org/Ticket/Display.html?id=57272 >


Hi,

Just a thought, but I get this error on ActivePerl due to Norton 
AntiVirus. With NAV switched off, it works for me. Could be your 
AntiVirus prog?

Mark

On 07/05/2010 02:42, Curtis Jewell via RT wrote:
> Thu May 06 21:42:10 2010: Request 57272 was acted upon.
> Transaction: Ticket created by CSJEWELL
> Queue: PAR-Packer
>   Subject: Error building on Strawberry 5.12.0.1 32-bit (can't find
>   script/parl.exe)
> Broken in: (no value)
>  Severity: Important
> Owner: Nobody
>Requestors: csjew...@cpan.org
>Status: new
>   Tickethttps://rt.cpan.org/Ticket/Display.html?id=57272>
>
>
> Reporting a build error - what can I do to help you fix this?
>
>CPAN.pm: Going to build R/RS/RSCHUPP/PAR-Packer-1.004.tar.gz
>
> cp lib/App/Packer/PAR.pm blib\lib\App\Packer\PAR.pm
> cp lib/PAR/Packer.pm blib\lib\PAR\Packer.pm
> cp lib/PAR/Filter/Obfuscate.pm blib\lib\PAR\Filter\Obfuscate.pm
> cp lib/PAR/Filter/PodStrip.pm blib\lib\PAR\Filter\PodStrip.pm
> cp lib/PAR/StrippedPARL/Base.pm blib\lib\PAR\StrippedPARL\Base.pm
> cp lib/PAR/Filter.pm blib\lib\PAR\Filter.pm
> cp lib/PAR/Filter/PatchContent.pm blib\lib\PAR\Filter\PatchContent.pm
> cp lib/PAR/StrippedPARL/Dynamic.pm blib\lib\PAR\StrippedPARL\Dynamic.pm
> cp lib/PAR/Filter/Bytecode.pm blib\lib\PAR\Filter\Bytecode.pm
> cp lib/pp.pm blib\lib\pp.pm
> cp lib/PAR/Filter/Bleach.pm blib\lib\PAR\Filter\Bleach.pm
> cp lib/PAR/StrippedPARL/Static.pm blib\lib\PAR\StrippedPARL\Static.pm
> C:\strawberry\perl\bin\perl.exe sha1.c.PL sha1.c
> gcc -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT  -DUSE_SITECUSTOMIZE
> -DPERL_IMPLICIT_CON
> TEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields
> -DPERL_MSVCRT_READF
> IX  -I"C:\strawberry\perl\lib\CORE"  -DPARL_EXE=\"parl.exe\" -s -O2 sha1.c
> C:\strawberry\perl\bin\perl.exe file2c.pl
> C:\strawberry\perl\bin\perl512.dll my_
> perl.c load_me_0 1 3
> dmake:  Warning: -- Found file corresponding to virtual target [mktmpdir.h].
> dmake:  Warning: -- Found file corresponding to virtual target [mktmpdir.c].
> dmake:  Warning: -- Found file corresponding to virtual target [main.c].
> gcc -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT  -DUSE_SITECUSTOMIZE
> -DPERL_IMPLICIT_CON
> TEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields
> -DPERL_MSVCRT_READF
> IX  -I"C:\strawberry\perl\lib\CORE"  -DPARL_EXE=\"parl.exe\" -s -O2 main.c
> C:\strawberry\perl\bin\perl.exe file2c.pl ..\script\par.pl my_par_pl.c
> load_me_2
>   1
> gcc -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT  -DUSE_SITECUSTOMIZE
> -DPERL_IMPLICIT_CON
> TEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields
> -DPERL_MSVCRT_READF
> IX  -I"C:\strawberry\perl\lib\CORE"  -DPARL_EXE=\"parl.exe\" -s -O2
> my_par_pl.c
> g++ main.o my_par_pl.o win32.coff -s   -s
> -L"C:\strawberry\perl\lib\CORE" -L"C:\
> strawberry\c\lib"  C:\strawberry\perl\lib\CORE\libperl512.a
> C:\strawberry\c\i686
> -w64-mingw32\lib\libmoldname.a
> C:\strawberry\c\i686-w64-mingw32\lib\libkernel32.
> a C:\strawberry\c\i686-w64-mingw32\lib\libuser32.a
> C:\strawberry\c\i686-w64-ming
> w32\lib\libgdi32.a C:\strawberry\c\i686-w64-mingw32\lib\libwinspool.a
> C:\strawbe
> rry\c\i686-w64-mingw32\lib\libcomdlg32.a
> C:\strawberry\c\i686-w64-mingw32\lib\li
> badvapi32.a C:\strawberry\c\i686-w64-mingw32\lib\libshell32.a
> C:\strawberry\c\i6
> 86-w64-mingw32\lib\libole32.a
> C:\strawberry\c\i686-w64-mingw32\lib\liboleaut32.a
>   C:\strawberry\c\i686-w64-mingw32\lib\libnetapi32.a
> C:\strawberry\c\i686-w64-min
> gw32\lib\libuuid.a C:\strawberry\c\i686-w64-mingw32\lib\libws2_32.a
> C:\strawberr
> y\c\i686-w64-mingw32\lib\libmpr.a
> C:\strawberry\c\i686-w64-mingw32\lib\libwinmm.
> a C:\strawberry\c\i686-w64-mingw32\lib\libversion.a
> C:\strawberry\c\i686-w64-min
> gw32\lib\libodbc32.a C:\strawberry\c\i686-w64-mingw32\lib\libodbccp32.a
> C:\straw
> berry\c\i686-w64-mingw32\lib\libcomctl32.a -o par.exe
> C:\strawberry\perl\bin\perl.exe -e1
> C:\strawberry\perl\bin\perl.exe file2c.pl par.exe my_par.c load_me_1 1 3
> gcc -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT  -DUSE_SITECUSTOMIZE
> -DPERL_IMPLICIT_CON
> TEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields
> -DPERL_MSVCRT_READF
> IX  -I"C:\strawberry\perl\lib\CORE"  -DPARL_EXE=\"parl.exe\" -s -O2 static.c
> static.c: In function 'main':
> static.c:106: warning: passing argument 3 of 'spawnvpe' from
> incompatible pointe
> r type
> c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/../../../../i686-w64-mingw
> 32/include/process.h:169: note: expected 'char * const*' but argument is
> of type
>   'const char * const*

Re: [rt.cpan.org #57272] Error building on Strawberry 5.12.0.1 32-bit (can't find script/parl.exe)

[Mark Dootson]

Hi,

Just a thought, but I get this error on ActivePerl due to Norton 
AntiVirus. With NAV switched off, it works for me. Could be your 
AntiVirus prog?


Mark

On 07/05/2010 02:42, Curtis Jewell via RT wrote:

Thu May 06 21:42:10 2010: Request 57272 was acted upon.
Transaction: Ticket created by CSJEWELL
Queue: PAR-Packer
  Subject: Error building on Strawberry 5.12.0.1 32-bit (can't find
  script/parl.exe)
Broken in: (no value)
 Severity: Important
Owner: Nobody
   Requestors: csjew...@cpan.org
   Status: new
  Tickethttps://rt.cpan.org/Ticket/Display.html?id=57272>


Reporting a build error - what can I do to help you fix this?

   CPAN.pm: Going to build R/RS/RSCHUPP/PAR-Packer-1.004.tar.gz

cp lib/App/Packer/PAR.pm blib\lib\App\Packer\PAR.pm
cp lib/PAR/Packer.pm blib\lib\PAR\Packer.pm
cp lib/PAR/Filter/Obfuscate.pm blib\lib\PAR\Filter\Obfuscate.pm
cp lib/PAR/Filter/PodStrip.pm blib\lib\PAR\Filter\PodStrip.pm
cp lib/PAR/StrippedPARL/Base.pm blib\lib\PAR\StrippedPARL\Base.pm
cp lib/PAR/Filter.pm blib\lib\PAR\Filter.pm
cp lib/PAR/Filter/PatchContent.pm blib\lib\PAR\Filter\PatchContent.pm
cp lib/PAR/StrippedPARL/Dynamic.pm blib\lib\PAR\StrippedPARL\Dynamic.pm
cp lib/PAR/Filter/Bytecode.pm blib\lib\PAR\Filter\Bytecode.pm
cp lib/pp.pm blib\lib\pp.pm
cp lib/PAR/Filter/Bleach.pm blib\lib\PAR\Filter\Bleach.pm
cp lib/PAR/StrippedPARL/Static.pm blib\lib\PAR\StrippedPARL\Static.pm
C:\strawberry\perl\bin\perl.exe sha1.c.PL sha1.c
gcc -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT  -DUSE_SITECUSTOMIZE
-DPERL_IMPLICIT_CON
TEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields
-DPERL_MSVCRT_READF
IX  -I"C:\strawberry\perl\lib\CORE"  -DPARL_EXE=\"parl.exe\" -s -O2 sha1.c
C:\strawberry\perl\bin\perl.exe file2c.pl
C:\strawberry\perl\bin\perl512.dll my_
perl.c load_me_0 1 3
dmake:  Warning: -- Found file corresponding to virtual target [mktmpdir.h].
dmake:  Warning: -- Found file corresponding to virtual target [mktmpdir.c].
dmake:  Warning: -- Found file corresponding to virtual target [main.c].
gcc -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT  -DUSE_SITECUSTOMIZE
-DPERL_IMPLICIT_CON
TEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields
-DPERL_MSVCRT_READF
IX  -I"C:\strawberry\perl\lib\CORE"  -DPARL_EXE=\"parl.exe\" -s -O2 main.c
C:\strawberry\perl\bin\perl.exe file2c.pl ..\script\par.pl my_par_pl.c
load_me_2
  1
gcc -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT  -DUSE_SITECUSTOMIZE
-DPERL_IMPLICIT_CON
TEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields
-DPERL_MSVCRT_READF
IX  -I"C:\strawberry\perl\lib\CORE"  -DPARL_EXE=\"parl.exe\" -s -O2
my_par_pl.c
g++ main.o my_par_pl.o win32.coff -s   -s
-L"C:\strawberry\perl\lib\CORE" -L"C:\
strawberry\c\lib"  C:\strawberry\perl\lib\CORE\libperl512.a
C:\strawberry\c\i686
-w64-mingw32\lib\libmoldname.a
C:\strawberry\c\i686-w64-mingw32\lib\libkernel32.
a C:\strawberry\c\i686-w64-mingw32\lib\libuser32.a
C:\strawberry\c\i686-w64-ming
w32\lib\libgdi32.a C:\strawberry\c\i686-w64-mingw32\lib\libwinspool.a
C:\strawbe
rry\c\i686-w64-mingw32\lib\libcomdlg32.a
C:\strawberry\c\i686-w64-mingw32\lib\li
badvapi32.a C:\strawberry\c\i686-w64-mingw32\lib\libshell32.a
C:\strawberry\c\i6
86-w64-mingw32\lib\libole32.a
C:\strawberry\c\i686-w64-mingw32\lib\liboleaut32.a
  C:\strawberry\c\i686-w64-mingw32\lib\libnetapi32.a
C:\strawberry\c\i686-w64-min
gw32\lib\libuuid.a C:\strawberry\c\i686-w64-mingw32\lib\libws2_32.a
C:\strawberr
y\c\i686-w64-mingw32\lib\libmpr.a
C:\strawberry\c\i686-w64-mingw32\lib\libwinmm.
a C:\strawberry\c\i686-w64-mingw32\lib\libversion.a
C:\strawberry\c\i686-w64-min
gw32\lib\libodbc32.a C:\strawberry\c\i686-w64-mingw32\lib\libodbccp32.a
C:\straw
berry\c\i686-w64-mingw32\lib\libcomctl32.a -o par.exe
C:\strawberry\perl\bin\perl.exe -e1
C:\strawberry\perl\bin\perl.exe file2c.pl par.exe my_par.c load_me_1 1 3
gcc -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT  -DUSE_SITECUSTOMIZE
-DPERL_IMPLICIT_CON
TEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields
-DPERL_MSVCRT_READF
IX  -I"C:\strawberry\perl\lib\CORE"  -DPARL_EXE=\"parl.exe\" -s -O2 static.c
static.c: In function 'main':
static.c:106: warning: passing argument 3 of 'spawnvpe' from
incompatible pointe
r type
c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/../../../../i686-w64-mingw
32/include/process.h:169: note: expected 'char * const*' but argument is
of type
  'const char * const*'
static.c:106: warning: passing argument 4 of 'spawnvpe' from
incompatible pointe
r type
c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/../../../../i686-w64-mingw
32/include/process.h:169: note: expected 'char * const*' but argument is
of type
  'const char * const*'
g++ static.o -s   -s -L"C:\strawberry\perl\lib\CORE"
-L"C:\strawberry\c\lib"  C:
\strawberry\perl\lib\CORE\libperl512.a
C:\strawberry\c\i686-w64-mingw32\lib\libm
oldname.a C:\strawberry\c\i686-w64-mingw32\lib\libkernel32.a
C:\strawberry\c\i68
6-w64-mingw32\lib\libuser32.a
C:\strawberry\c\i686-w64-mingw32\lib\libgdi32.a C:
\strawberry\c\i686-w64-m

Win32::Exe 0.14

[Mark Dootson]

Hi,

Win32::Exe 0.14 is uploaded to CPAN

Important additions are:

Can now add a resource section to a file that has none IF running on a 
MSWin platform.

Can now specify manifest arguments as an argument list.
Supports multiple GROUP_ICONs in an executable with methods for adding, 
replacing and removing group icons.


For example:

my $exe = Win32::Exe->new(myexec.exe);
$exe = $exe->create_resource_section;
$exe->update( manifestargs => [ 'ExecLevel=asInvoker', 
'CommonControls=1' ] );



will create a resource section with default version info ONLY if none 
exists.
Will make requiredExecutionLevel 'asInvoker' in any existing manifest, 
OR add a manifest if none exists. Will ensure that manifest contains 
dependency information for common controls v 6.0.0.0.


This should make it possible to stop providing pre-compiled resource 
objects with the PAR::Packer distribution. When resources are added 
post-compile, if the compiler has already embedded a manifest and or 
version info, the commands will just merge provided info with existing 
structures.


Hope this is useful.


Mark

Re: Win32::Exe development release

[Mark Dootson]

Hi,
Another dev release

http://cpan.perl.org/CPAN/authors/id/M/MD/MDOOTSON/Win32-Exe-0.12_03.tar.gz

is uploaded to CPAN.

Enhancements - I did what I should have done first, and read the 
Win32::Exe bug list - where a patch had already been posted re PE+ 64bit 
handling. That patch could handle 64bit images in 32 bit Perl as it 
treats some Quad addresses as pack format 'a8'.


So - re-read PE file spec, had a think, and decided Parse::Binary never 
uses or interprets the addresses unpacked / packed as 'a8', so this 
would work fine. Therefore, 32bit Perl can now modify 64 bit PE images.


Have tested across several versions of Windows. Test also passed on 
Linux and MacOSX.  Have tested executables modified with Win32::Exe on 
'alien' OS's ( Linux and big-endian powerpc Mac ) and all seems well 
with them.


So if I don't get bad test reports, I'll put this out as version 0.12 of 
Win32::Exe in one week.


Regards

Mark



On 23/04/2010 04:16, Mark Dootson wrote:

Hi,

A development release of Win32::Exe has been posted to CPAN

http://cpan.perl.org/CPAN/authors/id/M/MD/MDOOTSON/Win32-Exe-0.12_01.tar.gz

Important changes are

* Added support for 64 bit executables
* Fixed long standing bug with manifests on Perl >= 5.10
* Added many convenience methods for manifest handling - you no longer
have to pass raw manifest xml.

Methods such as
$manifest->set_execution_level
$manifest->set_compatibility
$manifest->set_dpiaware

should produce correct namespace etc in the manifests.
See POD for Win32::Exe::Manifest

Currently, 64 bit executables are only editable on 64 bit platforms.

Any reports of successful / none successful use would be most welcome.

Regards

Mark

Win32::Exe development release

[Mark Dootson]

Hi,

A development release of Win32::Exe has been posted to CPAN

http://cpan.perl.org/CPAN/authors/id/M/MD/MDOOTSON/Win32-Exe-0.12_01.tar.gz

Important changes are

* Added support for 64 bit executables
* Fixed long standing bug with manifests on Perl >= 5.10
* Added many convenience methods for manifest handling - you no longer 
have to pass raw manifest xml.


Methods such as
$manifest->set_execution_level
$manifest->set_compatibility
$manifest->set_dpiaware

should produce correct namespace etc in the manifests.
See POD for Win32::Exe::Manifest

Currently, 64 bit executables are only editable on 64 bit platforms.

Any reports of successful / none successful use would be most welcome.

Regards

Mark

Re: wxbase26_gcc_custom.dll was not found

[Mark Dootson]

Hi,

Is there any reason you are running with Wx version 0.26? Current CPAN 
version is 0.9701.


Wx::Perl::Packager does not work with Wx version 0.26. I don't think you 
will be able to package with pp using this version.


Current PPMs for Wx are available from http://www.wxperl.co.uk or from 
ActiveState's own repository.


Regards

Mark

On 20/04/2010 21:55, Edwin Kraus wrote:

Hi Everybody,
I am trying to get a perl script packaged that uses the WxPerl libraries,
and I am running into a problem when I try to run the .exe that was created
with PAR. I must add that I am new at the the whole business of using a GUI
with a perl script and packaging a perl script for stand alone use.
Anyway this is what I ran into and hope that somebody can tell me what I am
doing wrong.
When I run the exe a dialog box pops up with the following error message:
Error:
This application has failed to start because wxbase26_gcc_custom.dll was not
found.
Re-installing this application may fix this problem.

I looked inside the exe with winzip and can see that the dll
(wxbase26_gcc_custom.dll)
that can't be found, is in fact present in the package.
I created the package with the following command:
wxpar  -o minimal.exe minimal.pl

(I also tried "wxpar  -o minimal.exe --link=wxbase26_gcc_custom.dll
minimal.pl" with the same result)

The packaging process did not report any problems.
The script by the way, works fine when I run it from the command line with
the Perl
interpreter, just not from the packaged exe.
I am using the following setup:
perl, v5.8.9 built for MSWin32-x86-multi-thread
ActivePerl Build 827 [291969]
Wx0.26
Wx-Perl-Packager  0.24
PAR   0.994
PAR-Packager 1.002

The  screen dump says the following:
DEBUG : Initial wx_path is :
DEBUG : preparing Wx for runtime PARLEXE
DEBUG : Runtime PARLEXE Preparation complete
DEBUG : Preparing Load Paths for Wx
DEBUG : Load Path set C:\Documents and Settings\xz3kg2\Local
Settings\Temp\par-xz3kg2\cache-2688caf696428bf9343f512d5ab2d5dbf408ec6e
DEBUG : Load Paths Complete
DEBUG : Preparing and Loading Wx
DEBUG : Core Load = 1
Use of uninitialized value in -f at Wx/Perl/Packager/Base.pm line 445.
Use of uninitialized value in numeric eq (==) at Wx/Perl/Packager/Base.pm
line 445.
DEBUG : Load Method = packload
Can't load
'C:\DOCUME~1\xz3kg2\LOCALS~1\Temp\par-xz3kg2\cache-2688caf696428bf9343f512d5ab2d5dbf408ec6e\e808d0ef.dll'
for module Wx: load_fil
e:The specified module could not be found at C:/Perl/lib/DynaLoader.pm line
226.
  at C:/Perl/site/lib/PAR/Heavy.pm line 128
Compilation failed in require at Wx/Perl/Packager/Base.pm line 489.
Compilation failed in require at script/minimal.pl line 13.
BEGIN failed--compilation aborted at script/minimal.pl line 13.
Out of memory!

At this point I am at a loss for ideas and useful hints for solving my
problem are very much appreciated.
Thanks
Edwin

Re: Win32::Exe

[Mark Dootson]

Steffen,

Thanks, and thanks to Audrey.  I'll use this list to announce any 
uploads to cpan. It is my intention to upload a development release 
first and hopefully get some feedback.


Regards

Mark

On 18/04/2010 15:19, Steffen Mueller wrote:

Hi Mark,

thank you for your work on Win32::Exe.

Mark Dootson wrote:

Just a note in case anyone is thinking of working on Win32::Exe and
has progressed further than I have.


I'm neither working on it nor in a position to comment. Win32 stuff is
generally inaccessible to me.

But I've gone forward and checked with Audrey whether she'd be okay if I
assigned co-maintenance permissions for Win32::Exe(?:::.*)? to you. She
is okay with that, so now you have the permissions to release Win32::Exe
tarballs to CPAN at your discretion. Of course, any discussion and
announcements are highly welcome on this list. Let me know if you hit
any problems or would like me to do something.

Best regards,
Steffen

Win32::Exe

[Mark Dootson]

Hi,

Just a note in case anyone is thinking of working on Win32::Exe and has 
progressed further than I have.


I have spent the time understanding Parse::Binary better so I have been 
able to wrap the PE+ / COFF specification for 64bit binaries in 
Win32::Exe. It turned out to be reasonably simple once you understand 
Parse::Binary :-).  The fact that Parse::Binary already knows that the 
PE+ spec exists and looks for a PEPlus handler made things quite 
straightforward.


All tests pass so that bit is complete.

I'm currently working on the embedded manifest handling. It is currently 
an all or nothing process. I think most people will want to use the 
manifest for the following:


1) Request elevated startup permissions.
2) Embed a dependency on a themed common controls version.

Also, it would be nice if Win32::Exe could parse any existing manifest 
(such as embedded by Visual Studio) and just add the extra bits you want.


So, I'll add some options:

manifest_perms => 
manifest_themed => 1
manifest_name => Your.App.Name

The existing methods that input and output the entire manifest xml will 
still exist so if you have more complex requirements you can handle them 
via that.


When that is complete, that will be it for Win32::Exe for now. I'll need 
somewhere to post a zip though. I've added some new binary content 
(small execs and an icon) used for testing - so can't post a patch.


On to PAR::Packer - I've got 64 bit .obj and .coff files so I just need 
to fix the makefile generation to choose the right one. Then I need to 
add a couple of steps to the build in the right places whereby 
Win32::Exe is used to ensure the PAR executables have an embedded 
manifest that includes 'asInvoker' - which will depend on the compiler 
used.  The reason for this is the same as having a manifest in Perl 
itself - without one the process gets 'virtualized'. Having no manifest 
at all is not the same as having one that specifies 'asInvoker'



Finally, should I add

--manifest_perms
--manifest_themed
--manifest_name

as options to pp?

I probably should, I think.  Just 'perms' and 'named' getting added to 
the 'outer' executable manifest, with all three added to the 'inner'.


So - if someone is already doing this, pipe up and I'll stop !

If there are some other manifest options you think are needed on pp 
command line, then let me know. (or perhaps you feel strongly they 
shouldn't be added at all!)


regards

Mark

Re: Wxpar compiled on Linux RH4 generates errors when running onLinuxRH5

[Mark Dootson]

Hi,

I think this breaks Wx::Html.
Run Wx::Demo - see Windows->wxHtmlWindow->Simple.

I'm just going to submit a patch for Mattia's consideration which covers 
loading the plugins in general, then I can push out a fix to 
Wx::Perl::Packager / wxpar that overcomes this issue (amongst others)


I've been putting some work in on PPMs for Linux and making sure PAR / 
PerlApp work happily with them


Mark



Mattia Barbon wrote:
[Sorry, missed this mail, it ended up in the par folder, that I do not 
read that often...]


Roderich Schupp wrote:

On Thu, Nov 12, 2009 at 10:21 AM, Steffen Mueller
 wrote:
Unfortunately, there's long been an issue with running PAR::Packer 
generated
binaries from RH4 on RH5. It's a recurring one that's regularly 
raised on
par@perl.org (including a recent post by yourself). It's also an 
issue that
*seems* to be isolated to RedHat Linuxes. I've never used RedHat and 
do not
plan to do so. Therefore, I can't debug it. Nobody else has managed 
to do
so. Your specific issue may or may not be the same as the historic 
one since

it's using tons of "external" Wx shared libraries.


I don't have RedHat either :) But I'm convinced that Erez' particular 
problem
would probably show on my Debian system, too (if configured in a 
certain way).

The error messages for the missing *.so files are generated from Wx.pm
based on a (build-time generated) list in Wx/Mini.pm.

For some reason, Wx.pm doesn't trust the inter-library dependencies 
among the
many wxwindows shared libraries that are present in the libraries 
themselves
(i.e. NEEDED tags for Elf based systems e.g. Linux), but tries to 
"preload"

these libraries itself (though it has no immediate use for them since all
access from Perl to wxwindows goes thru the "glue" libraries provided 
by Wx).


  Rest assured that the code is not there because I like to complicate 
people's life ;-)  It is required under Win32 because you can't always 
trust wxWidgets' DLLs to be in the DLL search path (or in the same 
directory as Wx.dll).


  I can't remember if the code is enabled under Linux because of an 
oversight or if there are (or were) situations when it was necessary.


To sum up: complain to the maintainer of the Wx module to stop using 
.so names.


  I'll disable that code in the next release, and we will see if 
anything breaks...


Thanks!
Mattia

Re: ExtUtils::PerlToExe, and binaries that don't need unpacking

[Mark Dootson]

Hi,

Glenn Linderman wrote:



Is the replacement OS?  Who needs a GUI?



Not OS no, as written for part of larger project.
But if I were to start from scratch to implement the idea, it would end 
up looking something like :


hPerlLib = LoadLibrary( pathToPerlDll);
numopts = argc + 2;
dynamicargv = malloc(numopts * sizeof (char*));
dynamicargv[0] = argv[0];
dynamicargv[1] = (char *)pBufferIncPath;
dynamicargv[2] = (char *)pBufferScriptPath;

for (i = 1; i < argc; i++)
dynamicargv[i + 2] = argv[i];

returnval = RunPerl(numopts, dynamicargv, environ);
FreeLibrary(hPerlLib);
free(dynamicargv);
return returnval;


If there is any real interest I'd be happy to knock out some working 
code - but my C skills are V. limited and I thought anyone with 
rudimentary C would be able to do a better job with the idea.


Or the 
deployed application is packaged by some installer, but has the 
structure mentioned, thus not depending on installed Perls?




This.

Regards

Mark

Re: ExtUtils::PerlToExe, and binaries that don't need unpacking

[Mark Dootson]

Hi All,

Ben Morrow wrote:


I've just looked at it now... It looks as though it will do some of what
I want, but I don't really like not being able to see what it's doing.



I agree too. It was an error not to OS, but one I'm stuck with in the 
short term.


I do have a very simple replacement that currently has no GUI but I use 
in real world applications.


Deployed applications have two side by side directories -
.../bin
.../lib

Executable in bin. Everything else in 'lib' - that's a full @INC tree 
(for modules used) plus perl5x.dll and main script.


Exec does 3 simple things.

1. Utilises a delayed load for Perl5x.dll - so code figures out where 
Perl5x.dll is relative to 'bin' dir and loads it.


2. reworks args so I get the equivalent of
-I../lib ../lib/scriptname.pl all other arguments

3. Passes this arglist to RunPerl

And that's it. Passing the script name in this way rather than passing 
perl code directly insulates you from any number of issues.


All that's needed then is method of your choice to determine dependencies :)


Regards

Mark

Re: pp @INC question

[Mark Dootson]

Steffen Mueller wrote:


Insofar as I understand par.pl, this should fix it. Curiously, I've been
happily using pp with 5.10 and never had the issue.


I think Tie::Hash::NamedCapture is loaded on demand and you have to do 
specific things in a regexp to cause it to load.


My guess would be that 'use English' is a probable culprit - but I've 
never bothered to find out what the specific things are that cause 
Tie::Hash::NamedCapture to load.


Best Regards

Mark

Re: pp @INC question

[Mark Dootson]

Hi,

Isn't the underlying problem, in this particular case, Perl 5.10 regex 
engine dependency on Tie/Hash/NamedCapture.pm  ?


Everything about the shebang line include is, of course, correct. But 
the issue Evan is seeing appears to be that Tie/Hash/NamedCapture.pm is 
not packaged.


Tie/Hash/NamedCapture.pm always requires packaging with Perl 5.10.

Mark


Steffen Mueller wrote:

Hi Evan,

Evan Harrell wrote:

For some reason when I use pp to package my software, my @INC array is not
correct. The error I get when I try to run the resulting executable is:



#!/usr/bin/perl -w -I/home/valdar/perl/include/


That's the culprit. The command line options get lost. This is currently
a bug in PAR(::Packer) and potentially Module::ScanDeps, but it's not
easy to fix as we'd have to redo the whole of perl's command line parsing.

The simple workaround is to do:

#!/usr/bin/perl
use warnings;
use lib '/home/valdar/perl/include/';
...

As for the packaged executable only searching its temporary paths by
default: That's on purpose as the executables are supposed to be
self-contained.

If you want to do away with the fixed path in the executable, try adding
the option -I /home/valdar/perl/include/ to your call to pp and it'll
search modules in that path, too.

Best regards,
Steffen

Re: PAR for Windows x64

[Mark Dootson]

Hi,

Sorry, I don't ever recall seeing the separate par icon anywhere in the source 
code.
You could just use any icon to see if the process works (perl icon from perl 
source?) and then design some magnificent new par icon at your leisure :-)

Mark




Sisyphus wrote:
> 
> - Original Message ----- From: "Mark Dootson" <[EMAIL PROTECTED]>
> To: "Sisyphus" <[EMAIL PROTECTED]>
> Cc: "Steffen Mueller" <[EMAIL PROTECTED]>; "christian"
> <[EMAIL PROTECTED]>; 
> Sent: Thursday, September 18, 2008 6:47 PM
> Subject: Re: PAR for Windows x64
> 
> 
>> Hi.
>>
>> The win32.obj is a compiled resource file containing version info and
>> the icon for the executable.
> 
> Is this documented somewhere in the PAR-Packer docs ? Perhaps I just
> don't know where to look - otherwise I think some explanatory
> documentation would be an appropriate addition.
> 
>>
>> You need an 'rc' file like the one attached plus a suitable icon
>> called par.ico as mentioned in the rc file.
>>
>> Then, I'd guess that within the AMD64 build environment,
>>
>> rc win32.rc
>> cvtres win32.res
>>
>> will give you the win32.obj that your require.
>>
>> At least that works for ix86 builds.
>>
> 
> Aaah ... that sort of fits in with the one test failure I got when
> ignoring 'win32.obj'. If I get a suitable win32.obj built for AMD64,
> then perhaps that failure will go away. (The SDK compiler comes with
> both rc.exe and cvtres.exe, so it looks promising.)
> 
> Which 'par.ico' do the x86 builds use ? (I might as well use the same.)
> 
> Cheers,
> Rob
> 
> 

Re: PAR for Windows x64

[Mark Dootson]

Hi.

The win32.obj is a compiled resource file containing version info and the icon 
for the executable.

You need an 'rc' file like the one attached plus a suitable icon called par.ico 
as mentioned in the rc file.

Then, I'd guess that within the AMD64 build environment,

rc win32.rc
cvtres win32.res

will give you the win32.obj that your require.

At least that works for ix86 builds.

Mark



Sisyphus wrote:
> 
> - Original Message - From: "Steffen Mueller"
> <[EMAIL PROTECTED]>
> To: "Sisyphus" <[EMAIL PROTECTED]>
> Cc: "christian" <[EMAIL PROTECTED]>; 
> Sent: Thursday, September 18, 2008 5:04 PM
> Subject: Re: PAR for Windows x64
> 
> 
>> Hi Rob,
>>
>> Sisyphus wrote:
>>> But win32.obj is part of the PAR-Packer source. How am I supposed to
>>> come up with a win32.obj that's suitable for AMD64 ?
>>> Will I also need different versions of win32.coff and win32.res ?
>>
>> unfortunately, I have no idea about that at all. I have no C development
>> experience on Windows.
>>
> 
> Is there likely to be some documentation somewhere that throws some
> light on the matter ?
> 
> I couldn't see any mention of 'win32.obj' in the PAR-Packer ChangeLog -
> no mention of it in the PAR ChangeLog either. But, at some stage,
> someone must have created the file and added it to the PAR-Packer (or
> PAR) source. It could be useful to know just how this file got created
> in the first place. (Opening the file in a text editor doesn't really
> help all that much :-)
> 
> Luckily, it seems that (for the purpose of the x64 build, at least) the
> file is not needed. In the myldr/Makefile.PL I simply changed:
> 
> $res = 'win32.obj';
> to
> $res = '';
> 
> I guess a portable fix is to rewrite the assignment as:
> 
> $res = $Config{ivsize} == 4 ? 'win32.obj' : '';
> 
> It's hard to envisage a sutuation where $Config{ivsize} != 4 && we still
> need to link to that win32.obj.
> 
> PAR-Packer-0.982 then built, tested and installed pretty goodly. Just
> one failing test:
> 
> 
> t/20-pp.ok 31/34
> Can't locate object method "load" via package
> "Win32::Exe::PE::Header::PE32Plus" at
> C:/_64/perl1004/site/lib/Parse/Binary.pm line 484.
> 
> #   Failed test 'pp_gui_tests
> # amsg572: sub pp_gui_tests cannot system pp --gui --icon hi.ico -o
> hello.exe hello.pl:No such file or directory:
> t/20-pp.NOK 32/34# '
> #   at automated_pp_test.pl line 8445.
> 
> 
> Does that failure call for further investigation ? (As soon as I see the
> term 'gui' I tend to lose interest pretty quickly :-)
> 
>> P.S.: I'll apply your patch asap, unless you beat me to it.
> 
> Oooow  it's within my power to apply patches to PAR-Packer source ?
> (That could be dangerous.)
> 
> Cheers,
> Rob

// win32.rc

// (c) 1995-1999 Microsoft Corporation. All rights reserved.
//  Distribution Compiled as Cava Perl.

//  You may distribute under the terms of either the GNU General Public
//  License or the Artistic License, as specified in the README file.

#include 

WINEXE  ICONpar.ico

#define VER_DEBUG   0

VS_VERSION_INFO VERSIONINFO
FILEFLAGSMASK  VS_FFI_FILEFLAGSMASK
FILEFLAGS  VER_DEBUG
FILEOS VOS_NT_WINDOWS32
FILETYPE   VFT_APP
FILESUBTYPEVFT2_UNKNOWN

BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "040904E4"
BEGIN
VALUE "CompanyName"," \0",
VALUE "FileDescription"," \0",
VALUE "FileVersion"," \0",
VALUE "InternalName",   " \0",
VALUE "LegalCopyright", " \0",
VALUE "LegalTrademarks"," \0",
VALUE "OriginalFilename",   " \0",
VALUE "ProductName"," \0",
VALUE "ProductVersion", " \0",
END
END

BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x409, 0x04E4
// English language (0x409) and the Windows ANSI codepage (0x04E4)
END
END

Re: PAR installation question....

[Mark Dootson]

Hi,

Can you name any module that will compile on Strawberry Perl via the CPAN shell 
that won't compile on ActivePerl via the CPAN shell?

Regards

Mark


Packy Anderson wrote:


On Jun 29, 2008, at 8:23 AM, Paul Miller wrote:

Why is everyone so down on Active Perl lately?



I was just at YAPC::NA two weeks ago, and Adam Kennedy was talking about 
the status of Strawberry Perl and how it differs from ActiveState.  He 
went into great detail about the differences between the two--details I 
can't recall all of so I can't go into here--but (for me) it boils down 
to one major thing: CPAN support.


There are certain modules in the PPM repository that ActiveState cannot, 
for contractual support reasons, update because they would break 
installations they have support contract with.  There are other modules 
that don't build cleanly, but ActiveState marks them as valid and 
delivers them anyway.  Just take a look at the PPM Repository Build 
Status page for 5.8:


http://ppm.activestate.com/BuildStatus/5.8.html

ActiveState was a good tool at the time it came out, when there wasn't 
an easily available, open source C compiler for Win32.  Now that MinGW 
is available, ActiveState Perl is being surpassed by Strawberry Perl.  
Does that mean that NOBODY should use ActiveState?  No, clearly not.  If 
all you need is the core modules or modules that *do* build cleanly for 
the PPM, then there's no reason for you to go out and get Strawberry 
Perl.  Similarly, there are people who use the ancient version of Perl 
that ships with Solaris, too, because that's all they need.


If, however, you want to be able to update to the most recent version of 
any CPAN module you want and you wouldn't mind using the incredibly 
simple cpan shell to do it, then Strawberry's your Perl.


-packy

--
Packy Anderson  
[EMAIL PROTECTED]


I'd be dead by 33; well, that was my best guess...
but, hey, here I am this morning.
Singing 'Happy Birthday to Me' as I clean up all this mess,
'Cause I'm left still alive without warning.
In the big boring middle of my long book of life,
after the twist has been told,
if you don't die in glory at the age of Christ
then your story is just getting old...

Re: PAR installation question....

[Mark Dootson]

Hi,

I don't think everyone is.
I use ActivePerl and can see no benefit for my particular situation in changing.

But Strawberry provides a viable alternative on Windows, and choice has to be a 
good thing.

The nice thing about it is that whatever choice you make at the outset, you are 
not locked in. If you find somewhere down the line that one distribution 
provides something the other does not and you need it, just switch. I can't off 
the top of my head think of anything that would prevent you from doing so.

In any event, in one or two releases Strawberry will have sorted out the minor 
issues around relocation on install and for ActivePerl, folks may realise how 
easy it is to install MinGW now which 'just works' with recent ActivePerl 
releases.

At which point, they look technically equivalent to me so it's down to 
questions of your view on licensing and support, which each distribution 
addresses in different ways. Whether one or the other is 'better' is down to 
individual preferences and circumstance.

Regards

Mark



Paul Miller wrote:

On Sun, Jun 29, 2008 at 08:21:47AM +0200, Alvar Freude wrote:
But since Strawberry can install PPMs too (5.10.0.1), there are only a  
few reasons left to use ActivePerl ...


Why is everyone so down on Active Perl lately?

Re: problem with POSIX package and par

[Mark Dootson]

Hi,

Having read through the thread, my somewhat Windows specific view on this is 
that there is only one case where the current PAR implementation does not work.

That is where a shared library is loaded in a completely none standard manner 
for the operating system concerned.
This is the case with Gtk2, and to a lesser extend with Wx (you can alter Wx 
within Perl so that libs are loaded using current PAR implementation).

I don't recall any other genuine cases reported to this list, though there may 
be some.
For example, Image::Magick uses standard methods to load its dependencies so it 
is just a matter of packing the correct ones to 'shlib'.

In general, the only shared libraries that can have common names within a Perl 
process are the XS modules themselves. Dependent shared libraries - i.e. those 
linked to XS modules by standard dynamic linking, must have unique file names.

For the example
sys/libfoo.dll, glib/libfoo.dll, and a bork/libfoo.dll
in windows at least, in general, the first libfoo.dll your process attempts to 
load is the libfoo.dll you get.

Note that in Windows 'side by side' loading works from the perspective of DLLs 
too
e.g. If I have process perl.exe that loads
../auto/My/Module/Module.dll

and Module.dll has a dependency on ModuleExtra.dll, then if 
../auto/My/Module/ModuleExtra.dll exists, that will get loaded .
If later in my prog I do "loadlibrary('ModuleExtra.dll') then I will just get 
an increase in the ref count to ./auto/My/Module/ModuleExtra.dll.

So, the current implementation of mangling XS module library names and 
extracting dependent libs from shlib to the cache root works for everything 
except odd cases.

In the odd case of Gtk2, the only way to cope with its behaviour is to extract 
to a standard 'tree' (as pointed out earlier in thread).

We could change everything about PAR to cope with Gtk2, but if we do so, it 
might be a good idea to take a step back and think about wider alterations to 
current PAR.

Why not take recent work on Archive::Unzip::Burst and incorporate that in a 
reworked PAR - say PAR::Burst

PAR::Burst would then just extract everything to cache directory with no name 
mangling and a simple tree structure like

inc
shlib
script

'inc' gets added to @INC, shlib to library paths, script folder is added to 
'PATH' and perms mask is 0755.

End users can add whatever else thy like to zip structure.

Of course, this would mean that foo.par packed under PAR would be different to 
foo.par packed under PAR::Burst - so PAR::Burst would need a fallback method 
whereby after extraction, if we don't have 'PAR::Burst' structure, start again 
with PAR. This would make older .par files take slightly longer to load, but it 
would still work until all dependencies were converted to PAR::Burst


For PAR::Burst::Packer, the goal would be to incorporate the unzip code 
directly within the compiled executable, removing the need to load Perl at all 
until after the extract is complete.
In addition to increased speed, this would give us the huge advantage that when 
the initial executable stub has extracted the zip tree, we can then in the 
extracted second executable simply mangle the arguments and call
perl_parse on the path to the extracted script - removing any BEGIN, eval, do  -e 
wrapper. We would have to prepend a BEGIN block to the script to set up necessary PATHS / 
@INC but this would still make the script code that followed run exactly as if it have 
been called as "perl myscript.pl". A big win I think.

I would quite like to work on this if there is any agreement that any of it 
represents a reasonable idea.

Regards


Mark






Steffen Mueller wrote:


Hi Glenn, hi all,

Glenn Linderman schrieb:
Now if a library was not originally part of the  tree, 
it is an open question where it should be installed... and maybe that 
is what you are referring to?


Unless I'm grossly mistaken, that's exactly what Scott is referring to.

So then in the PAR case we have 
/(lib|bin|script) and you are suggesting that 
anything that is included from other parts of the original file system 
should be placed in ?  I'd have suggested 
placing them in /script -- the script and any 
non-perl stuff should go there?


I don't see any reason to put non-perl stuff in script, to be honest. 
Maybe this is a Windows thing where people generally put dlls next to 
the executables in PATH?


My suggestion would be the following:
- For any Perl stuff, use the original paths and names.
- For shared libraries added with -l, use shlib/ORIGINALNAME or whatever 
that path's called. Add that to LD_LIBRARY_PATH and -- on Windows -- to 
PATH.
- For data files added with -a, use the main cache directory and the 
original file name.


Now, what happens if filenames of external shared objects clash? There 
might be a sys/libfoo.so, a glib/libfoo.so, and a bork/libfoo.so 
required by the same program, as far as I know. (Is that right?)


We can't possibly recover those paths by looking at them 

Re: problem with POSIX package and par

[Mark Dootson]

Hi,

For what it is worth, I have 'coped' with autoload issues like this in the past 
with the following amendment to AutoLoader.pm


sub find_filename {
 my $sub = shift;
 my $filename;
 # Braces used to preserve $1 et al.
 {
   my ($pkg,$func) = ($sub =~ /(.*)::([^:]+)$/);
   $pkg =~ s#::#/#g;
   if (defined($filename = $INC{"$pkg.pm"})) {
 if( $filename =~ /^CODE\([^()]+\)/ ) {
   $filename = qq(auto/$pkg/$func.al);
return $filename if ( DynaLoader::dl_findfile{$filename} );
 }


The additional lines are the last 4.

The untested bit of this is "if ( DynaLoader::dl_findfile{$filename} );".
In my implementation I have a different method of storing the mappings of 
hashed filenames.

For PAR, I imagine overriding  AutoLoader::find_filename in PAR::Heavy in the 
same manner that DynaLoader::dl_findfile is overridden there would work.


Regards

Mark





Scott Stanton wrote:

I have a trivial program test.pl:

 


use POSIX qw(strftime ceil floor);

 


I create a par binary like so:

 


pp test.pl -o test.exe

 


When I run it, I get the following output:

 


Subroutine import redefined at POSIX.pm line 21.

Subroutine croak redefined at POSIX.pm line 29.

Subroutine AUTOLOAD redefined at POSIX.pm line 39.

Subroutine DESTROY redefined at POSIX.pm line 80.

 


I am using perl-5.10.0 built with vc6 on Windows XP, and the 0.980
version of PAR & PAR::Packer.

 


Looking at the POSIX module, it does define those methods, but only
once.  I wonder if there is some bleedthrough from the bootstrap process
that is causing the module to get loaded multiple times.  This same
program works as expected under perl-5.8.8, so it seems likely to be a
perl-5.10 related change.  Anyone have any ideas?

 


--Scott

Re: perl510.dll not being included

[Mark Dootson]

Oops

This is already fixed in trunk.
I'll run around the pitch 5 times for not paying attention.



Mark Dootson wrote:


Hi,

This is, I think, a bug in the way PAR::Packer determines the name of 
libperl at make time which is basically to take $Config::Config{libperl} 
and append the 'so' extension for dynamic Perls.


So, in a VC++ built Perl on MSWin, such as ActivePerl, we get
$Config::Config{libperl} eq 'perl510.lib'

whilst for a MinGW built Perl like Strawberry we get

$Config::Config{libperl} eq 'libperl510.a'
..

All the test succeed because perl510.dll is on the path.

I think the way to fix this is to have an MSWin specific check for a 
dynamic libperl in the appropriate makefile that strips any leading 
'lib' from $Config::Config{libperl}and then looks for the DLL under that 
name. Note this will only have any effect if the DLL name so determined 
actually exists so I can't think of any effect other than that this will 
make PAR::Packer on Strawberry work.


Any other thoughts? Is there a simpler way to find out the name of the 
dynamic Perl DLL on MSWin?


If this is a reasonable approach I don't mind doing a simple patch and 
testing against various Win32 Perls to ensure it works.


The current test I assume fails is in myldr/Makefile.PL at around line 135.

Regards

Mark





Robert Davis wrote:

I have strawberry perl installed.
I have PAR .980 installed.
 
I did what Roderich Schupp suggested from a previous thread:

http://www.mail-archive.com/par@perl.org/msg03147.html
 
- installed Strawberry Perl 5.10 from scratch

- installed libwin32, PAR, PAR::Packer (and its prerequisites) from CPAN
- pp -o hello.exe -e "print qq[hullo world\n]"
- invoked hello.exe from another console window with everything
mentioning
strawberries removed from environment:  
didn't work for me.
 
 
I verified the only missing dll was perl510.dll. I copied perl510.dll to

the current directory and it worked.
I checked the cache directory(after cleaning it first) and there is a
libperl510.a in there but no perl510.dll
 
Help
 
bob
 

Re: perl510.dll not being included

[Mark Dootson]

Hi,

This is, I think, a bug in the way PAR::Packer determines the name of libperl 
at make time which is basically to take $Config::Config{libperl} and append the 
'so' extension for dynamic Perls.

So, in a VC++ built Perl on MSWin, such as ActivePerl, we get 


$Config::Config{libperl} eq 'perl510.lib'

whilst for a MinGW built Perl like Strawberry we get

$Config::Config{libperl} eq 'libperl510.a'
.

All the test succeed because perl510.dll is on the path.

I think the way to fix this is to have an MSWin specific check for a dynamic 
libperl in the appropriate makefile that strips any leading 'lib' from 
$Config::Config{libperl}and then looks for the DLL under that name. Note this 
will only have any effect if the DLL name so determined actually exists so I 
can't think of any effect other than that this will make PAR::Packer on 
Strawberry work.

Any other thoughts? Is there a simpler way to find out the name of the dynamic 
Perl DLL on MSWin?

If this is a reasonable approach I don't mind doing a simple patch and testing 
against various Win32 Perls to ensure it works.

The current test I assume fails is in myldr/Makefile.PL at around line 135.

Regards

Mark





Robert Davis wrote:

I have strawberry perl installed.
I have PAR .980 installed.
 
I did what Roderich Schupp suggested from a previous thread:

http://www.mail-archive.com/par@perl.org/msg03147.html
 
- installed Strawberry Perl 5.10 from scratch

- installed libwin32, PAR, PAR::Packer (and its prerequisites) from CPAN
- pp -o hello.exe -e "print qq[hullo world\n]"
- invoked hello.exe from another console window with everything
mentioning
strawberries removed from environment: 
 
didn't work for me.
 
 
I verified the only missing dll was perl510.dll. I copied perl510.dll to

the current directory and it worked.
I checked the cache directory(after cleaning it first) and there is a
libperl510.a in there but no perl510.dll
 
Help
 
bob
 

Re: best win32 perl to use

[Mark Dootson]

Bob Davis wrote:

I assume that either of these perls fix my problems(limitations) with 
cygwin.


Hi,

Of course, that depends what on the list of limitations you are experiencing. I 
have noticed a few of your posts to list but I don't have a Cygwin environment 
installed so can't help at all with those.

However, ActivePerl and Strawberry work for many people and you will get a 
better response to support questions on these than you will on Cygwin purely 
from a number of users point of view.

Generally, I use ActivePerl together with the MinGW compiler so I get direct 
access to CPAN as well as PPM. They work perfectly together. But that is purely 
from habit and familiarity with dependencies when packaging an app. For testing 
I have used Strawberry too and experienced no particular problems there.

It is worth noting that the current release of Strawberry includes PPM too and 
PPMs built for ActivePerl will, in general, work with Strawberry Perl and PPMs 
built for Strawberry Perl will generally work with ActivePerl.

I must confess, I've not quite got my head around what makes Strawberry Perl more 'UNIX like' so at the moment ActivePerl + MinGW (or a compiler of your choice) seems more or less equivalent to Strawberry Perl to me. I'm prepared to be trampled under the rush to correct this perception though :)  



Regards

Mark

Re: Archive::Unzip::Burst on Win32

[Mark Dootson]

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   256341  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

Re: Archive::Unzip::Burst on Win32

[Mark Dootson]

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   256341  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

Re: PAR::Packer 0.980 MSWin32 .par binary?

[Mark Dootson]

Yuv,

As your wiki entry covers everything you need to install PAR::Packer, I 
wondered if you might like to add the following to it to make it absolutely 
complete.

The method described works for any ActivePerl 5.10 version.
For ActivePerl 5.8 versions it works for any build >= 820.

For ActivePerl builds < 820, the following additional action is required.

Install ExtUtils::FakeConfig >= 0.11 by downloading the source from CPAN and 
doing:

perl Makefile.PL
dmake
dmake test
dmake install

When you come to build modules, you need to pass an extra option when running 
Makefile.PL so that the method for building modules becomes:

perl -MConfig_m Makefile.PL
dmake
dmake test
dmake install

The ExtUtils::FakeConfig pod also points out you can set set PERL5OPT=-MConfig_m
However, the PAR::Packer build will fail if you use this option. For most 
modules, either way of setting Config_m will work, but for a very few cases you 
will find that only one of the methods work.

Regards


Mark




Yuval Levy wrote:

So, here is my promised write up - correct me if I am wrong:
 



I went the MinGW way (thank you, Mark!).

Jan Dubois wrote:
Setting of ccversion will be done automatically (at runtime) in 
ActivePerl build 823

(whenever 5.8.9 gets released) and in 1003 (probably out next week).


I may try this one at a later stage.


I would recommend using either VC++ 6 or MinGW to build Perl modules, 
and especially
PAR binaries because these 2 compilers use MSVCRT.dll as the C runtime 
library, and
this library is part of the OS, so there is no need to deploy it with 
your application.
If you compile any module with VC 2008, then you will always have to 
include MSVCR90.dll
with your applications too because it may not be present on a target 
machine.


that's quite an important detail. can anybody explain to me why 
Microsoft amputates its own O/S and does not include MSVCR90.dll?


and (correct me if my language is not precise, I'm a caveman) is there a 
way to bring statically linked Perl modules that don't need any of these 
dll?


the current ("legacy"/undocumented) way to ship compiled Perl modules 
with hugin is to bundle perl58.dll. I see with great pleasure that this 
is no longer necessary with PAR::Packer - my hello world test seems to 
run without it?


thanks a lot again!
Yuv

Archive::Unzip::Burst on Win32

[Mark Dootson]

Hi,

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.

Regards

Mark

diff -ruw Burst.xs Burst.xs
--- Burst.xs2007-09-05 16:19:54.0 +0100
+++ Burst.xs2008-05-16 03:55:50.371125000 +0100
@@ -4,8 +4,171 @@
 
 #include "ppport.h"
 
+# if (defined(_WIN32))
+
+#include "res/unzip-5.52/windll/structs.h"
+#include "res/unzip-5.52/windll/decs.h"
+
+
+LPUSERFUNCTIONS lpUserFunctions;
+HANDLE hUF = (HANDLE)NULL;
+LPDCL lpDCL = NULL;
+HANDLE hDCL = (HANDLE)NULL;
+HANDLE hZCL = (HANDLE)NULL;
+DWORD dwPlatformId = 0x;
+int WINAPI DisplayBuf(LPSTR, unsigned long);
+int WINAPI GetReplaceDlgRetVal(LPSTR);
+int WINAPI password(LPSTR, int, LPCSTR, LPCSTR);
+void WINAPI ReceiveDllMessage(unsigned long, unsigned long, unsigned,
+unsigned, unsigned, unsigned, unsigned, unsigned,
+char, LPSTR, LPSTR, unsigned long, char);
+
+static void FreeUpMemory(void);
+
+int
+UzpMain(int argc, char **argv)
+{
+int r;
+int exfc, infc;
+char **exfv, **infv;
+
+hDCL = GlobalAlloc( GPTR, (DWORD)sizeof(DCL));
+if (!hDCL)
+   {
+   return 0;
+   }
+lpDCL = (LPDCL)GlobalLock(hDCL);
+if (!lpDCL)
+   {
+   GlobalFree(hDCL);
+   return 0;
+   }
+
+hUF = GlobalAlloc( GPTR, (DWORD)sizeof(USERFUNCTIONS));
+if (!hUF)
+   {
+   GlobalUnlock(hDCL);
+   GlobalFree(hDCL);
+   return 0;
+   }
+lpUserFunctions = (LPUSERFUNCTIONS)GlobalLock(hUF);
+
+if (!lpUserFunctions)
+   {
+   GlobalUnlock(hDCL);
+   GlobalFree(hDCL);
+   GlobalFree(hUF);
+   return 0;
+   }
+
+lpUserFunctions->password = password;
+lpUserFunctions->print = DisplayBuf;
+lpUserFunctions->sound = NULL;
+lpUserFunctions->replace = GetReplaceDlgRetVal;
+lpUserFunctions->SendApplicationMessage = ReceiveDllMessage;
+
+lpDCL->ncflag = 0; /* Write to stdout if true */
+lpDCL->fQuiet = 2; /* 0 = We want all messages.
+  1 = fewer messages,
+  2 = no messages */
+lpDCL->ntflag = 0; /* test zip file if true */
+lpDCL->nvflag = 0; /* give a verbose listing if true */
+lpDCL->nzflag = 0; /* display a zip file comment if true */
+lpDCL->ndflag = 1; /* Recreate directories != 0, skip "../" if < 2 */
+lpDCL->naflag = 0; /* Do not convert CR to CRLF */
+lpDCL->nfflag = 0; /* Do not freshen existing files only */
+lpDCL->noflag = 1; /* Over-write all files if true */
+lpDCL->ExtractOnlyNewer = 0; /* Do not extract only newer */
+lpDCL->PromptToOverwrite = 0; /* "Overwrite all" selected -> no query mode 
*/
+lpDCL->lpszZipFN = argv[3]; /* The archive name */
+lpDCL->lpszExtractDir = NULL; /* The directory to extract to. This is set
+ to NULL if you are extracting to the
+ current directory.
+   */
+
+infc = exfc = 0;
+infv = exfv = NULL;
+
+r = Wiz_SingleEntryUnzip(infc, infv, exfc, exfv, lpDCL, lpUserFunctions);
+FreeUpMemory();
+return r;
+}
+
+int WINAPI GetReplaceDlgRetVal(LPSTR filename)
+{
+/* This is where you will decide if you want to replace, rename etc 
existing
+   files.
+ */
+return 1;
+}
+
+static void FreeUpMemory(void)
+{
+if (hDCL)
+   {
+   GlobalUnlock(hDCL);
+   GlobalFree(hDCL);
+   }
+if (hUF)
+   {
+   GlobalUnlock(hUF);
+   GlobalFree(hUF);
+   }
+}
+
+/* This is a very stripped down version of what is done in Wiz. Essentially
+   what this function is for is to do a listing of an archive contents. It
+   is actually never called in this example, but a dummy procedure had to
+   be put in, so this was used.
+ */
+void WINAPI ReceiveDllMessage(unsigned long ucsize, unsigned long csiz,
+unsigned cfactor,
+unsigned mo, unsigned dy, unsigned yr, unsigned hh, unsigned mm,
+char c, LPSTR filename, LPSTR methbuf, unsigned long crc, char fCrypt)
+{
+char psLBEntry[_MAX_PATH];
+char LongHdrStats[] =
+  "%7lu  %7lu %4s  %02u-%02u-%02u  %02u:%02u  %c%s";
+char CompFactorStr[] = "%c%d%%";
+char CompFactor100[] = "100%%";
+char szCompFactor[10];
+char sgn;
+
+if (csiz > ucsize)
+   sgn = '-';
+else
+   sgn = ' ';
+if (cfactor == 100)
+   lstrcpy(szCompFactor, CompFactor100);
+else
+   sprintf(szCompFactor, CompFactorStr, sgn, cfactor);
+   wsprintf(psLBEntry, LongHdrStats,
+  ucsize, csiz, szCompFactor, mo, dy, yr, hh, mm, c, filename);
+
+printf("%s\n", psLBEntry);
+}
+
+/* Password entry routine - see password.c in the wiz directory for how
+   this is actually implemented in WiZ. If you have an encrypted file,
+   this will prob

Re: PAR::Packer 0.980 MSWin32 .par binary?

[Mark Dootson]

Hi,

PAR::Packer executables are really just zip files on steroids.
So Perl510.dll et al get extracted and execute from temp directories at run 
time.

Static linking - now that you know that a PAR exec is just a zip, I guess your 
question would be 'can I wrap everything up in the zip' to which the answer is 
yes EXCEPT for anything the external par.exe itself is linked against. So, if 
you had a module compiled with MSVC2005 you could just wrap MSVCR90.dll in the 
par exec.
Anyway, the short answer to avoid an extra C/C++ runtime is use VC6 or MinGW - 
you might still end up having to use a module compiled with VC7 /8 /9.
This would be the case if the module author only targetted those compilers and 
you weren't in the mood to learn how to 'fix' the code to work with VC6 /MinGW. 
But you just ahve to add the appropriate runtime to the PAR.

By forcing you to distribute MSVCR90.dll with your app and install it to an application directory, MS avoids having to cope with version conflicts between, say, MSVCR90.dll original and MSVCR90.dll service pack 2. In the world of MSI installers and huge storage media, this is probably a good idea. 


Nice work with the wiki entry.

Regards

Mark



Yuval Levy wrote:

So, here is my promised write up - correct me if I am wrong:
 



I went the MinGW way (thank you, Mark!).

Jan Dubois wrote:
Setting of ccversion will be done automatically (at runtime) in 
ActivePerl build 823

(whenever 5.8.9 gets released) and in 1003 (probably out next week).


I may try this one at a later stage.


I would recommend using either VC++ 6 or MinGW to build Perl modules, 
and especially
PAR binaries because these 2 compilers use MSVCRT.dll as the C runtime 
library, and
this library is part of the OS, so there is no need to deploy it with 
your application.
If you compile any module with VC 2008, then you will always have to 
include MSVCR90.dll
with your applications too because it may not be present on a target 
machine.


that's quite an important detail. can anybody explain to me why 
Microsoft amputates its own O/S and does not include MSVCR90.dll?


and (correct me if my language is not precise, I'm a caveman) is there a 
way to bring statically linked Perl modules that don't need any of these 
dll?


the current ("legacy"/undocumented) way to ship compiled Perl modules 
with hugin is to bundle perl58.dll. I see with great pleasure that this 
is no longer necessary with PAR::Packer - my hello world test seems to 
run without it?


thanks a lot again!
Yuv

Re: PAR::Packer 0.980 MSWin32 .par binary?

[Mark Dootson]

Hi,

I think you are on your own building with MSVC 2008EE. I don't know if there 
will be anyone else out there using this that can help you. I think you would 
have to make considerable amendments to the current build process to 
accommodate MSVC 2008EE and I'm not sure at all if you could satisfy MSVC 
2008EE assembly requirements whatever you did - but perhaps someone with more 
knowledge can correct here?

However, it is simple to build PAR::Packer from source and this is definitely 
the way to go. You can use MinGW.

Download MinGW-5.1.4.exe from http://www.mingw.org/
Install to C:\MinGW.

Run the now installed C:\MinGW\MinGW-5.1.4.exe to ensure you get the latest 
updates.

Download dmake from http://search.cpan.org/~shay/dmake-4.11-20080107-SHAY/

Extract the whole tree to C:\MinGW\dmake  (so probably just to C:\MinGW as 
dmake is in the tar folder structure)

Make yourself an environment batch file that contains something like the 
following:

#--

set MINGW_PATH=C:\MinGW
set PERL_PATH=C:\Perl
set PATH=%MINGW_PATH%\bin;%MINGW_PATH%\mingw32\bin;%MINGW_PATH%\dmake;
set PATH=%PATH%C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;
set LIB=%MINGW_PATH%\lib;
set INCLUDE=%MINGW_PATH%\include;
set PATH=%PERL_PATH%\site\bin;%PERL_PATH%\bin;%PATH%
cmd /K

#---

Then, run the batch file to open a command prompt and do

perl Makefile.PL
dmake
dmake par


Regards

Mark


Yuval Levy wrote:

Hi guys,

Mark Dootson wrote:

If there are no takers by this evening, I shall build for 5.10 and 5.8
I just need to set up a 5.8 environment.


I would like to try this as well but I'm a newbie, so please do it 
anyway as I am afraid you can not really rely on me (yet).


I've reported my previous attempt at 
<http://www.nntp.perl.org/group/perl.par/2008/04/msg3426.html>


it failed somewhere at NMAKE.

My process (on April 13 2008):
* start with a WinXP SP2 box with MSVC 2008EE installed
* installed a fresh AS 5.10.0 build 1002
* start the Perl Package Manager
* install Get-opt-ArgvFile, module-scandeps, par-dist, parse-binary with 
the PPM

* downloaded manually PAR::Packer (0.978), Win::Exe (0.11) and PAR (0.979)
* tried to build manually the three above packages. Win::Exe and PAR 
worked, but Par::Packer failed during nmake.


Right now here, in Canada, I still see 0.979 as the latest version on 
search.cpan.org.


Thanks a lot for this great module, I look forward to (hopefully) build 
it or at least use it - currently I have to nag one of my fellow 
community members who has sort of a 
legacy-still-working-but-not-documented way to produce executables:
<http://wiki.panotools.org/Install_Panotools-Script_on_Windows#Creating_.exe_tools> 



that then end up in our window installers <http://panospace.wordpress.com/>

THANKS A LOT!
Yuv




Regards

Mark


Steffen Mueller wrote:

Hi list,

in the past, we usually supplied a binary of PAR::Packer for our Windows
users.

Could somebody build PAR::Packer 0.980 (when it hits your mirror) on
Windows (win32, please no 64) using AS Perl or Strawberry as follows and
send me the .par file per mail so I can upload it in my CPAN directory?

perl Makefile.PL
make
make par

Thanks and best regards,
Steffen

Re: PAR::Packer 0.980 MSWin32 .par binary?

[Mark Dootson]

Hi,

If there are no takers by this evening, I shall build for 5.10 and 5.8
I just need to set up a 5.8 environment.

Regards

Mark


Steffen Mueller wrote:

Hi list,

in the past, we usually supplied a binary of PAR::Packer for our Windows
users.

Could somebody build PAR::Packer 0.980 (when it hits your mirror) on
Windows (win32, please no 64) using AS Perl or Strawberry as follows and
send me the .par file per mail so I can upload it in my CPAN directory?

perl Makefile.PL
make
make par

Thanks and best regards,
Steffen

Re: How do I use/extract the icon packaged with --icon

[Mark Dootson]

Hi,

I use Wx quite a bit and I would always just use --addfile for icons and 
resources.

I think your problem is that you are getting your executable path from the 
wrong source.

As I recall, $0 will always give you the relative path to the exec you created 
with pp, so it is this one you want to grab the icons from if you prefer the PE 
resource route.

Regards

Mark 


John wrote:

Mark Dootson wrote:

Hi,

Check out the source code for

Win32::Exe
Win32::Exe::IconFile
Win32::Exe::Resource::Icon;
Win32::Exe::Resource::GroupIcon;

Instead of specifying '-icon' as a param to pp, you should be able to 
figure out how to add icons with specific id's after you have built 
the exec.


untested, but looks something like following should work:

# get icons from an iconfile

my @icons = Win32::Exe::IconFile->new($iconfile)->icons;
# @icons = array of Win32::Exe::Resource::Icon objects
# reorder @icons setting Id of each one

my $exe = Win32::Exe->new($execfile);

$exe->set_icons([EMAIL PROTECTED]).

To repeat, untested so the correct approach may not be exactly as above.


Mark


Thank you Mark

This idea is something I will follow up on because I think it is a way 
of automating what I am doing manually with a resource editor at the 
moment and I need to understand what is happening better, but I don't 
think it will address my original issue.


I had two issues that I was trying to solve with a common solution.

1. I wanted a particular icon in the executable package file so that it 
would display on the desktop, explorer etc. --icon, the methods you 
indicate above or a resource editor can facilitate this.


2. I wanted the same icon to appear in my apps window title bar. I was 
trying to extract the icon from the executable that was processing my 
script, believing it to be (or to have inherited the icon from) the 
executable package, and could not find the one I wanted. Digging deeper 
reveals this is not the case. For now, my workaround is to use --addfile 
to include my icon file in the package.







John wrote:

Philippe Schaffnit wrote:

Hi!

I haven't managed either exactly what you are attempting (though I 
would

be really interested!), but a fairly painless workaround (which I
actually use), is to pack the icon additionally with '--addfile', and
get it from there afterwards (it's messy, but the file is tiny
anyway...).

Good luck!

Philippe

Thank you Phillipe

I eventually came up with that idea as well. May be someone else will 
chip in with a response and we will both learn something new.


John



John wrote:

Hi

I am packaging a Win32::GUI app with:

pp -i myicon.ico -M Math::Trig -M Win32::GUI -M Win32::GUI::Grid -g -o
b.exe guess1.plw

in my app Iam using:

my $icon = new Win32::GUI::Icon(105);
$main->ChangeIcon($icon);

to access and set my apps title bar icon. Looking in the packaged app
with a resource editor myicon appears as 101. When I use that 
number in
the statement above (currently 105) I get a camel. Changing that 
number

I get a variety of other icons but not the one I want.

Could someone please suggest how I might achieve what I want and
possibly explain what is happening. As I write this I think that the
camel icon is coming from parl.exe which I understand to be part of 
the

executable component of the package.

--
Regards
John McMahon
 [EMAIL PROTECTED]

Re: How do I use/extract the icon packaged with --icon

[Mark Dootson]

Hi,

Check out the source code for

Win32::Exe
Win32::Exe::IconFile
Win32::Exe::Resource::Icon;
Win32::Exe::Resource::GroupIcon;

Instead of specifying '-icon' as a param to pp, you should be able to figure 
out how to add icons with specific id's after you have built the exec.

untested, but looks something like following should work:

# get icons from an iconfile

my @icons = Win32::Exe::IconFile->new($iconfile)->icons;
# @icons = array of Win32::Exe::Resource::Icon objects
# reorder @icons setting Id of each one

my $exe = Win32::Exe->new($execfile);

$exe->set_icons([EMAIL PROTECTED]).

To repeat, untested so the correct approach may not be exactly as above.


Mark



John wrote:

Philippe Schaffnit wrote:

Hi!

I haven't managed either exactly what you are attempting (though I would
be really interested!), but a fairly painless workaround (which I
actually use), is to pack the icon additionally with '--addfile', and
get it from there afterwards (it's messy, but the file is tiny
anyway...).

Good luck!

Philippe

Thank you Phillipe

I eventually came up with that idea as well. May be someone else will 
chip in with a response and we will both learn something new.


John



John wrote:

Hi

I am packaging a Win32::GUI app with:

pp -i myicon.ico -M Math::Trig -M Win32::GUI -M Win32::GUI::Grid -g -o
b.exe guess1.plw

in my app Iam using:

my $icon = new Win32::GUI::Icon(105);
$main->ChangeIcon($icon);

to access and set my apps title bar icon. Looking in the packaged app
with a resource editor myicon appears as 101. When I use that number in
the statement above (currently 105) I get a camel. Changing that number
I get a variety of other icons but not the one I want.

Could someone please suggest how I might achieve what I want and
possibly explain what is happening. As I write this I think that the
camel icon is coming from parl.exe which I understand to be part of the
executable component of the package.

--
Regards
John McMahon
 [EMAIL PROTECTED]

Re: Failed test 'Found the static build of parl in myldr for perlv5.10.0 build for MSWin32-x86-multi-thread

[Mark Dootson]

Hi Steffen,

How about setting which tests to run explicitly? The following change to
Makefile.PL does it.


my $pgentest = (!$par and $cc) ? ' t/10-parl-generation.t ' : '';
my $tests = qq(t/00-pod.t$pgentest t/20-pp.t t/30-current_exec.t);
makemaker_args(
test => { TESTS => $tests },


of course, it means you have to update Makefile.PL if you add extra test
scripts - but it is the simplest way I could think of.

Regards

Mark
 


Steffen Mueller wrote:
> Hi Mark,
>
> Mark Dootson schrieb:
>> The correct way to handle this is to skip all the t/10-parl-generation
>> tests if installing using the downloadable PAR dist.
>
> I agree. At first, I thought this would be really simple and was going
> to do just that. However, the tricky part is to determine during "make
> test" whether the pre-built .par was used or not. I got this far:
>
> 1) During Makefile.PL modify the Makefile that's written out so
> 2) the Makefile sets an environment variable (If that's possible in a
> portable way!)
> 3) which can be tested against by the test script.
>
> The tricky bit is that Module::Install is such a weird beast that I
> can't figure out how to modify the Makefile from Makefile.PL. I'd
> rather not add a PAR::Packer local M::I subclass to inc/ because I'd
> most certainly delete it by accident before doing a release... And it
> seems overkill anyway.
>
> Another route might be to test for some file's existence in the test
> script, but that seems even worse.
>
> Better ideas?
>
> Cheers,
> Steffen

Re: Failed test 'Found the static build of parl in myldr for perl v5.10.0 build for MSWin32-x86-multi-thread

[Mark Dootson]

Hi,

As you found in prior post, the t/10-parl-generation tests will always
fail if you are installing using the downloadable PAR dist.

So, you should run all the tests, and provided that only the
t/10-parl-generation tests fail, you can happily proceed to 'nmake install'.

The correct way to handle this is to skip all the t/10-parl-generation
tests if installing using the downloadable PAR dist.

Regards

Mark



emfee wrote:
> I have installed perl v5.10.0 build for MSWin32-x86-multi-thread for
> ActiveState:
>
> Binary build 1001 [283495] provided by ActiveState
> http://www.ActiveState.com
> Built Dec 18 2007 08:46:15
>
> As there are no ppm packages for PAR::Packer in ppm4.activestate.com I
> have been trying to build it from the sources.
> Doing so, I did succeed for Module-ScanDeps-0.81, PAR-0.977,
> PAR-Dist-0.25 but PAR-Packer-0.977 did give problems.
> nmake did run without errors, but nmake test did give an error:
>
> t/10-parl-generationok 1/31
> #   Failed test 'Found the static build of parl in myldr'
> #   at t/10-parl-generation.t line 26.
> t/10-parl-generationNOK 4/31# Looks like you failed 1 test of 31.
> t/10-parl-generationdubious
>Test returned status 1 (wstat 256, 0x100)
> DIED. FAILED test 4
>Failed 1/31 tests, 96.77% okay (less 27 skipped tests: 3 okay,
> 9.68%)
>
> Debugging this I changed line 26 of 10-parl-generation.t to:
>
> ok(-f $static, 'Found the static build of parl in myldr (static' .
> $Config{_exe} . ' in '. $myldr . ')');
>
> and now the error became:
>
> t/10-parl-generationok 1/31
> t/10-parl-generationNOK 4/31#   Failed test 'Found the static
> build of parl in myldr (static.exe in
> C:\Perl\sources\PAR-Packer-0.977\myldr)'
> #   at t/10-parl-generation.t line 26.
> # Looks like you failed 1 test of 31.
>
> (Makefile.PL is in C:\Perl\sources\PAR-Packer-0.977)
>
> Indeed: in C:\Perl\sources\PAR-Packer-0.977\myldr there is no
> static.exe. Furthermore, there is a par.exe in myldr but with size 0
> bytes.
>
> I found Mark Dootson wrote Tue, 21 Aug 2007 07:04:59 -0700 on this list:
>
>> The t/10-parl-generation tests will always fail if you are installing
>> using the downloadable PAR dist.
>> (PAR-Packer-0.976-MSWin32-x86-multi-thread-5.8.8.par), so that
>> failure can be ignored.
>
>
> I saw indeed "perl Makefile.PL" getting a .par from www.cpan.org
>
> Fetching 'PAR-Packer-0.977-MSWin32-x86-multi-thread-5.10.0.par' from
> www.cpan.org... done!
>
> but I am not sure if I indeed can just ignore this error as the
> 10-parl-generation.t script "says":
>
> if (not -f $static) {
>SKIP: {
>skip "No static parl found. Test script cannot continue!",
> TEST_NO()-4;
>}
>exit();
> }
>
> so the remainder of the tests in 10-parl-generation.t will not be
> executed.
>
> Not good to skip the other tests I think and also par.exe being 0
> bytes is suspicious.
> Anybody any idea how to solve this correctly? I am missing the
> background on how this is supposed to work.
>
> Thanks!
>
> Mike.

Re: cwd in pp

[Mark Dootson]

Hi Steffen,

I did think this trough.

On my Win32 box, as a packed pp exec, test.exe called as

..\..\test.exe

or just test.exe

gets 

C:\fullpath\to\test.exe

in $0.

So, anything that parses $0 and uses the result correctly when it is a script ( 
so gets the right path whether $0 contains C:\fullpath\to\test.exe or 
..\..\test.exe or .\test.exe or test.exe ), will always work when $0 contains a 
full path.

I can't speak for PerlApp - didn't check that out.

Best Regards

Mark


Steffen Mueller wrote:
> Hi Louis-Philippe,
> 
> Louis-Philippe schrieb:
>> Thanks Mark! thats it:
>>
>> script: $0 =
>> /Volumes/KanDriv/svn_repos/alpha/trunk/perl/svn_tools/testDir.pl $^X
>> = /usr/bin/perl
>>
>> with pp: $0 =
>> /Volumes/KanDriv/svn_repos/alpha/trunk/perl/svn_tools/testDir_pp $^X
>> = perl
>>
>> with PerlApp: $0 =
>> /Volumes/KanDriv/svn_repos/alpha/trunk/perl/svn_tools/testDir_perlapp
>>  $^X = perl
>>
>>
>> so that happen to be the most portable way of doing it, this way I
>> don't have to modify my programs to package them with either utility.
> 
> For more detailed information about the various paths involved in a
> PAR-packaged binary, you could read the PAR::Environment POD
> documentation which comes with PAR-Packer. Of course, if this is already
> exactly what you need, that's fine. But please try putting a pp'd binary
> into PATH and executing it from a different path. Is $0 ($^X) still the
> same? If not, one of the PAR environment vars would help.
> 
> Best regards,
> Steffen

Re: cwd in pp

[Mark Dootson]

Hi,

from memory, $0 contains the full path to your exec when packaged.

Try packaging

print qq(\$0 = $0\n);
print qq(\$^X = $^X\n);

and see what it gives you.

This should mean that $0 should always work in packaged code if it worked in 
the script. (I think !!!)

Regards

Mark


Louis-Philippe wrote:
> Hi All,
> 
> I am new to PAR & pp, I discovered it this week when I ran into trouble 
> trying to package scripts with PerlApp that PerlApp wouln't package because 
> of version compatibility... so I tried pp an just felt in love with is 
> simplicity & free nature.  
> 
> so, now I am trying to port my script to pp, and one command is missing from 
> my toolkit:
> in PerlApp, I am aple to call PerlApp::exe() to get the executable file 
> directory,
> something I would do with cwd() inside of a straight .pl script...
> I tried cwd() with a pp executable and it returns the shell working directory 
> (i.e. my home folder).
> anybody knows how to grab the executable directory path with pp?
> 
> thanks!
> 
> l-p

Re: Problems with ActiveState PAR/PP -- procedure entry point error (Summary)

[Mark Dootson]

[EMAIL PROTECTED] wrote:

...
> 
> Mark's solution (with Steffen's installation tip) worked perfectly.
> For future reference, should this be considered a general solution to
> the problem?
> 
..

Hi,

The solution you used will only work with latest ActivePerl (currently 822). It 
was also just one of the steps required for a complete install (dependencies 
etc) - but I figured you had completed all the others.

The full method, assuming you don't have a C compile environment, is to 
download the free nmake from Microsoft, download the PAR::Packer source, and do 
a standard

perl Makefile.pl
nmake
nmake test
nmake install

Even then, this is only ever likely to work if you have the latest ActivePerl. 
(It downloads the same PAR dist that you downloaded manually - which is always 
likely to be compiled against latest ActivePerl)

A solution for everyone, if you can't upgrade your ActivePerl, is to install 
MinGW and build yourself. This is much simpler than you might think.
I have promised to do a 'HOWTO' by putting together all the info offered in 
past threads by several folks with necessary info on the minor changes you have 
to make for different ActivePerl versions. Going forward, you won't have to 
tweak anything because you can use MinGW with ActivePerl from version 822 
without needing any minor tweaks etc.
I just haven't got around to doing it. You only really need a HOWTO if you have 
no experience compiling anything at all OR you want to compile on Vista.

Anyway, glad you got things working.

Regards

Mark

Re: Problems with ActiveState PAR/PP -- procedure entry point error

[Mark Dootson]

Hi,

For ActiveState build 822 you can download the PAR dist from

http://backpan.perl.org/authors/id/S/SM/SMUELLER/PAR-Packer-0.976-MSWin32-x86-multi-thread-5.8.8.par

and install it with:

perl -MPAR::Dist -e"install_par( 
'PAR-Packer-0.976-MSWin32-x86-multi-thread-5.8.8.par' )"


Regards

Mark


[EMAIL PROTECTED] wrote:
> The "procedure entry point" error message is all over various lists/
> groups but I haven't found a good resolution yet.
> 
> Fresh install of ActiveState Perl, Par-Package too.  The error is:
> 
>  The procedure entry point Perl_sv_2iv_flags could not be located
> in the
>  dynamic link library perl58.dll
> 
> I think I understand the explanations given elsewhere, that the PAR
> packager is looking for a different version of Perl58.dll than the one
> that it has.  What I haven't seen is how to resolve it.  Rebuilding
> PAR from scratch, probably not an option for me.  I just need to re-
> distribute a perl program to others...  What versions of what packages
> do I need to install?
> 
> The Perl58.dll version:
> 
> C:\Perl\bin>perl -MWin32 -e "print Win32::GetFileVersion('c:/perl/
> bin/perl58.dll')"
> 588822
> 
> There are no other perl58.dll's on my system.  Par's version:
> 
> C:\Perl\site\bin>pp -V
> PAR Packager, version 0.976 (PAR version 0.976)
> 
> And Perl reports:
> 
> C:\Perl\site\bin>perl -v
> This is perl, v5.8.8 built for MSWin32-x86-multi-thread
> (with 18 registered patches, see perl -V for more detail)
> 
> Copyright 1987-2007, Larry Wall
> 
> Binary build 822 [280952] provided by ActiveState 
> http://www.ActiveState.com
> Built Jul 31 2007 19:34:48
> 
> Is there a resolution to all of this?
> 

Re: Problems with ActiveState PAR/PP -- procedure entry point error

[Mark Dootson]

Hi, 

If your only perl58.dll is the one from ActiveState build 822, then the problem 
is with your PAR packager. It contains an image of perl58.dll from a different 
(earlier) version of Perl.

Where did you get the PAR::Packer modules from?

Regards

Mark


[EMAIL PROTECTED] wrote:
> The "procedure entry point" error message is all over various lists/
> groups but I haven't found a good resolution yet.
> 
> Fresh install of ActiveState Perl, Par-Package too.  The error is:
> 
>  The procedure entry point Perl_sv_2iv_flags could not be located
> in the
>  dynamic link library perl58.dll
> 
> I think I understand the explanations given elsewhere, that the PAR
> packager is looking for a different version of Perl58.dll than the one
> that it has.  What I haven't seen is how to resolve it.  Rebuilding
> PAR from scratch, probably not an option for me.  I just need to re-
> distribute a perl program to others...  What versions of what packages
> do I need to install?
> 
> The Perl58.dll version:
> 
> C:\Perl\bin>perl -MWin32 -e "print Win32::GetFileVersion('c:/perl/
> bin/perl58.dll')"
> 588822
> 
> There are no other perl58.dll's on my system.  Par's version:
> 
> C:\Perl\site\bin>pp -V
> PAR Packager, version 0.976 (PAR version 0.976)
> 
> And Perl reports:
> 
> C:\Perl\site\bin>perl -v
> This is perl, v5.8.8 built for MSWin32-x86-multi-thread
> (with 18 registered patches, see perl -V for more detail)
> 
> Copyright 1987-2007, Larry Wall
> 
> Binary build 822 [280952] provided by ActiveState 
> http://www.ActiveState.com
> Built Jul 31 2007 19:34:48
> 
> Is there a resolution to all of this?
> 

Re: Can't install PAR::Packer 0.976

[Mark Dootson]

Mark Dootson wrote:


mingw-runtime 3.13
gcc 3.4.5
w32api 3.9


looking at wrong environment - doh!

successful build I used was
mingw-runtime 3.12
gcc 3.4.2
w32api 3.9

I doubt it makes any difference - but just in case.

Regards

Mark

Re: Can't install PAR::Packer 0.976

[Mark Dootson]

Hi,

Looks like its your environment / Mingw.

mingw-runtime 3.13
gcc 3.4.5
w32api 3.9

works fine for me with ActivePerl 810.

I'm not too familiar with mingw history - perhaps you need to upgrade your 
Mingw? - maybe you can get way with just updating w32api?
Be sure to check your INCLUDE paths.

Note:

You have to do
perl -MConfig_m makefile.pl
NOT set PERL5OPT=-MConfig_m

the latter causes some later stages in the build to fail.

Regards

Mark


Michael Carman wrote:

Mark Dootson <[EMAIL PROTECTED]> wrote:

You could try installing ExtUtils::FakeConfig.


Good guess, but I'm already using that. I tried both nmake and dmake with the 
same result.

-mjc

Re: Can't install PAR::Packer 0.976

[Mark Dootson]

You could try installing ExtUtils::FakeConfig.
( I think you need the free nmake from msoft for that - dmake didn't work for 
me )

If you want to use dmake , remove nmake from your path after installing 
ExtUtils::FakeConfig.

Then do

set PERL5OPT=-MConfig_m

before you do
perl Makefile.PL
dmake
etc.

Michael Carman wrote:
I'm trying to get pp working, but I'm getting beat down at every turn. I'm 
running Perl 5.8.4 (ActivePerl build 810). I have MinGW 3.1.0-1 installed. When 
I try to build PAR::Packer 0.976 I get the errors below. Can someone who 
understands the guts at least tell me whether the problem is in PAR::Packer or 
my environment?


Unfortunately there doesn't seem to be a binary version available for Perl 
5.8.4. I was able to install the PPM via 
http://theoryx5.uwinnipeg.ca/ppms/PAR-Packer.ppd which is listed as "probably" 
compatible at http://par.wikia.com/wiki/PAR_PPM_Compatibility_List but it dies 
with "Perl lib version (v5.8.4) doesn't match executable version (v5.8.0)."


I'm at an impasse. All advice is appreciated.

C:\Archives\Perl\PAR-Packer-0.976>dmake
cp lib/App/Packer/PAR.pm blib\lib\App\Packer\PAR.pm
cp lib/PAR/Packer.pm blib\lib\PAR\Packer.pm
cp lib/PAR/Filter/Obfuscate.pm blib\lib\PAR\Filter\Obfuscate.pm
cp lib/PAR/Filter/PodStrip.pm blib\lib\PAR\Filter\PodStrip.pm
cp lib/PAR/StrippedPARL/Base.pm blib\lib\PAR\StrippedPARL\Base.pm
cp lib/PAR/Filter.pm blib\lib\PAR\Filter.pm
cp lib/PAR/Filter/PatchContent.pm blib\lib\PAR\Filter\PatchContent.pm
cp lib/PAR/StrippedPARL/Dynamic.pm blib\lib\PAR\StrippedPARL\Dynamic.pm
cp lib/PAR/Filter/Bytecode.pm blib\lib\PAR\Filter\Bytecode.pm
cp lib/pp.pm blib\lib\pp.pm
cp lib/PAR/Filter/Bleach.pm blib\lib\PAR\Filter\Bleach.pm
cp lib/PAR/StrippedPARL/Static.pm blib\lib\PAR\StrippedPARL\Static.pm
C:\Perl\bin\perl.exe sha1.c.PL sha1.c
gcc -c -g -O2 -DWIN32 -DPERL_IMPLICIT_CONTEXT -DPERL_MSVCRT_READFIX  
-I"C:\Perl\lib\CORE" sha1.c
C:\Perl\bin\perl.exe .\file2c.pl C:\Perl\bin\perl58.dll my_perl.c load_me_0 1 
3
gcc -c -g -O2 -DWIN32 -DPERL_IMPLICIT_CONTEXT -DPERL_MSVCRT_READFIX  
-I"C:\Perl\lib\CORE" main.c

C:\Perl\bin\perl.exe .\file2c.pl ..\script\par.pl my_par_pl.c load_me_2 1
gcc -c -g -O2 -DWIN32 -DPERL_IMPLICIT_CONTEXT -DPERL_MSVCRT_READFIX  
-I"C:\Perl\lib\CORE" my_par_pl.c
gcc main.o my_par_pl.o win32.coff -s   -g -L"C:\Perl\lib\CORE"  
C:\Perl\lib\CORE\libperl58.a C:\Ming
w\lib\libmsvcrt.a C:\Mingw\lib\libmoldname.a C:\Mingw\lib\libkernel32.a 
C:\Mingw\lib\libuser32.a C:\
Mingw\lib\libgdi32.a C:\Mingw\lib\libwinspool.a C:\Mingw\lib\libcomdlg32.a 
C:\Mingw\lib\libadvapi32.
a C:\Mingw\lib\libshell32.a C:\Mingw\lib\libole32.a C:\Mingw\lib\liboleaut32.a 
C:\Mingw\lib\libnetap
i32.a C:\Mingw\lib\libuuid.a C:\Mingw\lib\libwsock32.a C:\Mingw\lib\libmpr.a 
C:\Mingw\lib\libwinmm.a

 C:\Mingw\lib\libversion.a C:\Mingw\lib\libodbc32.a --output .\par.exe
Info: resolving ___mb_cur_max by linking to __impmb_cur_max (auto-import)
Info: resolving __pctype by linking to __imp___pctype (auto-import)
main.o(.text+0x391): In function `par_findprog':
C:/Archives/Perl/PAR-Packer-0.976/myldr/utils.c:96: undefined reference to 
`GetModuleFileNameA'

main.o(.text+0x1fe8): In function `par_mktmpdir':
C:/Archives/Perl/PAR-Packer-0.976/myldr/mktmpdir.c:74: undefined reference to 
`GetUserNameA'

main.o(.text+0x2585): In function `par_rmtmpdir':
C:/Archives/Perl/PAR-Packer-0.976/myldr/mktmpdir.c:230: undefined reference to 
`GetModuleHandleA'

main.o(.text+0x25b5):C:/Archives/Perl/PAR-Packer-0.976/myldr/mktmpdir.c:233:
  undefined reference to `FreeLibrary'
main.o(.text+0x2677):C:/Archives/Perl/PAR-Packer-0.976/myldr/mktmpdir.c:251:
  undefined reference to `GetModuleHandleA'
main.o(.text+0x26af):C:/Archives/Perl/PAR-Packer-0.976/myldr/mktmpdir.c:254:
  undefined reference to `FreeLibrary'
fu01.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname'
fu03.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname'
nmth00.o(.idata$4+0x0): undefined reference to `_nmmb_cur_max'
nmth02.o(.idata$4+0x0): undefined reference to `_nm___pctype'
dmake.exe:  Error code 1, while making '.\par.exe'
dmake.exe:  Error code 255, while making 'subdirs'

ActivePerl binaries for PAR Packer

[Mark Dootson]

All,

I decided to check how easy it is to setup mingw32 to build PAR::Packer.

The steps followed were:

Download mingw32 installer ( 1 file ).
Run it and accept default options to install mingw32.
Download and extract dmake from CPAN
Create a batch file to setup build environment (PATH, LIB, INCLUDE)
Create libperl58.a (not sure I actually needed this)

from command prompt opened via batch file
perl makefile.PL
dmake
dmake test
dmake install

and I have a working PAR::Packer.
I'm using ActivePerl build 822.
I think 820 would need ExtUtils::FakeConfig too. (I've not tested if it would 
actually work on that build though).

Maybe its time for a HOWTO and to mention this as the preferred way to get 
PAR::Packer. It seemed quite simple.
May as well take advantage of the effort ActiveState have put in for mingw32 
compatibility.

The binary installs do seem to cause a lot of grief over versions.

I'll author the HOWTO if wanted.

Regards

Mark

Re: PAR::Packer on Windows Vista

[Mark Dootson]

Again - with correction to silly mistake
Could you try the following test:

Open a command prompt.
Enter the following command:

set PATH=C:\Perl\bin;C:\Perl\site\bin;%PATH%

Then change directory to your script dir:

cd C:\Users\deadpickle\Desktop

Then check the pp version (do not put the full path to pp)

pp -V

Then try to package your test script

pp -o test.exe GRRUVI-windowed-v1.004.pl


What are the results?

Regards

Mark


Mark Dootson wrote:

Jamie,

Could you try the following test:

Open a command prompt.
Enter the following command:

set PATH=C:\Perl\bin;C:\Perl\site\bin;%PATH%

Then change directory to your script dir:

cd C:\Users\deadpickle\Desktop\GRRUVI-windowed-v1.004.pl

Then check the pp version (do not put the full path to pp)

pp -V

Then try to package your test script

pp -o test.exe GRRUVI-windowed-v1.004.pl


What are the results?


Regards

Mark



Jamie Lahowetz wrote:

I tried packing a test.exe using:
C:\Perl\site\bin>pp -o C:\Users\deadpickle\Desktop\test.exe
C:\Users\deadpickle\
Desktop\GRRUVI-windowed-v1.004.pl

and recieved this error:
parloQXY.exe - Entry Point Not Found: The procedure entry point
Perl_sv_2iv_flags could not be located in the dynamic link library
perl58.dll

And this in the terminal window:
Can't load 'C:/Perl/lib/auto/IO/IO.dll' for module IO: load_file:The
specified p
rocedure could not be found at C:/Perl/lib/XSLoader.pm line 64.
 at C:/Perl/lib/IO.pm line 11
Compilation failed in require at C:/Perl/lib/IO/Handle.pm line 263.
BEGIN failed--compilation aborted at C:/Perl/lib/IO/Handle.pm line 263.
Compilation failed in require at C:/Perl/lib/IO/Seekable.pm line 101.
BEGIN failed--compilation aborted at C:/Perl/lib/IO/Seekable.pm line 101.
Compilation failed in require at C:/Perl/lib/IO/File.pm line 133.
BEGIN failed--compilation aborted at C:/Perl/lib/IO/File.pm line 133.
Compilation failed in require at -e line 405.
pp: Failed to extract a parl from 'PAR::StrippedPARL::Static' to file
'parl7zp57
i2.exe' at C:/Perl/site/lib/PAR/Packer.pm line 1149,  line 1.

Any help in this would be great.

On 8/21/07, Jamie Lahowetz <[EMAIL PROTECTED]> wrote:

The ActiveState Perl build I am using is 822. When installing PAR-Packer
using AS the files are automatically put in C:\Perl\site\bin. I added 
this
to the windows path (assuming that is what you mean). It still will 
not run
giving that pp is not an external command in cmd prompt. I did verify 
that
pp.bat is in that directory and does exist. I may have to just 
navigate to

the file to run pp.

--
Jamie Lahowetz

Re: PAR::Packer on Windows Vista

[Mark Dootson]

Jamie,

Could you try the following test:

Open a command prompt.
Enter the following command:

set PATH=C:\Perl\bin;C:\Perl\site\bin;%PATH%

Then change directory to your script dir:

cd C:\Users\deadpickle\Desktop\GRRUVI-windowed-v1.004.pl

Then check the pp version (do not put the full path to pp)

pp -V

Then try to package your test script

pp -o test.exe GRRUVI-windowed-v1.004.pl


What are the results?


Regards

Mark



Jamie Lahowetz wrote:

I tried packing a test.exe using:
C:\Perl\site\bin>pp -o C:\Users\deadpickle\Desktop\test.exe
C:\Users\deadpickle\
Desktop\GRRUVI-windowed-v1.004.pl

and recieved this error:
parloQXY.exe - Entry Point Not Found: The procedure entry point
Perl_sv_2iv_flags could not be located in the dynamic link library
perl58.dll

And this in the terminal window:
Can't load 'C:/Perl/lib/auto/IO/IO.dll' for module IO: load_file:The
specified p
rocedure could not be found at C:/Perl/lib/XSLoader.pm line 64.
 at C:/Perl/lib/IO.pm line 11
Compilation failed in require at C:/Perl/lib/IO/Handle.pm line 263.
BEGIN failed--compilation aborted at C:/Perl/lib/IO/Handle.pm line 263.
Compilation failed in require at C:/Perl/lib/IO/Seekable.pm line 101.
BEGIN failed--compilation aborted at C:/Perl/lib/IO/Seekable.pm line 101.
Compilation failed in require at C:/Perl/lib/IO/File.pm line 133.
BEGIN failed--compilation aborted at C:/Perl/lib/IO/File.pm line 133.
Compilation failed in require at -e line 405.
pp: Failed to extract a parl from 'PAR::StrippedPARL::Static' to file
'parl7zp57
i2.exe' at C:/Perl/site/lib/PAR/Packer.pm line 1149,  line 1.

Any help in this would be great.

On 8/21/07, Jamie Lahowetz <[EMAIL PROTECTED]> wrote:

The ActiveState Perl build I am using is 822. When installing PAR-Packer
using AS the files are automatically put in C:\Perl\site\bin. I added this
to the windows path (assuming that is what you mean). It still will not run
giving that pp is not an external command in cmd prompt. I did verify that
pp.bat is in that directory and does exist. I may have to just navigate to
the file to run pp.

--
Jamie Lahowetz

Re: PAR::Packer on Windows Vista

[Mark Dootson]

Hi,

Steffen Mueller wrote:


I haven't looked at this at all, but do you think it would be possible
to either make them pass or have them skipped in this use case?


Should be straightforward to skip any inappropriate tests. I'll have time to 
make and test a simple patch later in the week so if no-one gets there before 
me, I'll do that then.

Regards

Mark

Re: PAR::Packer on Windows Vista

[Mark Dootson]

Hi,

Had a chance for a better look at this.

The t/10-parl-generation tests will always fail if you are installing using the 
downloadable PAR dist. (PAR-Packer-0.976-MSWin32-x86-multi-thread-5.8.8.par), 
so that failure can be ignored.

Your Config (dependent on version of ActivePerl) causes scripts & execs to be installed in 
C:\Perl\site\bin


You need this on your path - which it doesn't seem to be.

I think the site/bin issue is solved in recent ActivePerl releases - either 
Config.pm is changed or MSI puts c:\Perl\Site|bin on your path (or both).

So putting C:\Perl\site\bin on your path will mean that 'pp' can be run. 
Whether it works or not is another matter. That will depend on your ActivePerl 
build.

My guess is that PAR-Packer-0.976-MSWin32-x86-multi-thread-5.8.8.par will 
probably work with ActivePerl builds 820 and 822 but almost certainly won't 
work with earlier releases.


Regards

Mark  





Jamie Lahowetz wrote:

I'm trying to install PAR-Packer of my windows Vista machine. I first tried
this using Perl Package Manager on ActivePerl with version 0.976. Didnt
work. Now I'm trying to install version 0.976 using nmake. Here is the
output:

C:\Users\deadpickle\Desktop\PAR-Packer-0.976>perl Makefile.PL
Fetching 'PAR-Packer-0.976-MSWin32-x86-multi-thread-5.8.8.par' from
www.cpan.org
... done!
Checking if your kit is complete...
Looks good
Writing Makefile for PAR::Packer

C:\Users\deadpickle\Desktop\PAR-Packer-0.976>nmake

Microsoft (R) Program Maintenance Utility   Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.

 C:\Perl\bin\perl.exe "-Minc::Module::Install" -e
"extract_par(q(PAR-Pac
ker-0.976-MSWin32-x86-multi-thread-5.8.8.par))"
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/tkpp
blib\
script\tkpp
pl2bat.bat blib\script\tkpp
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/pp
blib\sc
ript\pp
pl2bat.bat blib\script\pp
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/par.pl
bli
b\script\par.pl
pl2bat.bat blib\script\par.pl

C:\Users\deadpickle\Desktop\PAR-Packer-0.976>nmake test

Microsoft (R) Program Maintenance Utility   Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.

C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/tkpp
blib\
script\tkpp
pl2bat.bat blib\script\tkpp
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/pp
blib\sc
ript\pp
pl2bat.bat blib\script\pp
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/par.pl
bli
b\script\par.pl
pl2bat.bat blib\script\par.pl
C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0,
'in
c', 'blib\lib', 'blib\arch')" t/*.t
t/00-podskipped
all skipped: Set environment variable PERL_TEST_POD=1 to test POD
t/10-parl-generationok 1/31
#   Failed test 'Found the static build of parl in myldr'
t/10-parl-generationNOK 4/31#   at t/10-parl-generation.t line 26.
# Looks like you failed 1 test of 31.
t/10-parl-generationdubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 4
Failed 1/31 tests, 96.77% okay (less 27 skipped tests: 3 okay, 9.68%
)
t/20-pp.ok
t/30-current_exec...# Please wait
t/30-current_exec...ok
1/4 skipped: various reasons
Failed TestStat Wstat Total Fail  List of Failed
---
t/10-parl-generation.t1   256311  4
1 test and 28 subtests skipped.
Failed 1/4 test scripts. 1/69 subtests failed.
Files=4, Tests=69, 1050 wallclock secs ( 0.00 cusr +  0.00 csys =  0.00 CPU)
Failed 1/4 test programs. 1/69 subtests failed.
NMAKE : fatal error U1077: 'C:\Windows\system32\cmd.exe' : return code
'0xff'
Stop.

C:\Users\deadpickle\Desktop\PAR-Packer-0.976>nmake install

Microsoft (R) Program Maintenance Utility   Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.

 C:\Perl\bin\perl.exe "-Minc::Module::Install" -e
"extract_par(q(PAR-Pac
ker-0.976-MSWin32-x86-multi-thread-5.8.8.par))"
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/tkpp
blib\
script\tkpp
pl2bat.bat blib\script\tkpp
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/pp
blib\sc
ript\pp
pl2bat.bat blib\script\pp
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/par.pl
bli
b\script\par.pl
pl2bat.bat blib\script\par.pl
Installing C:\Perl\html\bin\par.html
Installing C:\Perl\html\bin\tkpp.html
Installing C:\Perl\html\site\lib\pp.html
Installing C:\Perl\html\site\lib\App\Packer\PAR.html
Installing C:\Perl\html\site\lib\PAR\Filter.html
Installing C:\Perl\html\site\lib\PAR\Packer.html
Installing C:\Perl\html\site\lib\PAR\Filter\Bleach.html
Installing C:\Perl\html\site\lib\PAR\Filter\Bytecode.html
Installing C:\Perl\html\site\lib\PAR\Filter\Obfuscate.ht

Re: PAR::Packer on Windows Vista

[Mark Dootson]

Hi,

Which build of ActivePerl are you using?

perl -e"print Win32::BuildNumber() . qq(\n)"

The 'PAR-Packer-0.976-MSWin32-x86-multi-thread-5.8.8.par' is built against 
ActivePerl build 822 and probably won't work with previous releases.

I have no idea if it is this that is causing the particular error messages you 
are seeing. If you can confirm the build number I will check this out.

Regards

Mark




Jamie Lahowetz wrote:

I'm trying to install PAR-Packer of my windows Vista machine. I first tried
this using Perl Package Manager on ActivePerl with version 0.976. Didnt
work. Now I'm trying to install version 0.976 using nmake. Here is the
output:

C:\Users\deadpickle\Desktop\PAR-Packer-0.976>perl Makefile.PL
Fetching 'PAR-Packer-0.976-MSWin32-x86-multi-thread-5.8.8.par' from
www.cpan.org
... done!
Checking if your kit is complete...
Looks good
Writing Makefile for PAR::Packer

C:\Users\deadpickle\Desktop\PAR-Packer-0.976>nmake

Microsoft (R) Program Maintenance Utility   Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.

 C:\Perl\bin\perl.exe "-Minc::Module::Install" -e
"extract_par(q(PAR-Pac
ker-0.976-MSWin32-x86-multi-thread-5.8.8.par))"
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/tkpp
blib\
script\tkpp
pl2bat.bat blib\script\tkpp
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/pp
blib\sc
ript\pp
pl2bat.bat blib\script\pp
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/par.pl
bli
b\script\par.pl
pl2bat.bat blib\script\par.pl

C:\Users\deadpickle\Desktop\PAR-Packer-0.976>nmake test

Microsoft (R) Program Maintenance Utility   Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.

C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/tkpp
blib\
script\tkpp
pl2bat.bat blib\script\tkpp
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/pp
blib\sc
ript\pp
pl2bat.bat blib\script\pp
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/par.pl
bli
b\script\par.pl
pl2bat.bat blib\script\par.pl
C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0,
'in
c', 'blib\lib', 'blib\arch')" t/*.t
t/00-podskipped
all skipped: Set environment variable PERL_TEST_POD=1 to test POD
t/10-parl-generationok 1/31
#   Failed test 'Found the static build of parl in myldr'
t/10-parl-generationNOK 4/31#   at t/10-parl-generation.t line 26.
# Looks like you failed 1 test of 31.
t/10-parl-generationdubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 4
Failed 1/31 tests, 96.77% okay (less 27 skipped tests: 3 okay, 9.68%
)
t/20-pp.ok
t/30-current_exec...# Please wait
t/30-current_exec...ok
1/4 skipped: various reasons
Failed TestStat Wstat Total Fail  List of Failed
---
t/10-parl-generation.t1   256311  4
1 test and 28 subtests skipped.
Failed 1/4 test scripts. 1/69 subtests failed.
Files=4, Tests=69, 1050 wallclock secs ( 0.00 cusr +  0.00 csys =  0.00 CPU)
Failed 1/4 test programs. 1/69 subtests failed.
NMAKE : fatal error U1077: 'C:\Windows\system32\cmd.exe' : return code
'0xff'
Stop.

C:\Users\deadpickle\Desktop\PAR-Packer-0.976>nmake install

Microsoft (R) Program Maintenance Utility   Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.

 C:\Perl\bin\perl.exe "-Minc::Module::Install" -e
"extract_par(q(PAR-Pac
ker-0.976-MSWin32-x86-multi-thread-5.8.8.par))"
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/tkpp
blib\
script\tkpp
pl2bat.bat blib\script\tkpp
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/pp
blib\sc
ript\pp
pl2bat.bat blib\script\pp
C:\Perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e cp script/par.pl
bli
b\script\par.pl
pl2bat.bat blib\script\par.pl
Installing C:\Perl\html\bin\par.html
Installing C:\Perl\html\bin\tkpp.html
Installing C:\Perl\html\site\lib\pp.html
Installing C:\Perl\html\site\lib\App\Packer\PAR.html
Installing C:\Perl\html\site\lib\PAR\Filter.html
Installing C:\Perl\html\site\lib\PAR\Packer.html
Installing C:\Perl\html\site\lib\PAR\Filter\Bleach.html
Installing C:\Perl\html\site\lib\PAR\Filter\Bytecode.html
Installing C:\Perl\html\site\lib\PAR\Filter\Obfuscate.html
Installing C:\Perl\html\site\lib\PAR\Filter\PatchContent.html
Installing C:\Perl\html\site\lib\PAR\Filter\PodStrip.html
Installing C:\Perl\html\site\lib\PAR\StrippedPARL\Base.html
Installing C:\Perl\html\site\lib\PAR\StrippedPARL\Dynamic.html
Installing C:\Perl\html\site\lib\PAR\StrippedPARL\Static.html
Installing C:\Perl\site\lib\pp.pm
Installing C:\Perl\site\lib\App\Packer\PAR.pm
Installing C:\Perl\site\lib\PAR\Filter.pm
Installing C:\Perl\site\lib\PAR\Packer.pm
Installing C:\Perl\site\lib\PAR\Filter\Bleach

Re: Temporary file left behind when including icon file

[Mark Dootson]

committed to svn.

Steve Hay wrote:
> Works well for me too, so it's probably worth committing.
> 
> Thanks!
>  
> 
> -Original Message-----
> From: Mark Dootson [mailto:[EMAIL PROTECTED] 
> Sent: 13 August 2007 19:28
> To: Steve Hay
> Cc: par@perl.org
> Subject: Re: Temporary file left behind when including icon file
> 
> Hi,
> 
> Attached small patch *I think* does the right thing. Certainly, it gets
> rid of the temp file and seems to work OK with my limited testing.
> 
> Regards
> 
> Mark 
> 
> Steve Hay wrote:
>> If I run
>>
>> pp -i command.ico -o test.exe test.pl
>>
>> on the "Hello, world" program (in test.pl), where command.ico is the
>> attached Win32 icon file, I find that I get a temporary executable
> file
>> with a name like "parl6z2zdSc.exe" left behind as well as the desired
>> "test.exe".
>>
>> The temporary file does not get left if I don't specify the -i option
> on
>> the command-line.
>>
>> Any ideas how to stop the temporary file getting left? It doesn't have
> a
>> fixed name, so all I can do at the moment in scripts that I have for
>> building things is to delete "parl*.exe" and hope that it doesn't
> catch
>> anything unintentional.
>>
>> Versions:
>> perl-5.8.8
>> PAR-0.976
>> PAR-Dist-0.25
>> PAR-Packer-0.976
>> Parse-Binary-0.10
>> Win32-Exe-0.11
>>
>>
>>
> 
> 

Re: Temporary file left behind when including icon file

[Mark Dootson]

Hi,

Attached small patch *I think* does the right thing. Certainly, it gets rid of 
the temp file and seems to work OK with my limited testing.

Regards

Mark 

Steve Hay wrote:
> If I run
> 
> pp -i command.ico -o test.exe test.pl
> 
> on the "Hello, world" program (in test.pl), where command.ico is the
> attached Win32 icon file, I find that I get a temporary executable file
> with a name like "parl6z2zdSc.exe" left behind as well as the desired
> "test.exe".
> 
> The temporary file does not get left if I don't specify the -i option on
> the command-line.
> 
> Any ideas how to stop the temporary file getting left? It doesn't have a
> fixed name, so all I can do at the moment in scripts that I have for
> building things is to delete "parl*.exe" and hope that it doesn't catch
> anything unintentional.
> 
> Versions:
> perl-5.8.8
> PAR-0.976
> PAR-Dist-0.25
> PAR-Packer-0.976
> Parse-Binary-0.10
> Win32-Exe-0.11
> 
> 
> 
> 

Index: Packer.pm
===
--- Packer.pm   (revision 519)
+++ Packer.pm   (working copy)
@@ -1253,6 +1253,7 @@
 
 $self->_fix_console();
 unlink($self->{parl});
+unlink($self->{orig_parl});
 unlink("$self->{parl}.bak");
 return;
 }

Re: command line error

[Mark Dootson]

Eric Wilhelm wrote:

> 
> A little here + a little there + a little more = bloat.  No, it's not 
> optimal as-is, but I don't think that makes a good excuse to make it 
> less so.
> 

On reflection, getting past the 'lets have a --bloat-flag' and "Haven't got a 
clue" sillyness, I think you may well be right.

My initial post came out of the fact that the only real world situation I have 
come across where a dependency on attributes.pm was missed by M::SD isn't fixed 
by "if threads::shared add attributes". My feeling is that this will add 
attributes.pm when it isn't needed and miss it when it is needed, at least as 
often as it turns out to be the right thing to do. So, I think the only 
realistic  way you can cope with attributes by default is to add attributes.pm 
to your default list.

However,there is an established method of adding known dependencies to M::SD. 
So I can see the reasoning for not doing anything specific for attributes.pm 
itself.

IF it were the case that

pp -o my.exe my.pl

gave you a working exec in 99.9% of cases, then the case for including 
attributes.pm by default would be stronger, I think. But in the real world, you 
will almost certainly have to read the pp POD and understand how to include 
modules and libs, and work out when pp misses the odd module. As Steffen says, 
it is a developer tool.

So, I'll turncoat and switch my vote for the 'do nothing' option.

Regards

Mark

Re: command line error

[Mark Dootson]

Oh well.

I did say it was just my vote. 

I don't regard the addition of attributes.pm as bloat, nor would I feel 
qualified to use the phrase "I don't have a clue what I'm doing" in connection 
with a user who had difficulty figuring out why pp didn't work. I don't think 
users should have to figure out why pp doesn't work.

It seems to me that being able to type 'pp' and just have it work without 
really having to know how or why is a desirable goal. If adding the module 
attributes.pm to the mix helps to achieve that then that seems a good thing to 
me.

I know I use tools and technologies every day without having the first clue how 
they actually work - so maybe I'm in the "haven't got a clue" section.

Perhaps we could have a "--miss-out-essential-bits-flag" for use by the 
cognoscenti which would allow them to bring the full and mighty weight of their 
knowledge to bear, and have 'pp' just produce working execs for the rest of us?


Mark




Eric Wilhelm wrote:
> # from Mark Dootson
> # on Monday 25 June 2007 10:09 am:
> 
>> I think it might be best to add attributes.pm by default as an
>> implicitly required module.
> 
> I have to disagree.  The compiler will tell you if you need it or not.  
> Adding it "in case someone might need it" seems too capable of creating 
> bloat.
> 
> Perhaps a --bloat flag?  At least a --nobloat option please.
> 
> It really comes down to whether pp/M::SD intend to support "I know what 
> I'm doing" usage or "I don't have a clue what I'm doing" usage.  Both 
> have their uses, but I prefer to not let ease-of-learning interfere 
> with power and ease-of-use.
> 
> --Eric

Re: command line error

[Mark Dootson]

Re attributes.pm

I think it might be best to add attributes.pm by default as an implicitly 
required module.

You don't necessarily have to 'use threads::shared' anywhere in your script 
just because you do

my $val : shared;

so the answer isn't really adding code that relies on 'threads::shared';

My vote would be for adding attributes.pm to the implicitly required list.


Regards

Mark



Roderich Schupp wrote:
> On 6/25/07, deadpickle <[EMAIL PROTECTED]> wrote:
>> > pp -o GWC.exe -Mattributes GWC.pl
>> >
>> It worked!!
>>
>> > If this works, we still need to figure out why attributes.pm wasn't
>> detected.
>> > Can you post your script?
>>
>> It is a large script, but sure if no body minds:
>> PS the attribute error is on line 11.
>> ...
>> my $user:shared = 'uas';
> 
> Thanks, that's a straightforward use of attributes.
> 
> I just checked Module::ScanDeps and it currently has no provision to detect
> the use of attributes. AFAICT, it would be non-trivial to add this,
> because M::SD would have to look at every "sub ..." and "my ..." statement
> which it currently doesn't.
> 
> But Eric Wilhelm <[EMAIL PROTECTED]>'s suggestion
> to infer "attributes.pm" whenever we see "use threads::shared"
> (because that makes usage of attribute ":shared" highly likely)
> is very good. I'll add that to M::SD later in the day.
> 
> Cheers, Roderich

Re: command line error

[Mark Dootson]

pp moved to separate package.

It is now part of PAR::Packer.

Install PAR::Packer.

Regards

Mark


deadpickle wrote:
> C:\Documents and Settings\deadpickle\Desktop\PAR-0.973>perl
> Makefile.PL
> Set up gcc environment - 3.2 (mingw special 20020817-1)
> *** Module::AutoInstall version 1.03
> *** Checking for Perl dependencies...
> [Core Features]
> - File::Temp ...loaded. (0.18 >= 0.05)
> - Compress::Zlib ...loaded. (1.42 >= 1.16)
> - Archive::Zip   ...loaded. (1.20 >= 1)
> - PAR::Dist  ...loaded. (0.22 >= 0.21)
> - AutoLoader ...loaded. (5.63 >= 5.62)
> *** Module::AutoInstall configuration finished.
> Checking if your kit is complete...
> Looks good
> Writing Makefile for PAR
> 
> C:\Documents and Settings\deadpickle\Desktop\PAR-0.973>nmake
> 
> cp lib/PAR/FAQ.pod blib\lib\PAR\FAQ.pod
> cp lib/PAR/Tutorial.pod blib\lib\PAR\Tutorial.pod
> cp lib/PAR/Environment.pod blib\lib\PAR\Environment.pod
> cp lib/PAR/Heavy.pm blib\lib\PAR\Heavy.pm
> cp lib/PAR.pm blib\lib\PAR.pm
> 
> C:\Documents and Settings\deadpickle\Desktop\PAR-0.973>nmake test
> 
> C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e"
> "test_harness(0, 'in
> c', 'blib\lib', 'blib\arch')" t/00-pod.t t/01-basic.t t/40-par-
> hashref.t t/50-au
> toloaderfix.t
> t/00-pod..skipped
> all skipped: Set environment variable PERL_TEST_POD=1 to test
> POD
> t/01-basicok
> t/40-par-hashref..ok
> t/50-autoloaderfixok
> All tests successful, 1 test skipped.
> Files=4, Tests=16,  3 wallclock secs ( 0.00 cusr +  0.00 csys =  0.00
> CPU)
> 
> C:\Documents and Settings\deadpickle\Desktop\PAR-0.973>nmake install
> 
> Installing C:\Perl\html\site\lib\PAR.html
> Installing C:\Perl\html\site\lib\PAR\Environment.html
> Installing C:\Perl\html\site\lib\PAR\FAQ.html
> Installing C:\Perl\html\site\lib\PAR\Heavy.html
> Installing C:\Perl\html\site\lib\PAR\Tutorial.html
> Installing C:\Perl\site\lib\PAR.pm
> Installing C:\Perl\site\lib\PAR\Environment.pod
> Installing C:\Perl\site\lib\PAR\FAQ.pod
> Installing C:\Perl\site\lib\PAR\Heavy.pm
> Installing C:\Perl\site\lib\PAR\Tutorial.pod
> Writing C:\Perl\site\lib\auto\PAR\.packlist
> Appending installation info to C:\Perl\lib/perllocal.pod
> 
> but after the install i tried typing 'pp' to get the config options
> and recieved this error:
> 
> C:\Documents and Settings\deadpickle\Desktop\PAR-0.973>pp
> 'pp' is not recognized as an internal or external command,
> operable program or batch file.
> 
> How can I remedy this?
> 

Re: Problem using PAR with OpenPGP?

[Mark Dootson]

pp -x -o prog.exe script.pl

produces working exec from your test script in script.pl

There are some dependencies missed by basic scan that -x option picks up.

Regards

Mark



misoldgit wrote:
> On 17 May, 11:40, [EMAIL PROTECTED] (Steffen Mueller) wrote:
>> misoldgit schrieb:
>>
>>
>>
>>
>>
>>> Binary build 820 [274739] provided by ActiveStatehttp://www.ActiveState.com
>>> Built Jan 23 2007 15:57:46
>>> ┌──┬──┬─┬──­┐
>>> │ name │ version  │ abstract│
>>> area │
>>> ├──┼──┼─┼──­┤
>>> │ HTML-Parser  │ 3.56 │ Parsing of HTML documents   │
>>> perl │
>>> │ Math-Pari│ 2.010603 │ │
>>> site │
>>> │ PAR  │ 0.90 │ Perl Archive Tookit │
>>> site │
>>> │ PAR-Dist │ 0.22 │ Create and manipulate PAR distributions │
>>> site │
>>> │ PAR-Packer   │ 0.973│ PAR Packager│
>>> site │
>>> │ Parse-Binary │ 0.10 │ │
>>> site │
>>> │ XML-Parser   │ 2.34-r1  │ Parsing of XML documents│
>>> perl │
>>> └──┴──┴─┴──­┘
>> Whoa there!
>>
>> Before version 0.970 of PAR, PAR and PAR::Packer were both part of a
>> monolithic PAR package. Having PAR 0.90 and PAR::Packer 0.973 installed
>> at the same time is absolutely a problem. I.e. they both provide a pp
>> script, etc.
>>
>> If you installed PAR+PAR::Packer from a dependency-aware source (like
>> using the CPAN.pm client), the installer would have told you about this
>> problem and upgraded your PAR to the version required by the
>> corresponding PAR::Packer.
>>
>> It seems you installed PAR from the ActiveState PPM repository. That
>> repository is *severely* out of date regarding PAR. Can't blame them,
>> they sell a similar tool (PerlApp as part of their Perl Dev Kit).
>>
>> I suggest installing compatible versions of PAR and PAR::Packer such as
>> those from bribes.org. Note that I'm not saying that this will magically
>> fix all problems you might have with OpenPGP, but the setup as it stands
>> is *asking* for trouble.
>>
>> Cheers,
>> Steffen- Hide quoted text -
>>
>> - Show quoted text -
> 
> Hi guys,
> 
> OK I've tried to reply through this google interface twice now and it
> doesnt seem to take it - this may be due to the unicode text boxes
> that the new version of ppm puts round it's the module version output.
> 
> I have changed the version of Perl to 5.8.8.820 AND the versions of
> Par-packer etc per your instructions. It didnt seem to fix the
> problem.
> 
> BUT I think I've found the issue. The contents of @INC are different
> when the code is run natively to when it's run from the .exe:
> 
> When running the program .pl file:
> 
> @INC = C:/Perl/site/lib C:/Perl/lib .
> 
> When running the program via a .exe file:
> 
> @INC = C:\DOCUME~1\misoldgit\LOCALS~1\Temp\par-misoldgit
> \cache-1179417278/inc/lib C:\DOCUME~1\misoldgit\LOCALS~1\Temp\par-
> misoldgit\cache-1179417278/inc CODE(0xd5952c) .
> 
> So I manually re-assigned @INC to the correct paths within the program
> and voila! it works.
> 
> Guys, many thanks for all your help!

Re: Are parl/pp the right tools?

[Mark Dootson]

I've found where I picked up this idea from.

On the Perl Foundation pages there is a copy of Artistic License 2.0 together 
with notes.

I interpret Section 8 of Artistic 2.0 as meaning you can't do
'mypacked.exe anyoldscript.pl'

But its all moot anyway as we are talking perl5 and Artistic 1.0.

Once again - sorry for FUD!!

Mark

Mark Dootson wrote:
> Hi,
> 
> I stand corrected then.
> I always thought 'mypacked.exe anyoldscript.pl' would NOT be OK.
> 
> Sorry for creating FUD!!
> 
> Mark
> 
> Steffen Mueller wrote:
>> Mark Dootson schrieb:
>>> Duncan Murdoch wrote:
>>>
>>>> 2.  Can you run a script that's not in the .par file, but look in
>>>> there for any modules it depends on?  For example, I'd like to do
>>>> something like the line above even though subdir/baz.pl was not in
>>>> foo.par.
>>> It is probably possible but it is a generally accepted interpretation
>>> of the Perl License that you may not create executables with a
>>> packager (PAR, PerlApp etc) that can run arbitrary external perl
>>> scripts on systems without a Perl installed.
>> I think what Duncan was intending to do was something like
>>
>> perl foo.pl
>>
>> with foo.pl loading modules from some.par.
>>
>>> So, having an executable mypacked.exe
>>>
>>> that can do
>>>
>>> mypacked.exe anyoldscript.pl
>>>
>>> on a system without Perl installed, is at the very least in a grey
>>> area as far as the Perl License is concerned.
>>>
>>> I only post this to flag up a potential issue that you may not have
>>> considered. I may be completely wrong and "mypacked.exe
>>> anyoldscript.pl" might be fine. I just always understood that you
>>> could not do this and should distribute Perl instead.
>> I am not aware that this (i.e. your scenario, not the one I point to
>> above!) is violating perl's license. In fact, I am somewhat confident
>> that it's fine. I suppose only Larry, the perl5-porters or lawyers can
>> answer this question definitely, though.
>>
>> Steffen
> 
> 

Re: Are parl/pp the right tools?

[Mark Dootson]

Hi,

I stand corrected then.
I always thought 'mypacked.exe anyoldscript.pl' would NOT be OK.

Sorry for creating FUD!!

Mark

Steffen Mueller wrote:
> Mark Dootson schrieb:
>> Duncan Murdoch wrote:
>>
>>> 2.  Can you run a script that's not in the .par file, but look in
>>> there for any modules it depends on?  For example, I'd like to do
>>> something like the line above even though subdir/baz.pl was not in
>>> foo.par.
>>
>> It is probably possible but it is a generally accepted interpretation
>> of the Perl License that you may not create executables with a
>> packager (PAR, PerlApp etc) that can run arbitrary external perl
>> scripts on systems without a Perl installed.
> 
> I think what Duncan was intending to do was something like
> 
> perl foo.pl
> 
> with foo.pl loading modules from some.par.
> 
>> So, having an executable mypacked.exe
>>
>> that can do
>>
>> mypacked.exe anyoldscript.pl
>>
>> on a system without Perl installed, is at the very least in a grey
>> area as far as the Perl License is concerned.
>>
>> I only post this to flag up a potential issue that you may not have
>> considered. I may be completely wrong and "mypacked.exe
>> anyoldscript.pl" might be fine. I just always understood that you
>> could not do this and should distribute Perl instead.
> 
> I am not aware that this (i.e. your scenario, not the one I point to
> above!) is violating perl's license. In fact, I am somewhat confident
> that it's fine. I suppose only Larry, the perl5-porters or lawyers can
> answer this question definitely, though.
> 
> Steffen

Re: Are parl/pp the right tools?

[Mark Dootson]

Duncan Murdoch wrote:

> 2.  Can you run a script that's not in the .par file, but look in there
> for any modules it depends on?  For example, I'd like to do something
> like the line above even though subdir/baz.pl was not in foo.par.
> 

It is probably possible but it is a generally accepted interpretation of the 
Perl License that you may not create executables with a packager (PAR, PerlApp 
etc) that can run arbitrary external perl scripts on systems without a Perl 
installed.

So, having an executable mypacked.exe

that can do

mypacked.exe anyoldscript.pl

on a system without Perl installed, is at the very least in a grey area as far 
as the Perl License is concerned.

I only post this to flag up a potential issue that you may not have considered. 
I may be completely wrong and "mypacked.exe anyoldscript.pl" might be fine. I 
just always understood that you could not do this and should distribute Perl 
instead.

Regards

Mark

Re: Nested .par problem?

[Mark Dootson]

Hi,

May I suggest the following solution.

You have two scripts you wish to call via make.

test1.pl
test2.pl

You would like to call plain perl scripts under linux, and distribute a pp'd 
exec under Win32.

Solution-

put test1.pl and test2.pl in directory /var/local/myscripts

Change your build script so that where before it called

test1.pl @args

now it calls

nicetest test1.pl @args

An example nicetest is attached.

To package on Win32 do

pp --lib="c:/var/local/myscripts" -M "test1.pl" -M "test2.pl" -o nicetest.exe 
nicetest

so now, on Win32 with nicetest exe installed,
nicetest test1.pl @args

is the same as
nicetest test1.pl @args
with perl installed.

Regards

Mark


Roderich Schupp wrote:
> On 5/7/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
>> I have a Perl script in scripts.par being run by parl.  The script calls
>> make, and make in turn calls parl to run a different script in the same
>> scripts.par.
>>
>> Things work fine if I manually execute the call to make, but when nested
>> as above, I get this error:
>> Is this something I'm not allowed to do, i.e. will the two instances of
>> parl working on the same scripts.par file conflict with each other?
> 
> Let's say it's a bug in PAR::Packer. I was able to reproduce this on Linux
> (so it's not specific to Windows) with the following sequence:
> 
> $ pp -p -o foo.par -e 'print "foo!\n"'
> $ pp -p -o bar.par -e 'print "bar\n"; system "parl foo.par"'
> $ parl bar.par
> bar!
> foo!
> 
> But when I rename my installed PAR.pm os that it can't be found I get
> 
> $ parl bar.par
> bar!
> Can't locate PAR.pm in @INC (@INC contains: /etc/perl
> /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5
> /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8
> /usr/local/lib/site_perl /usr/local/lib/perl/5.8.7 .) at -e line 882.
> 
> Here's a workaround: invoke the inner parl with its full pathname, i.e. in
> my Linux environment
> 
> $ pp -p -o bar.par -e 'print "bar\n"; system "/usr/bin/parl foo.par"'
> 
> For those interested in the gory details:
> 
> - parl is the "prototypical" packed executable; it works as follows:
>  - create a cache directory /tmp/par-USER/XX
>  - copy some files (all etxtracted by obscure means from the parl
> executable itself)
>   into this cache directory
>  - these files are Perl modules (but with rather cryptical names),
> shared libraries
>   (the architecture dependent part of some of the Perl modules), the
> shared perl
>   library (libperlXXX.so) (on systems where is perl is dynamically
> linked) and
>   one executable which is a special purpose perl
>  - it then exec's this executable in an environment so that it will
> load the shared
>   perl library and the modules including their architecture dependent parts
>   (this is essentially PAR.pm plus all modules that are called by it
> directly or indirectly)
> - now we have a perl running with the PAR apparatus loaded, so we can 
> finally
>   load the .par from the original command line
> 
> - the problem is that the executable in the cache directory is also
> called parl (though
>  it isn't identical to the parl you called) and that it is run in an
> environment with
>  the cache directory *prepended to PATH*
> 
> - so when the inner parl is invoked, you actually get the parl
> executable in the cache
>  directory, which isn't prepared to do a "real" parl's job...
> 
> Note that we can't get rid of the augmentation of PATH  on Windows -
> what's actually
> necessary is to prepend the cache directory to the search path for
> shared libraries,
> e.g. LD_LIBRARY_PATH on Linux. parl does that already, but on Windows
> there is
> no separate library search path.
> 
> Cheers, Roderich



nicetest.pl
Description: Perl program

Re: Problem with executable created on Windows with AS 820

[Mark Dootson]

Hi,

The fix hasn't made it to CPAN yet.

If you can compile PAR::Packer, then use the source from

http://svn.openfoundry.org/par/PAR-Packer/trunk/

where this issue has been fixed.

Alternatively, apply attached patch to 0.973 sources.

Regards

Mark


Rob Roy wrote:
> I just installed both PAR and PAR-Packer .973. I have ActiverPerl
> 5.8.8.820. I create an executable of my Perl script but when I run it I
> get the following error message:
> 
>  
> 
> Can't locate Win32.pm in @INC (@INC contains: .) at -e line 826.
> 
> BEGIN failed--compilation aborted at -e line 896.
> 
>  
> 
> I've read the archives about this problem but I thought it'd be fixed in
> .973. Am I missing something? Is there an environment variable that
> needs to be set before compiling and installing the packages?
> 
>  
> 
> Thanks,
> 
> Rob
> 
>  
> 
> 

Index: ChangeLog
===
--- ChangeLog   (revision 436)
+++ ChangeLog   (working copy)
@@ -1,3 +1,7 @@
+[Changes for 0.975 - May 06, 2007]
+* Bug fixes, etc.
+- trailing backslashes in @INC paths handled in
+PAR::StrippedParl::Base
 
 [Changes for 0.975 - May 01, 2007]
 * Bug fixes, etc.
Index: lib/PAR/StrippedPARL/Base.pm
===
--- lib/PAR/StrippedPARL/Base.pm(revision 436)
+++ lib/PAR/StrippedPARL/Base.pm(working copy)
@@ -2,7 +2,7 @@
 use 5.006;
 use strict;
 use warnings;
-our $VERSION = '0.958';
+our $VERSION = '0.975';
 
 use File::Temp ();
 use File::Spec;
@@ -68,7 +68,11 @@
 chmod(oct('755'), $tfile);
 
 # Use this to generate a real parl
-my @libs = (map {"-I\"$_\""} @INC);
+my @libs = ();
+for my $ilib ( @INC ) {
+$ilib =~ s/\\$//;
+push(@libs, qq(-I\"$ilib\") );
+}
 my @args = (@libs, qw/-q -B/);
 
 # prepend ./ if applicable
Index: lib/PAR/Packer.pm
===
--- lib/PAR/Packer.pm   (revision 436)
+++ lib/PAR/Packer.pm   (working copy)
@@ -3,7 +3,7 @@
 use strict;
 use warnings;
 
-our $VERSION = '0.973';
+our $VERSION = '0.975';
 
 =head1 NAME
 
Index: script/par.pl
===
--- script/par.pl   (revision 436)
+++ script/par.pl   (working copy)
@@ -688,6 +688,7 @@
 require PAR::Heavy;
 require PAR::Dist;
 require PAR::Filter::PodStrip;
+eval { require Win32 };
 eval { require Scalar::Util };
 }

Re: Problems Using Par 0.973 with Windows AS Build 820

[Mark Dootson]

Hi,

The change I just tested was

my @libs = ();
for my $ilib ( @INC ) {
   $ilib =~ s/\\$//;
   push(@libs, qq(-I\"$ilib\") );
}

I chose this route purely to be consistent with the implementation in 
Module::ScanDeps::DataFeed.
(Which is not explicitly MSWin specific). The thinking here is that fixes for 
problems that are exposed by usage of either module can be applied to both.

I chose an implementation without 'map' as I have an unreasonable antipathy 
towards it :-)

However, as all suggestions will 'work' for the specific case in question. I 
have no preference.

Steffen, as maintainer the choice is yours. I'll test build and patch whichever 
method decided upon.

For info, the history of this begins with PAR::Packer 0.960 where the 
implementation was:
my @libs = (map {"-I$_"} @INC);

This does not handle paths with spaces so was changed in 0.970 to:
my @libs = (map {"-I\"$_\""} @INC);

Regards

Mark






Steven Mackenzie wrote:
> Hello,
> 
> Sorry to go quiet on the thread that I started, and thanks for all the 
> debugging!
> 
> I would amend Dr Ruud's suggestion as below:
>   if ($^O =~ /^MSWin/) {
>   s{\\$}{}g for @libs;
>   }
> 
> 1/ The $^O check at the head of the block is clearer (for me) to read - the 
> flow
> of the code is such that you can skip reading the block if you aren't 
> interested
> in the MSWin case, rather than trying to understand what is happening, and 
> then
> noticing "Oh, it's MSWin only"
> 
> 2/ *Removing* only the trailing \ instead of replacing with / means that all
> slashes within a single path are consistent, and minimally changed from the
> value read from the environment, and it works.
> 
> 
> Steven
> 
> 
> Mark Dootson wrote:
>> Hi,
>>
>> I limited to just the trailing backslash because I was confident that that 
>> would work in all cases I know of.
>>
>> I'm not sure if '//server/share' would work nor am I entirely confident I've 
>> thought of all the ways a path can be constructed in the Windows/Samba 
>> world. I am as confident as one can be that just changing the trailing 
>> backslash would work.
>>
>> I took a look at Module::ScanDeps::DataFeed which is another module where 
>> the trailing backslash issue is addressed. That module escapes the trailing 
>> slash with
>>
>> join(',', map("\n\t'$_'", map {s/\\$//; $_} @inc));
>>
>> I have no preference between the two methods, but as the two modules are 
>> often used together, would it be a good idea to take a common approach in 
>> both modules?
>>
>> I will prepare/test patch that escapes the trailing backslash in Base.pm and 
>> post + apply.
>>
>> Regards
>>
>> Mark
>>
>>
>>
>>
>>
>> Steffen Mueller wrote:
>>> Hi Mark,
>>>
>>> Mark Dootson schrieb:
>>>> Is it possible to have full UNC paths in @INC?
>>>> For this and other cases the attached patch works too.
>>> For those not in the know: UNC paths are mostly the \\Server\Share\Dir
>>> syntax commonly seen in Windows/Samba shares. To be entirely honest, I
>>> had to look that up. :)
>>>
>>> I never really thought about this. I would guess such paths break all
>>> kinds of regular expressions in various places. Not just in PAR and its
>>> companion modules but perhaps also in perl itself, File::Spec, etc.
>>>
>>> But it's something to keep in mind. Better to be safe than sorry.
>>>
>>> About the code:
>>> Why s/\\+$/\//? Is replacing just a trailing backslash with a slash a
>>> good idea? s/\\/\/g would have done, too, wouldn't it? (perl doesn't
>>> care about / vs \ in paths.) Or removing any trailing (back-)slash  in
>>> the first place: s/(?:\\|\/)$//?
>>>
>>> I think your patch isn't clumsy at all. "elegant", "one-line",
>>> "readable", pick two. :)
>>>
>>> I assume you did the replacement of just one path separator in order to
>>> change the string as little as possible, after all c:\foo\ is
>>> semantically more similar to c:\foo/ than to c:\foo.
>>>
>>> Can you apply your patch yourself?
>>>
>>> Steffen
>>>
>>

Re: Problems Using Par 0.973 with Windows AS Build 820

[Mark Dootson]

Hi,

I limited to just the trailing backslash because I was confident that that 
would work in all cases I know of.

I'm not sure if '//server/share' would work nor am I entirely confident I've 
thought of all the ways a path can be constructed in the Windows/Samba world. I 
am as confident as one can be that just changing the trailing backslash would 
work.

I took a look at Module::ScanDeps::DataFeed which is another module where the 
trailing backslash issue is addressed. That module escapes the trailing slash 
with

join(',', map("\n\t'$_'", map {s/\\$//; $_} @inc));

I have no preference between the two methods, but as the two modules are often 
used together, would it be a good idea to take a common approach in both 
modules?

I will prepare/test patch that escapes the trailing backslash in Base.pm and 
post + apply.

Regards

Mark





Steffen Mueller wrote:
> Hi Mark,
> 
> Mark Dootson schrieb:
>> Is it possible to have full UNC paths in @INC?
>> For this and other cases the attached patch works too.
> 
> For those not in the know: UNC paths are mostly the \\Server\Share\Dir
> syntax commonly seen in Windows/Samba shares. To be entirely honest, I
> had to look that up. :)
> 
> I never really thought about this. I would guess such paths break all
> kinds of regular expressions in various places. Not just in PAR and its
> companion modules but perhaps also in perl itself, File::Spec, etc.
> 
> But it's something to keep in mind. Better to be safe than sorry.
> 
> About the code:
> Why s/\\+$/\//? Is replacing just a trailing backslash with a slash a
> good idea? s/\\/\/g would have done, too, wouldn't it? (perl doesn't
> care about / vs \ in paths.) Or removing any trailing (back-)slash  in
> the first place: s/(?:\\|\/)$//?
> 
> I think your patch isn't clumsy at all. "elegant", "one-line",
> "readable", pick two. :)
> 
> I assume you did the replacement of just one path separator in order to
> change the string as little as possible, after all c:\foo\ is
> semantically more similar to c:\foo/ than to c:\foo.
> 
> Can you apply your patch yourself?
> 
> Steffen
> 

Re: Problems Using Par 0.973 with Windows AS Build 820

[Mark Dootson]

Hi,

replaying to my own posts againt :-)

Is it possible to have full UNC paths in @INC?
For this and other cases the attached patch works too.


Mark


Mark Dootson wrote:
> Hi,
> 
> It is a separate issue.
> 
> The problem lies in PAR::StrippedPARL::Base.pm.
> 
> The problem is a "simple" issue of back-slashing a double quote in a command 
> arg.
> 
> So, the attached patch contains my rather clumsy fix. It changes backslashes 
> to forward slashes in paths  on MSWin. Elegant one line replacements welcome.
> 
> I haven't got the time at present to check how, if, or when this was 
> introduced.
> But I suspect it has always been there.
> I, for example, always removed the PERL5LIB env created by PDK as it seemed 
> to be at the root of a couple of the problems I encountered.
> 
> Regards
> 
> Mark
> 
> 
> 
> 
> Steffen Mueller wrote:
>> Hi Steven,
>>
>> Steven Mackenzie schrieb:
>>> There is a note in the Module-ScanDeps change log about the trailing
>>> slash issue
>>> [Changes for 0.66 - 2006-09-24]
>>> * Fixed another bug in Module::ScanDeps::Datafeed which would break
>>>   run- and compile-time dependency scanners if $ENV{PERL5LIB} entries
>>>   had trailing backslashes.
>>>
>>> I am currently running ScanDeps 0.71:
>>> C:\Documents and Settings\steven>perl -MModule::ScanDeps -e "print
>>> $Module::Scan
>>> Deps::VERSION"
>>> 0.71
>>>
>>> If I remove the trailing slash from the path, then my problem goes
>>> away. :-)
>>>
>>> Steffen, has this problem crept back in to Module::ScanDeps, or is it
>>> replicated
>>> somewhere else?
>> I'm not sure. I would think its a separate issue. But I'm not currently
>> completely on top of things, sorry!
>>
>> You can get a complete diff between two releases of a module (if they're
>> still available from CPAN) using search.cpan.org's "Tools" section on
>> the modules homepage.
>>
>> Steffen
> 
> 
> 
> 
> Index: Base.pm
> ===
> --- Base.pm   (revision 436)
> +++ Base.pm   (working copy)
> @@ -68,7 +68,12 @@
>  chmod(oct('755'), $tfile);
>  
>  # Use this to generate a real parl
> -my @libs = (map {"-I\"$_\""} @INC);
> +my @libs = ();
> +for (@INC) {
> +my $ilib = $_;
> +$ilib =~ s/\\/\//g if($^O =~ /^MSWin/);
> +push(@libs, qq(-I\"$ilib\") );
> +}
>  my @args = (@libs, qw/-q -B/);
>  
>  # prepend ./ if applicable

Index: Base.pm
===
--- Base.pm (revision 436)
+++ Base.pm (working copy)
@@ -68,7 +68,12 @@
 chmod(oct('755'), $tfile);
 
 # Use this to generate a real parl
-my @libs = (map {"-I\"$_\""} @INC);
+my @libs = ();
+for (@INC) {
+my $ilib = $_;
+$ilib =~ s/\\+$/\// if($^O =~ /^MSWin/);
+push(@libs, qq(-I\"$ilib\") );
+}
 my @args = (@libs, qw/-q -B/);
 
 # prepend ./ if applicable

Re: Problems Using Par 0.973 with Windows AS Build 820

[Mark Dootson]

Hi,

It is a separate issue.

The problem lies in PAR::StrippedPARL::Base.pm.

The problem is a "simple" issue of back-slashing a double quote in a command 
arg.

So, the attached patch contains my rather clumsy fix. It changes backslashes to 
forward slashes in paths  on MSWin. Elegant one line replacements welcome.

I haven't got the time at present to check how, if, or when this was introduced.
But I suspect it has always been there.
I, for example, always removed the PERL5LIB env created by PDK as it seemed to 
be at the root of a couple of the problems I encountered.

Regards

Mark




Steffen Mueller wrote:
> Hi Steven,
> 
> Steven Mackenzie schrieb:
>> There is a note in the Module-ScanDeps change log about the trailing
>> slash issue
>> [Changes for 0.66 - 2006-09-24]
>> * Fixed another bug in Module::ScanDeps::Datafeed which would break
>>   run- and compile-time dependency scanners if $ENV{PERL5LIB} entries
>>   had trailing backslashes.
>>
>> I am currently running ScanDeps 0.71:
>> C:\Documents and Settings\steven>perl -MModule::ScanDeps -e "print
>> $Module::Scan
>> Deps::VERSION"
>> 0.71
>>
>> If I remove the trailing slash from the path, then my problem goes
>> away. :-)
>>
>> Steffen, has this problem crept back in to Module::ScanDeps, or is it
>> replicated
>> somewhere else?
> 
> I'm not sure. I would think its a separate issue. But I'm not currently
> completely on top of things, sorry!
> 
> You can get a complete diff between two releases of a module (if they're
> still available from CPAN) using search.cpan.org's "Tools" section on
> the modules homepage.
> 
> Steffen

Index: Base.pm
===
--- Base.pm (revision 436)
+++ Base.pm (working copy)
@@ -68,7 +68,12 @@
 chmod(oct('755'), $tfile);
 
 # Use this to generate a real parl
-my @libs = (map {"-I\"$_\""} @INC);
+my @libs = ();
+for (@INC) {
+my $ilib = $_;
+$ilib =~ s/\\/\//g if($^O =~ /^MSWin/);
+push(@libs, qq(-I\"$ilib\") );
+}
 my @args = (@libs, qw/-q -B/);
 
 # prepend ./ if applicable

Re: Problems Using Par 0.973 with Windows AS Build 820

[Mark Dootson]

Hi,

Sorry I can't be of much help.

The code that is throwing the error is in

PAR::StrippedPARL::Base.pm

around line 80 - in sub write_parl. Something is going awry with the 
construction of the $execute params before that.

Mark



Steven Mackenzie wrote:
> Mark Dootson wrote:
>> Hi,
> 
> Hello, thanks for looking :-)
> 
>>> I got this error:
>>> Set up gcc environment - 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
>> gcc ? cygming ??
> 
> Actually, I normally build with the Visual Studio C++ 6.0 VCVars32.bat
> environment, and then that line does not appear. In the output I pasted
> previously, I hadn't set up that environment (which usually works fine too).
> 
> Otherwise, I do have a Cygwin gcc, which is perhaps what is used here.
> 
> I've just retested with the VCVars environment, and the behaviour is the same,
> but without the gcc message.
> 
>>> Usage: C:\DOCUME~1\steven\LOCALS~1\Temp\parlzLhs.exe [ -Alib.par ] [ -Idir 
>>> ] [
>>> -Mmodule ] [ src.par ] [ program.pl ]
>>>C:\DOCUME~1\steven\LOCALS~1\Temp\parlzLhs.exe [ -B|-b ] [-Ooutfile] 
>>> src.par
>>> C:\Perl\bin/pp: Failed to extract a parl from 'PAR::StrippedPARL::Static' to
>>> file 'parlEE2gFTR.exe' at C:/Perl/site/lib/PAR/Packer.pm line 1149,  
>>> line 1.
>> what does "pp --version" output? 
> 
> C:\cvs\pwebcosm\2.2\ANPerl\AnalysisFramework\Clients>perl -M"PAR::Packer" -e
> "print $PAR::Packer::VERSION"
> 0.973
> C:\cvs\pwebcosm\2.2\ANPerl\AnalysisFramework\Clients>
> 
> C:\cvs\pwebcosm\2.2\ANPerl\AnalysisFramework\Clients>pp --version
> PAR Packager, version 0.973 (PAR version 0.973)
> Copyright 2002, 2003, 2004, 2005, 2006 by Audrey Tang <[EMAIL PROTECTED]>
> 
> :-(

Re: Problems Using Par 0.973 with Windows AS Build 820

[Mark Dootson]

Hi,

Steven Mackenzie wrote:

> I noted this warning:
> Output file '..\blib\lib\PAR\StrippedPARL\Dynamic.pm' does not have an empty
> __DATA__ section. Not appending encoded data from '.\par.exe'. This is NOT a
> fatal error! at encode_append.pl line 26.

That's normal.

 > pp --lib ../../../../../external/perl/lib --lib ../../.. -M
> ANPerl/AnalysisFramework/ResourceStore/Metadata/DBUserMetadataValues.pm [...] 
> -M
> MIME::Types -M String::CRC::Cksum -M PerlIO -o ./clan.exe CLAnalysis.pl
> 
> I got this error:
> Set up gcc environment - 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)

gcc ? cygming ??

> Usage: C:\DOCUME~1\steven\LOCALS~1\Temp\parlzLhs.exe [ -Alib.par ] [ -Idir ] [
> -Mmodule ] [ src.par ] [ program.pl ]
>C:\DOCUME~1\steven\LOCALS~1\Temp\parlzLhs.exe [ -B|-b ] [-Ooutfile] 
> src.par
> C:\Perl\bin/pp: Failed to extract a parl from 'PAR::StrippedPARL::Static' to
> file 'parlEE2gFTR.exe' at C:/Perl/site/lib/PAR/Packer.pm line 1149,  
> line 1.

what does "pp --version" output? 

Regards

Mark