Hi list,
after some discussion with Roderich, I dove into the PAR::Packer sources
and changed some rather integral parts. Here's what happened:
- We had lots of bugs due to XS modules being built into 'parl' being
insufficient for the packaged code (Scalar::Util::refaddr()) or
incompatible
Me again!
Steffen Mueller schrieb:
I'm going to commit these changes to SVN now. I strongly urge all of you
to test these changes thoroughly. They're somewhat extensive and I would
hate if the blew up in my face when I make the 0.958 release.
For your information, I have just tested these
On Mon, 2006-11-06 at 14:38 +0100, Steffen Mueller wrote:
Roderich Schupp schrieb:
[...]
You could try what happens for system() (don't remember). If system()
doesn't
flash a DOS box with --gui, you could replace the backticks by using
IPC::Run3 (that allows you to catch stdout/stderr
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
Glenn Linderman schrieb:
[...]
So most of the extra run-time cost of pp in the above sequence could be
eliminated by doing it at installation time, or at a later re-run this
if you upgrade XS modules. If this sort of packaging of the build time
works for all pre-built installation
I created an application that uses DBD::MySQL. I add the MySQL client
library to the PAR with '-l
/opt/mysql/lib/mysql/libmysqlclient.so.15'. When I do the 'pp' on my
Solaris 8 system the executable runs and completes without issue,
however, when I do the same command line on Linux, things get
