Hi Glenn,
instead of replying to each point, I'll write a coherent reply. I hope
you don't mind.
It mostly boils down to this valid question Glenn asked:
> If the stripped parl has a chance of working when executed
> by pp, why would in not be able to work in all cases of
> execution?
Let me put the long answer to this:
A pp-ed binary is basically:
- Some C loading code + a modified perl ==> parl
- PAR (or rather par.pl!) and its dependencies embedded into the above
==> stand-alone parl
- A .par file appended to the above ==> standalone program
Executing this, the first stage extracts the second and uses it to load
the third. Removing the second part (par.pl and friends) should stop it
from working as expected. That's what I'm seeing on win32 but not on
linux. Why? Bear with me:
Roderich and I tried using a parl without the second part on linux. It
worked just fine. For the reasons laid out above, it shouldn't have, but
it did anyway. So I tried it out and implemented the new behaviour.
Understanding what happens during make() in myldr/ was a good part of
the work involved. That's not lost.
The experiment worked flawlessly on my linux. Why? Because parl==perl+C
has @INC paths compiled into it. It picked up stuff from my installed
perl. I don't mind that, of course, for uses of parl via pp which
happens on a fully configured perl at all times. When building
executables from parl+C+.par but without par.pl+dependencies and running
these executables on the same system, parl *still* picked out the
dependencies from my system. Here is my big, big error. I didn't expect
it to. I recently changed the code in the packaged "main.pl" so that
@INC is cleared if you recall. parl picks up the libs, then runs a new
interpreter for main.pl which clears *only its own @INC* and runs the
user code. Hence the user code doesn't see the hardwired @INC, but parl
does.
This is also the reason things blew up on win32: perl doesn't have
hardcoded @INC there.
So. The easy way doesn't work. I can either do the embedding of the
par.pl+deps code into parl for every pp call or I can roll back svn to
the state a few commits ago and call it a broken experiment.
I'm not sure how practical the former is. I'd have to think that through
(this time for real).
Steffen
P.S: Now that you bore with me, I can tell you the short answer: I
expected parl not to have perl's compiled-in @INC because I removed it
in main.pl. I was wrong.
