but i need something that is stable

They're all stable, but none of them are compilers

I have always heard if you are on Linux and compile on Linux then your compiled code will not run on windows.

Yeah, that is how it works. There is such things as cross compilers and virtual machines, so you can compile for a different platform by running such a platform

I like http://CavaPackager.com/ and http://CitrusPerl.com

The Perl-interpreter is needed to run Perl-code.
Typically, the interpreter is written in C.
There are different versions of the interpreter, some for Linux, others for Windows.
As the Perl-script runs on top of the interpreter, it is platform-independent, but the interpreter itself isn't.

perl2exe, PAR and others extract the files from the interpreter which are needed to run the script and put it all together into some code-package.
That's the way, they make the program seemingly independent from the interpreter: They supply the interpreter-parts (taken from the installed version of the interpreter) together with the script.

They do not compile the Perl-script to C or something.
If you wonder, why they don't, take a look at this article:

http://www.perl.com/pub/2001/06/27/ctoperl.html

Cheers

Others told you that there is no Perl compiler. There are some packagers, and they all suck, some more, some less. Using them for security is a really stupid idea. (See also Re: Protection for Perl Scripts and Re^2: Where should I have configuration information in a file or database.)

Using them to deliver an application is simply stupid, for reasons you have explained yourself: You are limited to a single combination of platform. If your clients use a mix of 32 and 64 bit systems running *BSD, Solaris, various Linux distrubutions, Windows, MacOS X, you have to build a separate bundle for each of these systems, and for all packagers I know (remotely), you need to have a working instance of the target system.

In contrast, deliver a cpan-installable source archive (*.tar.gz), make the cpan utility install the sources, and you are done with a single archive for all platforms. For systems that lack a sane perl installation (Windows), deliver or point your users to a perl installer for their system. The Java folks handle the problem in nearly the same way. You are expected to install a JRE version, unless your system already includes one. Only after that, you may use Java-based applications. Some software packages come with an installer that installs the JRE more or less silently, so the user does not have to install the JRE separately.

Of course, you can also omit using the cpan utility and use a DIY installer script. Bugzilla takes this way (checksetup.pl), and I did something similar some years ago.

Alexander

In contrast, deliver a cpan-installable source archive (*.tar.gz), make the cpan utility install the sources, and you are done with a single archive for all platforms.

In theory -- because in practice it is not that simple, folks invented various packagers, to make deployment as painless as possible

"Others told you that there is no Perl compiler"

Actually, there is... B::C. Prior to 5.10 it was distributed alongside Perl. It's never been especially reliable, but it works in some cases.

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

I am ok with installing active state and compiling there as well.

The ActiveState tool will cost some bucks. It doesn't compile to ASM code or C code or anything like that. It can make an executable image for a platform. I haven't done it myself, but the tool can make a Unix image on a Windows platform, etc. (or so I hear). But you are into making an image per platform...and that's a hassle.

I use this to distribute Windows programs for folks who know nothing of Perl and don't have it on their systems. This will not protect your source code although breaking the ActiveState encryption in the latest versions is "non- trivial". The open source "packers" are far easier to "break". Basically, I use PerlApp to deliver a .exe file to folks who don't even know what Perl is. And it works great for that. I don't expect it to protect my source code or run faster (its actually a bit slower). I do it that way because it is a single file that is easy to use.

It can make an executable image for a platform. I haven't done it myself, but the tool can make a Unix image on a Windows platform, etc. (or so I hear).

A single image for all Unixes? I highly doubt that. Building a single image "just" for all Linuxes out there is at least hard, if not impossible. Just look at the various CPUs Linux can run on, not to mention libc versions, processor optimized code, and so on.

Also, ActiveState lists only Windows, Linux, Mac OS X in the free edition, plus Solaris, HP-UX and AIX in the commercial editions. Where are the BSDs? SCO? Minix? All those legacy Unixes?

It might be a fun or research project to write a single executable that can run "just" on all CPUs Linux supports. For some people, it might be even more fun to make that executable run on non-Linux systems. But those won't end in a commercial project, simply because the resulting executable has to be ridiculously large to contain binary code for all the different platforms. See also fat binary, FatELF. Note that ELF is just one of many executable formats, FatELF files won't work on systems that can't execute ELF files.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)