Re: Problem with IPC::Cmd under windows
On 5/23/2011 7:23 AM, Philip Kime wrote: I don't really understand why this works fine unpacked but doesn't when packed ... As Mark said below, this happens because the IPC::Run module on Win32 (only) tries to run subprocesses using $^X, which normally contains the path to perl.exe. However, when PAR packs an executable, $^X doesn't happen to point to perl.exe, and so IPC::Run fails at that point. Implementing IPC::Run on Windows without using subprocesses is an unsolved problem. IPC::Run::run() is almost always overkill for the tasks it's used for. I wrote it and even I only use it rarely. As Roderich said, IPC::Run3 is probably a faster, simpler choice. And Perl's backticks and pipe open were designed for doing things like the example you show and are simpler and faster than IPC::Run3 if you don't need to quote $filename or need kpsewich's exit code. - Barrie
[PATCH] Preemptive extraction
This patch preemptively extracts the contents of the .zip file and not
unshift &find_par on @INC. This is necessary to, for instance, use
POSIX on Unix platforms. I think it would also address my older issues,
but that's moot.
A minor debugging fix is also added below.
It also adds a dependancy in myldr/Makefile.PL that should theoretically
cause make to update the parl executable more often, but it still
doesn't remake thinks properly here when I edit lib/PAR.pm and type
"make".
- Barrie
diff -aur PAR.orig/lib/PAR.pm PAR/lib/PAR.pm
--- PAR.orig/lib/PAR.pm 2004-01-26 00:22:18.0 -0500
+++ PAR/lib/PAR.pm 2004-01-30 22:45:43.0 -0500
@@ -165,6 +165,8 @@
my $arch = $Config{archname};
my ($par_temp, $progname);
+my $preemptive_extraction_mode = 1;
+
sub import {
my $class = shift;
@@ -186,7 +188,8 @@
return if $PAR::__import;
local $PAR::__import = 1;
-unshift @INC, \&find_par unless grep { $_ eq \&find_par } @INC;
+unshift @INC, \&find_par
+unless $preemptive_extraction_mode || grep { $_ eq \&find_par } @INC;
require PAR::Heavy;
PAR::Heavy::_init_dynaloader();
@@ -196,6 +199,19 @@
push @PAR_INC, unpar($0, undef, undef, 1);
my $zip = $LibCache{$0};
+if ( $preemptive_extraction_mode ) {
+my $preemptive_lib_dir = $par_temp;
+$zip->extractTree( "", "$preemptive_lib_dir/" );
+unshift @INC,
+map File::Spec->catdir( $preemptive_lib_dir, @$_ ),
+[ "lib" ],
+[ "arch" ],
+[ $arch ],
+[ $ver ],
+[ $ver, $arch ],
+[];
+}
+
my $member = $zip->memberNamed("script/main.pl")
|| $zip->memberNamed("main.pl");
@@ -292,6 +308,7 @@
my %escapes;
sub unpar {
my ($par, $file, $member_only, $allow_other_ext) = @_;
+
my $zip = $LibCache{$par};
my @rv = $par;
Only in PAR/lib: .PAR.pm.swp
Only in PAR: Makefile.old
Only in PAR/myldr: Makefile.old
diff -aur PAR.orig/myldr/Makefile.PL PAR/myldr/Makefile.PL
--- PAR.orig/myldr/Makefile.PL 2004-01-07 10:58:31.0 -0500
+++ PAR/myldr/Makefile.PL 2004-01-30 21:56:29.0 -0500
@@ -150,7 +150,7 @@
$par_exe: \$(OBJECTS) my_par_pl$o
\$(LD) \$(OBJECTS) \$(PERL_LDFLAGS) $out$par_exe_link
-my_par_pl.c:
+my_par_pl.c: $par_pl
\$(PERL) $f2c $par_pl \$@ load_me_2 $long_literal
$parl_exe: $par
Only in PAR/myldr: static.c.orig
diff -aur PAR.orig/script/par.pl PAR/script/par.pl
--- PAR.orig/script/par.pl 2004-01-25 11:10:44.0 -0500
+++ PAR/script/par.pl 2004-01-30 22:03:27.0 -0500
@@ -247,6 +247,7 @@
$PAR::Heavy::ModuleCache{$fullname} = {
buf => $buf,
crc => $crc,
+name => $fullname,
};
}
read _FH, $buf, 4;
@@ -477,7 +478,10 @@
next unless defined $name and not $written{$name}++;
next if !ref($file) and $file =~ /\.\Q$lib_ext\E$/;
-outs(qq(Packing "$file"...));
+outs( join "",
+qq(Packing "), ref $file ? $file->{name} : $file,
+qq("...)
+);
my $content;
if (ref($file)) {
AutoLoader.pm, POSIX, and lib/... assumptions, oh my!
I'm trying to build a binary on RedHat 8 using the stock perl5.8.0 for
now. The binary boots and runs, but locks up in an infinite loop.
Running it in the debugger leads me to a line like:
use POSIX qw( dup dup2 );
in my code. POSIX uses AutoLoader. AutoLoader is looking up
$INC{"POSIX.pm"} and getting one of the CRC32 .pm files:
/tmp/par-barries/cache-2...5/cf1cb7e2.pm
It's then doing
$filename =~ s#^(.*)$pkg\.pm\z#$1auto/$pkg/$func.al#s;
at line 47, where $pkg is POSIX. And failing. Then it spirals in to an
infinite loop because the s/// fails and it re-require()s cf1cb7e2.pm
and tries to go to POSIX::load_imports which, because the s### failed
isn't loaded and viola!, instant infinite loop.
Here's the quick reproducer:
pp -o foo -e 'use POSIX qw( horse_puckey )'
./foo
Thanks,
Barrie
Re: /usr/bin/parl: creation of /tmp/par-barries/.../libperl.so failed - aborting with 2.
On Thu, Jan 29, 2004 at 10:46:20PM -0500, Barrie Slaymaker wrote: > /usr/bin/parl: creation of > /tmp/par-barries/cache-b1a427210984eb4e1eb7feac2f4c904246fc7f9c/libperl.so failed - > aborting with 2. > > Has anyone seen this or have any advice? Blowing away /tmp/par-barries seemed to get me over this hump. Perhaps a permissions error. Next problem in a new email. - Barrie
/usr/bin/parl: creation of /tmp/par-barries/.../libperl.so failed - aborting with 2.
Trying the same (other than the binary name) pp -o vcp-bin -M=... ... bin/vcp command on RH8 that works on Win32 I get: /usr/bin/parl: creation of /tmp/par-barries/cache-b1a427210984eb4e1eb7feac2f4c904246fc7f9c/libperl.so failed - aborting with 2. Has anyone seen this or have any advice? Thanks, Barrie
IO object version 1.20 does not match bootstrap parameter 1.21
I built a vcp.exe using a relatively recent PAR snapshot (which works much better, thanks!) and a VCP user tried to run it on a machine with a different Perl version. He reports bug 4863 I entered a while ago: http://rt.cpan.org/NoAuth/Bug.html?id=4863 I can reproduce it by building a foo.exe like so: pp -o foo.exe foo.pl where foo.pl is: use IO::Handler; print "hi\n"; and running it on a different VM with a different (older) ActiveState perl installed. IO.* are bundled in to foo.exe AFAICS: Z:\HostShare>wzunzip -v foo.exe | grep /IO\. 469 DeflatN317 33% 01/29/2004 22:19 9e5ba568 lib/IO.pm 0 Stored 0 0% 12/09/2003 10:23 lib/auto/IO/IO.bs 24645 DeflatN 5535 78% 12/09/2003 10:24 6e28c4ca lib/auto/IO/IO.dll 696 DeflatN352 50% 12/09/2003 10:24 f9748ddf lib/auto/IO/IO.exp Z:\HostShare> What can I do to help debug this? - Barrie - Forwarded message - Hey Barrie, I synced it down and gave it a go. Here's what I see when I run it: C:\Documents and Settings\yargle>vcp IO object version 1.20 does not match bootstrap parameter 1.21 at C:/Perl/lib/XSLoader.pm line 91. Compilation failed in require at C:/Perl/lib/IO/Handle.pm line 260. BEGIN failed--compilation aborted at C:/Perl/lib/IO/Handle.pm line 260. 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 117. BEGIN failed--compilation aborted at C:/Perl/lib/IO/File.pm line 117. Compilation failed in require at -e line 300. Is it me or is it? =) Would like Perl version info or anything? - End forwarded message -
Re: Problems with pp -M
On Mon, Jan 26, 2004 at 07:04:10PM +0800, Autrijus Tang wrote: > ?b ä, 2004-01-21 22:14, Roderich Schupp ?g?D?G > > Hi, > > there's a problem with "pp -M ...". It shows when you > > compare the result of the following commands > > i.e. the module itself (both pm and dll in case of an XS module) > > is MIA for "pp -M ..." though all modules it depends on are > > there. I can reproduce this on Linux and WinXp (using > > perl 5.8.2, PAR 0.79, Module::Scandeps 0.38 on both platforms). > > Thanks, fixed in depot. I also extended the same fix to Edward's > App::Packer::Backend::PAR here. Oooh, does that mean I can stop patching pp to AddFile( $_ ) for all the -add=Foo files? Thanks! - Barrie
Re: Coderefs in @INC and pre-extraction
On Tue, Jan 27, 2004 at 12:42:12AM +0800, Autrijus Tang wrote: > > > - The %2E is perhaps best left as a "." when not on VMS and the > > filename begins with a non-".". > > - This would make the paths easier to read and work with when > > spelunking around to see what's what. > > I have reservations on that, since PAR names may well contain unsafe > characters like "http://";. Maybe the standard URL escaping rule should > be used, where '.' is a safe char. All I'm proposing here is to not escape safe chars like '.' (%2E). I well understand the need for escapism in general here :). > > - I'm pretending that PAR files only contain lib/...-like > > file trees and that any collisions are ok because they are > > collisions with or without this simplification due to > > normal first-match @INC processing. > > That is an incorrect assumption -- see above for multiarch and recursive > PAR setups. So we will always need a coderef hook to set things up, > and intermediate directories to distinguish the sources. Would't the directory named with the arch name prevent collisions, just like in real multi-arch perl lib dirs? Or are people building different architectures in to the same pathnames and using PAR options to only unpack the appropriate ones? > > > Also -- I dislike needless pre-extraction. It penalize people using > > > many PAR files, some of which may be remote. I can see that files other > > > than .pm and .dll needs to be pre-extracted, though. Would be good > > > enough for you? > > > > I (did) need .pms, because they have POD I want Pod::Usage to find. > > Oh, you need .pm files prior to require() them? I think that is a > relatively unusual demand, but I'm willing to be convinced otherwise. Any POD parsing program may need that sort of thing, for instance to generate a set of documentation that includes libs you haven't require()ed. VCP used to scan for .pm and .pod files using File::Find on grep( -d, map "$_/VCP/Filter", @INC ) to see what HTML to generate. Additionally, VCP uses @INC scanning to implement plugability. By doing the equivalent of: grep -f, map glob "$_/VCP/Filter/*.pm", @INC; it can figure out what plugins are present. Useful for UI work, for instance, to know what options to present. - Barrie
Re: Coderefs in @INC and pre-extraction
Preface: the reason I'm pushing for this is that I have a packager like
PAR that does *not* build .exes but does use the simple expand-first,
ask questions later behavior I'm advocating here. So I have a narrower
set of expectations than other PAR users might. PAR is far superior in
many ways to my packager and I'd like to abandon mine and switch to PAR
completely.
On Mon, Jan 26, 2004 at 11:11:24PM +0800, Autrijus Tang wrote:
> ?b ä, 2004-01-23 19:55, Barrie Slaymaker ?g?D?G
> > What is the advantage of using the CODE refs in @INC?
>
> It makes it easier for people to dynamically add PAR files to @INC,
> which is why PAR exists in the first place.
How is this better than extracting a PAR file to a temp dir and adding
that temp dir to @INC, as you propose below? As long as it happens up
front, it should be transparent. A bit slower perhaps, but only for
large PAR archives.
Another thing I tripped over after writing the original message is that
[EMAIL PROTECTED] is not self-documenting in debug dumps. You can't see
what @INC *really* is by carp( join " ", @INC ), for instance.
> > Is there a disadvantage to just unzipping the packaged files in to a
> > temp dir and putting the appropriate entry in to @INC?
>
> I do not think those two approach needs to be mutually exclusive.
> Actually, I think what we need is, instead of the current scheme of
> creating a temp file for, say, IO::File in file1.par and DBI in
> file2.par:
>
> $PAR_TEMP/abcd0123.pm
> $PAR_TEMP/bcde5432.pm
>
> We ought to use:
>
> $PAR_TEMP/file1%2Epar/IO/File.pm
> $PAR_TEMP/file2%2Epar/DBI.pm
>
> and assign the two subdirectories to @INC, directly before our coderef
> hook. Of course, $INC{'IO/File.pm'} will be a physical file instead of
> a code reference.
Feedback:
- Yeah, baby! That is perfect. I don't think it breaks *any*
assumptions about behavior that existing Perl code makes.
- You would not need to set %INC in PAR (duh), require() would.
- I think this is the safest, conceptually simplest route and
therefore should be the default.
- This would add startup time the first run.
- Should not increase overall run time that much
- Does PAR keep $PAR_TEMP around now unless the clean option is
set?
- That means second and later starts would be very fast.
- The %2E is perhaps best left as a "." when not on VMS and the
filename begins with a non-".".
- This would make the paths easier to read and work with when
spelunking around to see what's what.
- For normal programs, you could elide the file1.par/ and file2.par/
intermediate dirs and just shove $PAR_TEMP on @INC. This
corresponds to exactly what would happen if you were to install
the two PAR archives' contents under $INSTALLSITELIB.
- Pros:
- This would make things simpler in the "normal" case.
- This would speed up @INC searches by both internals and by
scripts.
- Fewer @INC entries
- Lower directory hierarchy to search means faster path
name processing by the OS.
- This would use up fewer characters in the filepaths and
lower the (already minimal) risk of hitting OS path name
limitations.
- Cons:
- I'm pretending that PAR files only contain lib/...-like
file trees and that any collisions are ok because they are
collisions with or without this simplification due to
normal first-match @INC processing.
> Also -- I dislike needless pre-extraction. It penalize people using
> many PAR files, some of which may be remote. I can see that files other
> than .pm and .dll needs to be pre-extracted, though. Would be good
> enough for you?
I (did) need .pms, because they have POD I want Pod::Usage to find.
However, VCP's ok for now, I added a script and Makefile rule to
preextract all POD and subsets of POD and generate lib/VCP/Help.pm from
them with a giant hash and some accessors, and another script and
Makefile rule to build all the HTML. So VCP theoretically no longer
needs Pod::* foo, and thus works well with the current PAR.
I'm still willing to contribute to the cause, will discuss with you
privately.
> The risk is acknowledged. I'd love to hear comments form you and other
> folks about the new scheme outlined above.
See above :)
Digression: Seems like File::Spec could/should grow
File::Spec::*::escape() method that takes a path, runs it through
splitpath() and splitdir(), then escapes the various pieces of the path,
then joins 'em. Too many OSs with different filesystem syntaxes.
> Parl.exe needs only VC6 -- at leas
Expanding to a real dir in @INC [Was: Another sighting of "Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372"]
Ok, I reworked my app to work around the [EMAIL PROTECTED] implementation of PAR, so while I (from the comfort of my armchair) still think avoiding [EMAIL PROTECTED] is a good idea, at least VCP is ok with PAR using it. Thanks for the great app; PAR's a lifesaver. - Barrie
Re: Another sighting of "Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372"
On Wed, Jan 21, 2004 at 11:14:30AM -0500, Barrie Slaymaker wrote:
> On Sun, Jan 11, 2004 at 03:41:15AM +0800, Autrijus Tang wrote:
> >
> > I just gave it a try, and committed a modified PAR.pm to the snapshot
> > version (linked to from http://par.perl.org/). Can you test it a bit to
> > see if it works for you or not?
>
> This looks ok with some basic tests, thanks!
But further testing reveals that this issue is not fixed. One problem
is that the line in PAR.pm:
$INC{$file} = $LastTempFile if (lc($file) =~ /^(?!tk).*\.pm$/);
did not make it in to parl.exe which is not in the snapshot.
But, even without testing it, unless I'm missing some code elsewhere,
this does not allow a program to scan @INC for a lib tree. In order for
programs like VCP to reflect upon the modules bundled with them, the
"low tech" approach of extracting all the lib/... files (at least) in to
a normal lib structure and making @INC contain that structure and no
CODE refs.
What is the advantage of using the CODE refs in @INC?
They're sexy, but they're more complicated, more limited, and probably a
bit slower once the tmp cache is expanded.
Is there a disadvantage to just unzipping the packaged files in to a
temp dir and putting the appropriate entry in to @INC?
Also, I believe the current practice of extracting files to filenames
based on the CRC32 of the file's contents leaves some chance that two
files will have the same CRC and thus end up extracting to the same
filename. Yes the risk is low, but it's present. Matt Sergeant came
across two image files with identical MD5 hashes and that's even less
likely :).
I'd love to implement a PAR.pm patch for this, but I can't seem to get
pp to bundle the XS code for installed modules into a pp -p -B version
of VCP and I don't have VS.net here to compile parl.exe myuself. Maybe
I can figure out how to unpack and repack parl.exe and insert my own
.exe.
Thanks,
Barrie
- Barrie
Re: incompatible features?
On Wed, Jan 21, 2004 at 06:01:08PM -0700, Mike Schroeder wrote:
> a pp generated exe ... not finding LWP::Simple.
Have you tried --add=LWP::Simple? Not sure if it will be found in the
.exe's archive before the remote fetch is done, and I haven't tried that
with LWP::Simple, but I use it here with the following patch to pp.
Autrijus hasn't been able to reproduce the --add failure I see here, so
the patch may not be needed for anyone else.
- Barrie
--- script\pp Tue Jan 06 16:18:50 2004
+++ c:\perl\bin\pp Wed Jan 07 23:31:05 2004
@@ -172,6 +172,8 @@
@Input = grep !/\.pm\z/i, @Input;
+$zip->addFile( $_ ) for @files;
+
$zip->addDirectory('', 'script') if @Input and $] >= 5.008;
my $script_filter = PAR::Filter->new( @{ opt(f) } ) if opt(f);
Re: Another sighting of "Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372"
On Sun, Jan 11, 2004 at 03:41:15AM +0800, Autrijus Tang wrote: > > I just gave it a try, and committed a modified PAR.pm to the snapshot > version (linked to from http://par.perl.org/). Can you test it a bit to > see if it works for you or not? This looks ok with some basic tests, thanks! I still have to add the patch to the pp script that makes it add the files mentioned in --add=Foo::Bar to the archive. Without the patch, Foo::Bar's dependancies get added, but not lib/Foo/Bar.pm. - Barrie
Re: Another sighting of "Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372"
On Sat, Jan 10, 2004 at 01:52:03AM +0800, Autrijus Tang wrote:
> ?b å, 2004-01-08 12:40, Barrie Slaymaker ?g?D?G
> > Below is a quick patch to make --add actuall add the requested file(s)
> > instead of merely scanning it for dependancies.
>
> Wait, --add really works for me. What file(s) failed to --add for you?
> Are they .pm files?
Hopefully it's PEBKAC. Here's what I do and how I'm checking (*lots* of
-adds elided). I'm expecting to see a lib/VCP/DB_File.pm in the
.zip file and neither I nor vcp can find it:
C:\Perforce\VCP>bin\build_vcp_executable.pl
pp -o vcp.exe -lib=lib --add=VCP::ConfigFileUtils ... --add=VCP::DB_File ...
--add=VCP::Utils::vss bin/vcp
C:\Perforce\VCP>wzunzip -v vcp.exe | grep DB_File
4802 DeflatN 1482 70% 01/09/2004 14:14 b942fe2c
lib/VCP/DB_File/big_records.pm
4341 DeflatN 1379 69% 01/09/2004 14:14 161f2ac8 lib/VCP/DB_File/sdbm.pm
C:\Perforce\VCP>.\vcp.exe help
Can't locate VCP/DB_File.pm in @INC (@INC contains: CODE(0xa3dbcc)
CODE(0xd27230) .) at VCP/DB_File/sdbm.pm line 33.
BEGIN failed--compilation aborted at VCP/DB_File/sdbm.pm line 33.
Compilation failed in require at VCP/DB_File/big_records.pm line 62.
BEGIN failed--compilation aborted at VCP/DB_File/big_records.pm line 62.
Compilation failed in require at VCP/Revs.pm line 27.
BEGIN failed--compilation aborted at VCP/Revs.pm line 27.
Compilation failed in require at VCP/Plugin.pm line 34.
BEGIN failed--compilation aborted at VCP/Plugin.pm line 34.
Compilation failed in require at VCP.pm line 31.
Compilation failed in require at script/vcp line 274.
BEGIN failed--compilation aborted at script/vcp line 274.
C:\Perforce\VCP>
You can see the source for DB_File here in case it's a scanner bug:
http://makeashorterlink.com/?Y41032407
> I think one possible way is to force-assign the temp/cache file name
> into the $INC{} hash, instead of their current value of CODE(abcdef).
> How to do that is left as an exercise for the list, or at least until I
> get more tuits. :-)
This is fundable for reasonable amounts of funding. I'll dig in and do
it or you can. My alternative is to simply bundle the files I need
from the disk in to and to have Perl code in vcp.exe extract them as
need be.
> /Autrijus/
- Barrie
Prexisting perl lib conflicts
Looks like my freshly minted perl5.8.2 based vcp.exe is finding an incompatible XSLoader.pm on a test system with a loitering perl5.8.0 install, see below. Renaming C:\Perl works around the problem. Added to rt. - Barrie Z:\HostShare\VCP>perl -v This is perl, v5.8.0 built for MSWin32-x86-multi-thread (with 1 registered patch, see perl -V for more detail) Copyright 1987-2002, Larry Wall Binary build 806 provided by ActiveState Corp. http://www.ActiveState.com Built 00:45:44 Mar 31 2003 Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. Z:\HostShare\VCP>.\vcp.exe IO object version 1.20 does not match bootstrap parameter 1.21 at C:/Perl/lib/XS Loader.pm line 91. Compilation failed in require at C:/Perl/lib/IO/Handle.pm line 260. BEGIN failed--compilation aborted at C:/Perl/lib/IO/Handle.pm line 260. 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 117. BEGIN failed--compilation aborted at C:/Perl/lib/IO/File.pm line 117. Compilation failed in require at -e line 300. Z:\HostShare\VCP>ren c:\Perl Perl.foo Z:\HostShare\VCP>.\vcp.exe This is vcp's text mode interactive user interface. It asks a series of questions and then allows you to save the answers in a configuration file and/or do a conversion based on them. After each question any example free-form input is shown in parentheses. If a default value is available, that is shown in square brackets. You may press 'Enter' to accept the default. For yes/no questions, 'y' or 'n' is sufficient. For non-yes/no multiple choice questions, use the number or enter the entire choice text. vcp may also be provided with all the information it needs on the command line or using a configuration file. To read up on these options, run "vcp help" from the command line after quitting the interactive interface. Source id - A symbolic name for the source repository. This is used to organize the VCP databases and to refer to the source repository in other places. Must consist of a leading letter then letters, numbers, underscores and dashes only. Source id?
Re: Another sighting of "Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372"
On Sun, Dec 28, 2003 at 10:59:41AM +0800, Autrijus Tang wrote:
> å ä, 2003-12-23 11:50, Andy Balaam åéï
> > More info:
> > After reading Autrijus' message here:
> > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00670.html
> > I tried to do what he said:
>
> Thanks for the input, and sorry that I did not reply this earlier.
>
> Can you give 0.76_99 a try? It works on my WinXP home edition here...
Woohoo! That, with perl5.8.2, fixes VCP on WinXP. Many thanks to Andy
and Autrijus!
Below is a quick patch to make --add actuall add the requested file(s)
instead of merely scanning it for dependancies.
I'll need to tackle an "extract all .pm and .pod modules to somewhere in
@INC" behavior to get my online help working (vcp help VCP::Foo scans
@INC for VCP/Foo.{pm,pod} and POD::Texts it). Any guidance about where
to look, what to change?
- Barrie
--- script\pp Tue Jan 06 16:18:50 2004
+++ c:\perl\bin\pp Wed Jan 07 23:31:05 2004
@@ -172,6 +172,8 @@
@Input = grep !/\.pm\z/i, @Input;
+$zip->addFile( $_ ) for @files;
+
$zip->addDirectory('', 'script') if @Input and $] >= 5.008;
my $script_filter = PAR::Filter->new( @{ opt(f) } ) if opt(f);
Re: Another sighting of "Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372"
On Tue, Dec 23, 2003 at 03:14:47AM +, Andy Balaam wrote: > Hi All, > > I'm trying to compile a Perl script > (the XMLTV tools - http://sourceforge.net/projects/xmltv) > into a Win32 executable on Windows XP Home using a custom compiled Perl > 5.8.0 > (compiled with MinGW). I'm using PAR 0.76. > > [Note for those following my previous activity: I gave up on Borland > BCC55 and > am now using MinGW, which has worked well for me - PAR compiles at least.] > > I am getting the same problems that Barrie Slaymaker reported here: > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00423.html Whew! I'm not crazy, and this rules out VMware. It also breaks for me on Win2K. I'll try the Win95 compatibility mode, but until I get to it, you might want to see if this shows any significant or useful differences between the win95 mode or not: http://razor.bindview.com/tools/desc/strace_readme.html I ran it on my foo.exe and noticed that some of the file reads got extra garbage bytes in them (IIRC), but I didn't think to try it on parl.exe. - Barrie
Re: Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372
On Thu, Dec 11, 2003 at 09:12:56AM -0800, Peter Kay wrote: > I apoligise if this message doesn't get posted to the > par mailing list correctly - I'm trying here... Mine seems to have problems running parl.exe in WinXX VMWare and, when it does generate an exectable, the resulting executable has troubles. The resulting executables seem to work on real WinNT and WinXP systems however. I also used strace at one point on the VM-hosted WinXP and it seemed like the executable was reading in strings with extra garbage in them. - Barrie
PAR vs. Pod::Usage
I have an app (VCP) that likes to use Pod::Usage to emit help and that likes to allow access to help topics by scanning @INC for modules and .pod files that contain the docs. It also uses the POD in the modules to insert comments in config files it emits for all the options it places in there. PAR plays subtle and efficient tricks using [EMAIL PROTECTED], but this breaks code like mine. Is there a strategy for generating executables that allows normal @INC behavior using a temp lib directory or some such? Thanks, Barrie
Re: strace diff for: Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372
On Sep 27 2003, Barrie Slaymaker wrote: Here's a diff -U1 between an strace of foo.exe built with: Hit Send too quickly. It's a diff between two runs, one good and one bad. There are a lot of differences in the batch of files it writes, but the killer difference seems to be in around event number 256, in the bad version, a ^C (can't tell if it's really one char or two in the strace output, suspect it's one) sneaks on to the end or the filename "\??\C:\tmp\par_priv.1188.tmp\par.exe" causing an open failure. This is with the perl below. Thanks, Barrie C:\tmp>perl -V Summary of my perl5 (revision 5 version 8 subversion 0) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=define usemultiplicity=def ine useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE - DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_ PERLIO -DPERL_MSVCRT_READFIX', optimize='-MD -Zi -DNDEBUG -O1', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksi ze=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C: \Perl\lib\CORE" -machine:x86' libpth="C:\Perl\lib\CORE" libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32 .lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsoc k32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comd lg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib gnulibc_version='undef' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf - libpath:"C:\Perl\lib\CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_ CONTEXT PERL_IMPLICIT_SYS Locally applied patches: ActivePerl Build 806 Built under MSWin32 Compiled at Mar 31 2003 00:45:44 @INC: C:/Perl/lib C:/Perl/site/lib .
strace diff for: Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372
Here's a diff -U1 between an strace of foo.exe built with:
pp -o foo.exe -e "print STDERR q{Hi\n}"
.
http://users.telerama.com/~rbs/foo_good_and_bad.diff
- Barrie
Re: Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372
On Sep 27 2003, Autrijus Tang wrote: ?b 六, 2003-09-27 17:28, Barrie Slaymaker ?g?D?G > It's a binary install hidden from me by PAR-0.75's Makefile.PL > magic :). Oh. Yes, the prebuilt pardists are indeed compiled with VC++ 6.0 on win2k. I wonder if it'd be better if I change the build platform to WinXP. Dunno; I'm getting failures on Win2K as well, so who knows? I haven't dug in to see what can generate a "Failed to spawn" message with no error. perl.exe must be generating that message, but how can it tell that the spawn failed? The fact that parl.exe and vcp.exe both exhibit this behavior from the command line makes me suspect some kind of very primitive startup issue in the basic .exe. How do those .exes differ from normal C++ .exes? Do you have access to a VC++ there? Not yet, but I can see it in my future. We use Borland tools as much as possible, but I have a client that may want us to port a messaging library to build under both Borland and VC++, not sure. Maybe it's time to seriously investigate switching to MinGW as the default compiler... :) - Barrie
Re: Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372
On Sep 27 2003, Autrijus Tang wrote: Bummer. Having no WinXP here I can't test it at all. However, what version of VC++ are you using to compile parl.exe on WinXP? It's a binary install hidden from me by PAR-0.75's Makefile.PL magic :). - Barrie
Re: Bundling app specific libs with -l?
On Sep 27 2003, Autrijus Tang wrote: ?b 六, 2003-09-27 16:49, Barrie Slaymaker ?g?D?G > > C:\Perforce\VCP>pp -o vcp.exe -l lib bin/vcp > > -l=lib fails too, but --lib=lib seems to work. Now to get all the > lazily loaded modules included :). -I is --lib (as in perl -I). -l is --link. You need a better font. :-) Bingo, thanks. Bloody default fonts in IE. - Barrie
Re: Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372
On Sep 27 2003, Barrie Slaymaker wrote: On Sep 27 2003, Barrie Slaymaker wrote: > pp looks to be very nice, but I can't seem to get parl.exe to load > reliably on WinXPPro, example session below. Any ideas? More info: parl.exe launches reliably on Win2KPro. Spoke too soon. Every once in a while I get the same failure when running pp on Win2KPro. I also get silent, quick exits occasionally when running the generated executable, unfortunately. I'm running both Win2K and WinXP under VMWare, but all other executables seem to load well and run (we run some pretty serious C++ compiles on win2k, for instance). - Barrie
Re: Bundling app specific libs with -l?
C:\Perforce\VCP>pp -o vcp.exe -l lib bin/vcp -l=lib fails too, but --lib=lib seems to work. Now to get all the lazily loaded modules included :). - Barrie
Re: Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372
On Sep 27 2003, Barrie Slaymaker wrote: pp looks to be very nice, but I can't seem to get parl.exe to load reliably on WinXPPro, example session below. Any ideas? More info: parl.exe launches reliably on Win2KPro. - Barrie
Bundling app specific libs with -l?
I'm missing something about how to bundle libs with an executable. Given a standard perl module build where bin/vcp is the script I'm trying to package with no XS and all .pms are in lib/..., I tried the below. Sorry if I'm missing the bloody obvious. - Barrie C:\Perforce\VCP>pp -o vcp.exe -l lib bin/vcp C:\Perforce\VCP>vcp.exe Can't locate VCP/Logger.pm in @INC (@INC contains: CODE(0xc29a14) CODE(0xd152f0) .) at script/vcp line 271. BEGIN failed--compilation aborted at script/vcp line 271.
Can't spawn parl.exe: No error at c:\Perl\bin\pp line 372
pp looks to be very nice, but I can't seem to get parl.exe to load reliably on WinXPPro, example session below. Any ideas? Thanks, Barrie C:\Perforce\VCP>parl C:\Perforce\VCP>parl C:\Perforce\VCP>parl C:\Perforce\VCP>parl C:\Perforce\VCP>pp -o vcp.exe bin/vcp Can't spawn "C:\Perl\bin\parl.exe": No error at C:\Perl\bin\pp line 372. C:\Perforce\VCP>parl C:\Perforce\VCP>parl Usage: C:\Perl\bin\parl.exe [ -Alib.par ] [ -Idir ] [ -Mmodule ] [ src.par ] [ p rogram.pl ] C:\Perl\bin\parl.exe [ -B|-b ] [-Ooutfile] src.par C:\Perforce\VCP>pp -o vcp.exe bin/vcp C:\Perforce\VCP>vcp.exe Can't locate VCP/Logger.pm in @INC (@INC contains: CODE(0xc29844) CODE(0xd151e0) .) at script/vcp line 271. BEGIN failed--compilation aborted at script/vcp line 271.
