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/XXXXXXXXXXXXXX > - 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
