> using PAR, but I cannot claim to understand that much about it), but I
> *do* believe that PAR executables sometimes (...) revert to the local
> installation... now and then...
Behaviour on Windows (native, not cygwin) is definitely different
than on *nix (tried Solaris, Linux, cygwin - basica
> > First check that Tk::Event has really been packed in by pp:
> Yes, it is included, both Event.so binary and the perl Event.pm
> The output of the unzip is attached.
Strange.
> [EMAIL PROTECTED]:/lch/tst/swp/swptst$ print_inc
> INC=/tmp/par-swptst/cache-da39a3ee5e6b4b0d3255bfef95601890afd8
>
> Can someone explain what is going on. Platform is Solaris 2.8
First check that Tk::Event has really been packed in by pp:
$ unzip -l /lch/tst/swp/swptst/system/scmon
and look for .../Tk/Event.pm. If it isn't, try adding "-M Tk::Event"
on your pp command line. Might be that Module::ScanDeps di
> The command I use to create the par file 'update_create.par'
> from my script 'update_create.pl' is:
> pp -vvv -x -n -p -o update_create.par update_create.pl
> ...
> One of the modules that is missing is 'Digest::MD5'.
> I also tried to add this module by adding '-M Digest::MD5'
> to the pp comm
> I installed it via ppm.
This should actually be in the FAQ: the Perl where you
built the PAR tools (esp. parl.exe) and the Perl where
you actually pp something must be equivalent (i.e. same
Perl version and same build options, e.g. threaded or not).
Potentially even the versions of assorted cor
> XP Pro + SP2
> ActivePerl v5.8.8.817
> PAR 0.942
>
> I am compiling a perl script using pp, and was wondering
> where it gets
> its copy of perl58.dll from that is unpacked into the cache dir? I am
> running ActivePerl v5.8.8.817, but the file version in the unpacked
> cache dir is v5.8.6.81
> > This heuristic looks bogus, but what is it that actually
> > fails for you?
>
> Because heuristic looks bogus :)
>
>
> > (AFAICT, finding "Tk.pm" when looking for the incorrectly deduced
> > "tk.pm"
> > has nothing to do with this and is in fact unavoidable when using
> > a case-insensitive
> I return into this already discussed item, because something
> other is broken.
>
> Namely, ScanDeps contains "case-sensitive FS" heuristic also,
> and it seem to fail in my case:
This heuristic looks bogus, but what is it that actually fails for you?
(AFAICT, finding "Tk.pm" when looking for
> Is it possible to populate "my %Preload" hash with Tcl::Tk as
> a special case??
That won't help, because listing Foo.pm in %Preload doesn't prevent
Foo.pm from being scanned, it only adds to the list of stuff to scan.
> this is probably FAQ item, but why not tracking all these "require"
> str
> Due to twisted nature of Tk Module::ScanDeps has some
> heuristic to deal with it, which appears to give false
> positive in my case.
And twisted it is: line 626 of Module::ScanDeps
return $1 if /\b(\w[\w:]*)::\w+\(/;
runs afoul of lines in Tcl/Tk.pm like
$bot->pack(-side => "bott
Steffen Mueller wrote:
> Since nobody answered to my previous suggestion, I just
Sorry, that post never made it to my mailbox.
> The diffs for ScanDeps.pm and PAR/Filter/PatchContent.pm are
> attached.
The Module::ScanDeps patch seems to do the job, but is there
a reason why you implemented
[cc'ed the Module:ScanDeps maintainer, see below]
> When I do the following on Windows:
>
> pp -v -o out.exe -e "use diagnostics;"
>
> and then run .\out.exe, it gives the following error message:
>
> No diagnostics? at diagnostics.pm line 429.
> Compilation failed in require at script/ppCTAFk.pl
> Is there documentation somewhere of what comprises the non-ZIP
> portion of a PAR standalone executable and/or a PAR standalone
> script?
http://search.cpan.org/~smueller/PAR-0.94/script/par.pl#Stand-alone_exec
utable_format
> Most importantly: besides the ZIP portion, does the PAR exe
>
> Is there a reasonable way to turn off -B in pp to make a nearly-
> standalone executable? I'm working on a specialized app that will
> run only on MacOSX 10.4, and therefore is guaranteed to have Perl
> 5.8.6 installed. I'd like to shrink my multiple 5 MB executables by
> using the syste
> I am currently using PAR v0.90. The problem I am running into is if I
> have a Perl script (lets call it A) that has been converted to an exe
> that calls another Perl script (lets call it B) which has also been
> converted to an exe, I get an error message that command line
> parameters
> are
Steffen Mueller wrote:
> http://rt.cpan.org/Ticket/Display.html?id=19030
>
> Finally, we have https://rt.cpan.org/Ticket/Display.html?id=18536
Oops, I just added a comment to #19030 before reading up on #18536.
As explained in my comment to #19030, pp'ed executables (on any ELF
system,
e.g. Lin
> You are right on. The packed exe has version 1.07, and the script is
> written, and using 1.18. Now, if only I can get it to use 1.18
>
> use Scalar::Util 1.18 qw/refaddr/ doesn't seem to work
>
> Oddly, when I unzip the exe that I have created with pp, the 1.18
> version is actuall i
> The parl.exe executable is stored on the local users pc. The
> .par file is
> stored on the network drive. Due to security issues, .exe
> files are not
> allowed on the network drive.
> The files are being cached on the local users pc under
> c:\documents and
> settings\{user}\local settting
> pp.exe is from ActiveState's package manager. I suppose I
> can build it
> by hand, and see if I get anything different, however, the correct
> version of Scalar::Util is packed into the exe.
Actually there are TWO versions of Scalar::Util etc in
the executable created by pp from my oneline
> I'm trying to create a packed exe to deploy on windows servers. Build
> as 'pp -o file.exe script.pl' . Builds fine, but when I run it I get:
Following up my previous mail:
Did you build pp.exe from the same version of perl and Scalar::Util
that is now on the machine you are packing script.pl?
> I'm trying to create a packed exe to deploy on windows servers.
Build
> as 'pp -o file.exe script.pl' . Builds fine, but when I run it I get:
>
> Undefined subroutine &Scalar::Util::refaddr called at overload.pm
> line92.
>
> In an attempt to troubleshoot this, I added:
> use Scalar::Util qw(
> From: Eadon, Bryant [mailto:[EMAIL PROTECTED]
> Well, since I couldn't find main, maybe this will help ?
>
> .oO([EMAIL PROTECTED] ~/build/PAR-0.92) readelf -s myldr/par
> Symbol table '.dynsym' contains 256 entries:
>Num:Value Size TypeBind Vis Ndx Name
> 0:
From: Eadon, Bryant [mailto:[EMAIL PROTECTED]
> ./par -I"/home/beadon1/build/PAR-0.92/inc" -I"/app/gmd/pm"
> -I"/home/beadon1/perl587/lib/5.8.7/sun4-solaris-thread-multi"
> -I"/home/beadon1/perl587/lib/5.8.7"
> -I"/home/beadon1/perl587/lib/site_perl/5.8.7/sun4-solaris-thre
> ad-multi" -I"/home
> it's time for another PAR release. Primarily because the SIGNATURE of
> the 0.91 release was broken. I'm really sorry for that mistake.
>
> You can find the preflight version at http://steffen-mueller.net/tmp
>
> Please test and report your findings to me directly or as an
> answer to this po
> and on both systems the commands pp or par or running resulting
> executables,
> will take some space in /tmp.
> the files there will not be removed.
> i set the env variable PAR_TEMP to /usr/tmp with no effect.
PAR_TEMP is used by the pp'ed application to know
where it has been extracted to (e.
> >I wonder how to compile such small script using PAR to make it work:
> >
> >#!perl
> >use warnings;
> >use strict;
> >use LWP::UserAgent;
> >my $ua = new LWP::UserAgent;
> >my $req = new HTTP::Request(GET => 'http://www.google.com');
> >my $res = $ua->request($req);
> > If this works for you, I'll follow up with a fix
> > for Module::ScanDeps.
Here it is, it actually fixes three bugs w.r.t. to "autouse":
- return not just the autouse'd module, but also "autouse.pm" itself
(that's the cause of your problem)
- the autouse'd module may also be given as a barew
> I got some further hints (via perlbug): it does seem that the
> resulting
> archive is not fully self-contained and relies on the local
> perl having
> an "autouse.pm": is this the way it's meant to be?
Definitely not. Actually it's a bug in Module::ScanDeps
(which is used to scan your script
> Malcolm Nooning wrote:
> The -v problem may get better or worse with this fix. The file
> automated_pp_test.pl already uses POSIX uname to get the $os,
> so please
> try making the change below.
>
> my $_out = $Config{_exe} || '.out';
> if ($os =~ m/CYGWIN/i) {
> $_out = '.out';
> }
Thank
> > This undefined reference is caused by a superfluous blank
> > in /usr/lib/perl5/5.8/cygwin/Config_heavy.pl:
> >
> > ...
> > static_ext=' Win32CORE'
> > ^
> > ...
> >
> > Removing it results in a successful build, but "make test"
> > fails in t/2-pp.t with
> >
> > The perl executa
> > PS: the error message I now get:
> > main.o:main.c:(.text+0x67): undefined reference to `_boot_'
> > collect2: ld returned 1 exit status
This undefined reference is caused by a superfluous blank
in /usr/lib/perl5/5.8/cygwin/Config_heavy.pl:
...
static_ext=' Win32CORE'
^
...
Remov
> Sorry, if I selected a wrong address.
It's the correct one :)
> The next attempt was with -a option:
> pp -B -a dir.tar.zip -o new_script new_script.pl
>
> #!/sne/perl/bin/perl
>
> system "unzip -p dir.tar.zip | tar xf -";
> ...
>
> The problem is: I don't know the path of my dir.ta
32 matches
Mail list logo
