Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll
Tue Jun 01 05:01:25 2010: Request 57948 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Packer Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll Broken in: (no value) Severity: (no value) Owner: RSCHUPP Requestors: m...@iki.fi Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=57948 RSCHUPP via RT wrote: Queue: PAR-Packer Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=57948 On Sun May 30 08:20:47 2010, mark.doot...@znix.com wrote: I don't think you can mix and match your linking model on Windows. So if you had a static perl.exe (or par.exe) you could not then load separate xs code dynamically - you would have to compile in all the xs modules you require. That's why, by default, you don't get a static perl built on MSWin. It is not generally useful. Thanks for the explanation, Mark. I'll hold my nose and try the load_me_3 approach then, stay tuned. Hey, I survived modifying the load_me stuff, too! But I probably have lower standards :) More seriously, I'm pretty sure you already know how it works, but it's just a vehicle of embedding an arbitrary file as a variable in C code extracting it when run. I believe I refactored some of it to be slightly less insane a few years back. It's still totally a kludge, but alas, I don't have a good idea of how we could work around it. Except that statically linking a libz for some minor compression and reduction of the executable file size would be really cool. Not saying *you* should do that, mind you. Cheers, Steffen
Re: compressed loadme
Hi all, Steffen Mueller via RT wrote: Except that statically linking a libz for some minor compression and reduction of the executable file size would be really cool. Not saying *you* should do that, mind you. I thought about this some more and did some experimenting. a) par.pl can't be (simply) compressed because its string is used in the signature generation, it seems. b) Just compressing libperl roughly halves the size of the resulting Hello World executable. We could save even more if we had to include another library (cf. the recent bug report). In my experiment, I got as far as finding the right libz options for static and dynamic linking, telling file2c to do compression, compressing the output in file2c using Compress::Zlib, and marking the binary blob in the resulting C code as compressed. I just read up on the zlib C interface and while it's conceptually the same as Compress::Zlib (surprise), it shows that C is a horrible language and my C even more so. That is to say it's too annoying to serve as a distraction from more important work, so I'll punt for now. I guess the only difficult part that remains to be done is to modify the WRITE_* macros that are generated by file2c so that they take into account the compression. This seems difficult only because of the obscure chunk logic. If anybody else would like to get a copy of my changes, let me know. I simply didn't commit them in a branch since they're really quite hackish. Cheers, Steffen
Re: compressed loadme
On Wed, Jun 2, 2010 at 3:58 PM, Steffen Mueller smuel...@cpan.org wrote: b) Just compressing libperl roughly halves the size of the resulting Hello World executable. Yes, I did some experiments, too :) We could save even more if we had to include another library (cf. the recent bug report). Though libgcc_s is pretty small (e.g. 87 KB on x86_64). I guess the only difficult part that remains to be done is to modify the WRITE_* macros that are generated by file2c so that they take into account the compression. This seems difficult only because of the obscure chunk logic. Actually no. The chunk stuff is very easily adapted when using zlib's inflateBack() interface. I just took the gun.c example from zlib's tarball and tweaked file2c.pl a little and bingo: I can decompress from file2c.pl generated chunks to an open file descriptor with very little code. I could easily shave off some more lines of code if I somehow omit the gzip header information from the chunks. (I created the chunks simply by reading from gzip -c input-file) Also we can steal the howto-build-zlib-from-source from the Compress::Raw::Zlib distribution. But first things first: I'll unbreak PAR::Packer for Strawberry 5.12 by adding another load_me item for libgcc_s. Cheers, Roderich
'pp' is not recognized as an internal or external command.
Hi,
I have developed a perl application by using ActiveState PDK with trial
version.This is not helping us for longer usage.
Now I'm trying to create a Standalone Executables using PAR in windows xp.
I have installed PAR by using *PPM install PAR* command. And I have ensured
the PAR version by using *perl -MPAR -e print
PAR-VERSION.qq{\n};*command which also gave the version as 1.000.
After that i tried to create a exe by using command *pp -o hello.exe
hello.pl*. then i got the error as 'pp' is not recognized as an internal or
external command.
and then I tried to find the PP file in my hard disk which is not available.
Could you please advice me how to proceed furture?
Thanks in Advance!!
Regards
Ramesh Kasimani
--
Efforts may Fail, But don't Fail to make efforts
