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
