(Oops, forgot to add PMQS to Cc. Sending again. Sorry for the dupe.) On Mon, Oct 20, 2003 at 03:13:22PM +0200, Markus Jansen wrote: > >On Fri, 2003-10-17 at 15:31, [EMAIL PROTECTED] wrote: > >Actually, executing a PAR-packed exe works like this - > >Autrijus correct me if I got this wrong: > > > >(1) exe creates a temp directory > >(2) exe writes to files into this temp directory: > > the shared perl library (e.g. libperl.so) and a small executable > > called par; these files get extracted from C char[] arrays inside > > the executable > >(3) exec then sets LD_LIBRARY_PATH to the temp direcctory and execs par > > with one argument: the name of the executable > >(4) par is actually a mini-perl (linked against libperl.so), that > > does some stuff in C, then eval's a Perl script contained in par > >(5) this script extracts all modules that a required for PAR.pm to work > > from the executable; the script can't use any modules > > > >The problem is (5) above: PAR.pm uses Archive::Zip which uses > >Compress::Zlib which has ashared library Zlib.so that links to > >libz.so. Everything is there EXCEPT libz.so.
<snip> This is entirely correct. May I re-use it in the documentations? :-) > my ultimate solution to this clash so far was to build Zlib.so with > all .o files from libz.so around, and modifying the Makefile a little bit > (I think there is also a lately added option in Compress::Zlib to build > libz in the same run (of course only if it cannot be found), but I have not > tried this). This way I get a self-contained Zlib.so. > > But of course you are right, the problem should be addressed from the PAR side. (Cc'ing Paul Marquess, author of Compress::Zlib) Maybe the solution would be a Compress::Zlib::Static, which is just like Compress::Zlib but is guaranteed to statically link zlib inside, so we can safely distribute it to machines without zlib. Paul, do you think it is feasible, or is there a better way? Thanks, /Autrijus/
pgp00000.pgp
Description: PGP signature
