Re: PAR Packer, Win32::Exe (exe_update) --icon not working
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
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 windows.h
-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
21
=
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
Re: PAR::Packer - problem installing under Windows / Strawberry portable
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 windows.h
-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.pleljot_...@poczta.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++
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 Dootsonmark.doot...@znix.com
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.
Building on Windows with mingw resource bug
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 windows.h
-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++
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 TicketURL: https://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: [rt.cpan.org #75193] [PATCH] Fix build on Win32/VC++
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
Windows compilation - resource sections
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 io.h
+#else
#include unistd.h
+#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: Windows compilation - resource sections - Update
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
Re: Problem with IPC::Cmd under windows
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: Problem with IPC::Cmd under windows
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
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 Dootsonmark.doot...@znix.com 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
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
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
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 Dootsonmark.doot...@znix.com 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: PP failure
One further thought on this. The object files in the zips contain a basic manifest that includes requestedExecutionLevel level=asInvoker In the compiled executables, the manifest whitespace is preserved. So, it should be possible to do a simple replace of requestedExecutionLevel level=asInvoker with requestedExecutionLevel level=requireAdministrator 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 roderich.sch...@googlemail.com 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 engin...@fuse.net 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
Re: PP failure
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 requestedExecutionLevel level=requireAdministrator as you requested and that then also worked with no visible difference. I did get one failure on the tests, but it appears to be just trying to implement converting a file that doesn't exist. I'm attaching two files to this email. The 'make test messages so you can see for yourself the error message and a zip of the files exactly as needed to run on my system as is. This one is prior to running the Makefile.PL so all someone would need to do is extract the zip, and then: perl makefile.pl dmake dmake test (ignoring the failed single test) dmake install Thanks again for your help. If I can be of any further help to you I'm here. Bob Ross
Re: OSX problem packing for 10.5 on 10.6
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: OSX problem packing for 10.5 on 10.6
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: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
Re: OSX problem packing for 10.5 on 10.6
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_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
Re: OSX problem packing for 10.5 on 10.6
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 myconfig.sh 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/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
Re: Running with elevated privileges on Windows
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
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
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_Tecniciexe_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\binpp -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.006dmake 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
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 URL: 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
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 URL: 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 TicketURL: http://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
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
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 TicketURL: http://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
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)
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 URL: 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 TicketURL: https://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 -IC:\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 -IC:\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 -IC:\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 -LC:\strawberry\perl\lib\CORE -LC:\ 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 -IC:\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
Re: [rt.cpan.org #57272] Error building on Strawberry 5.12.0.1 32-bit (can't find script/parl.exe)
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 TicketURL: https://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 -IC:\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 -IC:\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 -IC:\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 -LC:\strawberry\perl\lib\CORE -LC:\ 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 -IC:\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 -LC:\strawberry\perl\lib\CORE -LC:\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:
Win32::Exe 0.14
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
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
Re: wxbase26_gcc_custom.dll was not found
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
Win32::Exe development release
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: Win32::Exe
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
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 = asInvoker|requestAdministrator|highestAvailable|* 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: ExtUtils::PerlToExe, and binaries that don't need unpacking
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: ExtUtils::PerlToExe, and binaries that don't need unpacking
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: pp @INC question
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: pp @INC question
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: PAR for Windows x64
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]; par@perl.org 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 installation question....
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: PAR installation question....
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: problem with POSIX package and par
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: problem with POSIX package and par
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 perl-install 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
par-cache-for-this-app/(lib|bin|script) and you are suggesting that
anything that is included from other parts of the original file system
should be placed in par-cache-for-this-app? I'd have suggested
placing them in par-cache-for-this-app/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.
Re: perl510.dll not being included
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
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: best win32 perl to use
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
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?
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: http://wiki.panotools.org/Install_Panotools-Script_on_Windows#Infrastructure_to_build_the_.exe_tools_-_the_new_way 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?
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: PAR::Packer 0.980 MSWin32 .par binary?
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: How do I use/extract the icon packaged with --icon
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
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 perl v5.10.0 build for MSWin32-x86-multi-thread
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: Failed test 'Found the static build of parl in myldr for perlv5.10.0 build for MSWin32-x86-multi-thread
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: cwd in pp
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
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 -einstall_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\binperl -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\binpp -V
PAR Packager, version 0.976 (PAR version 0.976)
And Perl reports:
C:\Perl\site\binperl -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
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.976dmake 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 -IC:\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 -IC:\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 -IC:\Perl\lib\CORE my_par_pl.c gcc main.o my_par_pl.o win32.coff -s -g -LC:\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'
Re: Can't install PAR::Packer 0.976
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 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: PAR::Packer on Windows Vista
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\binpp -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, DATA 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
ActivePerl binaries for PAR Packer
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
Hi, Which build of ActivePerl are you using? perl -eprint 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.976perl 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.976nmake 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.976nmake 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.976nmake 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.pm Installing
Re: PAR::Packer on Windows Vista
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: Temporary file left behind when including icon file
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
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
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
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
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
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.973perl 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.973nmake 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.973nmake 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.973nmake 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.973pp '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?
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: Nested .par problem?
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: Are parl/pp the right tools?
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: Are parl/pp the right tools?
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?
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: Problems Using Par 0.973 with Windows AS Build 820
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\stevenperl -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
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
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: Building PAR::Packer against ActiveState build 820 on Win32
Great. At compile time, the script/par.pl is packed as a char* ready to be run in any exe's you create. So changing the installed c:\perl\bin\par.pl won't make any difference when you run an exe created with pp. Regards Mark m.nooning wrote: Yep. It works on my Windows XP Home, ActiveState Perl 5.8.8 build 820. Thanks
Re: Problems Using Par 0.973 with Windows AS Build 820
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, DATA line 1. what does pp --version output? Regards Mark
Re: Problems Using Par 0.973 with Windows AS Build 820
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, DATA line 1. what does pp --version output? C:\cvs\pwebcosm\2.2\ANPerl\AnalysisFramework\Clientsperl -MPAR::Packer -e print $PAR::Packer::VERSION 0.973 C:\cvs\pwebcosm\2.2\ANPerl\AnalysisFramework\Clients C:\cvs\pwebcosm\2.2\ANPerl\AnalysisFramework\Clientspp --version PAR Packager, version 0.973 (PAR version 0.973) Copyright 2002, 2003, 2004, 2005, 2006 by Audrey Tang [EMAIL PROTECTED] :-(
Re: Building PAR::Packer against ActiveState build 820 on Win32
Patch applied to SVN.
Tested build against Win32 AS perl, a none AS perl, and on a Linux machine.
(You never know when a typo might catch you out :-) )
Regards
Mark
That seems just about right, I think. Thanks for your detective work! Do
you think you could patch par.pl with this suggestion?
Steffen
Index: ChangeLog
===
--- ChangeLog (revision 436)
+++ ChangeLog (working copy)
@@ -1,4 +1,9 @@
+[Changes for 0.975 - May 01, 2007]
+* Bug fixes, etc.
+- Win32 added to 'required modules' to handle changes in Win32 core
+ present in ActiveState build 820 and development branches.
+
[Changes for 0.974 - Apr 14, 2007]
* Bug fixes, etc.
- No longer assume -B when using pp -P (or -p). (Roderich Schupp)
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: Building PAR::Packer against ActiveState build 820 on Win32
It is the only change.
Please build from patched sources. It will fix the problem.
m.nooning wrote:
Mark Dootson wrote:
Patch applied to SVN.
Tested build against Win32 AS perl, a none AS perl, and on a Linux
machine. (You never know when a typo might catch you out :-) )
Regards
Mark
That seems just about right, I think. Thanks for your detective work! Do
you think you could patch par.pl with this suggestion?
Steffen
Index: ChangeLog
===
--- ChangeLog(revision 436)
+++ ChangeLog(working copy)
@@ -1,4 +1,9 @@
+[Changes for 0.975 - May 01, 2007]
+* Bug fixes, etc.
+- Win32 added to 'required modules' to handle changes in Win32 core
+ present in ActiveState build 820 and development branches.
+
[Changes for 0.974 - Apr 14, 2007]
* Bug fixes, etc.
- No longer assume -B when using pp -P (or -p). (Roderich Schupp)
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 };
}
Mine still does not work.
Let me make sure about your patch. I went into C:\perl\bin\par.pl and
added
eval { require Win32 };
as shown in your patch. That seems to be the only real change. My
results are the same.
BTW: Any idea which file is meant by line 826?
paste test
C:\temptype hello.pl
print Hello\n;
C:\temppp -o hello.exe hello.pl
C:\temphello.exe
Can't locate Win32.pm in @INC (@INC contains: .) at -e line 826.
BEGIN failed--compilation aborted at -e line 896.
Re: Building PAR::Packer against ActiveState build 820 on Win32
Hi, Nothing like that I can spot, I'm afraid. And as stated earlier, Win32.pm IS in the packed exe. I'm in the middle of testing vs a good 0.973 on a non ActiveState perl at present. I'll let you know. Eric Wilhelm wrote: # from Mark Dootson # on Monday 30 April 2007 01:31 pm: # Instead, it produced :: Can't locate Win32.pm in @INC (@INC contains: C:\Perl\build\PAR-Packer-0.973\blib\lib C:\Perl\build\PAR-Packer-0.973\contrib \automated_pp_test C:\Perl\build\PAR-Packer-0.973\inc C:\Perl\build\PAR-Packer-0.973\blib\lib C:\Perl\build\PAR-Packer-0.973\blib\arch .) at -e line 8 This appears to be happening during the build. Where is Win32.pm? Is there a 'perl -I' involved? `pp -e 'use Win32'` ? --Eric
Re: Building PAR::Packer against ActiveState build 820 on Win32
Hi, The failure is in par.pl. It appears that Win32::GetCwd can no longer be called without loading Win32.pm (so it would seem it is no longer CORE). If I add Win32 to the par.pl require_modules sub all is well. Hm... Eric Wilhelm wrote: # from Mark Dootson # on Monday 30 April 2007 01:31 pm: # Instead, it produced :: Can't locate Win32.pm in @INC (@INC contains: C:\Perl\build\PAR-Packer-0.973\blib\lib C:\Perl\build\PAR-Packer-0.973\contrib \automated_pp_test C:\Perl\build\PAR-Packer-0.973\inc C:\Perl\build\PAR-Packer-0.973\blib\lib C:\Perl\build\PAR-Packer-0.973\blib\arch .) at -e line 8 This appears to be happening during the build. Where is Win32.pm? Is there a 'perl -I' involved? `pp -e 'use Win32'` ? --Eric
Re: Building PAR::Packer against ActiveState build 820 on Win32
Yep,
A check of the AS820 diff shows Win32::GetCwd has moved from CORE to the XS
module.
I think are going to be stuck with
if { $^O =~ /^MSWin/) { require Win32; }
because Win32::LoginName has moved out of the core too.
Any thoughts?
Mark Dootson wrote:
Hi,
The failure is in par.pl.
It appears that Win32::GetCwd can no longer be called without loading
Win32.pm (so it would seem it is no longer CORE).
If I add Win32 to the par.pl require_modules sub all is well.
Hm...
Eric Wilhelm wrote:
# from Mark Dootson
# on Monday 30 April 2007 01:31 pm:
# Instead, it produced :: Can't locate Win32.pm in @INC (@INC
contains: C:\Perl\build\PAR-Packer-0.973\blib\lib
C:\Perl\build\PAR-Packer-0.973\contrib \automated_pp_test
C:\Perl\build\PAR-Packer-0.973\inc
C:\Perl\build\PAR-Packer-0.973\blib\lib
C:\Perl\build\PAR-Packer-0.973\blib\arch .) at -e line 8
This appears to be happening during the build. Where is Win32.pm? Is
there a 'perl -I' involved? `pp -e 'use Win32'` ?
--Eric
Building PAR::Packer against ActiveState build 820 on Win32
A quick question. Has anybody else successfully built PAR::Packer 0.973 against ActiveState build 820 on Win32? My attempts fail when a pp packed exec is run ( and in all pp tests, of course ) I can build against my own build of perl 5.8.8 just fine. I haven't posted more detail as a quick yes from anyone who has had no problems will do fine. I imagine it is something specific to me as I see no other mention on the list - but confirmation would be helpful. Regards Mark
Re: Guesswork on pp -c not working
The involvement of 'sitecustomize.pl' is a symptom rather than the problem.
If, anywhere in your code you have:
do 'absolute_path_to_file.pl';
or
require 'absolute_path_to_file.pl';
then pp (using the --compile flag or not) won't work on Win32.
If you don't have a 'do/require' then it only shows up with --compile /
--execute because then the interpreter does 'do $path_to_sitecustomize'
anyway.
To fix this, PAR community / maintainers need to decide what what should
happen when the argument to 'do' and 'require' in code is an absolute path.
IMHO, Module::ScanDeps should continue to work exactly as it does at
present, but PAR::Packer should never package anything returned by
Module::ScanDeps keyed as an absolute path. The code that used the
'require' or 'do' could never find the packaged version anyway, even if
the volume in the path didn't break zip.
Regards
Mark
Malcolm Nooning wrote:
This is guesswork and may be ignored totally.
Here is what I have looked at. I am viewing DataFeed.pm VERSION = '0.07';
Starting at line 55, which show my modifications.
paste
# print FH join(
my @try_1 = join( #xxx
',' = map {
sprintf(
\n\t'$_' = '%s/%s',
Cwd::abs_path(File::Basename::dirname($inc{$_})),
File::Basename::basename($inc{$_}),
),
} keys(%inc)
);
print (map{$_\n} @try_1); print \n;#xxx
print FH @try_1;#xx
print FH \n);\n;
-end paste
The line print FH @try_1; prints this:
'C:/perl/site/lib/sitecustomize.pl' =
'C:/perl/site/lib/sitecustomize.pl'
with a blank line before and after it.
I mention it because in and older email with subject Re: pp -c not
working dated 1/24/2007 8:38 AM, I show that after putting in cluck and
print statements into C:\perl\lib\Archive\Zip.pm I saw this:
C:\DOCUME~1\malcolm\LOCALS~1\Temp\par-malcolm\cache-47dd25f0d96d76185f811633af835bed5c2cafd9/inc/lib/C:/perl/site/lib/sitecustomize.pl
which means C:/perl/site/lib/sitecustomize.pl is getting tacked to the
end of c:\path_to_my_cache/inc/lib
I would like to ask, what was the original purpose of sitecustomize.pl?
From it's name, I would guess that it is for adding library paths. If
that is the case, I would guess that we want the contents of
sitecustomize.pl, not the name sitecustomize.pl itself. This is just
pure guesswork, of course.
I hope it helps.
Re: Not a par problem
Hello,
Win32::OLE won't work with fork(). Lots of Win32 specific modules don't
work with fork(). Signals are problematic too.
You'll need to go with a Win32 specific approach and code. But as you're
using Win32::OLE that'll be no problem.
I guess you're coming to Win32 Perl from a Unix background so life
without fork will seem strange?
Fortunately, many of the CPAN modules that do the sort of stuff fork()
is just dandy for have working Win32 implementations under the skin -
usually threaded so its not quite the same thing as forking a process.
So, if you're writing a daemon or whatever, someone else will have
already done the work for you (which is why we love CPAN).
If you start putting fork() in your own original Win32 specific code,
you'll age before your time.
Best Regards
Mark
Malcolm Nooning wrote:
Hello,
I would like to ask a few people who have a Windows2000 or WindowsXP
machine to run a short code snippet.
There is no one forum on which to ask for this, so I am picking on this
par forum and asking for forgiveness for interrupting your normal flow
of thought.
I am in communication with the author of Win32::Process::Info about an
Activestate Windows fork problem versus Win32::Process::Info. The
author has responded at http://rt.cpan.org/Public/Bug/Display.html?id=24286
It seems that the mere presence of a use Win32::Process::Info
statement, along with even an empty fork(), causes a perl interpreter
crash. As it turns out, there are a number of use things that
will result in a perl interpreter crash, if there is a Windows fork
involved.
If you have a windows 2K or XP machine, please run the code snippet
below, after uncommenting each use statement, one at a time, in turn,
to see if your machine, too, exhibits the perl interpreter crash. On my
machine, any of the last four will cause it. I find it hard to believe
that such an important problem would never have been reported before. I
need to know if it is particular to my machine.
Thanks
--paste
#!/usr/bin/perl -w
#use Win32::API;
#use Win32API::Registry;
#use Win32::OLE;
#use Win32::OLE::Const;
#use Win32::OLE::Variant;
#use Win32::Process::Info;
if (my $pid = fork()) {
print Parent\n;
}
elsif(defined $pid) {
print Child\n;
exit;
} else {
print Failed to fork:$!:\n;
}
--end paste
