> On Tue, Feb 08, 2005 at 11:26:55AM -0800, Peter Mueller wrote:
>># perlcc sanitizer.pl -o sanitizer
>>/tmp/ccZDnQzM.o: In function `dl_init':
>>/tmp/ccZDnQzM.o(.text+0x114da8): undefined reference to `boot_MIME__Base64'
>>/tmp/ccZDnQzM.o(.text+0x114e5e): undefined reference to `boot_Digest__MD5'
>>collect2: ld returned 1 exit status
> yep, same on a Debian 3.x system; but I doubt the perlcc-reduced binary
> would be much better than the plain .pl: I tried
> perlcc sanitizer.pl -o sanitizer.c -c
> and got a ~7MB sanitizer.c (!)
> which - just for fun - I tried to gcc-compile; on a 512MB RAM + 256 MB swap
> pc gcc got killed due to vm exhaustion. Then I tried with +1GB swapfile
> but got endless list of unreferences.
> perlcc might do a better job doing the binary directly, but it got stuck
> as above despite any -I, -L I tried. So I gave up.
Yep... Perl's compiler is still experimental. I wouldn't try it with
versions less than perl 5.8. Anyway, the point of compiling is to
reduce perl's startup overhead, which translates to lower load average
and processing time per message. You can reduce the size of the binary
a little using "strip".
I have several sparc solaris 8 systems using sanitizer.pl compiled
with perl 5.8.0 and it works flawlessly.
What's really needed to reduce sanitizer's overhead is a daemonized
version (how about it, Bjarni? ;-). Once perl gets running it's very
fast but the startup overhead is a killer. Short of rewriting the
sanitizer as a daemon, Persistent Perl
(http://daemoninc.com/PersistentPerl/) seems to work. It's originally
designed for perl CGI scripts, but I've also used it with Sanitizer.
Your mileage will vary.
-- Derrick Webber Advosys Consulting Inc. Ottawa http://advosys.ca/ --