Perl FAQ 3.5

The short answer is: ``No, you can't compile perl into C. Period.''

However, having said that, it is believed that it would be possible to write a perl to C translator, although it is a PhD thesis waiting to happen. Anyone need a good challenging thesis?

In the way of further, detailed explication, it seems that the reasons people want to do this usaully break down into one or more of the following:

1. speed
2. secrecy
3. maintainability

1. SPEED:
   1. You can't turn perl source code or perl intermediary code into native machine code to make it run faster, and saving the perl intermediary code doesn't really buy you as much as you'd like. If you really must, check out the undump and unexec alternatives. If your motivations are speed, then this may or may not help you much.

      You might also look into autoloading functions on the fly, which can greatly reduce start-up time.

   2. If you have a few routines that are bogging you down, you just possibly might wish to hand-translate just them into C, then dynamically load these in. See perlapi(1) for details. Most of the time, however, reorganizing your perl algorithm is the best way to address this.

2. SOURCE-CODE SECRECY:
   1. If you're trying to stop people from seeing what you're doing, you can shroud it, i.e. turn all the idents into silly stuff, rearrange strings, and remove redundant white space. There's a program out there called ShroudIt! that works on a number of languages, including Perl. Note that it is a commercial product though. Contact David Webber (webber@lnk.com) for more information.
   2. You might also look into the cryptswitch() stuff in the perl source, which would allow you to ship something in a form they can't read. This isn't particulary well-documented.

   3. If you're worried about them using your software without licence, you put some huge disclaimer at the top that says something like the following. This is actually the best solution, because only a legal solution will really work if legality is what you're worried about: trying to solve legal problems with technical solutions is not worth the effort, and too easily circumvented.

      This is UNPUBLISHED PROPRIETARY SOURCE CODE of XYZZY, Inc.; the contents of this file may not be disclosed to third parties, copied or duplicated in any form, in whole or in part, without the prior written permission of XYZZY, Inc.

      Permission is hereby granted soley to the licencee for use of this source code in its unaltered state. This source code may not be modified by licencee except under direction of XYZZY Inc. Neither may this source code be given under any circumstances to non-licensees in any form, including source or binary. Modification of this source constitutes breach of contract, which voids any potential pending support responsibilities by XYZZY Inc. Divulging the exact or paraphrased contents of this source code to unlicensed parties either directly or indirectly constitutes violation of federal and international copyright and trade secret laws, and will be duly prosecuted to the fullest extent permitted under law.

      This software is provided by XYZZY Inc. ``as is'' and any express or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the regents or contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this software, even if advised of the possibility of such damage.

3. MAINTAINABILITY:
   1. If you just want to stop people from changing it because you're concerned about support issues, you can put in a big disclaimer at the top that says that if they touch the file they void the warranty, and then make them give you a size, checksum, and version of the file before answering any questions about it.

      If you maintain a central site that distributes software to internal client machines, use rdist(1) to send around a proper version periodically, perhaps using the -y option on the install to flag destinations younger than the source.

      Let it be noted than in the many, many years that Perl's author has been releasing and supporting freely redistributable software, he has NEVER ONCE been bitten by a bogus bug report generated by someone breaking his code because they had access to it. Rather, he and many other open software provided (where open software means that for which the source is provided, the only truly open software) have saved themselves countless hours of labor thousands of times over because they've allowed people to inspect the source for themselves. Proprietary source-code hoarding is its own headache.

      Thus, obscurity for the sake of maintainability would seem to be a red herring.

   2. If you can't count on perl being installed at the destination customer, then by all means, merely ship it with your program. This is no hardship, since software providers are accustomed to shipping software in machine-specific binary form. The basic idea is as simple as:

      
      shar /usr/local/{lib,bin,man}/perl myprog
      
      

      Just don't overwrite their own Perl installation if they have one!

• Return to Perl FAQ index.
• Return to MoxPerl Home Page.
• Send mail to Tom Christiansen.