All the mentioned perlmonk nodes point out that it's best not to compile code and instead use an interpreter; I agree with this point entirely. My question is more about whether perlcc is still supported and what people ended up doing in the past 5-6 years since they wanted to compile their perl code.

I googled PerlCC and doom the second item in the list is the perlmonk node Compiling Perl? (circa 2000). I didn't really expect perlcc and doom to have any correlation; but then again, that's why I'm posting this question.

perlcc, the byteloader and the supporting modules (B::C, B::CC, B::Bytecode, etc.) are no longer distributed with the perl sources. Those experimental tools have never worked reliably, and, due to the lack of volunteers to keep them in line with the perl interpreter developments, it was decided to remove them instead of shipping a broken version of those. The last version of those modules can be found with perl 5.9.4.

However the B compiler framework stays supported in the perl core, as with the more useful modules it has permitted (among others, B::Deparse and B::Concise).

I actually use perlcc for a project I'm working on. The environment is tinycore 4.7 x86 and the version of perl there (which appears to be 5.14!) seems to work very well with perlcc. I have had absolutely no problems compiling and running on various x86 systems (using CFLAGs for generic x86 architecture).
As I recall, I just installed the module manually... and it worked.

Wasn't part of the reason that nobody was maintaining it was because it was meant to be a way to start a Perl script faster that turned out to be much slower? So even when you didn't run into a bug, it was slow enough to be of little value. If somebody wanted it as a way to hide source code, then the existence of B::Deparse likely makes it at least much less than foolproof.

So I thought it was an interesting idea that turned out to be rather useless and hard to maintain so it was no surprise that it wasn't maintained. But I only ever paid peripheral attention to it.

Hi ,
My aim is to hide the perl code from end user and I am looking at either of the options of encrypting it or converting to some executable.perlcc is showing some errors in my case .perl2exe doesn't provide any licence (in free version) ,so I can't use at company level.
Can any monk provide some pointers ,how to go about from here i.e. either tweaking with perlcc to make it work or some other tool !!
Thnx

I really cannot think of a good reason why someone would want to hide their Perl source code. Certainly any hacker who would take the time to study someone else's Perl algorithms (since they are done at such a high-level anyway) in order to reverse-engineer the solution would already possess the ability to code it originally.

The only code that I ever felt necessary to hide would be machine-specific assembler stuff, but even that runs contrary to my Open Source philosophy.

That's nothing at all like perlcc. perlcc stored compiled Perl code, possibly in a machine-independent manner. Rather than a working perlcc, you seem to want an obfuscation tool.

Your tool fails at obfuscation too. The first thing the generated program does is decode the entire script into one variable. Dump that variable, and the source is recovered.

No attempts whatsoever at obfuscation are attempted except for the option to use Acme::Bleach on the source. That means, your tool is just a very restrictive version of Acme::Bleach. Why not just use Acme::Bleach?

"No attempts whatsoever at obfuscation are attempted
except for the option to use Acme::Bleach"

False. Source code is also obfuscated using a simple key to avoid extracting the string from the executable.

"Dump that variable, and the source is recovered."

And how would they do that?

Yes, if they know how to run a debugger on an executable that is compiled without debugging symbols and can figure out how to get the data out of that symbol, then they can get your source. Do you know how to do that?

And regardless, I refer you to the perlc page itself which states:

Ignoring the practicality of hiding the code in most situations just because someone can get the code is like deciding to not lock your house anymore, just because locks can be picked.

Yes. Someone can get in. That doesn't mean there is no reason to try to make it difficult. I'm glad that you are (possibly) clever enough to get the data out of a perlc obfuscated program. Most people are not.

Again, if you don't want to use an obfuscator than don't. Many people find them useful. You may find them foolish. Some people may think it's foolish to lock your house up. That's fine as well.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other